www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - operator ** for 'power'

reply "Lionello Lunesu" <lio lunesu.removethis.com> writes:
How about adding an operator ** for 'to the power' ?

I know there's no single CPU instruction to do 'x to the power n' with 
integers (only floats, right?) but it seems silly that you need a library 
function to be able to do 'to the power'.

Maybe 'x**n' should simply always return a float?

Definately not important, I know.

L.
Mar 08 2005
next sibling parent reply "Alex Stevenson" <ans104 cs.york.ac.uk> writes:
On Tue, 8 Mar 2005 17:32:01 +0200, Lionello Lunesu  
<lio lunesu.removethis.com> wrote:


 How about adding an operator ** for 'to the power' ?

 I know there's no single CPU instruction to do 'x to the power n' with
 integers (only floats, right?) but it seems silly that you need a library
 function to be able to do 'to the power'.

 Maybe 'x**n' should simply always return a float?

 Definately not important, I know.

 L.


I think there's a problem disambiguating x**n - it could be 'x to the  
power n' or x * *n - 'x times the contents of pointer n'



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Mar 08 2005
parent reply "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Alex Stevenson" <ans104 cs.york.ac.uk> skrev i en meddelelse 
news:opsnbu9fmu08qma6 mjolnir.spamnet.local...

 How about adding an operator ** for 'to the power' ?


 I think there's a problem disambiguating x**n - it could be 'x to the 
 power n' or x * *n - 'x times the contents of pointer n'


That is not really a problem. If wanted, the lexer could identify "**" as a 
power operator just as "--" is identified as a decrement operator; ie. it is 
no worse than:

    x - -n

compared to

    x--n

Regards,
Martin
Mar 08 2005
parent reply "Nick Sabalausky" <z a.a> writes:
"Martin M. Pedersen" <martin moeller-pedersen.dk> wrote in message 
news:d0lhcv$p72$1 digitaldaemon.com...

 "Alex Stevenson" <ans104 cs.york.ac.uk> skrev i en meddelelse 
 news:opsnbu9fmu08qma6 mjolnir.spamnet.local...

 How about adding an operator ** for 'to the power' ?


 I think there's a problem disambiguating x**n - it could be 'x to the 
 power n' or x * *n - 'x times the contents of pointer n'


 That is not really a problem. If wanted, the lexer could identify "**" as 
 a power operator just as "--" is identified as a decrement operator; ie. 
 it is no worse than:

    x - -n

 compared to

    x--n

 Regards,
 Martin


Is that really a valid analogy, though? 'x--n' is an invalid way of 
expressing the decrement operator (it amounts to either '(x--)n' or 
'x(--n)', both of which are invalid), so wouldn't that make it easier for 
the compiler to determine that it means 'x - -n'?

Making 'x**n' mean "raised to a power" would be just like giving a special 
meaning to 'x--n', which *would* cause confusion with 'x - -n'.
Mar 09 2005
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Nick Sabalausky wrote:
<snip>

 Is that really a valid analogy, though? 'x--n' is an invalid way of 
 expressing the decrement operator (it amounts to either '(x--)n' or 
 'x(--n)', both of which are invalid), so wouldn't that make it easier for 
 the compiler to determine that it means 'x - -n'?


<snip>

We'd need to either make the lexer dependent on the parser, or 
explicitly define

     AddExpression :: AddExpression -- MulExpression

This suffers from the same old ambiguity for as long as the old C cast 
syntax remains in the language.  But even when this is got rid of,

     a -- * b

could mean either

     (a--) * b

or

     a -- (*b)

Moreover, why would one want to write 'x--n' in preference to 'x+n'? 
And even if a class defines them to be different, it goes without saying 
that you'll need a space.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Mar 09 2005
prev sibling parent reply "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Nick Sabalausky" <z a.a> skrev i en meddelelse 
news:d0n2rd$2e6b$1 digitaldaemon.com...

    x - -n
 compared to
    x--n


 Is that really a valid analogy, though? 'x--n' is an invalid way of 
 expressing the decrement operator (it amounts to either '(x--)n' or 
 'x(--n)', both of which are invalid), so wouldn't that make it easier for 
 the compiler to determine that it means 'x - -n'?


