1. Re: [E - 6 to 7 Jun 1997] Sub'ing seqs with seqs

> Anders Eurenius <c96aes at OXE.CS.UMU.SE> writes...

>>Thank you. The way I'm figuring it, sequences are stored as linked lists. The
>>node-type is some kind of datatype tag (as prolly all objects have)
>>in addition to the actual data (pointer to next node, integer,
>>whatever). If so, making trees (and such) tricky would really feel
>>pretty stupid...

>  You may be right - but the actual method of storage turns out
>  to be irrelevant, since you (the Euphoria programmer) can't
>  take advantage of it in any sensible way - Euphoria is
>  _strictly_ and _universally_ call by value from your point of
>  view, even though Robert has written it to handle actual
>  storage efficiently.  As far as you're concerned, it doesn't
>  matter whether the actual implementation is more akin to your
>  description or to a simple array - to you, it looks like an
>  array.  Period.

Yeah... I know... It's just that I've been breaking my head on pointers, and I
have a pretty exact picture of what I want, an' I can't have it! I guess, If I
want to play speed demon, I'll have use another language. (And battle it out
with it's compilers... ;-( )

>  Robert's position is that if you can accomplish the same aims
>  using the existing Euphoria capabilities, there's no reason to
>  add more syntax oddities - and this idea is, quite honestly,
>  "oddity-er" than most.

Yeah... I can relate to that...

>  I've written a set of routines that
>  implements the "Zeitlin/APL" idea, and one that implements the
>  associative table/array idea.  They're available from the
>  Euphoria home page, but don't download them yet; wait for
>  Robert to announce that he's received the revised package I'm
>  sending simultaneously with this message.

>>> 1. Jeff Zeitlin's idea (it's done like this in APL):
>>>     s[{a,b,c}] is {s[a],s[b],s[c]}
>>Kinky! Hey Jeff! Does it do any cool tricks?

>  Well, I've implemented this with a function, rather than
>  preprocessing this syntax, so you actually call it as
>  xslice(s,{a,b,c}).  It allows you to take non-sequential
>  elements, and they don't have to be in ascending index order.
>  The operational structure of the routine should be fairly
>  obvious; I loop on the sequence (call it k) and build up and
>  eventually return a sequence consisting of all the elements
>  s[k[i]], i=1..length(k).

Sure. Ok. But what happens when you want to write into it?
Again: Does do any kinky tricks? All I can see is simplified subscripting...

>  I've implemented this (see my file assoc.e - the revised one,
>  which works); it's actually a three-element sequence: the first
>  element is the user-definable default (which defaults to an
>  empty sequence), the second element is a sequence where each
>  element is a key, and the third element is a sequence where
>  each element is the value associated with the corresponding (by
>  index) key.  There are a whole set of routines for setting a
>  key/value pair, deleting one, changing the value, setting or
>  changing the default, and so on.

Uhh, so basically, it's about set/getting key/value pairs? Ok.

Anyway... The Better Way hit me: (Right after that post I think it was)
Array Implementation. Bloated and Stupid, if you can do it with pointers, but
here it might be kinda nifty. It would allow me to make a tree (or any other
pointer structure) by using the (one-dimensional) sequence index as I would an
address/pointer... And having a variable number of children and variable size
data might make up for some of the bloatedness... We'll see what happens...

Cascade:
>>> Rob Craig
>>  Anders Eurenius
>   Jeff Zeitlin
    Anders Eurenius

/Anders
--------------------------------------------------------------
Anders Eurenius <c96aes at cs.umu.se> UIN:1453793
Computer Science/Engineering student at the university of Umea
--------------------------------------------------------------

new topic     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu