1. How Come This Binary Op Doesn't Work?
- Posted by c.k.lester <euphoric at cklester.?om>
Jul 13, 2007
-
Last edited Jul 14, 2007
sequence temp
integer bool
temp = {}
bool = atom(temp) and temp = 1
bool keeps getting set to an empty sequence, not 0.
What's up with that?!?!
2. Re: How Come This Binary Op Doesn't Work?
- Posted by Tristen B Wilson <twilsonwoody at h?tmail.com>
Jul 13, 2007
-
Last edited Jul 14, 2007
c.k.lester wrote:
>
> }}}
<eucode>sequence temp
> integer bool
>
> temp = {}
>
> bool = atom(temp) and temp = 1</eucode>
{{{
>
> bool keeps getting set to an empty sequence, not 0.
Temp has Nothing! No atoms, sequences. Try Splicing or using length(temp).
subscripting is easily used.
3. Re: How Come This Binary Op Doesn't Work?
- Posted by Pete Lomax <petelomax at blueyonder.co.?k>
Jul 13, 2007
-
Last edited Jul 14, 2007
c.k.lester wrote:
>
> }}}
<eucode>sequence temp
> integer bool
>
> temp = {}
>
> bool = atom(temp) and temp = 1</eucode>
{{{
>
> bool keeps getting set to an empty sequence, not 0.
>
> What's up with that?!?!
{} = <any atom> will always yield {}.
<any atom> and {} falls foul of the short circuiting in Eu.
Within an if expression it will yield false if the LHS is false,
but in an assignment it will always yield {}.
This is standard sequence op behaviour.
What you probably need to do is:
bool=False
if atom(temp) and temp=1 then
bool=True
end if
One of the many reasons I never liked sequence ops.
Regards,
Pete
4. Re: How Come This Binary Op Doesn't Work?
- Posted by Jason Gade <jaygade at ya?oo.com>
Jul 13, 2007
-
Last edited Jul 14, 2007
c.k.lester wrote:
>
> }}}
<eucode>sequence temp
> integer bool
>
> temp = {}
>
> bool = atom(temp) and temp = 1</eucode>
{{{
>
> bool keeps getting set to an empty sequence, not 0.
>
> What's up with that?!?!
I was testing this. What's happening is the interpreter sees "temp = 1" as a
sequence operation.
If you set temp to {1, 0, 1} and then print temp = 1 you get {1, 0, 1}. See what
I'm saying?
See http://www.rapideuphoria.com/refman_2.htm#26
Plus, short-circuiting only works in if and while statements. Another reason for
that not to work.
You're gonna have to wrap your expression in an if statement.
--
"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.
5. Re: How Come This Binary Op Doesn't Work?
- Posted by c.k.lester <euphoric at cklester?com>
Jul 13, 2007
-
Last edited Jul 14, 2007
Thanks, Pete and Jason... I thought short-circuiting worked in those cases. :/
6. Re: How Come This Binary Op Doesn't Work?
- Posted by c.k.lester <euphoric at ckleste?.com>
Jul 13, 2007
-
Last edited Jul 14, 2007
Tristen B Wilson wrote:
> c.k.lester wrote:
> > }}}
<eucode>sequence temp
> > integer bool
> > temp = {}
> > bool = atom(temp) and temp = 1</eucode>
{{{
> > bool keeps getting set to an empty sequence, not 0.
> Temp has Nothing! No atoms, sequences. Try Splicing or using length(temp).
> subscripting is easily used.
Technically, temp is a sequence with no elements.
7. Re: How Come This Binary Op Doesn't Work?
- Posted by Jason Gade <jaygade at y?hoo.com>
Jul 13, 2007
-
Last edited Jul 14, 2007
Pete Lomax wrote:
>
> One of the many reasons I never liked sequence ops.
>
> Regards,
> Pete
I like the idea behind sequence ops, but are they really used that often?
When I was doing Computer Language Shootout stuff I tried to find ways to use
sequence ops but for the kinds of benchmarks they had sequence ops were either
more difficult to implement or sometimes even slower than the more obvious
implementations.
Now if sequence ops used some kind of SIMD instructions in the interpreter and
were actually faster than iterating, that would be nice. But then that version of
the interpreter wouldn't run on older machines.
Just musing.
--
"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.
8. Re: How Come This Binary Op Doesn't Work?
- Posted by Al Getz <Xaxo at aol.?om>
Jul 13, 2007
-
Last edited Jul 14, 2007
Hi,
It appears that the equals sign, when used in that context, is best
not used with sequences or when the result of another operation
might result in a sequence that gets used with the equals sign.
My guess is that other logical type operations like that dont
work either, like != for example.
The following are ok:
?1=1
?1=0
?0=0
while these are different:
?1={}
?{}=1
?{}={}
?1 and {}
and interesting is:
?1 and {23,2,0} --{1,1,0}
Note this works ok:
temp = {}
bool = sequence(temp) and (1=1)
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."
9. Re: How Come This Binary Op Doesn't Work?
Jason Gade wrote:
>
> Pete Lomax wrote:
> >
> > One of the many reasons I never liked sequence ops.
> >
> I like the idea behind sequence ops, but are they really used that often?
See:
http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=6&fromYear=1&toMonth=7&toYear=C&postedBy=&keywords=Lomax+win32lib+edita+arwen+sequence+ops
In summary: as at 22/2/07, I found a total of 37 uses in wildcard.e(2),
Edita(11, I quashed the lot), Arwen(6, ditto, on my/the edita copy), and
win32lib(18, Derek may have since quashed some), in over 87,000 lines of code.
That is less that once per 2000 lines, not counting the sources that I found no
examples in, and all that were found were easily replaceable at zero to minimal
runtime cost.
> Now if sequence ops used some kind of SIMD instructions ...
> were actually faster than iterating, that would be nice.
In my experience, not directly with Eu, on the 286 and before this stuff was
great, on the 386 (the first chip with a decent on-chip cache), this kind of
stuff was astonishing, especially if code & data all fit on chip - again not
directly Eu but I saw 8-fold-plus gains. So I can see why one might have writ
such in the early 90s. But for the past ten years or more cpu designs show very
little to no gains for sequence ops. You can prove this, I have.
Ripping them wholesale out of the language is so clearly to me a great idea, but
not one I can give the great argument/explain the gains for. I guess I hit a
brick wall with the fact that allowing eg:
if name="Pete" then
does not appear to be a good enough excuse ;-((.
Regards,
Pete
10. Re: How Come This Binary Op Doesn't Work?
Pete Lomax wrote:
>
> Jason Gade wrote:
> >
> > Pete Lomax wrote:
> > >
> > > One of the many reasons I never liked sequence ops.
> > >
> > I like the idea behind sequence ops, but are they really used that often?
> See: <a
> href="http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=6&fromYear=1&toMonth=7&toYear=C&postedBy=&keywords=Lomax+win32lib+edita+arwen+sequence+ops">http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=6&fromYear=1&toMonth=7&toYear=C&postedBy=&keywords=Lomax+win32lib+edita+arwen+sequence+ops</a>
>
> In summary: as at 22/2/07, I found a total of 37 uses in wildcard.e(2),
> Edita(11,
> I quashed the lot), Arwen(6, ditto, on my/the edita copy), and win32lib(18,
> Derek may have since quashed some), in over 87,000 lines of code. That is less
> that once per 2000 lines, not counting the sources that I found no examples
> in, and all that were found were easily replaceable at zero to minimal runtime
> cost.
Huh. More than I expected...
>
> > Now if sequence ops used some kind of SIMD instructions ...
> > were actually faster than iterating, that would be nice.
> In my experience, not directly with Eu, on the 286 and before this stuff was
> great, on the 386 (the first chip with a decent on-chip cache), this kind of
> stuff was astonishing, especially if code & data all fit on chip - again
> not directly Eu but I saw 8-fold-plus gains. So I can see why one might have
> writ such in the early 90s. But for the past ten years or more cpu designs
> show
> very little to no gains for sequence ops. You can prove this, I have.
>
> Ripping them wholesale out of the language is so clearly to me a great idea,
I dunno, it still seems to be very "Euphorian" to have them -- I just think they
need to be better somehow.
> but not one I can give the great argument/explain the gains for. I guess I hit
> a brick wall with the fact that allowing eg:
> }}}
<eucode>
> if name="Pete" then
> </eucode>
{{{
> does not appear to be a good enough excuse ;-((.
>
> Regards,
> Pete
Heh, we've discussed this one a lot. Short-circuiting works differently in if
and while statements, why not sequence ops?
--
"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.
11. Re: How Come This Binary Op Doesn't Work?
Jason Gade wrote:
> Heh, we've discussed this one a lot. Short-circuiting works differently in >
> if and while statements,
For any particular reason? Erm, NO.
> why not sequence ops?
You asking me whether we should bastardize the semantics of the language in a
similar way to perserve sequence ops? Erm, NO.
Regards,
Pete
PS Short-circuiting works exactly the same in if and while statements, of
course, but different in assignment statements, I think you meant.
PPS I have yet to find a single example in live code where non-short-ciruit in
assignment is actually taken advantage of - anyone know of any?
PPPS Short circuiting works exactly the same in if, while, and assignment
statements etc in Positive, albeit maybe 2.57 times slower than Eu2c'd stuff,
plus hitches, but I work on that, and gain ground every day 
.
12. Re: How Come This Binary Op Doesn't Work?
Pete Lomax wrote:
>
> Jason Gade wrote:
> > Heh, we've discussed this one a lot. Short-circuiting works differently in >
> if and while statements, </font></i>
> For any particular reason? Erm, NO.
> > why not sequence ops?
> You asking me whether we should bastardize the semantics of the language in
> a similar way to perserve sequence ops? Erm, NO.
>
> Regards,
> Pete
>
> PS Short-circuiting works exactly the same in if and while statements, of
> course,
> but different in assignment statements, I think you meant.
>
> PPS I have yet to find a single example in live code where non-short-ciruit
> in assignment is actually taken advantage of - anyone know of any?
It took me a bit to understand what you meant, and then I had my "ah-ha!"
moment. Of course, short-circuiting works in all expressions in C and it makes
sense to do so. It would in Euphoria, too. It shouldn't cause any kind of
performance hit, especially when a short-circuit path is taken. In fact, it
should be a performance benefit if done correctly.
I still vote for comparison operators to work in 'if' and 'while' statements
like they do in any other language.
--
"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.
13. Re: How Come This Binary Op Doesn't Work?
c.k.lester wrote:
> }}}
<eucode>sequence temp
> integer bool
>
> temp = {}
>
> bool = atom(temp) and temp = 1</eucode>
{{{
>
> bool keeps getting set to an empty sequence, not 0.
>
> What's up with that?!?!
A comparison such as
temp = 1
only works as you'd expect when you are sure that 'temp' is an atom.
If 'temp' is or might be a sequence, and you also don't want those
special sequence operations to take place, then use 'equal()' instead
of '='.
bool = atom(temp) and equal(temp,1)
works fine.
BTW: This is old news, but it's so easy to forget it. 
Regards,
Juergen
14. Re: How Come This Binary Op Doesn't Work?
Me wrote:
> c.k.lester wrote:
>
> > }}}
<eucode>sequence temp
> > integer bool
> >
> > temp = {}
> >
> > bool = atom(temp) and temp = 1</eucode>
{{{
> >
> > bool keeps getting set to an empty sequence, not 0.
> >
> > What's up with that?!?!
>
> A comparison such as
> temp = 1
> only works as you'd expect when you are sure that 'temp' is an atom.
> If 'temp' is or might be a sequence, and you also don't want those
> special sequence operations to take place, then use 'equal()' instead
> of '='.
>
> bool = atom(temp) and equal(temp,1)
> works fine.
>
> BTW: This is old news, but it's so easy to forget it.
Erm ...
It's not necessary anyway to use
atom(temp)
here. Just use
bool = equal(temp, 1)
Regards,
Juergen
