1. math operators
PREFACE
I'm still not a C programmer, but operators appear to be
more logical to me. Easier to use. But that's just my
opinion.
POWER
I would love to see power(4, 5) become 4^5.
I know that we wouldn't be able to get read of power()
Shouldn't move it to an include either. Since it is a
built-in. Of course, I would also like to see many others.
BITWISE OPERATORs
compare() become ==
and_bits() become &&
or_bits() become ||
or at least see them used as operators. Such as:
if (int1 and_bits int2) then
if (int2 or_bits int2) then
end if
end if
But that wouldn't be backwards compatible. :(
also there is modulo and integer divide
MODULO
I've always thought it odd that we didn't have a modulo
operator. We have remainder(). Why not have (5 % 3)
or (5 mod 3) or even (5 modulo 3)
INTEGER DIVIDE
We have floor(5/3). Is 5\3 just too confusing?
I like % for modulo because it looks like a fancy divide.
Look at this.
5%3 -- remainder - modulo
5/3 -- divide
5\3 -- integer divide
They all are related and they all look similiar.
if (you_have_a_computer_problem) then
blame("Microsoft")
reason("because everyone else does.")
end if
Lucius L. Hilley III - Unkmar
2. Re: math operators
Jon wrote:
>> Lucius Hilley wrote:
>>
>> POWER
>> I would love to see power(4, 5) become 4^5.
>> I know that we wouldn't be able to get read of power()
>
> YES! i prefer "^" but another alternative is "**" (like Ruby)
I never saw a program, that uses '++' as alternative for '*', or '--' as
alternative for '/'. I know, that there are some programs that use '**'
as alternative for '^', but I don't see any reason, why that should be
useful.
The following text explains, why I prefer 'power(x,y)' to 'x^y':
Math operations of the same priority, such as 7+5+1, are normally
evaluated from left to right, if no parentheses are used. OK.
And how about the power operator? What is the result of
2^3^2 ?
Mathematically, evaluation is right to left for the power operator! So
2^3^2 = 2^(3^2) = 2^9 = 512.
But there seems to be a kind of "industry standard", that says that such
expressions should be calculated from left to right. That means:
2^3^2 = (2^3)^2 = 8^2 = 64
For example all PowerBASIC versions that I know, and AFAIK also Visual
Basic calculates such expressions this way.
I have a pocket calculator that doesn't perform it's calculation until
the entire expression has been entered (very nice, BTW).
It returns 64 for 2^3^2, too (which is false, strictly mathematically
speaking).
IMHO, this situation is very strange.
And Euphoria completly avoids this dilemma by using a 'power()' function,
instead of a power operator!!! I was very pleased, when I noticed that.
So beside Euphorias obvious elegance, it has some "hidden elegance",
that cannot be seen at the first glance.
>> BITWISE OPERATORs
>> compare() become ==
>> and_bits() become &&
>> or_bits() become ||
>>
>> or at least see them used as operators. Such as:
>> if (int1 and_bits int2) then
>> if (int2 or_bits int2) then
>> end if
>> end if
>> But that wouldn't be backwards compatible. :(
>
> again, yes!
No, please!
I'm happy that Euphoria code is very good readable ATM.
I would not be happy to see anything that makes it less readable.
<snip>
Regards,
Juergen
--
Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
3. Re: math operators
compare() and equal() arent bitwise function technically, to be sure.
Of course, if calling them bitwise is what it takes to turn them into
operators, then I'll call them bitwise. ;D
jbrawn
On Fri, Sep 19, 2003 at 10:31:13PM -0400, Lucius Hilley wrote:
>
>
> > compare() become ==
>
> I meant equal() become ==
>
> if ("this" == "this") then -- TRUE
> puts(1, "TRUE\n")
> end if
>
>
> Lucius L. Hilley III
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
--
"Life can be unbearable but it will never become better until one accepts this
and moves on." - Someone
4. Re: math operators
On Sat, Sep 20, 2003 at 11:08:26AM -0400, jbrown105 at speedymail.org wrote:
>
>
> compare() and equal() arent bitwise function technically, to be sure.
>
> Of course, if calling them bitwise is what it takes to turn them into
> operators, then I'll call them bitwise. ;D
>
> jbrawn
err, jbrown
>
> On Fri, Sep 19, 2003 at 10:31:13PM -0400, Lucius Hilley wrote:
> >
> >
> > > compare() become ==
> >
> > I meant equal() become ==
> >
> > if ("this" == "this") then -- TRUE
> > puts(1, "TRUE\n")
> > end if
> >
> >
> > Lucius L. Hilley III
> >
> >
> > TOPICA - Start your own email discussion group. FREE!
> >
> >
> --
> "Life can be unbearable but it will never become better until one accepts this
> and moves on." - Someone
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
--
"Life can be unbearable but it will never become better until one accepts this
and moves on." - Someone
5. Re: math operators
>From: Juergen Luethje <j.lue at gmx.de>
>Subject: Re: math operators
>
>Jon wrote:
>
> >> Lucius Hilley wrote:
> >>
> >> POWER
> >> I would love to see power(4, 5) become 4^5.
> >> I know that we wouldn't be able to get read of power()
> >
> > YES! i prefer "^" but another alternative is "**" (like Ruby)
>
>
>I never saw a program, that uses '++' as alternative for '*', or '--' as
>alternative for '/'. I know, that there are some programs that use '**'
>as alternative for '^', but I don't see any reason, why that should be
>useful.
>
In C, ++ is equivalent to +=1 and -- is equivalent to -=1, in most cases.
Pointers complicate things of course. Powers are repeated multiplication, so
** somewhat makes sense for this, but of course, multiplication is repeated
addition, so someone might just think it is ++. I have seen ** in a few
other languages.
>
>The following text explains, why I prefer 'power(x,y)' to 'x^y':
>
>Math operations of the same priority, such as 7+5+1, are normally
>evaluated from left to right, if no parentheses are used. OK.
>
>And how about the power operator? What is the result of
> 2^3^2 ?
>
>Mathematically, evaluation is right to left for the power operator! So
> 2^3^2 = 2^(3^2) = 2^9 = 512.
>
I think the problem here is that it is hard to tell what you mean when
the exponents are not in superscript. I think the way you see it, 2^3^2 is 2
with a superscript 3 to the upper right, and the 3 has a superscript 2 to
the upper right of it. The "industry standard" sees it as (2^3)^2, ie, 2
with a superscript 3, all in brackets, and then with a superscript 2 for the
brackets. 2^(3^2) translates to 2^9, which is 512, but (2^3)^2 is 2^(3 * 2),
then 2^6, making 64. This is the major problem with the power symbol. It is
too ambigous to tell which form was meant. Even C had this problem, and
decided to go with the pow() function. (For those who thought ^ was power,
it really is bitwise XOR.)
>But there seems to be a kind of "industry standard", that says that such
>expressions should be calculated from left to right. That means:
> 2^3^2 = (2^3)^2 = 8^2 = 64
>
This right-to-left thing really depends on how you think 2^3^2 should look
on paper. Mathematics does say that expressions are evaluated left-to-right,
no matter what. It is because you see it as 2^(3^2) that makes the
difference.
>For example all PowerBASIC versions that I know, and AFAIK also Visual
>Basic calculates such expressions this way.
>I have a pocket calculator that doesn't perform it's calculation until
>the entire expression has been entered (very nice, BTW).
>It returns 64 for 2^3^2, too (which is false, strictly mathematically
>speaking).
>
My calculator, which does the same thing, evaluates it to 64, as well.
>IMHO, this situation is very strange.
>And Euphoria completly avoids this dilemma by using a 'power()' function,
>instead of a power operator!!! I was very pleased, when I noticed that.
>
Yes, this situation is quite annoying. However, proper use of brackets, to
clarify your meaning, will fix the problem.
>So beside Euphorias obvious elegance, it has some "hidden elegance",
>that cannot be seen at the first glance.
>
>
6. Re: math operators
On Sat, 20 Sep 2003 16:50:39 +0200, Juergen Luethje <j.lue at gmx.de>
wrote:
>And how about the power operator? What is the result of
> 2^3^2 ?
>
>Mathematically, evaluation is right to left for the power operator! So
> 2^3^2 =3D 2^(3^2) =3D 2^9 =3D 512.
>
>But there seems to be a kind of "industry standard", that says that such
>expressions should be calculated from left to right. That means:
> 2^3^2 =3D (2^3)^2 =3D 8^2 =3D 64
When I wrote the expression evaluator for my report generator, I snuck
^ in and found EXACTLY that example! After thinking about it a while,
I made the operator non-associative so if you key that expression it
complains "ambiguous: add parenthesis".
>>> BITWISE OPERATORs
>>> compare() become =3D=3D
>>> and_bits() become &&
>>> or_bits() become ||
>>>
>>> or at least see them used as operators. Such as:
>>> if (int1 and_bits int2) then
>>> if (int2 or_bits int2) then
>>> end if
>>> end if
>>> But that wouldn't be backwards compatible. :(
>>
>> again, yes!
>
>No, please!
>I'm happy that Euphoria code is very good readable ATM.
>I would not be happy to see anything that makes it less readable.
As an aside, I based my expression evaluator on a paper by Thomas
Niemann (http://epaperpress.com/oper/index.html) which, as the author
admits, has some unusual effects: All of the following evaluate to 25:
power 5 2
power() 5 2
power(5) 2
power(5,2)
5 power 2
5 power() 2
5 power(2)
5 2 power()
^ 5 2
5^2
5 2 ^
If anyone is interested, I'll clean it up and post it. Maybe someone
with a fresh perspective can fix that for me.
I also support and_bits and or_bits, which can also be written infix.
Elliot wrote:
>(For those who thought ^ was power, it really is bitwise XOR.)
Yes, you're probably right. I think I'll remove the ^ operator.
Regards,
Pete
7. Re: math operators
- Posted by kbochert at copper.net
Sep 21, 2003
On 21 Sep 2003 at 2:06, Pete Lomax wrote:
>
>
> On Sat, 20 Sep 2003 16:50:39 +0200, Juergen Luethje <j.lue at gmx.de>
> wrote:
>
> >And how about the power operator? What is the result of
> > 2^3^2 ?
> >
> >Mathematically, evaluation is right to left for the power operator! So
> > 2^3^2 = 2^(3^2) = 2^9 = 512.
> >
> >But there seems to be a kind of "industry standard", that says that such
> >expressions should be calculated from left to right. That means:
> > 2^3^2 = (2^3)^2 = 8^2 = 64
>
> When I wrote the expression evaluator for my report generator, I snuck
> ^ in and found EXACTLY that example! After thinking about it a while,
> I made the operator non-associative so if you key that expression it
> complains "ambiguous: add parenthesis".
>
> >>> BITWISE OPERATORs
> >>> compare() become ==
> >>> and_bits() become &&
> >>> or_bits() become ||
> >>>
> >>> or at least see them used as operators. Such as:
> >>> if (int1 and_bits int2) then
> >>> if (int2 or_bits int2) then
> >>> end if
> >>> end if
> >>> But that wouldn't be backwards compatible. :(
> >>
> >> again, yes!
> >
> >No, please!
> >I'm happy that Euphoria code is very good readable ATM.
> >I would not be happy to see anything that makes it less readable.
>
> As an aside, I based my expression evaluator on a paper by Thomas
> Niemann (http://epaperpress.com/oper/index.html) which, as the author
> admits, has some unusual effects: All of the following evaluate to 25:
> power 5 2
> power() 5 2
> power(5) 2
> power(5,2)
> 5 power 2
> 5 power() 2
> 5 power(2)
> 5 2 power()
> ^ 5 2
> 5^2
> 5 2 ^
>
> If anyone is interested, I'll clean it up and post it. Maybe someone
> with a fresh perspective can fix that for me.
>
I think this is an unjustly-ignored parsing technique. It is considerably faster
than a
recursive-descent parser, and much easier to follow and debug (for me at least).
The weirdness refered to above can be removed by checking for the alternation of
operands and operators.
Karl Bochert
8. Re: math operators
On Sat, 20 Sep 2003 19:52:29 -0700, kbochert at copper.net wrote:
>> If anyone is interested, I'll clean it up and post it. Maybe someone
>> with a fresh perspective can fix that for me.
>>=20
>
>I think this is an unjustly-ignored parsing technique. It is =
considerably faster than a=20
>recursive-descent parser, and much easier to follow and debug (for me at=
least).
>The weirdness refered to above can be removed by checking for the =
alternation of=20
>operands and operators.
I'll take that as a firm offer then 
. I've posted it up on my web
page: http://palacebuilders.pwp.blueyonder.co.uk/euphoria.html
Pete
9. Re: math operators
Pete wrote:
> On Sat, 20 Sep 2003 16:50:39 +0200, Juergen Luethje <j.lue at gmx.de>
> wrote:
>
>> And how about the power operator? What is the result of
>> 2^3^2 ?
>>
>> Mathematically, evaluation is right to left for the power operator! So
>> 2^3^2 = 2^(3^2) = 2^9 = 512.
>>
>> But there seems to be a kind of "industry standard", that says that such
>> expressions should be calculated from left to right. That means:
>> 2^3^2 = (2^3)^2 = 8^2 = 64
>
> When I wrote the expression evaluator for my report generator, I snuck
> ^ in and found EXACTLY that example!
> After thinking about it a while,
> I made the operator non-associative so if you key that expression it
> complains "ambiguous: add parenthesis".
Very nice! That's the best choice in that situation IMHO.
<snip>
> As an aside, I based my expression evaluator on a paper by Thomas
> Niemann (http://epaperpress.com/oper/index.html) which, as the author
> admits, has some unusual effects: All of the following evaluate to 25:
> power 5 2
> power() 5 2
> power(5) 2
> power(5,2)
> 5 power 2
> 5 power() 2
> 5 power(2)
> 5 2 power()
> ^ 5 2
> 5^2
> 5 2 ^
LOL! Unusual indeed.
<snip>
Regards,
Juergen
--
Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
10. Re: math operators
Elliott wrote:
>> From: Juergen Luethje <j.lue at gmx.de>
>>
>>>> Lucius Hilley wrote:
>>>>
>>>> POWER
>>>> I would love to see power(4, 5) become 4^5.
>>>> I know that we wouldn't be able to get read of power()
<snip>
>> The following text explains, why I prefer 'power(x,y)' to 'x^y':
>>
>> Math operations of the same priority, such as 7+5+1, are normally
>> evaluated from left to right, if no parentheses are used. OK.
>>
>> And how about the power operator? What is the result of
>> 2^3^2 ?
>>
>> Mathematically, evaluation is right to left for the power operator! So
>> 2^3^2 = 2^(3^2) = 2^9 = 512.
>>
>
> I think the problem here is that it is hard to tell what you mean when
> the exponents are not in superscript. I think the way you see it, 2^3^2 is 2
> with a superscript 3 to the upper right, and the 3 has a superscript 2 to
> the upper right of it. The "industry standard" sees it as (2^3)^2, ie, 2
> with a superscript 3, all in brackets, and then with a superscript 2 for the
> brackets. 2^(3^2) translates to 2^9, which is 512, but (2^3)^2 is 2^(3 * 2),
> then 2^6, making 64. This is the major problem with the power symbol. It is
> too ambigous to tell which form was meant. Even C had this problem, and
> decided to go with the pow() function. (For those who thought ^ was power,
> it really is bitwise XOR.)
Ah, interesting.
>> But there seems to be a kind of "industry standard", that says that such
>> expressions should be calculated from left to right. That means:
>> 2^3^2 = (2^3)^2 = 8^2 = 64
>>
> This right-to-left thing really depends on how you think 2^3^2 should look
> on paper. Mathematics does say that expressions are evaluated left-to-right,
> no matter what. It is because you see it as 2^(3^2) that makes the
> difference.
Yes, on paper -- if written tidyly -- it's unambiguous even
without brackets. On paper it looks somehow like:
2
3
2
The math rules say: "Evaluate that from the top to the bottom."
That can be translated to: "Evaluate that from right to left."
If we want to write that in a single line, then we get something like:
2^3^2
Now there is no top and no bottom any more. Only the rule
"Evaluate that from right to left." is left (no pun intended).
>> For example all PowerBASIC versions that I know, and AFAIK also Visual
>> Basic calculates such expressions this way.
>> I have a pocket calculator that doesn't perform it's calculation until
>> the entire expression has been entered (very nice, BTW).
>> It returns 64 for 2^3^2, too (which is false, strictly mathematically
>> speaking).
>>
> My calculator, which does the same thing, evaluates it to 64, as well.
>
>> IMHO, this situation is very strange.
>> And Euphoria completly avoids this dilemma by using a 'power()' function,
>> instead of a power operator!!! I was very pleased, when I noticed that.
>>
> Yes, this situation is quite annoying. However, proper use of brackets, to
> clarify your meaning, will fix the problem.
Yes. But I believe, that many people are not aware of this problem, and
so it's rather likely, that they won't use brackets at all.
A good solution is then -- as Pete wrote -- that the software complains
about an ambiguous expression.
Regards,
Juergen
--
The difference between men and boys
is the price of their toys.
