OpenEuphoria

2. Re: ? 1={}, is there really any other interpretation?

• Posted by Jason Gade <jaygade at ?ahoo.com> Jul 15, 2007
• 673 views

Al Getz wrote:
> 
> Hello,
> 
> 
> For the following statement:
> 
> ? 1={}
> 
> could there really be any interpretation other than to compare
> every element of the sequence with the atom '1' ?
> After all, we are not trying to compare what types the two
> arguments are, we are trying to compare all the sequence elements
> to the atom '1'.
> 
> In this example,
> 
> ? 1={1,2,3}
> 
> the number 1 is compared to every element of the sequence, and
> a sequence is returned with the results, and it must be a sequence
> returned in order to show the results.  A single number like 1 or
> 0 would not indicate anything useful, and if we want to know what
> type something is, we have 'atom()' and 'sequence()'.
> 
> 
> Al
> 
> E boa sorte com sua programacao Euphoria!
> 
> 
> My bumper sticker: "I brake for LED's"
> 

I was trying to decide how to respond to this, and I confess that I don't have a
very good answer.

For '=' and '!=' I would prefer to return a boolean determining the actual
equality of the values. I mean, are they the same or not? To compare the equality
of actual sequence elements I would prefer a named function like equal().
Basically, flip the current meaning of the two methods.

With regards to relational operator such as '>' and '<', I don't know how to
define whether an atom is greater than or less than a sequence. That would
require some thought and discussion.

--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.

4. Re: ? 1={}, is there really any other interpretation?

• Posted by Pete Lomax <petelomax at blueyo?der.co.uk> Jul 15, 2007
• 682 views

> Al Getz wrote:
> > 
> > ? 1={}
> > 
> > could there really be any interpretation other than to compare
> > every element of the sequence with the atom '1' ?
While I get the distinct feeling I am being trolled here, the obvious answer is
YES!

Clearly, ? 1={} *should* print FALSE

It is what any rational being not previously infected with the flawed concept of
implicit sequence ops would expect. [NB I said implicit.]

Clearly, ? sq_eq(1,{}) should [erm, might] print {}

Obviously, there is need for "deep compare", but I have said before and I will
say again, such need is *very* rare, and more often than not downright confusing
given it would be a different "=" to the 99 above and the 99 below.

> > In this example,
> > 
> > ? 1={1,2,3}
> > 
<snip>
> > A single number like 1 or 0 would not indicate anything useful

<again feeling like I just got trolled>
<i>Au contraire</i>, I consider true and false rather useful!
</again feeling like I just got trolled>

Pop question (for as-is behaviour): 

?{2, {2}, {2}, {{2}}, {{2}}, {{2,2}}, {{2,2}}}=
 {3,  3,  {3}, {3},   {{3}}, {3},     {{3,3}}}

Without checking, write down the theoretically expected output, and/or note any
elements which will trigger the "sequence lengths not the same" error.
I wonder how many will get that 100% right, not many I'll wager. [see PS]

Were I to replace all 3 with 2, I am equally (groan) sure I or someone else
might find good use for a {1,0,1,0,1,0,1} result, ie compare to depth 1.

Jason Gade wrote:
> 
> With regards to relational operator such as '>' and '<', I don't know how
> to define whether an atom is greater than or less than a sequence. That 
> would require some thought and discussion.
The compare() docs state atoms are deemed less than sequences, works for me.

Regards,
Pete
PS OK, the pop question may recurr at a later date "what does sq_eq()" do? But a
core operator such as "=" should deliver one obvious answer and not, as some
fools propose, vary between "if" and "assign" use, like "and" and "or" do, where
this thread all started. (Keep the semantics clean.)

6. Re: ? 1={}, is there really any other interpretation?

• Posted by CChris <christian.cuvier at agricul?ure.gouv.fr> Jul 15, 2007
• 687 views

Jason Gade wrote:
> 
> Pete Lomax wrote:
> > PS OK, the pop question may recurr at a later date "what does sq_eq()" do?
> > But
> > a core operator such as "=" should deliver one obvious answer and not, as
> > some
> > fools propose, vary between "if" and "assign" use, like "and" and "or" do,
> > where
> > this thread all started. (Keep the semantics clean.)
> 
> Hey, now! That's not nice! ;)
> 
> If you read the thread you can see that I've since amended my opinion on that.
> 
> As someone who has been in the community for several years (but really hasn't
> written much of note) I've never needed to use compare() hence my
> unfamiliarity
> with its basics.
> 
> So I still stick with the idea of switching equal() and compare() to compare
> sequences with other things (either atoms or sequences of different lengths)
> and leave =, !=, <, > to mean what they otherwise mean and return some
> kind of singular truth value.
> 
> --
> "Any programming problem can be solved by adding a level of indirection."
> --anonymous
> "Any performance problem can be solved by removing a level of indirection."
> --M. Haertel
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
> j.

I really think having a ternary logic (true/false/nil) would make a lot of
things easier.

nil would be a special value allowed for any type. Any operation involving nil
in its arguments should return nil (functions) or return immediately
(procedures).
(note: you can't test directly whether something is nil, since nil is neither
true or false - consider it as Not_a_Value, by analogy with NaNs).

The benefits:
* No longer need for functions to return special values on error, with subtle
problems arising from failing to check or wrong choice of the invalid value.
Return nil.
* No need to crash when a variable wasn't ever assignd a value and is being
read. Return nil.
* No need to crash when operating on sequences whose lengths don't match. Terms
in the result that don't make get sense are set to nil.

