1. Rob re: Slicing
I seem to be doing this kind of thing repeatedly in my programs:
function slice(sequence data, integer field)
for i = 1 to length(data) do
data[i] = data[i][field]
end for
return data
end function
This is used, for example, to extract names from an address listing in order to
put the names into a listbox, to extract dollar amounts from invoices for
totalling, or to create a sequence that find() and find_all() will be able to
use ( since they fail on nested sequences )
Question for Rob is this: do you forsee a way that Euphoria could implement
such slicing internally, and if so, would you expect it to be significantly
faster than a loop such as above?
-- Regards,
-- Irv
2. Re: Rob re: Slicing
Hello,
<Irv writes about vertical slicing>
>Question for Rob is this: do you forsee a way that Euphoria could implement
>such slicing internally, and if so, would you expect it to be significantly
>faster than a loop such as above?
I for one cast my vote in favor or moving vertical slicing
from the wish-list (where it has resided a long time) to
the soon-to-be-done-list.
:)
Lewis Townsend
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
3. Re: Rob re: Slicing
- Posted by Robert Craig <rds at ATTCANADA.NET>
Aug 31, 2000
-
Last edited Sep 01, 2000
Irv Mullins writes:
> Question for Rob is this: do you forsee a way
> that Euphoria could implement such slicing internally,
> and if so, would you expect it to be significantly
> faster than a loop such as above?
I could take *any* Euphoria code and implement it
internally as either a built-in routine or a language feature
(column selection) and it would run faster. There is nothing
about column selection that I can do internally in a dramatically
faster way, i.e. by taking advantage of the internal representation
of sequences. The routine you wrote is quite reasonable,
and should be fairly efficient. My philosophy in these matters is
that Euphoria should be lean and fast, so that people aren't
afraid to code frequently-called utilities in Euphoria.
If Euphoria were 40-60 times slower, such as Python or Perl,
then I would understand people wanting to jam lots of stuff into
the interpreter where it can be handled by C code.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Rob re: Slicing
On Thu, 31 Aug 2000, you wrote:
> Irv Mullins writes:
> > Question for Rob is this: do you forsee a way
> > that Euphoria could implement such slicing internally,
> > and if so, would you expect it to be significantly
> > faster than a loop such as above?
>
> I could take *any* Euphoria code and implement it
> internally as either a built-in routine or a language feature
> (column selection) and it would run faster. There is nothing
> about column selection that I can do internally in a dramatically
> faster way, i.e. by taking advantage of the internal representation
> of sequences. The routine you wrote is quite reasonable,
> and should be fairly efficient. My philosophy in these matters is
> that Euphoria should be lean and fast, so that people aren't
> afraid to code frequently-called utilities in Euphoria.
> If Euphoria were 40-60 times slower, such as Python or Perl,
> then I would understand people wanting to jam lots of stuff into
> the interpreter where it can be handled by C code.
Then I am forced to ask: why do you brag that "sequences make
Euphoria very simple and very powerful"?
What's the point of including math operations on sequences:
e.g: {1,2,3} + 5, when any programmer could easily write a loop to do this?
Why is this seldom-used feature a part of the language, when similar
features that have _obvious_ and frequent utility are steadfastly
dismissed as "easily user-written", such as sum(), min(), max()....?
Again, to quote from the manual: "Making a flexible list that contains
a variety of different kinds of data objects is trivial in Euphoria, but
requires dozens of lines of ugly code in other languages."
True. Making the list is trivial.
When we try to USE the list, THAT's when that we get to write the
"dozens of lines of ugly code."
Let's take an example of this directly from the manual:
include sort.e
sequence database
database = {{"Smith", 95.0, 29},
{"Jones", 77.2, 31},
{"Clinton", 88.7, 44}}
database = sort(database) --sort works fine on mixed sequences
for i = 1 to length(database) do -- added to verify sort
printf(1,"Name: %s\n",{database[i][1]})
end for
? find("Jones",database) -- ain't there, is it?
? match("Jones",database) -- nope, can't find Jones anywhere.
The manual even adds, right at the bottom of the page:
"See Also: compare, match, find", implying that find and/or
match would work on sequences as easily as sort. They don't.
At least, not without writing those dozens of lines of ugly code.
These are the kinds of inconsistencies that I at first overlooked
because of the newness of the language, assuming they would
be fixed in due time. At this point, however, I have my doubts.
Regards,
Irv
5. Re: Rob re: Slicing
On Fri, 1 Sep 2000 04:48:22 -0400, irv <irv at ELLIJAY.COM> wrote:
>Then I am forced to ask: why do you brag that "sequences make
>Euphoria very simple and very powerful"?
>
>What's the point of including math operations on sequences:
>e.g: {1,2,3} + 5, when any programmer could easily write a loop to do this?
>Why is this seldom-used feature a part of the language, when similar
>features that have _obvious_ and frequent utility are steadfastly
>dismissed as "easily user-written", such as sum(), min(), max()....?
>
>Again, to quote from the manual: "Making a flexible list that contains
>a variety of different kinds of data objects is trivial in Euphoria, but
>requires dozens of lines of ugly code in other languages."
>True. Making the list is trivial.
>When we try to USE the list, THAT's when that we get to write the
>"dozens of lines of ugly code."
irv, are you feeling okay?
