1. Re: [E - 6 to 7 Jun 1997] Sub'ing seqs with seqs
- Posted by Anders Eurenius <c96aes at OXE.CS.UMU.SE> Jun 10, 1997
- 646 views
> 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 --------------------------------------------------------------