Re: More benchmark bullshit, and Linux luser mating calls... (was Re: Linux betas NT in TPC testing, running Oracle8

On Sat, 01 May 1999 12:39:19 GMT, cbbrowne_at_news.brownes.org (Christopher B. Browne) wrote:

>On Sat, 01 May 1999 08:37:12 GMT, Anthony Ord
><nws_at_rollingthunder.demon.co.uk> posted:
>>On Fri, 30 Apr 1999 04:12:03 GMT, cbbrowne_at_news.brownes.org
>>(Christopher B. Browne) wrote:
>>
>>>On Thu, 29 Apr 1999 17:22:05 GMT, Anthony Ord
>>><nws_at_rollingthunder.demon.co.uk> posted:
>>>>On Wed, 28 Apr 1999 00:20:45 GMT, cbbrowne_at_news.hex.net
>>>>(Christopher Browne) wrote:
>>>>
>>>>>On 27 Apr 99 21:58:41 GMT, David Brower <dbrower_at_us.oracle.com> wrote:
>>>>>>nws_at_rollingthunder.demon.co.uk (Anthony Ord) writes:
>>>>>>>>How can pointers in structures be naughty?
>>>>>>
>>>>>>>Can someone point out how to do linked lists and binary

                                       ^^^^^^^^^^^^
***************************************************


>>>>>>>trees without them?

We are talking about simulating linked-lists (binary trees got dropped somewhere) using arrays in order to avoid pointers. (see above).

>>512->714->986 and you delete the entry such that your linked
>>list is now 512->986. If it is an array, then 714 is still
>>there. Alive, yet not alive (like Leonard Cohen).
>>
>>>There are two reasonable ways for what you're saying to be expressed
>>>in Scheme, which calls arrays "vectors."
>>>
>>>a) I might delete the *contents* of entry 714.
>>>
>>>(define V (make-vector 800 'a))
>>>(define V (do-things-to-vector V))
>>>(vector-set! V 714 #f) ; Nuke entry 714
>>>
>>>In this case, all that happens is that the entry is empty. Neither
>>>Captain SEGV nor runtime system would flag an error at a reference to
>>>entry #714:
>>
>>Which is not very good.
>
>That's arguable; the really important point is that *neither* scheme
>is inherently better at finding the "error."

If you free no 714 then try to access it with a pointer you should get a SEGV (sometimes).

>Note that the reference to entry #714...
>
>>>(vector-ref V 714)
>>>#f
>
>... works fine. The entry happens to be empty, which may confuse a
>buggy program, but isn't something that can be analytically determined
>to be wrong.
>
>>>The program may freak at #f, but that's not a pointer problem, at
>>>least not one relating to the vector V.
>>>
>>>b) I might decide to resize the vector to some smaller size.
>>>
>>>There's not a standard R5RS call for this, but it might be done like:
>>>(define V (make-vector 800 'a))
>>>(define V (do-things-to-vector V))
>>>(define V (vector-resize V 700)) ; Nuke the last hundred entries
>>>
>>>At this point, a reference to the 714th entry returns something like:
>>>(vector-ref v 714)
>>>ERROR: In procedure vector-ref in expression (vector-ref v 800):
>>>ERROR: Argument out of range: 800
>>>ABORT: (out-of-range)
>>>
>>>Which is nicely trapped by the runtime system.
>>
>>But it only works if the stuff you delete is off the end.
>
>Well, the only part of an array that can "go missing" is a part that
>is off the end, in one direction or another.

Exactly.

>>>Or are you thinking about some other data structure, such as a list,
>>>or an associative array, both of which are capable of being used to
>>>simulate arrays?
>>
>>No. I'm thinking about a linked list being simulated by an
>>array. (for the sole purpose of avoiding pointers).
>
>There's no point to the attempt to "avoid pointers."

I agree.

>Supposing you use an array to implement a linked list, and do
>something like:
>
>(define DV (make-vector 900 #f)) ; Data Vector
>(define PV (make-vector 900 #f)) ; Pointer Vector
>(vector-set! PV 1 714) ; Entry #1 is followed by #714
>(vector-set! PV 714 850) ; Entry #714 is followed by #850
>(vector-set! PV 850 200) ; Entry #850 is followed by #200
>;;;; And one would probably want to put data into DV for
>;;;; entries 1, 714, 850, 200...

A more mainstream language would have been better. Visual Basic?

;-)

>The fact that the information being visibly manipulated doesn't
>represent direct memory references does not diminish the fact that all
>the entries in PV are still pointers, from a logical perspective, if
>not from a "physical" perspective.

Yep

>[And behind the scenes, the Scheme environment winds up doing a whole
>*lot* of pointer ops in order to get at the data...]

Oh yes.

Regards

Anthony

-- 
-----------------------------------------
| And when our worlds                   |
| They fall apart                       |
| When the walls come tumbling in       |
| Though we may deserve it              |
| It will be worth it  - Depeche Mode   |
-----------------------------------------