1. RE: Possible feature for new Euphoria-version
- Posted by "Derek Parnell" <ddparnell at bigpond.com> Jan 09, 2004
- 414 views
> -----Original Message----- > From: Robert Craig [mailto:rds at RapidEuphoria.com] > Subject: Re: Possible feature for new Euphoria-version > > > > Tommy Carlier wrote: > > sequence seq > > seq = {{1, 2, 3}, {4, 5, 6}, {7, 8, 9}} > > sequence b > > b = {2, 2} > > integer a > > a = seq[b] > > > > This way you can also pass and return multiple indices to and from > > procedures and functions. > > There are at least three logical ways that you might define > subscripting of a sequence with a sequence. > > 1. Your way (above). The sequence used as a subscript would > contain a series of subscripts to be applied. This > fills a logical gap in subscripting, since currently > the number of levels of subscripting is fixed at > compile-time. You could use this for reading and writing. > > 2. sequence s > s = {100, 200, 300, 400, 500} > s[{1,5,3}] is {100, 500, 300} > The subscript would let you randomly select a bunch of > elements for reading or writing. Or as alternative ... s = {100, 200, 300, 400, 500} s[1,5,3] is {100, 500, 300} > 3. sequence s > s[1] = 7 > s["Tommy"] = 99 > s["Carlier"] = 0 > s["Carlier"] += 1 > ? s["Tommy"] * s["Carlier"] > > The Euphoria implementer might set up a hash table internally. > Whenever you assigned to a previously nonexistent > element, the implementation would create a new > element for you. This would be good for symbol tables, > databases etc. Or as alternative ... s."Tommy" = 99 > Which approach is best? If you choose one, you'll > eliminate the possibility of doing the others. Well at least any of them will be an improvement, and the "eliminated" ones are still possible through slower methods. -- Derek
2. RE: Possible feature for new Euphoria-version
- Posted by Tommy Carlier <tommy.carlier at pandora.be> Jan 09, 2004
- 455 views
Peter Blonner wrote: > While it is true that there are alternative meanings that could be > applied > to subscripting through sequences, in my opinion the first is by far the > most attractive. The ability to access various levels of a sequence at > run-time could be quite a powerful tool, however as with Pete Lomax > suggestion implementing it with Euphoria (as it is currently works) would > impose a hefty overhead. > So for me, implementing this as part of the language would be a > significant > improvement that would enable a lot of code to be written more > generically > with reasonable efficiency. Whereas the other alternative applications > could just as well be implemented though library functions. I agree, the second & third application could be easily coded like this: -- first application global function put_in_sequence(sequence source, sequence indices, sequence new_values) for i = 1 to length(indices) do source[ indices[i] ] = new_values[i] end for return source end function -- second application: doesn't use any hashing technique (yet) global function new_key_value_list() return { {}, {} } -- { keys, values } end function global function add_key_value_pair(sequence list, object key, object value) -- doesn't check for double keys (yet) list[1] = append(list[1], key) list[2] = append(list[2], value) return list end function global function get_index_of_key(sequence list, object key) return find(key, list[1]) end function global function get_value_at_index(sequence list, integer index) return list[2][index] end function global function get_value(sequence list, object key) integer index index = get_index_of_key(list, key) if index > 0 then return get_value_at_index(list, index) else return 0 -- this should perhaps be something else end if end function -- Tommy Carlier tommy online: http://users.pandora.be/tommycarlier
3. RE: Possible feature for new Euphoria-version
- Posted by Andy Serpa <ac at onehorseshy.com> Jan 09, 2004
- 413 views
Robert Craig wrote: > > > Tommy Carlier wrote: > > sequence seq > > seq = {{1, 2, 3}, {4, 5, 6}, {7, 8, 9}} > > sequence b > > b = {2, 2} > > integer a > > a = seq[b] > > > > This way you can also pass and return multiple indices to and from > > procedures and functions. > > There are at least three logical ways that you might define > subscripting of a sequence with a sequence. > > 1. Your way (above). The sequence used as a subscript would > contain a series of subscripts to be applied. This > fills a logical gap in subscripting, since currently > the number of levels of subscripting is fixed at > compile-time. You could use this for reading and writing. > > 2. sequence s > s = {100, 200, 300, 400, 500} > s[{1,5,3}] is {100, 500, 300} > The subscript would let you randomly select a bunch of > elements for reading or writing. > > 3. sequence s > s[1] = 7 > s["Tommy"] = 99 > s["Carlier"] = 0 > s["Carlier"] += 1 > ? s["Tommy"] * s["Carlier"] > > The Euphoria implementer might set up a hash table internally. > Whenever you assigned to a previously nonexistent > element, the implementation would create a new > element for you. This would be good for symbol tables, > databases etc. > > Which approach is best? If you choose one, you'll > eliminate the possibility of doing the others. > Can't #1 and #2 be combined? sequence s s = {{1,2,3},{4,5,6},{7,8,9}} object x -- Like #2 x = s[{1,3}] -- Now x = {{1,2,3},{7,8,9}} x = s[{1,2}] -- Same as x = s[1..2], x = {{1,2,3},{4,5,6}} -- Like #1 x = s[{{1,2}}] -- Now x = 2, depth of subscripting sequence = depth of retrieved element -- Like #1 & #2 both x = s[{{1,2},{3,1}}] -- Now x = {2,7} x = s[{{1,2},3}] -- Now x = {2,{7,8,9}} Logical, consistent, no?
4. RE: Possible feature for new Euphoria-version
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Jan 09, 2004
- 403 views
> From: Robert Craig [mailto:rds at RapidEuphoria.com] > > There are at least three logical ways that you might define > subscripting of a sequence with a sequence. > > 1. Your way (above). The sequence used as a subscript would > contain a series of subscripts to be applied. This > fills a logical gap in subscripting, since currently > the number of levels of subscripting is fixed at > compile-time. You could use this for reading and writing. > > 2. sequence s > s = {100, 200, 300, 400, 500} > s[{1,5,3}] is {100, 500, 300} > The subscript would let you randomly select a bunch of > elements for reading or writing. I think 1 and 2 could be combined in this way: s = {{1,2,3},{4,5,6},{7,8,9,{10,11,12}}} s[{2,2}] is 5 s[{{2},{1}}] is {{4,5,6},{1,2,3}} s[{{2},{3,{2},{3,1}}] is {{4,5,6},8,10} In other words, each 1d sequence refers to an element. To get really fancy, we could do slices, too: s[{2,2}..{2,3}] is {5,6} s[{{2,1},{1,1}}..{{2,2},{1,3}}] is {{4,5},{1,2,3}} s[{{2},{3,{2},{3,1}}..{{3},{3,{4},{3,2}}}] is either: {{{4,5,6},{8,10}},{8,9,{10,11,12}},{10,11}} ...or... {{4,5,6},{8,10},8,9,{10,11,12},10,11} depending on whether we 'append()' or '&' multiple slices. > 3. sequence s > s[1] = 7 > s["Tommy"] = 99 > s["Carlier"] = 0 > s["Carlier"] += 1 > ? s["Tommy"] * s["Carlier"] > > The Euphoria implementer might set up a hash table internally. > Whenever you assigned to a previously nonexistent > element, the implementation would create a new > element for you. This would be good for symbol tables, > databases etc. > > Which approach is best? If you choose one, you'll > eliminate the possibility of doing the others. Personally, I think I'll find 1 and 2 much more valuable than 3. I think that hash/associative list implementations in pure Euphoria are acceptable performance-wise, but 'native sequence subscripting' could give a significant difference.
5. RE: Possible feature for new Euphoria-version
- Posted by Tommy Carlier <tommy.carlier at pandora.be> Jan 09, 2004
- 402 views
Options for seq[seq]: 1. s[{a, b, c}] = s[a][b][c] -- recursive indices 2. s[{a, b, c}] = { s[a], s[b], s[c] } -- direct indices 3. s["abc"] = s[VALUES][ find("abc", s[KEYS]) ] -- associative list I think that 2 and 3 are so easy and fast to do in Euphoria, that it doesn't really need to be a new feature (simple for-loop should do it). But if you want to do 1 in Euphoria, you'll have to use some recursive technique, and it will probably be quite slow. It would be great if that feature would be fast as hell, and directly available. Why did I propose for such a feature? Sequences can be used to store hierarchical (?) data, where each element can have nodes. Sometimes, you want to write a procedure or function, where you pass a large sequence of data and a pointer to an element inside that sequence that needs processing. In the current Euphoria, that pointer can only be an atom, and only the direct child-elements of the sequence can be accessed. In my SMEL-package, I have a type of sequence that is called SmelDocument: it represents a document with hierarchical data. Each node in the document can have children. The current implementation of that SmelDocument looks a bit like this: { {"data1", {2, 3, 4}}, -- node 1 has children 2,3 and 4 {"data2", {5, 6}}, -- node 2 has children 5 and 6 {"data3", {}}, -- node 3 has no children {"data4", {}}, -- node 4 has no children {"data5", {}}, -- node 5 has no children {"data6", {}} -- node 6 has no children } I want it to look like this: { {"data1", --> {{"data2", ----> {{"data5", {}}, ----> {"data6", {}}}, --> {"data3", {}}, --> {"data4", {}}}} ... where the children of each node are really children, and not pointers in a linear table. I implemented the linear table, because I need to pass pointers to nodes to functions and procedures, and with a hierarchical sequence that is currently not possible in a fast and easy-to-implement way.
6. RE: Possible feature for new Euphoria-version
- Posted by Andy Serpa <ac at onehorseshy.com> Jan 09, 2004
- 417 views
Derek Parnell wrote: > > > > Can't #1 and #2 be combined? > > > > sequence s > > > > s = {{1,2,3},{4,5,6},{7,8,9}} > > > > object x > > > > > > -- Like #2 > > > > x = s[{1,3}] > > > > -- Now x = {{1,2,3},{7,8,9}} > > Okay, so because the reference was {1,3} you have plucked out the 1st > and 3rd elements. Right. > > > x = s[{1,2}] > > > > -- Same as x = s[1..2], x = {{1,2,3},{4,5,6}} > > > > -- Like #1 > > > > x = s[{{1,2}}] > > > > -- Now x = 2, depth of subscripting sequence = depth of retrieved > > element > > > > > > -- Like #1 & #2 both > > > > x = s[{{1,2},{3,1}}] > > > > -- Now x = {2,7} > > > > x = s[{{1,2},3}] > > > > -- Now x = {2,{7,8,9}} > > > > > > Logical, consistent, no? > > > > I'm not sure if this solves the issue, Andy. I was thinking that the > syntax ... > > SEQ[ seq ] > > would only ever refer to a single element. The depth of that element is > the length of 'seq'. This is because at run time it is a trivial matter > to have the length of a sequence represent the depth you wish to fetch > from. It may be harder to do use the depth dynamically. > > If, for example, we didn't know until runtime, that we wanted something > 3 levels deep, it is trival to build a reference sequence thus ... > > refseq = {index1, index2, index3} > > but to do a depth reference sequence we would need to do ... > > refseq = {index1, index2, index3} > for i = 1 to length(refseq) do > refseq = {refseq} > end for > > Why bother? > > And ... > > SEQ[ a,b, ... ,z ] > > would refer to one or more elements, depending on the number of items in > the square-bracket-enclosed list. > > We could even do > SEQ[ a, b..c, {d,e,f}, $ ] > > which would create a new sequence whose 1st element would be SEQ[a], 2nd > would be SEQ[b..c], 3rd would be SEQ[{d,e,f}], and 4th would be > SEQ[length(SEQ)]. > Ok, I see. So to "go deep", you'd use: SEQ[ seq ] where s[{1,2,3}] is equivalent to: s[1][2][3] and to grab an arbitrary selection of items you use: SEQ[ element A, element B, element C ] where s[1,3,5] is equivalent to {s[1],s[3],s[5]} Right? Problem is, in the second syntax, you are hamstrung to a specific number of items because the "1,3,5" is not a sequence, which means the bracketed items are just a shorthand for something that you could represent already in Eu, e.g.: s[1,3,5] => {s[1],s[3],s[5]} s[a, b..c, {d,e,f}, $] => s{s[a],s[b],s[c],s{d..f},$} etc. Am I missing something? A list like "1,3,5" doesn't exist anywhere in Euphoria now. If it can't be replaced by something like "s" that can be of arbitrary size, then we're just talking about short-hand, not new, faster, more powerful functionality. With my way (or something like it, Matt's seems to flip it around?), you can pick an arbitrary number of elements at arbitrary depths without needed to anything about the shape & size at compile time. I use routines that do just what I'm suggesting quite often now, and building the "subscriting sequence" is not particularly hard. Your way is better if you know what you want before-hand, but the point of using a sequence for subscripts is that you don't know what you want. But since [a,b,c] is fundamentally different from [{a,b,c}], why can't we do it all -- your way and my way (or Matt's way)? New, "list" shorthand, plus the ability to use a sequence that can pick arbitrary elements from anywhere in the sequence at any depth. I want it all!
7. RE: Possible feature for new Euphoria-version
- Posted by Andy Serpa <ac at onehorseshy.com> Jan 09, 2004
- 421 views
> > With my way (or something like it, Matt's seems to flip it around?), you > > can pick an arbitrary number of elements at arbitrary depths without > needed to anything about the shape & size at compile time. I use > routines that do just what I'm suggesting quite often now, and building > the "subscriting sequence" is not particularly hard. > > Your way is better if you know what you want before-hand, but the point > of using a sequence for subscripts is that you don't know what you want. > > But since [a,b,c] is fundamentally different from [{a,b,c}], why can't > we do it all -- your way and my way (or Matt's way)? > > New, "list" shorthand, plus the ability to use a sequence that can pick > arbitrary elements from anywhere in the sequence at any depth. I want > it all! > Another thought. In my own work, the main purpose of flexible subscripting like this is usually for some sort of conditional filtering/extraction from sequences. With nested sequences, usually I'm navigating with a recursive "sequence diver" function, and often extracting from one sequence based on what is what in another sequence (of identical structure). Which leads to a 4th way to do subscripting by sequence -- via a truth vector. For instance: s = {1,3,5,7,9,2,4,6,8,10} s = s[s < 5] -- which is same as: s = s[{1,1,1,0,0,1,1,0,0,0}] -- Now s = {1,3,2,4} And this could work for nested sequences as well -- the subscripting sequence is of indentical structure to the sequence being subscripted. Could be a bit much for very large nested sequences though. BTW Rob, let's get that conditional operator for next version too. I'd love to do this: s = {1,2,3,4,5,6,7,8,9,10} s = (s < 5) iftrue (s*2):(s*4) -- now s = {2,4,6,8,10,24,28,32,36,40} instead of: for i = 1 to length(s) do if s[i] < 5 then s[i] *= 2 else s[i] *= 4 end if end for
8. RE: Possible feature for new Euphoria-version
- Posted by Philip Deets <philip1987 at hotmail.com> Jan 13, 2004
- 440 views
Robert Craig wrote: > > > Tommy Carlier wrote: > > sequence seq > > seq = {{1, 2, 3}, {4, 5, 6}, {7, 8, 9}} > > sequence b > > b = {2, 2} > > integer a > > a = seq[b] > > > > This way you can also pass and return multiple indices to and from > > procedures and functions. > > There are at least three logical ways that you might define > subscripting of a sequence with a sequence. > > 1. Your way (above). The sequence used as a subscript would > contain a series of subscripts to be applied. This > fills a logical gap in subscripting, since currently > the number of levels of subscripting is fixed at > compile-time. You could use this for reading and writing. > > 2. sequence s > s = {100, 200, 300, 400, 500} > s[{1,5,3}] is {100, 500, 300} > The subscript would let you randomly select a bunch of > elements for reading or writing. > > 3. sequence s > s[1] = 7 > s["Tommy"] = 99 > s["Carlier"] = 0 > s["Carlier"] += 1 > ? s["Tommy"] * s["Carlier"] > > The Euphoria implementer might set up a hash table internally. > Whenever you assigned to a previously nonexistent > element, the implementation would create a new > element for you. This would be good for symbol tables, > databases etc. > > Which approach is best? If you choose one, you'll > eliminate the possibility of doing the others. > > Regards, > Rob Craig > Rapid Deployment Software > http://www.RapidEuphoria.com > > My preference is number 2. But my vote shouldn't count as much as the other's votes because I'm not an experienced programmer. I'd like: sequence a, b a = {1,2,3,4,5} b = a[2,1,3..5,1] -- b now equals {2,1,{3,4,5},1} Just my input, Phil
9. RE: Possible feature for new Euphoria-version
- Posted by <Christian.CUVIER at agriculture.gouv.fr> Jan 30, 2004
- 447 views
idEu, my preprocessor (maybe an alpha release in June), will have this feature, using double brackets however for sequence indexes to sequences. Hopefully, OpenEuphoria will have it too. CChris Euman wrote: > > > Ouch, to much confusion...Im an old timer in euphoria > > Euman > > ----- Original Message ----- > From: "Tommy Carlier" <tommy.carlier at pandora.be> > To: "Euphoria Mailing List" <EUforum at topica.com> > Sent: Thursday, January 08, 2004 1:54 PM > Subject: Possible feature for new Euphoria-version > > > > Sequences are really easy to use, but there is no way you can create an > > index to a sub-, sub-, sub-sequence of a given sequence. Wouldn't it be > > nice if such a thing existed? > > > > In the current version of Euphoria, you can do: > > sequence seq > > seq = {{1, 2, 3}, {4, 5, 6}, {7, 8, 9}} > > integer a > > a = seq[2][2] > > > > My suggestion for a new feature: allow the index to be a sequence. That > > way you could do something like this: > > sequence seq > > seq = {{1, 2, 3}, {4, 5, 6}, {7, 8, 9}} > > integer a > > a = seq[ {2, 2} ] > > > > And now for the exciting part: > > sequence seq > > seq = {{1, 2, 3}, {4, 5, 6}, {7, 8, 9}} > > sequence b > > b = {2, 2} > > integer a > > a = seq[b] > > > > This way you can also pass and return multiple indices to and from > > procedures and functions. > > > > -- > > > > Tommy Carlier > > tommy online: http://users.pandora.be/tommycarlier > > > > > > TOPICA - Start your own email discussion group. FREE! > > > >
10. RE: Possible feature for new Euphoria-version
- Posted by <Christian.CUVIER at agriculture.gouv.fr> Jan 30, 2004
- 427 views
[snip] > Am I missing something? A list like "1,3,5" doesn't exist anywhere in > Euphoria now. Not true. In the valid statement integer i,j,k you are effectively using an undelimited, nonempty list of items of arbitrary length. >If it can't be replaced by something like "s" that can be > of arbitrary size, then we're just talking about short-hand, not new, > faster, more powerful functionality. > > > With my way (or something like it, Matt's seems to flip it around?), you > > can pick an arbitrary number of elements at arbitrary depths without > needed to anything about the shape & size at compile time. I use > routines that do just what I'm suggesting quite often now, and building > the "subscriting sequence" is not particularly hard. > > Your way is better if you know what you want before-hand, but the point > of using a sequence for subscripts is that you don't know what you want. If the indexing description is the result of some function, you don't need to know what you want, as this may just be the point of the program you are coding ! > But since [a,b,c] is fundamentally different from [{a,b,c}], why can't > we do it all -- your way and my way (or Matt's way)? > > New, "list" shorthand, plus the ability to use a sequence that can pick > arbitrary elements from anywhere in the sequence at any depth. I want > it all! > CChris