It is perfectly good analogy. '--' is a token in its own right, and there is 
no way you can convince the compiler that you mean binary-substract + 
unary-minus using it. This is a consequence of the "maximal munch technique" 
described at http://www.digitalmars.com/d/lex.html - the same technique also 
emplyed by C and C++ compilers.

It you look at http://www.digitalmars.com/d/expression.html#UnaryExpression 
you will see, that unary-minus ('-') and dereference ('*') are placed just 
besides each other in the grammer. Likewise, binary-substract and 
binary-multiply are placed almost at the same level in the grammer - just a 
slight difference to give multiply a slightly higher priority than 
substract.

So, it is basically the same, and we have already lived happily with the 
ambiguity for decades.

Regards,
Martin
Mar 09 2005
parent reply "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Martin M. Pedersen" <martin moeller-pedersen.dk> skrev i en meddelelse 
news:d0n7uk$2kj4$1 digitaldaemon.com...

 So, it is basically the same, and we have already lived happily with the 
 ambiguity for decades.


Now I think of it, it might introduce slight problems after all. Noone uses 
two successive '-' meaning unary-minus + unary-minus, simply because it 
would be a silly expression to write. Therefore, there is no conflict with 
'--' as decrement. However, two successive '*' meaning double dereference is 
quite common, and introducing '**' would break existing code. The fix is 
easy though - just insert a space.

Regards,
Martin
Mar 09 2005
parent reply "Lionello Lunesu" <lio lunesu.removethis.com> writes:
(nothing)**(pointer) would mean a double dereference, but 
(identifier)**(identifier) can't possibly be anything else than 'to the 
power' ? Or doesn't the parsing work this way? Probably not context-free 
this way, right?

L.
Mar 09 2005
parent pragma <pragma_member pathlink.com> writes:
In article <d0nl50$2sl$1 digitaldaemon.com>, Lionello Lunesu says...

(nothing)**(pointer) would mean a double dereference, but 
(identifier)**(identifier) can't possibly be anything else than 'to the 
power' ? Or doesn't the parsing work this way? Probably not context-free 
this way, right?

L. 


Still looks a touch confusing IMO.  Why not use ^^ and be done with it?


 const uint MEGABYTE = 1024^^2;


I don't forsee it being at all confusing since the xor operator (^) seems to
only get special use anyway.  Plus there is no valid grammar that reads like
this already, so its context free and compiler friendly to add.

I'd also like to propose the signature of 'opPower()' for overloading as well.

- EricAnderton at yahoo
Mar 09 2005
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Lionello Lunesu wrote:

 How about adding an operator ** for 'to the power' ?


*Could* break some existing code....


 I know there's no single CPU instruction to do 'x to the power n' with 
 integers (only floats, right?) but it seems silly that you need a library 
 function to be able to do 'to the power'.
 
 Maybe 'x**n' should simply always return a float?


Not sure what to say about the return type.  Possibilities:

- define it by the same rules as the other arithmetic operators

- return ulong if applied to unsigned integers, otherwise long if 
applied to integers, otherwise usual rules

- return ulong if applied to unsigned integers, otherwise long if 
applied to integers, otherwise real

- always return a real

Of course, exponentiating integers doesn't produce an integer if the 
exponent is negative.  But we discard the fractional part with integer 
division, so why not?

Whatever we do, it should be capable of generating an exact result 
within the range of long/ulong (and cent/ucent when we get them).

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Mar 08 2005
parent reply "Lionello Lunesu" <lio lunesu.removethis.com> writes:
Hey,


 How about adding an operator ** for 'to the power' ?


 *Could* break some existing code....


Not really, n**x with 'x' being a pointer to a float/int would 'cause a 
compile error, complaining that you can't raise 'n' to the power of 'a 
pointer'. And a new feature causing an error doesnot really break existing 
code, since you'll have to fix the incompatibility (using the hint in the 
error message).


 Of course, exponentiating integers doesn't produce an integer if the 
 exponent is negative.  But we discard the fractional part with integer 
 division, so why not?


That's right. Good point. The thing is that in code it will always use 
'fpow' meaning that'll always return a float/real internally and then cast 
them to integers if called on integers. Might need a performance warning.

L.
Mar 09 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Lionello Lunesu wrote:

 Hey,
 
 

