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
--------------------------------------------------------------
|
Not Categorized, Please Help
|
|
