<p>You can defiintely cook up promise problems where RAM is much stronger.  Of course it's weird because you have to actually phrase your problems in terms of comparisons. suppose your memory is initialised into a permtuation, i.e. with memory registers x(1), ..., x(n) taking on the values 1, .., n exactly once each.    The problem is to compute the # of i s.t. x(i) &lt; x(1).</p>

CC BY-SA 3.0
2012-07-05T18:24:52.167Z
That is nice. The query doesn't actually tell you anything about the input other than queried item itself which is curious.
Simd
CC BY-SA 3.0
2012-07-05T15:37:35.250Z
2012-07-05T15:37:35.250Z
Aram Harrow
<p>I have been wondering about comparison versus RAM models and have some very basic sounding questions.  </p>

<p>Is there a name for the subset of P (or FP really) that is computable by comparison RAM algorithms? For the avoidance of confusion we can think of the comparison RAM model as just being the normal RAM model where the input symbols are given in terms of rows/columns of a ternary matrix that tells us if pairs of symbols are bigger, the same, or smaller.  That is we never get to find out or use the value of the input symbols.</p>

<p>What are the biggest known gaps for the time complexity of RAM and comparison RAM algorithms for natural problems coming from this subset of P (or FP)? We can imagine unnatural examples where comparisons are constant time but the RAM model has to spend a lot of time inputting the bits.  Those are not the ones I am interested in.  Sorting is the simplest example with a log gap for poly size inputs but is there anything bigger?</p>

<p>Related to the last question, is there some reason to suppose a maximum gap between (natural) RAM and comparison RAM problems? I suppose one route would be to say that you could simulate one with the other efficiently.</p>

CC BY-SA 3.0
2012-07-05T03:47:02.130Z
A potential question of interest: [Examples of the price of abstraction?](http://cstheory.stackexchange.com/q/608/1037)
Artem Kaznatcheev
<cc.complexity-theory><reference-request><complexity-classes>
Comparison versus RAM models
Simd
# Comparison versus RAM models

(Asked by: username_0 on 2012-07-05)

I have been wondering about comparison versus RAM models and have some very basic sounding questions.

Is there a name for the subset of P (or FP really) that is computable by comparison RAM algorithms? For the avoidance of confusion we can think of the comparison RAM model as just being the normal RAM model where the input symbols are given in terms of rows/columns of a ternary matrix that tells us if pairs of symbols are bigger, the same, or smaller. That is we never get to find out or use the value of the input symbols.

What are the biggest known gaps for the time complexity of RAM and comparison RAM algorithms for natural problems coming from this subset of P (or FP)? We can imagine unnatural examples where comparisons are constant time but the RAM model has to spend a lot of time inputting the bits. Those are not the ones I am interested in. Sorting is the simplest example with a log gap for poly size inputs but is there anything bigger?

Related to the last question, is there some reason to suppose a maximum gap between (natural) RAM and comparison RAM problems? I suppose one route would be to say that you could simulate one with the other efficiently.

**Tags:** cc.complexity-theory, reference-request, complexity-classes
> **Comments:**
> **username_1**: A potential question of interest: [Examples of the price of abstraction?](http://cstheory.stackexchange.com/q/608/1037)  

---

## 1 answers

### Answer by username_2 on 2012-07-05. Score: 6

You can defiintely cook up promise problems where RAM is much stronger. Of course it's weird because you have to actually phrase your problems in terms of comparisons. suppose your memory is initialised into a permtuation, i.e. with memory registers x(1), ..., x(n) taking on the values 1, .., n exactly once each. The problem is to compute the # of i s.t. x(i) < x(1).

> **Comments:**
> **username_0**: That is nice. The query doesn't actually tell you anything about the input other than queried item itself which is curious.  

---

