1. RE: Possible feature for new Euphoria-version
> -----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
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
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
> 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
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
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
>
> 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
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
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
[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