The caveats (I don't see them as drawbacks):
* There will be a need to introduce two extra flavours of the if statement:
+ if_nil condition then/elsif/else/end if will execute the then branch when
condition is nil.
+ if_not_nil condition then/elsif/else/end if will execute the then branch when
condition is true or false.
* The same has to be done on while statements.
* nil = not nil, which may be perceived as unusual. After all inf+1=inf, so is
it a problem?

* The problem: I expect some amount of code to break if this happens, since "if
not condition then" will execute the then branch only when condition is false,
and not when it is nil. For this reason I don't have much hope that nil will ever
make it in. But that's really too bad. Think about it twice before discarding it,
the advantages outweigh the issues.

CChris

8. Re: ? 1={}, is there really any other interpretation?

• Posted by Al Getz <Xaxo at aol.co?> Jul 15, 2007
• 663 views

Pete Lomax wrote:
> 
> > Al Getz wrote:
> > > 
> > > ? 1={}
> > > 
> > > could there really be any interpretation other than to compare
> > > every element of the sequence with the atom '1' ?
> While I get the distinct feeling I am being trolled here, the obvious answer
> is YES!
> 
> Clearly, ? 1={} *should* print FALSE
> 
> It is what any rational being not previously infected with the flawed concept
> of implicit sequence ops would expect. [NB I said implicit.]
> 
> Clearly, ? sq_eq(1,{}) should [erm, might] print {}
> 
> Obviously, there is need for "deep compare", but I have said before and I will
> say again, such need is *very* rare, and more often than not downright
> confusing
> given it would be a different "=" to the 99 above and the 99 below.
> 
> > > In this example,
> > > 
> > > ? 1={1,2,3}
> > > 
> <snip>
> > > A single number like 1 or 0 would not indicate anything useful
> 
> <again feeling like I just got trolled>
> <i>Au contraire</i>, I consider true and false rather useful!
> </again feeling like I just got trolled>
> 
> Pop question (for as-is behaviour): 
> }}}
<eucode>
> ?{2, {2}, {2}, {{2}}, {{2}}, {{2,2}}, {{2,2}}}=
>  {3,  3,  {3}, {3},   {{3}}, {3},     {{3,3}}}
> </eucode>
{{{

> Without checking, write down the theoretically expected output, and/or note
> any elements which will trigger the "sequence lengths not the same" error.
> I wonder how many will get that 100% right, not many I'll wager. [see PS]
> 
> Were I to replace all 3 with 2, I am equally (groan) sure I or someone else
> might find good use for a {1,0,1,0,1,0,1} result, ie compare to depth 1.
> 
> Jason Gade wrote:
> > 
> > With regards to relational operator such as '>' and '<', I don't know how
> > to define whether an atom is greater than or less than a sequence. That 
> > would require some thought and discussion.
> The compare() docs state atoms are deemed less than sequences, works for me.
> 
> Regards,
> Pete
> PS OK, the pop question may recurr at a later date "what does sq_eq()" do? But
> a core operator such as "=" should deliver one obvious answer and not, as some
> fools propose, vary between "if" and "assign" use, like "and" and "or" do,
> where
> this thread all started. (Keep the semantics clean.)


Hi Pete,


Not sure what you mean by being 'trolled'.

> Clearly, ? 1={} *should* print FALSE

Well, lets look at another operation with an atom and a sequence...

?1+{1,2,3} --prints "{2,3,4}" without the quotes

In other words, that statement says, "Add 1 to every element of the
sequence {} and return the result and then print it to console".
Since there are three elements in the sequence, 1 gets added to
each element which forms the result which also has to be a sequence.

Now with the empty sequence...

?1+{} --prints {}

In other words, that statement still says, "Add 1 to every element of
the sequence {} and return the results and then print it".
In this case since there are no elements there is nothing to add 1 to,
so the sequence remains unmodified and the result is the empty sequence.

The same happens with the '=' operator, except instead of adding
1 to each element it does a logical compare to each element and
returns the result.  If the sequence is empty there is nothing to
compare so it is done, and returns the empty sequence.

If we were to allow
?1={}
to return *either* TRUE or FALSE, then that would be like saying,
"Compare 1 to a sequence and if it is a empty sequence then return
TRUE (or FALSE), but if it is not empty then compare 1 to every 
element of the sequence and return the result".
In other words, we would be asking for a return result that normally
only comes when comparing two atoms, not when comparing an atom to
a sequence.  I believe this would be a bit inconsistent.

The time when 1={} returning {} is useful is when you have a function
that returns an object.  If the object returns x={1,2,3} and you do
?1=x
you get
{1,0,0}
indicating that only one element was the same as 1 and you can test
each element to find out which ones pass.
On the other hand, if the object returns x={} and you do
?1=x
you get
{}
as return, and then you can still test each element to see which
ones pass, finding that there are no objects.  However, if
 1=x (x being the empty sequence)
returned FALSE for example, you would not even have a sequence
anymore, so your code would have to first test for atom or
sequence instead of just length(x) and simply not do anything
inside the loop that takes action on the result:
  for j=1 to length(x) do
    --do stuff based on elements of x
  end for
  --if x={} nothing gets done, which is appropriate.


It is possible that i am a victim of my own programming techniques,
in that the code i presented is only typical and not as general as
it might imply.  Because of this i invite you to present some
code that might make use of your suggestion of having 1={}
return FALSE (or TRUE even).  In doing so, perhaps also consider
the return possibilites of operations like 1+{} too.





Take care,
Al

E boa sorte com sua programacao Euphoria!


My bumper sticker: "I brake for LED's"

 From "Black Knight":
"I can live with losing the good fight,
 but i can not live without fighting it".
"Well on second thought, maybe not."

10. Re: ? 1={}, is there really any other interpretation?

• Posted by Al Getz <Xaxo at aol?com> Jul 15, 2007
• 677 views

Pete Lomax wrote:
> 
> Al Getz wrote:
> > Not sure what you mean by being 'trolled'.
> Don't worry about it. I just meant the uneasy self-important sensation that
> the author is playing with me, that they could not possibly believe what they
> were saying but instead deliberately crafting a message solely intended to
> provoke
> the maximum retaliatory outburst.  I probably spent too long reading that
> XP patent thing yesterday, and as noted I have a long history of ranting on
> and on and on about this topic...
> > 
> > > Clearly, ? 1={} *should* print FALSE
> > 
> > Well, lets look at another operation with an atom and a sequence...
> > 
> > ?1+{1,2,3} --prints "{2,3,4}" without the quotes
> > 
> If you want consistency then "1+{1,2,3}" should trigger an error, and much the
> same way that we've all been forced for years to replace = with equal, force
> it to be replaced with sq_add(1,{1,2,3}) or maybe 1 at +{1,2,3}.
> 
> > It is possible that i am a victim of my own programming techniques,
> > in that the code i presented is only typical and not as general as
> > it might imply.
> As I said, "not previously infected with the flawed concept
> of implicit sequence ops. [NB I said implicit.]"
> 
> Obviously, sq_eq(a,b) or a@=b are in contrast explicit sequence ops.
> 
> > Because of this i invite you to present some
> > code that might make use of your suggestion of having 1={}
> > return FALSE (or TRUE even).
> Too easy:
> }}}
<eucode>
> function killFilter()
>     if name="Pete Lomax" then
>         return reply_to="Al Getz"
>     end if
>     return False
> end function
> integer flag
>   flag=killFilter()
> </eucode>
{{{

> Almost everyone who has ever written some Eu code has tried something like
> that
> only to first run into the dreaded "true/false condition must be ATOM"
> then "type check error, flag is {1,1,1,1,1,1,1}", then "sequence lengths are
> not the same (4!=7)" and so on.
> 
> Obviously if you are asking for a "1={}" example that cannot be trivially
> replaced
> by "equal(1,{})" then there ain't one. The closest I can get:
> }}}
<eucode>
>   if alen=1 then emit_one_byte_opcode()
>   elsif alen=2 then emit_two_byte_opcode()
>   elsif alen={} then fatal("no valid length for opcode")
> </eucode>
{{{

> The point is simply that the above is the most natural and elegant way to
> write
> such code. I know you could easily fix it via equal() or using -1 for the
> error
> case.
> 
> Regards,
> Pete


Hi Pete,


I dont take this technical stuff too personal anymore, as i try
to let the logic speak for itself.  Also, if someone wants to argue
for days that 1=2 then after the first try or two i would be
happy to let them believe what they will.
I also dont put out 'feelers' for the sole purpose of arguing
over something, because i just dont feel like wasting the time.

As i said in my previous post, more or less, is that i would be
happy to see some of your (or others) code that demonstrates
a good use for 1={} returning FALSE, and you did that and made
the point clear with:

> function killFilter()
>     if name="Pete Lomax" then
>         return reply_to="Al Getz"
>     end if
>     return False
> end function

That's very nice too, and illustrates how that sort of syntax
could be very useful.  On the other hand, the old way isnt
so bad either, and comes in handy too.  I guess this means
we have a conflict where if you make it work one way you get
some benefits and some loss of other benefits, and if the
other way you get some other benefits and some other loss.
It's got to be one way or the other, and right now it works
as we all now are aware of (1={} returns {}).

Because of all this, i would suggest that it's time to introduce
the double equals sign "==", which comes in handy in my
Scientific Calculator (it's math language) as well as many other
computer languages.

To modify your nice example:

 function killFilter()
     if name=="Pete Lomax" then
         return reply_to=="Al Getz"
     end if
     return False
 end function

This, at least for me, has a nice personal side effect...
After working in Euphoria for hours, days, weeks, and i go
back to C or C++ to do something special, i will make the
mistake:

 if (a=b)
    DoThis();

at least once 

Also, i dont mind using the double equals sign for testing
and the single for assignments (or tests with atoms) but
i guess it could become confusing too.

I agree with most of what you are saying now, but I cant agree however
that making

? 1+{1,2,3}

return an error would be an improvement, even if we didnt worry about
backwards compatibility anymore.

More generally, i think that sequences are always going to be just
a little confusing.  For example, how do you answer this question:

x={{}}

Is the sequence x holding anything or not?

Then, what should be returned for this:

? 1=x

Then, change x:

  x={{{}}}

Now what should ? 1=x  return (or print)?


I guess what you are suggesting is to make operations between atoms
and sequences totally illegal?
If so, then i think we would be forced to use:
  pos=find(1,s)
over and over again for a large sequence.
Or, what else could be used to determine which elements of s
are equal to 1 exactly if 1={} current functionality is lost?



Take care,
Al

E boa sorte com sua programacao Euphoria!


My bumper sticker: "I brake for LED's"

 From "Black Knight":
"I can live with losing the good fight,
 but i can not live without fighting it".
"Well on second thought, maybe not."

12. Re: ? 1={}, is there really any other interpretation?

• Posted by Gary Shingles <eu at 531pi.co.n?> Jul 16, 2007
• 692 views

Al Getz wrote:
> Because the 'if' statement requires a boolean,
>   Name="Al"
> and
>   Name="Pete"
> should be handled as boolean.

The 'return' keyword also processes boolean statements too doesn't it?  When it
is used in a function that is, ie "return a < 10"

If double-equals for equality test could be implemented in a backward compatible
way then I would be for it. eg:

integer a
a = 3

if a = 3 then
   a = 5
end if

"Warning: single equal sign (=) for equality test detected at line 4" 
(unless 'without warning' used)

The only reason to do it though is to be friendly to people coding in other
languages.  Not a really big issue IMHO; you know you can't assign in an
if/while/return setting.

If we do go down the 'other language friendly' road though, can we make it so
semi-colons at end of each line are ignored? 

Gary

14. Re: ? 1={}, is there really any other interpretation?

• Posted by CChris <christian.cuvier at a?riculture.gouv.fr> Jul 16, 2007
• 683 views

[Snipped]
> 
> More generally, i think that sequences are always going to be just
> a little confusing.  

??? I don(t think so. Only thing is, sometimes there are two possible semantics
for a single piece of code, and the interpreter had to choose one of them, even
when you'd rather it making the other choice, which was about as justified.

> For example, how do you answer this question:
> 
> x={{}}
> 
> Is the sequence x holding anything or not?
> 

x has length 1, so it holds something.
What it holds is an empty sequence. A box which contains a box which is empty is
not emopty itself.

> Then, what should be returned for this:
> 
> ? 1=x
> 

Since x is {x[1]}, 1=x is equivalent to { 1=x[1] }, which is { 1={} }, which is
{{}}.

> Then, change x:
> 
>   x={{{}}}
> 
> Now what should ? 1=x  return (or print)?
> 

Same approach: 1=x is {1=x[1]}, which is { 1={{}} }, which is {{{}}} using the
previous result. Very claer and intuitive.

CChris

> 
> I guess what you are suggesting is to make operations between atoms
> and sequences totally illegal?
> If so, then i think we would be forced to use:
>   pos=find(1,s)
> over and over again for a large sequence.
> Or, what else could be used to determine which elements of s
> are equal to 1 exactly if 1={} current functionality is lost?
> 
> 
> Al
> 
> E boa sorte com sua programacao Euphoria!
> 
> 
> My bumper sticker: "I brake for LED's"
>

16. Re: ? 1={}, is there really any other interpretation?

• Posted by Al Getz <Xaxo at aol?co?> Jul 16, 2007
• 674 views

CChris wrote:
> 
> [Snipped]
> > 
> > More generally, i think that sequences are always going to be just
> > a little confusing.  
> 
> ??? I don(t think so. Only thing is, sometimes there are two possible
> semantics
> for a single piece of code, and the interpreter had to choose one of them,
> even
> when you'd rather it making the other choice, which was about as justified.
> 
> > For example, how do you answer this question:
> > 
> > x={{}}
> > 
> > Is the sequence x holding anything or not?
> > 
> 
> x has length 1, so it holds something.
> What it holds is an empty sequence. A box which contains a box which is empty
> is not emopty itself.
> 

That question was designed to get the reader to think more about
the sequence, not to provide one or more examples of how it 
*might* be interpreted.  You forced the sequence to be a box,
when really it is not that physical.  If you choose another
type of entity for the sequence to be it might not work
anymore. For example, can a hole in the ground hold another
hole in the ground?
This was mainly to show that thinking about the sequence is
different than thinking about other things like atoms.
I realize now though that i didnt make my intent that clear originally
so it would make sense when talking about 1={}.

> > Then, what should be returned for this:
> > 
> > ? 1=x
> > 
> 
> Since x is {x[1]}, 1=x is equivalent to { 1=x[1] }, which is { 1={} }, which
> is {{}}.
> 
> > Then, change x:
> > 
> >   x={{{}}}
> > 
> > Now what should ? 1=x  return (or print)?
> > 
> 
> Same approach: 1=x is {1=x[1]}, which is { 1={{}} }, which is {{{}}} using the
> previous result. Very claer and intuitive.
> 

(see above)

> CChris

My suggestion now is that if an operation is enclosed in curly
brackets that the operation return a sequence, otherwise
it returns an atom.

?{x={{}}} --x becomes a sequence: {{}} displayed

?x={{}} --x becomes an integer: 0 displayed

This, however, would break code unfortunately.


Take care,
Al

E boa sorte com sua programacao Euphoria!


My bumper sticker: "I brake for LED's"

 From "Black Knight":
"I can live with losing the good fight,
 but i can not live without fighting it".
"Well on second thought, maybe not."

18. Re: ? 1={}, is there really any other interpretation?

• Posted by Al Getz <Xaxo at ?o?.com> Jul 16, 2007
• 677 views

CChris wrote:
> 
> Al Getz wrote:
> > 
> > CChris wrote:
> > > 
> > > [Snipped]
> > > > 
> > > > More generally, i think that sequences are always going to be just
> > > > a little confusing.  
> > > 
> > > ??? I don(t think so. Only thing is, sometimes there are two possible
> > > semantics
> > > for a single piece of code, and the interpreter had to choose one of them,
> > > even
> > > when you'd rather it making the other choice, which was about as
> > > justified.
> > > 
> > > > For example, how do you answer this question:
> > > > 
> > > > x={{}}
> > > > 
> > > > Is the sequence x holding anything or not?
> > > > 
> > > 
> > > x has length 1, so it holds something.
> > > What it holds is an empty sequence. A box which contains a box which is
> > > empty
> > > is not emopty itself.
> > > 
> > 
> > That question was designed to get the reader to think more about
> > the sequence, not to provide one or more examples of how it 
> > *might* be interpreted.  You forced the sequence to be a box,
> > when really it is not that physical.  If you choose another
> > type of entity for the sequence to be it might not work
> > anymore. For example, can a hole in the ground hold another
> > hole in the ground?
> > This was mainly to show that thinking about the sequence is
> > different than thinking about other things like atoms.
> > I realize now though that i didnt make my intent that clear originally
> > so it would make sense when talking about 1={}.
> > 
> 
> It still works with holes.  
> Let a sequence be a hole leading to a cavity. Along the circular wall of the
> cavity are either atoms or other holes, or nothing at all. So {{}} is a hole
> at the bottom of which another smaller hole starts. The main hole is not
> empty,
> since there is one feature to be seen at the bottom.
> 
Well, one could argue along two lines here:
1.  The smaller hole is not contained within the larger hole so big
    hole still empty
2.  The smaller hole just makes the larger hole larger (extension).
I guess that we could call this a 'system' of holes, that contains
many holes, but that wouldnt be right either because we would have
to have two words to describe this, system and holes, and a sequence
is still just a sequence even if it holds other sequences.
Also, if everthing was as intuitive as you say it is then why
are people talking about this in the first place...only your
intuition is the correct one?  

But this is getting off the point now anyway.  The main idea is
that by far a sequence is not the same as an atom or integer,
and that it requires more thought about how to use it.
I'll accept your explanation using the boxes too, ok?

What happened was we started talking about 1={} being interpreted
as only returning a sequence and Pete brought up comparing sequences
using the equals sign, so we started talking about that.

> > 
> > My suggestion now is that if an operation is enclosed in curly
> > brackets that the operation return a sequence, otherwise
> > it returns an atom.
> > 
> > ?{x={{}}} --x becomes a sequence: {{}} displayed
> > 
> > ?x={{}} --x becomes an integer: 0 displayed
> > 
> > This, however, would break code unfortunately.
> > 
> 
> I still don't understand why not use compare() and equal() in these
> indeterminate
> contexts, since they were included in the language for that very purpose. What
> did I miss?
> 
> CChris
> 

I dont have any problem using compare() and equal() myself because
i am so used to using them now.  I guess Pete wants to see the
equals sign be used for sequence compares at some point so that
you can do this:

sequence s,ss

s="ab"
ss="abc"

if s=ss then
  --
end if

In the case of the if/then statement i guess it wouldnt hurt
if this worked the way you think it should.  Changing 1={}
to return a boolean is another matter the way i see it, because
that involves an atom and a sequence rather than two sequences.
Maybe there is more to look at here.


Take care,
Al

E boa sorte com sua programacao Euphoria!


My bumper sticker: "I brake for LED's"

 From "Black Knight":
"I can live with losing the good fight,
 but i can not live without fighting it".
"Well on second thought, maybe not."

20. Re: ? 1={}, is there really any other interpretation?

• Posted by Pete Lomax <petelomax at blueyond?r.co.?k> Jul 16, 2007
• 713 views

Andy Serpa wrote:
> the answer is, of course, just to ADD NEW OPERATORS -- just add a colon (or
> whatever) to each operator to make it a strict boolean operator:
> 
> :<
> :=
> :>
> 
> etc.
> 
> Problem solved.  No code breaks, and you've got some nice shortcuts so you
> never
> have to type compare().  What's the problem with that?
Some reasons why it should be @< to specify a sequence op rather than
:< to specify an atomic op:
1) Over 99.95% of existing operator usage is atomic.
2) It should be possible for one deviation in parser.e to process
   new @-ops whereas :-ops would probably want to be interleaved?
   (Specifically I am thinking that UFactor could have the one test
    if tok[T_ID]>=SPLUS and tok[T_ID]<=SXOR then invoke a new parse
    chain of SExpr->Srexpr->Scexpr->Saexpr->Sterm->SUFactor->Factor
    else ->Factor as now, iyswim.)
3) :-ops add to rather than decrease (newbie) confusion.
    return name="pete" is the natural thing to type.
    replacing "use equal()" with "use :=" is less than helpful.
    Eg name@="pete" makes it clear I want lots of 1s and 0s.
4) ":=" looks very misleading to this particular ex-Pascal student.

Rob: Perhaps instead of asking "should we kill off sequence ops", which
I am not advocating, it is the IMPLICIT part that causes problems, the
questions that should be asked (as well) are:
  Do we want short-circuiting in all expressions? This cannot be done
   as long as "and" & "or" are sequence-op-capable, but could be if
   "and" became atom-only and either "@and" or "sq_and()" created to
   replace that particular functionality, ditto "or".
  Do we want the 'if name="pete" then' gotcha to go away and instead
   for such expressions to work as humans expect?
  Do we want expressions to have the same meaning wherever they occur
   or behave different in if/while to assign/params?

Regards,
Pete

ERROR: Your rant quota has been exceeded.
       To increase this limit call 555-407-6565.

22. Re: ? 1={}, is there really any other interpretation?

• Posted by Derek Parnell <ddparnell at b?gpond.c?m> Jul 17, 2007
• 666 views

Robert Craig wrote:
> 
> Pete Lomax wrote:
> > Rob: Perhaps instead of asking "should we kill off sequence ops", which
> > I am not advocating, it is the IMPLICIT part that causes problems, the
> > questions that should be asked (as well) are:
> >   Do we want short-circuiting in all expressions? 
> 
> In an ideal world, that might be nice.

And one must never strive to make this an ideal world, of course.
 
> > This cannot be done
> > as long as "and" & "or" are sequence-op-capable, but could be if
> > "and" became atom-only and either "@and" or "sq_and()" created to
> > replace that particular functionality, ditto "or".
> 
> I think it's a bit late in the game to change the semantics 
> of "and", "or", "=", or any other operator when applied to sequences.
> 
> > Do we want the 'if name="pete" then' gotcha to go away and instead
> > for such expressions to work as humans expect?
> 
> Humans who were brought up on Basic are very disturbed by this.

And a whole host of other programming languages and human languages! 

> Humans who were brought up on C, think it's fine. 

And this is the majority of people nowadays, right?

In the newer C-family languages such as C++, C#, D, and Objective C one can
write 'if (name=="pete")'.

> In C you don't
> say: 
>     if (name == "pete")  
> You say:
>     if (strcmp(name, "pete") == 0)

And this has always been a mistake in my opinion, but as C was designed to be a
minimulist high-level assembler that does not have a native dynamic array or
string type, it makes sense as a compromise. But it doesn't make C a good
language.

> Since I was brought up on C (and APL, which works like Euphoria in
> this regard), I really can't see why people are so determined
> to replace:
>    if equal(a, b) then
> by something like:
>    if a == b then
>
> I don't see why that is so important.

You like consistency right? 

  integer  intA, intB
  sequence seqA, seqB

  if intA = intB -- This works
  if seqA = seqB -- This fails 

Duh!

How many times do you or anyone else write 'if equal(intA, intB)'?

> There wouldn't be any speed advantage,
> and we'd constantly have newbies asking
> what the difference is between == and =,
> and experienced users also frequently forgetting.

Instead, we have newbies writing the obvious 'if seqA = seqB' and wondering what
the difference is between 'equal()' and '='.

And this doesn't even begin to address the non-intuitive 'compare()' function
instead of the obvious '<', '>', '<=', '>='.

  if compare(seqA, seqB) >= 0 then --- Huh? Why the zero?

  if seqA >= seqB then --- Oh, is that what you really mean?

THE PURPOSE OF A PROGRAMMING LANGUAGE IS TO MAKE IT EASIER FOR HUMANS TO READ
PROGRAMS. Any programming language that creates a 'huh?' response in a human
reader of code, needs help.

Euphoria has mostly got it right, Robert. You are to be congratulated for that.
But there really are some parts of it that make humans work harder at
understanding the written code than is really necessary.

I don't see why you think it is not important to make Euphoria a
better-for-humans language.

> > Do we want expressions to have the same meaning wherever they occur
> > or behave different in if/while to assign/params?
> 
> In the context of an if/while/elsif we know that an expression 
> can't produce a sequence as it's overall result, otherwise it 
> would be an error, so we are "free" to sometimes ignore the 
> remainder of the expression, and assume we are dealing with atoms only. 

In your opinion! To re-phrase ...

 In the context of an if/while/elsif we know that an expression 
 can't produce a sequence as it's overall result, otherwise it 
 would be an error, so people naturally assume we are dealing
 with a logical expression (a comparision).

> Short-circuiting was retrofitted into Euphoria, and this little 
> trick made it possible. I realize things aren't as clean in this area 
> as they might be, but if you really want s.c. you can always change:
>    x = logical_expression
> into:
>    if logical-expression then
>        x = 1
>    else
>        x = 0
>    end if
> 
> to get short circuiting.

Why would someone think that 'name > "pete"' is not a logical expression in the
'if' statement?

And when it comes to things like ...

  x = name > "pete"

to me LOOKS like I'm setting 'x' to true/false depending on whether or not
'name' contains a string whose value is greater than the string "pete".

If for some rare reason I actually wanted to do a sequence operation, then I'd
appreciate using a different method - either a new operator or a function-like
construct.

  x = name [>] "pete"
  x = seq_gt(name, "pete")

These are rarely used operations and I firmly believe that breaking code is
justified if improves the language for (the many?) future users.

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

24. Re: ? 1={}, is there really any other interpretation?

• Posted by CChris <christian.cuvier at agric??ture.gouv.fr> Jul 17, 2007
• 672 views

Derek Parnell wrote:
> 
> Robert Craig wrote:
> > 
> > Pete Lomax wrote:
> > > Rob: Perhaps instead of asking "should we kill off sequence ops", which
> > > I am not advocating, it is the IMPLICIT part that causes problems, the
> > > questions that should be asked (as well) are:
> > >   Do we want short-circuiting in all expressions? 
> > 
> > In an ideal world, that might be nice.
> 
> And one must never strive to make this an ideal world, of course.
>  
> > > This cannot be done
> > > as long as "and" & "or" are sequence-op-capable, but could be if
> > > "and" became atom-only and either "@and" or "sq_and()" created to
> > > replace that particular functionality, ditto "or".
> > 
> > I think it's a bit late in the game to change the semantics 
> > of "and", "or", "=", or any other operator when applied to sequences.
> > 
> > > Do we want the 'if name="pete" then' gotcha to go away and instead
> > > for such expressions to work as humans expect?
> > 
> > Humans who were brought up on Basic are very disturbed by this.
> 
> And a whole host of other programming languages and human languages! 
> 
> > Humans who were brought up on C, think it's fine. 
> 
> And this is the majority of people nowadays, right?
> 
> In the newer C-family languages such as C++, C#, D, and Objective C one can
> write 'if (name=="pete")'.
> 
> > In C you don't
> > say: 
> >     if (name == "pete")  
> > You say:
> >     if (strcmp(name, "pete") == 0)
> 
> And this has always been a mistake in my opinion, but as C was designed to be
> a minimulist high-level assembler that does not have a native dynamic array
> or string type, it makes sense as a compromise. But it doesn't make C a good
> language.
> 
> > Since I was brought up on C (and APL, which works like Euphoria in
> > this regard), I really can't see why people are so determined
> > to replace:
> >    if equal(a, b) then
> > by something like:
> >    if a == b then
> >
> > I don't see why that is so important.
> 
> You like consistency right? 
> 
>   integer  intA, intB
>   sequence seqA, seqB
> 
>   if intA = intB -- This works
>   if seqA = seqB -- This fails 
> 
> Duh!
> 
> How many times do you or anyone else write 'if equal(intA, intB)'?
> 
> > There wouldn't be any speed advantage,
> > and we'd constantly have newbies asking
> > what the difference is between == and =,
> > and experienced users also frequently forgetting.
> 
> Instead, we have newbies writing the obvious 'if seqA = seqB' and wondering
> what the difference is between 'equal()' and '='. 
> 
> And this doesn't even begin to address the non-intuitive 'compare()' function
> instead
> of the obvious '<', '>', '<=', '>='.
> 
>   if compare(seqA, seqB) >= 0 then --- Huh? Why the zero?
> 
>   if seqA >= seqB then --- Oh, is that what you really mean?
> 
> THE PURPOSE OF A PROGRAMMING LANGUAGE IS TO MAKE IT EASIER FOR HUMANS TO READ
> PROGRAMS. Any programming language that creates a 'huh?' response in a human
> reader of code, needs help. 
> 
> Euphoria has mostly got it right, Robert. You are to be congratulated for
> that.
> But there really are some parts of it that make humans work harder at
> understanding
> the written code than is really necessary. 
> 
> I don't see why you think it is not important to make Euphoria a
> better-for-humans
> language.
> 
> > > Do we want expressions to have the same meaning wherever they occur
> > > or behave different in if/while to assign/params?
> > 
> > In the context of an if/while/elsif we know that an expression 
> > can't produce a sequence as it's overall result, otherwise it 
> > would be an error, so we are "free" to sometimes ignore the 
> > remainder of the expression, and assume we are dealing with atoms only. 
> 
> In your opinion! To re-phrase ...
> 
>  In the context of an if/while/elsif we know that an expression 
>  can't produce a sequence as it's overall result, otherwise it 
>  would be an error, so people naturally assume we are dealing
>  with a logical expression (a comparision).
> 
> > Short-circuiting was retrofitted into Euphoria, and this little 
> > trick made it possible. I realize things aren't as clean in this area 
> > as they might be, but if you really want s.c. you can always change:
> >    x = logical_expression
> > into:
> >    if logical-expression then
> >        x = 1
> >    else
> >        x = 0
> >    end if
> > 
> > to get short circuiting.
> 
> Why would someone think that 'name > "pete"' is not a logical expression in
> the 'if' statement?
> 
> And when it comes to things like ...
> 
>   x = name > "pete"
> 
> to me LOOKS like I'm setting 'x' to true/false depending on whether or not
> 'name'
> contains a string whose value is greater than the string "pete".
> 
> If for some rare reason I actually wanted to do a sequence operation, then I'd
> appreciate using a different method - either a new operator or a function-like
> construct. 
> 
>   x = name [>] "pete"
>   x = seq_gt(name, "pete")
> 
> These are rarely used operations and I firmly believe that breaking code is
> justified if improves the language for (the many?) future users.
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

But... but....
Euphoria doesn't have a native string type, hence }}}
<eucode>name > "Pete"</eucode>
{{{

CANNOT be an atom in a consistent way. "strings" are arrays, and a relational op
between arrays is supposed to return an array imho. Hence, even if it is not
ideal, the current way of doing things is probably the less problematic.

When Euphoria is able to store strings as 1 or 2 bytes a character, which is how
every OS stores and passes strings, and has operators to act upon these new
objects almost as if they were atoms, then you may have a point. And many
programs will become easier both to read and write - let's not forget this last
part.

CChris

26. Re: ? 1={}, is there really any other interpretation?

• Posted by CChris <christian.cuvier at agric?lture.gouv.f?> Jul 17, 2007
• 658 views

Derek Parnell wrote:
> 
> CChris wrote:
> > But... but....
> > Euphoria doesn't have a native string type,
> 
> Didn't say it did. 

Sure, but that's the root problem imho, see below.

> 
> > hence 'name > "Pete"' CANNOT be an atom in a consistent way. 
> 
> I disagree with the implied imperative in your use of 'hence'. You see, it all
> depends on what one means by the symbol '>'? To me, that symbol means 'compare
> the left and right operands with each other to determine which of them has the
> greater value'. I agree that when Euphoria current applies this symbol to
> operands,
> when at least one of them is a sequence, the symbol means 'compare each
> respective
> element, recursively, to form a new sequence that has the results of each
> atomic
> comparision'. 
> 
> My point is that when humans see '>' they tend to think 'is A bigger than
> B' rather than 'give me something that shows if each part of A is bigger than
> B'
> 

I agree with you. However, treating '>' and friends this way means that Euphoria
treats strings almost like atoms, so that }}}
<eucode>"Pete" > "Lomax"</eucode>
{{{
 is
treated the same as }}}
<eucode>5 > 3</eucode>
{{{
. Then the use of '>' you push for
would be consistent with the rest of the language, and it would help.

> 
> > "strings" are arrays, and a relational op between arrays is supposed to
> > return an array imho. 
> 
> So when somebody asks you does "Harris" come before or after "Harmon", you
> reply
> with {1,1,1,0,1,0}?

No, but that's because I have a native string type, while Eu doesn't.

> 
> > Hence, even if it is not ideal, the current way of doing things
> > is probably the less problematic.
> 
> "less problematic" than what? Than doing it they way most people tend to
> think?

As said above: Euphoria does not treat strings as almost atoms, and your stated
change in the meaning of '>' is not consistent with its current state, hence
would be more problematic if performed now.

The current use is consistent with the remainder of the language, and is less
problematic _in that framework_ as a result. It is (perhaps) less convenient, I
agree with this again.

> 
> > When Euphoria is able to store strings as 1 or 2 bytes a character,
> > which is how every OS stores and passes strings, and has operators
> > to act upon these new objects almost as if they were atoms, then
> > you may have a point.
> 
> I have a point now, actually. To make it easier for humans to create programs
> is why we have programming languages, therefore the languages should help
> humans
> do their job. Keeping poorer aspects of a language in place needs to be
> justified,
> as does changing them. We need to examine, empirically, the true cost of
> making
> Euphoria better. 

Definitely. Note how separating strings from general purpose sequences would
have other positive side effects - on print() for instance. Not mentioning better
support for DBCS strings.

> 
> Andy Serpa seems to be stating that 60% of all his expressions that involve
> the comparision operators are actually sequence operations. I'd like to see
> further analysis of other people's code before deciding if its worth
> attempting
> to improve Euphoria in this aspect.
> 
> > And many programs will become easier both to read and write
> > - let's not forget this last part.
> 
> I assume you mean easier when Euphoria treats comparision operators as
> operations
> that compare the operands as if they were entities in their own right as
> opposed
> to recursive lists of atomic entities. 

Not exactly. I meant "when it treats strings as entities in their own right".
Then the most consistent behaviour of comparison operators would become the one
you suggest, and the change will become an improvement. I'm not sure it would if
carried out now. That was my whole point.

> Yes, that would be easier to read an
> write than the current situation.
> 

CChris

> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

28. Re: ? 1={}, is there really any other interpretation?

• Posted by Derek Parnell <ddparnell at bigpond.??m> Jul 17, 2007
• 665 views

ChrisBurch2 wrote:

> > If for some rare reason I actually wanted to do a sequence operation, then
> > I'd
> > appreciate using a different method - either a new operator or a
> > function-like
> > construct. 
> > 
> >   x = name [>] "pete"
> 
> huh?

I agree. This was just a quick example of something that might be an operator. I
was not advocating this exact syntax or any specific syntax at this point. I
still talking concepts.
 
> >   x = seq_gt(name, "pete")
> > 
> > These are rarely used operations and I firmly believe that breaking code is
> > justified if improves the language for (the many?) future users.
> > 
> 
> This is the dangerous bit. While progress is good, breaking previous code is
> most definitely not - the more advanced programmers will have little
> difficulty
> migrating, but the mid class (eg me) would struggle for a while - I would get
> there eventually of course. However, would this in fact not be more confusing
> for 
> newbies? Ie an ettempt to make the code even more human readable, may in fact
> have the reverse effect.


And exactly how much of your code would break if we made comparision operators
behave intuitively in 'if' and 'while' statements? None! Because if you were
doing that now your code is already broken. And outside of these constrtucts I
suspect that almost no-one will be badly affected, notwithstanding Andy's 60%
analysis. A quick check on Andy's public code shows that he uses sequence
operations using '=', '>', '<' etc.. exactly zero times. He even uses compare()
on operands that are known to be atoms.

The case for breaking existing code must be based on actual empirical usage and
not guessitmates on what and who will be affected.

If it turns out that the cost of fixing existing code is too steep then we won't
change, but if it is not more costly than perpetually having non-intuitive
constructs then change should be considered.

 
> Whats wrong with compare?

Nothing per se, but to be consistant Euphoria coders should always use it rather
than sometime use compare and sometimes use comparision operators.

> Yes, there is an initial learning curve, but this would be true for any
> programming language.
> 
> >   if intA = intB -- This works
> >   if seqA = seqB -- This fails 
> 
> Of course that should fail, one is an integer, and one is a sequence. This
> seems
> obvious to me, after I have had the errors thrown up, and searched for, and
> 
> asked in this forum many times - this is part of the learning progress.

And it feels good when one stops hitting one's head too. So I guess I better
stop arguing for this 'cos I'm not going to convince anyone.

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

30. Re: ? 1={}, is there really any other interpretation?

• Posted by ChrisBurch3 <crylex at ?mail.co?> Jul 17, 2007
• 687 views

Derek Parnell wrote:
> 
> ChrisBurch2 wrote:
> 
> > > If for some rare reason I actually wanted to do a sequence operation, then
> > > I'd
> > > appreciate using a different method - either a new operator or a
> > > function-like
> > > construct. 
> > > 
> > >   x = name [>] "pete"
> > 
> > huh?
> 
> I agree. This was just a quick example of something that might be an operator.
> I was not advocating this exact syntax or any specific syntax at this point.
> I still talking concepts.
>  
> > >   x = seq_gt(name, "pete")
> > > 
> > > These are rarely used operations and I firmly believe that breaking code
> > > is
> > > justified if improves the language for (the many?) future users.
> > > 
> > 
> > This is the dangerous bit. While progress is good, breaking previous code is
> > most definitely not - the more advanced programmers will have little
> > difficulty
> > migrating, but the mid class (eg me) would struggle for a while - I would
> > get
> > there eventually of course. However, would this in fact not be more
> > confusing
> > for 
> > newbies? Ie an ettempt to make the code even more human readable, may in
> > fact
> > have the reverse effect.
> 
> 
> And exactly how much of your code would break if we made comparision operators
> behave intuitively in 'if' and 'while' statements? None! Because if you were
> doing that now your code is already broken. And outside of these constrtucts
> I suspect that almost no-one will be badly affected, notwithstanding Andy's
> 60% analysis. A quick check on Andy's public code shows that he uses sequence
> operations using '=', '>', '<' etc.. exactly zero times. He even uses
> compare() on operands that are known to be atoms.
> 
> The case for breaking existing code must be based on actual empirical usage
> and not guessitmates on what and who will be affected.
> 
> If it turns out that the cost of fixing existing code is too steep then we
> won't
> change, but if it is not more costly than perpetually having non-intuitive
> constructs
> then change should be considered.
> 
>  
> > Whats wrong with compare?
> 
> Nothing per se, but to be consistant Euphoria coders should always use it
> rather
> than sometime use compare and sometimes use comparision operators.
> 
> > Yes, there is an initial learning curve, but this would be true for any
> > programming language.
> > 
> > >   if intA = intB -- This works
> > >   if seqA = seqB -- This fails 
> > 
> > Of course that should fail, one is an integer, and one is a sequence. This
> > seems
> > obvious to me, after I have had the errors thrown up, and searched for, and
> > 
> > asked in this forum many times - this is part of the learning progress.
> 
> And it feels good when one stops hitting one's head too. So I guess I better
> stop arguing for this 'cos I'm not going to convince anyone.
> 

On the contrary Derek, don't stop arguing for it. My fear is that existing 
code would break in the name of progress, not that new constructs could be used,
which at the same time would NOT break existing code. I'm not against progress,
just against change for change's sake.

Regards

Chris

> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

32. Re: ? 1={}, is there really any other interpretation?

• Posted by Al Getz <Xaxo at aol??om> Jul 17, 2007
• 667 views

Juergen Luethje wrote:
> 
> Al Getz wrote:
> 
> <snip>
> 
> > Well, one could argue along two lines here:
> > 1.  The smaller hole is not contained within the larger hole so big
> >     hole still empty
> > 2.  The smaller hole just makes the larger hole larger (extension).
> > I guess that we could call this a 'system' of holes, that contains
> > many holes, but that wouldnt be right either because we would have
> > to have two words to describe this, system and holes, and a sequence
> > is still just a sequence even if it holds other sequences.
> 
> <snip>
> 
> Other interesting thoughts about holes:
> <<a
> href="http://plato.stanford.edu/entries/holes/">http://plato.stanford.edu/entries/holes/</a>>
> 
> 
> Regards,
>    Juergen


Hi Juergen,


Thanks for the link.  The article is short but at least it addresses
the philosophy of holes.  Now what we need is an article that 
addresses the philosophy of sequences 

Perhaps some day we will define the only 'true' hole as a place
in space that is totally void of anything but Higgs particles 
Lets get going CERN !


Take care,
Al

E boa sorte com sua programacao Euphoria!


My bumper sticker: "I brake for LED's"

 From "Black Knight":
"I can live with losing the good fight,
 but i can not live without fighting it".
"Well on second thought, maybe not."

34. Re: ? 1={}, is there really any other interpretation?

• Posted by Andy Serpa <ac at oneh?rse?hy.com> Jul 17, 2007
• 698 views

Messed up one example.  Getting the sequence indexes should be:

s = {1,10,3,4,30}
indexes_of_elements_greater_than_5 = ilist(length(s)) * (s > 5)
indexes_of_elements_greater_than_5 =
filter(indexes_of_elements_greater_than_5,indexes_of_elements_greater_than_5)

Need the last line to filter out the zeros...

36. Re: ? 1={}, is there really any other interpretation?

• Posted by Andy Serpa <ac at oneho?se?hy.com> Jul 17, 2007
• 672 views
• Last edited Jul 18, 2007

c.k.lester wrote:
> 
> Andy Serpa wrote:
> 
> > No one ever uses code like this?  It makes things so easy because
> > the boolean mask sequence can be made so easily with one operator.
> 
> I used to use it all the time until I found out that loops are faster. :/
> 
Not everything gets looped through a million times.  If it is, I spend time to
use the fastest method.  But if it doesn't have to be, it is hard to beat writing
one or two short simple lines.  Sequence ops are slower when they create an extra
sequence or two in the process that gets thrown out -- my boolean masks are all
this way, but again, unless you're looping many times it doesn't matter.

Your example just alters a single sequence -- does some math.  That has always
been quite fast I think...

38. Re: ? 1={}, is there really any other interpretation?

• Posted by Robert Craig <rds at RapidE?ph?ria.com> Jul 17, 2007
• 663 views
• Last edited Jul 18, 2007

c.k.lester wrote:
> Sequence ops aren't that slow anymore...? Were they in the past? Rob?

In 1.5a I speeded up most sequence ops on integers by about 30%,
by adding an end marker on each sequence. This eliminated
one test per element.

There is no simple rule of thumb that will tell you whether
a sequence op will be faster than a loop. Usually there is
not much difference, and you should write the code in
the simplest, easiest to understand way. Some factors
that come into play:

   * the cost per element is generally lower for sequence ops

   * the cost of allocating/deallocating space for sequences 
     adds overhead to sequence ops. Short sequences will be 
     affected more by this.

   * very long sequences may suffer from not being able to fit
     into the on-chip CPU data cache, so you end up reading them
     from slower RAM memory

   * doing multiple ops on an element while you have it in cache
     is better than doing one op and storing the result in a long
     temporary sequence that doesn't fit into cache. i.e. making many
     passes through long sequences in RAM. This factor favors atomic
     ops in loops.

   * use of the Translator will speed up loops of atomic ops,
     especially integer ops, but won't speed up sequence ops much at all

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

40. Re: ? 1={}, is there really any other interpretation?

• Posted by Derek Parnell <ddparnell at b?gpo?d.com> Jul 18, 2007
• 689 views

Andy Serpa wrote:
> 
> Some ways I frequently use sequence ops.
> 
> 
> Here's a function I use all the time:
> 
> }}}
<eucode>
> global function filter(sequence mask, sequence s)
> sequence s2
> integer c
> 	c = 0
> 	s2 = repeat(0,length(s))
> 	for i = 1 to length(s) do
> 		if mask[i] then
> 			c += 1
> 			s2[c] = s[i]
> 		end if
> 	end for
> 	return s2[1..c]
> end function
> </eucode>
{{{


Here are slightly faster versions ...

function filter(sequence mask, sequence s)
integer c
     c = 0
     for i = 1 to length(s) do
             if mask[i] then
                     c += 1
                     s[c] = s[i]
             end if
     end for
     return s[1..c]
end function

function filter_index(sequence mask, sequence s)
integer c
     c = 0
     for i = 1 to length(s) do
             if mask[i] then
                     c += 1
                     s[c] = i
             end if
     end for
     return s[1..c]
end function

> No one ever uses code like this?  It makes things so
> easy because the boolean mask sequence can be made so
> easily with one operator.

Can't say I've even needed to do this type of thing.

> Really no one uses code like this?  Why not?

It's too slow, and maybe it can be a bit hard to read for those not used to this
style of programming.

>  I find constructions like this useful in practically 
> every application.  I primarily do data processing and
> number crunching, but still it seems to be useful quite
> often.  This to me is the power of Euphoria.  With a
> few supporting functions I use as part of my standard
> library, I can accomplish so much with only a line or two.

> Not to mention the ease of doing math on whole sequences
> (or even matrices) at once.  Isn't it nice to be able to type
> 
> s/100 instead of looping through s and dividing each element?
> 
> How about this:
> 
> }}}
<eucode>
> s = ((s>=5)*(s*10)) + ((s<5)*(s*100))
> </eucode>
{{{

> 
> In a single line I've multiplied the elements of s that
> are greater or equal to 5 by 10, and the ones that are
> less than 5 by 100.  This particular construction
> is slow in a loop, which is why I want a built in
> conditional operator which could do it more efficiently,

I'm not a big fan of brevity for the sake of brevity. Sometimes extra lines can
give more understanding to the code reader.

Anyhow, I've set up a non-trival test program to see if my gut feel about the
performance was justified. This test counts the vowels in a text file and does
the 'maths' example you described above.

-- TESTING speed of sequence operations

integer vRID

function filter_index(sequence mask, sequence s)
integer c
     c = 0
     for i = 1 to length(s) do
             if mask[i] then
                     c += 1
                     s[c] = i
             end if
     end for
     return s[1..c]
end function

function TestLoop(sequence pLine)
    integer lCnt

    lCnt = 0

    for i = 1 to length(pLine) do
        if find(pLine[i], "aeiouAEIOU") then
            lCnt += 1
        end if
    end for

    return lCnt
end function

function TestSeqOp(sequence pLine)
    integer lCnt
    sequence lRes

    lCnt = 0
    lRes =
        pLine = 'a' or
        pLine = 'e' or
        pLine = 'i' or
        pLine = 'o' or
        pLine = 'u' or
        pLine = 'A' or
        pLine = 'E' or
        pLine = 'I' or
        pLine = 'O' or
        pLine = 'U'

    for i = 1 to length(lRes) do
        lCnt += lRes[i]
    end for

    return lCnt

end function

function TestFilter1(sequence pLine)
     return length(filter_index(
                        pLine = 'a' or
                        pLine = 'e' or
                        pLine = 'i' or
                        pLine = 'o' or
                        pLine = 'u' or
                        pLine = 'A' or
                        pLine = 'E' or
                        pLine = 'I' or
                        pLine = 'O' or
                        pLine = 'U',
                      pLine))

end function

function TestFilter2(sequence pLine)
    return
        length(filter_index(pLine = 'a', pLine)) +
        length(filter_index(pLine = 'e', pLine)) +
        length(filter_index(pLine = 'i', pLine)) +
        length(filter_index(pLine = 'o', pLine)) +
        length(filter_index(pLine = 'u', pLine)) +
        length(filter_index(pLine = 'A', pLine)) +
        length(filter_index(pLine = 'E', pLine)) +
        length(filter_index(pLine = 'I', pLine)) +
        length(filter_index(pLine = 'O', pLine)) +
        length(filter_index(pLine = 'U', pLine))

end function

function MathSeqOp(sequence pLine)
    pLine = ((pLine>='a')*(pLine*10)) + ((pLine<'a')*(pLine*100))

    for i = 2 to length(pLine) do
        pLine[1] += pLine[i]
    end for

    return pLine[1]
end function

function MathLoop(sequence pLine)
    object x
    for i = 1 to length(pLine) do
        x = pLine[i]
        if sequence(x) then
            x = MathLoop(x)
        else
            if x >= 'a' then
                x *= 10
            else
                x *= 100
            end if
        end if
        pLine[i] = x
    end for

    for i = 2 to length(pLine) do
        pLine[1] += pLine[i]
    end for

    return pLine[1]
end function


procedure main(sequence pArgs)
    sequence lFileName
    integer lFH
    object lLine
    atom lCnt
    atom lStartTime

    lFileName = ""
    vRID = -1

    for i = 3 to length(pArgs) do
        if equal(pArgs[i], "-loop") then
            vRID = routine_id("TestLoop")
        elsif equal(pArgs[i], "-filter1") then
            vRID = routine_id("TestFilter1")
        elsif equal(pArgs[i], "-filter2") then
            vRID = routine_id("TestFilter2")
        elsif equal(pArgs[i], "-seqop") then
            vRID = routine_id("TestSeqOp")
        elsif equal(pArgs[i], "-mathloop") then
            vRID = routine_id("MathLoop")
        elsif equal(pArgs[i], "-mathseqop") then
            vRID = routine_id("MathSeqOp")
        else
            lFileName = pArgs[i]
        end if
    end for

    if vRID = -1 then
        puts(1, "You must specify a valid test option:\n" &
                "  One of -loop, -seqop, -filter1, -filter2," &
                " -mathloop, -mathseqop\n")
        abort(1)
    end if

    if length(lFileName) = 0 then
        puts(1, "No file name supplied\n")
        abort(1)
    end if

    lFH = open(lFileName, "r")
    if lFH = -1 then
        puts(1, "File '" & lFileName & "' cannot be opened.\n")
        abort(1)
    end if

    lStartTime = time()
    lCnt = 0
    lLine = gets(lFH)
    while sequence(lLine) do
        if lLine[$] = 10 then
            lLine = lLine[1 .. $-1]
        end if
        if length(lLine) > 0 then
            lCnt += call_func(vRID, {lLine})
        end if

        lLine = gets(lFH)
    end while

    close(lFH)

    printf(1, "Result is %g\n", lCnt)
    printf(1, "Time elapsed is %f seconds\n", time() - lStartTime)

end procedure


main(command_line())
---------------------- end of program --------------------

Here are the results I got ...

C:\temp>dir y:\contest\file5.txt
 Volume in drive Y is DJP Personal
 Volume Serial Number is 10FE-E052

 Directory of y:\contest

05/11/2004  02:05 PM         4,982,742 file5.txt
               1 File(s)      4,982,742 bytes
               0 Dir(s)      70,768,640 bytes free

C:\temp>exwc test.ex y:\contest\file5.txt -loop
Result is 1.35768e+006
Time elapsed is 0.570000 seconds

C:\temp>exwc test.ex y:\contest\file5.txt -seqop
Result is 1.35768e+006
Time elapsed is 2.410000 seconds

C:\temp>exwc test.ex y:\contest\file5.txt -filter1
Result is 1.35768e+006
Time elapsed is 2.570000 seconds

C:\temp>exwc test.ex y:\contest\file5.txt -filter2
Result is 1.35768e+006
Time elapsed is 2.910000 seconds

C:\temp>exwc test.ex y:\contest\file5.txt -mathloop
Result is 1.04628e+010
Time elapsed is 1.090000 seconds

C:\temp>exwc test.ex y:\contest\file5.txt -mathseqop
Result is 1.04628e+010
Time elapsed is 2.190000 seconds


These tests seem to be saying that looping in these cases is significantly
faster than sequence operations. I'd appreciate it if you guys can demonstrate
the flaws in my tests.
 
> but the fact that I can manipulate a sequence in two
> different ways so easily with single line is not useful
> to anyone else?

Not to me, sorry. If the performance was there maybe I'd reconsider.

> Or you simply have always done it another way?

Apparently I do. I tend to use the 'iterator' pattern instead.

   FOR EACH ITEM IN LIST
   {
       IF ITEM SATIFIES CONDITION
       {
           PROCESS ITEM
       }
   }

There maybe an argument for such a pattern to be supported by native syntax in
Euphoria ... something like ...

   foreach <x> in <s> where <cond> do
       <statements>
   end foreach

as in 

   foreach char in pLine where find(char, "aeiouAEIOU") do
        lCnt += 1
   end foreach


-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

42. Re: ? 1={}, is there really any other interpretation?

• Posted by Juergen Luethje <j.lue at ?mx?de> Jul 18, 2007
• 609 views

Rob wrote:

<snip>

> There was a built-in function in APL that did this.
> It was used a great deal. This would add value to 
> relational and logical sequence ops, something people here 
> were complaining they rarely used. Maybe someone should write 
> a fast "filter" built-in routine in C code (assuming a majority want it). 
> In many cases it might still be faster to use atomic ops in a loop 
> for this, but this would probably be quite handy.

I agree. In another post, you wrote about several other built-in
functions in APL, and how useful they had been.

A long time ago, I tried to use built-in sequence operations in Euphoria
whenever possible, because at that time I had assumed that they are
aöways faster than loops. In most cases I ended up with 'for' or 'while'
loops instead, just because what I wanted to do was not possible with
built-in sequence operations.

So if built-in sequence operations should really become an important
feature of Euphoria (like it had been in APL), Euphoria actually should
provide more support for it (like there had been in APL).
Besides a filter() routine, functions such as sum(s), min(s), max(s)
spontaneously come to my mind.

Regards,
   Juergen

44. Re: ? 1={}, is there really any other interpretation?

• Posted by Andy Serpa <ac at ?neh?rseshy.com> Jul 19, 2007
• 629 views

Pete Lomax wrote:

> 
> SUMMARY:
> As noted above, in no way do I expect you to be chomping at the bit for a
> chance to apply such changes (as if), but the above is basically what the
> proposal would [probably] mean you'd have to do.
> 
> I always knew there would be a cost to bear, and it seems you would bear
> the biggest burden. But I have to say it seems bearable if you are somehow 
> convinced of a greater good.
> 
> Again I thank you for the examples posted and am personally very pleased
> to note that they would all fail "loudly" rather than in some obscure and 
> difficult to track down way, under the proposal. I do accept that rarely
> executed parts of the code could prove harder to find.
> 
> Regards,
> Pete
> PS Naturally, I am assuming the above changes could be made to impose an
> undetectable runtime performance hit, not that such appears to worry you.


You seem to think I posted my examples as "arguments" meant to convince you (and
others) of something.  They were just examples.  I have no need to prove to you
that I actually use code in the way I use it.  I'm not arguing that those
constructions are "superior", merely that those are some things that are
possible.  In the past in these discussions, we've had people posting that they
didn't even realize a = (a = b) was legal Euphoria syntax.

My point is that you have to give some weight -- some MASSIVE weight -- to the
fact that Euphoria is the way it is, and has been for years & years.  If you were
talking about creating a new language not called Euphoria I wouldn't say a thing
about it.  There is nothing wrong with your ideas except for the fact that it
will make every program I've got NO LONGER WORK.  You've got to have a better
reason than "well, it should have been done my way originally" if you are going
to make non-backward compatible changes.  "I don't like typing that" is not a
real compelling reason.  It won't even just break code -- i.e. crashes -- it will
keep some code keep running, but working differently!  Your proposal is on the
order of, "Hey everyone, let's swap the definitions of the English words 'food'
and 'poison'.  Don't worry, it won't confuse anyone and nothing bad will happen."
It is a big F.U. to anyone that has been USING THE LANGUAGE AS IT IS AND HAS BEEN
FOREVER and saying, "You may no longer upgrade to new versions of Euphoria
because all the programs you wrote in the last 10 years won't work anymore."

It is TOO LATE to do what you want the way you want it -- it is NOT AN OPTION. 
You can have the functionality you want, you JUST CAN'T HAVE IT BY CHANGING HOW
EXISTING OPERATORS ALREADY WORK.  To do so is absolute madness.  So you are left
with creating new functions for the new functionality you want, or creating new
operators that previously didn't exist in the language, i.e. @>, etc.  That is a
compromise we can all live with...