How about adding an operator ** for 'to the power' ?


*Could* break some existing code....


 
 
 Not really, n**x with 'x' being a pointer to a float/int would 'cause a 
 compile error, complaining that you can't raise 'n' to the power of 'a 
 pointer'. And a new feature causing an error doesnot really break existing 
 code, since you'll have to fix the incompatibility (using the hint in the 
 error message).


Before you consider operator overloads....


 Of course, exponentiating integers doesn't produce an integer if the 
 exponent is negative.  But we discard the fractional part with integer 
 division, so why not?


 
 That's right. Good point. The thing is that in code it will always use 
 'fpow' meaning that'll always return a float/real internally and then cast 
 them to integers if called on integers. Might need a performance warning.


Always?  We certainly shouldn't have the loss of precision on integers. 
  For this to work, every long and ulong would need to be expressible 
exactly as a real - I'm not sure if this is true of the 80-bit reals, 
but it won't be true on platforms where real is only 64-bit.  Moreover, 
are the platforms on which we will support cent going to have a 160-bit 
real to be a superset of it?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Mar 09 2005
prev sibling next sibling parent reply "uframer" <uframer sina100.com.cn> writes:
please think about pointer syntax.
"Lionello Lunesu" <lio lunesu.removethis.com>
写入消息新闻:d0kghi$2meh$1 digitaldaemon.com...

 How about adding an operator ** for 'to the power' ?

 I know there's no single CPU instruction to do 'x to the power n' with 
 integers (only floats, right?) but it seems silly that you need a library 
 function to be able to do 'to the power'.

 Maybe 'x**n' should simply always return a float?

 Definately not important, I know.

 L.
Mar 08 2005
parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:
"uframer" <uframer sina100.com.cn> wrote in message 
news:d0kns7$2uhm$1 digitaldaemon.com...

 please think about pointer syntax.


Yes, you're right, but 'n**x' can't really be interpreted any other way, 
since you'll get an error if 'x' is a pointer ('can't raise to the power of 
a pointer')

L.
Mar 09 2005
prev sibling next sibling parent reply "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Lionello Lunesu" <lio lunesu.removethis.com> skrev i en meddelelse 
news:d0kghi$2meh$1 digitaldaemon.com...

 I know there's no single CPU instruction to do 'x to the power n' with 
 integers (only floats, right?) but it seems silly that you need a library 
 function to be able to do 'to the power'.


Real programmers think binary and does not need any other power operator 
than '<<' :-)

Regards,
Martin
Mar 08 2005
next sibling parent reply "Lionello Lunesu" <lio lunesu.removethis.com> writes:
I KNEW I'd get at least one such response :-) And yeah, you're right.

In fact, I got the ** idea when I was defining some constant, 1024*1024, and 
thought 'it would be nice to do 1024**2' and then thought 'I should simply 
write 1048576' closely followed by the though 'I should write 2<<20'..

L.

"Martin M. Pedersen" <martin moeller-pedersen.dk> wrote in message 
news:d0lkto$sil$1 digitaldaemon.com...

 "Lionello Lunesu" <lio lunesu.removethis.com> skrev i en meddelelse 
 news:d0kghi$2meh$1 digitaldaemon.com...

 I know there's no single CPU instruction to do 'x to the power n' with 
 integers (only floats, right?) but it seems silly that you need a library 
 function to be able to do 'to the power'.


 Real programmers think binary and does not need any other power operator 
 than '<<' :-)

 Regards,
 Martin
Mar 09 2005
parent reply "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Lionello Lunesu" <lio lunesu.removethis.com> skrev i en meddelelse 
news:d0n7nn$2kc7$1 digitaldaemon.com...

I KNEW I'd get at least one such response :-) And yeah, you're right.
 In fact, I got the ** idea when I was defining some constant, 1024*1024, 
 and thought 'it would be nice to do 1024**2' and then thought 'I should 
 simply write 1048576' closely followed by the though 'I should write 
 2<<20'..


Now I see why '**' would have some value to you :-)

Regards,
Martin
Mar 09 2005
parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:
Would have saved me at least 1 minute thinking about the alternatives (and 
another two writing my post)...

Actually, I think I can summarize my position on this something like this:

All the instructions of modern CPU's should be accessible from the core 
languages, without the need for libraries.

OK, I can see the problems with this statement, MMX, SSE, etc.. Well maybe 
vector operations should imply the usage of these? And then there's inline 
assembly and I can just as well code my own 'fpow' without the need of a 
library.

Like I said, not so important.

L.

"Martin M. Pedersen" <martin moeller-pedersen.dk> wrote in message 
news:d0n9dr$2m6e$1 digitaldaemon.com...

 "Lionello Lunesu" <lio lunesu.removethis.com> skrev i en meddelelse 
 news:d0n7nn$2kc7$1 digitaldaemon.com...

I KNEW I'd get at least one such response :-) And yeah, you're right.
 In fact, I got the ** idea when I was defining some constant, 1024*1024, 
 and thought 'it would be nice to do 1024**2' and then thought 'I should 
 simply write 1048576' closely followed by the though 'I should write 
 2<<20'..


 Now I see why '**' would have some value to you :-)

 Regards,
 Martin
Mar 09 2005
prev sibling parent reply "Nick Sabalausky" <z a.a> writes:
"Martin M. Pedersen" <martin moeller-pedersen.dk> wrote in message 
news:d0lkto$sil$1 digitaldaemon.com...

 "Lionello Lunesu" <lio lunesu.removethis.com> skrev i en meddelelse 
 news:d0kghi$2meh$1 digitaldaemon.com...

 I know there's no single CPU instruction to do 'x to the power n' with 
 integers (only floats, right?) but it seems silly that you need a library 
 function to be able to do 'to the power'.


 Real programmers think binary and does not need any other power operator 
 than '<<' :-)

 Regards,
 Martin


I'm aware of the multipy/divide tricks with bitshifting, but could you 
enlighten me as to how that power one works?
Mar 09 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Nick Sabalausky wrote:


I know there's no single CPU instruction to do 'x to the power n' with 
integers (only floats, right?) but it seems silly that you need a library 
function to be able to do 'to the power'.


Real programmers think binary and does not need any other power operator 
than '<<' :-)


 I'm aware of the multipy/divide tricks with bitshifting, but could you 
 enlighten me as to how that power one works? 


assert(x == 2); ? ;-)

--anders
Mar 09 2005
prev sibling parent reply "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Nick Sabalausky" <z a.a> skrev i en meddelelse 
news:d0n8n5$2lek$1 digitaldaemon.com...
 I'm aware of the multipy/divide tricks with bitshifting, but could you

 enlighten me as to how that power one works?


    2 ** n

is the same as

    1 << n

At least if 'n' is a non-negative integer. It would be interesting to have 
fractional shifts :-)

Regards,
Martin
Mar 09 2005
parent "Nick Sabalausky" <z a.a> writes:
"Martin M. Pedersen" <martin moeller-pedersen.dk> wrote in message 
news:d0n9r3$2ml4$1 digitaldaemon.com...

 "Nick Sabalausky" <z a.a> skrev i en meddelelse 
 news:d0n8n5$2lek$1 digitaldaemon.com...
 I'm aware of the multipy/divide tricks with bitshifting, but could you

 enlighten me as to how that power one works?


    2 ** n

 is the same as

    1 << n

 At least if 'n' is a non-negative integer. It would be interesting to have 
 fractional shifts :-)

 Regards,
 Martin


Oh, lol, for some reason I was confusing left-shift and right-shift. It 
makes sense now ;)
Mar 09 2005
prev sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
Lionello Lunesu schrieb:

 How about adding an operator ** for 'to the power' ?


Nice idea. (Thought about it myself, but never took the trouble of 
bringing it up...)


 I know there's no single CPU instruction to do 'x to the power n' with 
 integers (only floats, right?) but it seems silly that you need a library 
 function to be able to do 'to the power'.
 
 Maybe 'x**n' should simply always return a float?


Definitely not. It should behave similar to '/': Dividing two integers 
results in an integer even if mathematically, it should result in a 
fraction.

This should also upscale to float vs. complex: if you do (-1.0)**0.5, it 
should raise some exception. Only (-1.0+0.0i)**0.5 should return an 
imaginary value.


 Definately not important, I know.


But also not a big issue to include.
Mar 09 2005