Question about pow

[Arnold]

Hi Charles,

using version 0.2.8 I tried this little code:

Code: [Select]

uses console

printl "0*0 = " 0*0               '0
printl

printl "0^2      = " 0^2          '#qNAN , expected 0
printl "pow(0,2) = " (pow(0,2))   '#qNAN , expected 0

printl "0^0      = " 0^0          '#qNAN , expected 1
printl "pow(0,0) = " (pow(0,0))   '#qNAN , expected 1

waitkey

Is there a reason, why with Oxygen the result is #qNAN for 0^x and 0^0? I expected 0 and 1, but looking up in Wikipedia this seems not to be so clear any more.

Roland
 

[Charles Pegge]

Very small  numbers ^zero produce unity. So  0^0 will also produce unity.

Very small  numbers ^unity produce their identity. So 0^1 should also produce 0. Perhaps 0^2 will produce an even smaller 0 

Should zero-handling be included in the power algorithm, or should it be the responsibility of the programmer?

[Arnold]

I have to admit that after reading:

Exponentiation
https://en.wikipedia.org/wiki/Exponentiation

Zero to the power of zero
https://en.wikipedia.org/wiki/Zero_to_the_power_of_zero

nothing is clear for me any more when it comes to zero. It is like entering quantum mechanics. Perhaps the IEEE floating-point standard can be applied in O2 too?

[Charles Pegge]

Okay.

0^0 == 1
All other powers of 0 ==1.0

I will implement this in 0.2.9 by prefixing this code to the powers macro: (in lang.inc)

Code: [Select]

  (
   fldz
   fucomip st2
   jnz exit
   fldz
   fucomip st1
   fstp st0
   fstp st0
   (
    jnz exit
    fld1
    jmp fwd _npower
   )
   fldz
   jmp fwd _npower
  )
...


[Charles Pegge]

What is 0/0 

should it be 0, 1, or #inf ?

[Arnold]

Hi Charles,

my pocket calculators return 0 E when I divide by 0, MS calc says: undefined result (also error). O2 returns #qNAN when calculating 0/0, but it behaves sometimes differently e.g. 0\0, (0/0), 42/0 * 50 etc. Sometimes O2 crashes without notice.

In my opinion division by 0 is an error. But of course I can treat this special case in the source code of a program.

Roland

[Charles Pegge]

n\0 Integer division by zero will cause a GPF but n/0 will produce float infinity #INF, except 0/0 will produce #qNAN.

BTW: You can do significant maths with infinity

Code: [Select]

float inf=1/0       'create infinity variable
print inf + inf     '#inf
print inf - inf     '#qnan
print inf * inf     '#inf
print inf / inf     '#qnan
print 1/inf         '0
print 0/inf         '0
print inf/0         '#inf
print inf/2         '#inf
print deg(atn(inf)) '90


[jack]

if you have a 10+ year old intel fpu, then you may want to avoid doing math operations with NaN's because it's incredibly slow. https://randomascii.wordpress.com/2012/05/20/thats-not-normalthe-performance-of-odd-floats/

Performance implications on the x87 FPU

The performance of Intel’s x87 units on these NaNs and infinites is pretty bad. Doing floating-point math with the x87 FPU on NaNs or infinities numbers caused a 900 times slowdown on Pentium 4 processors. Yes, the same code would run 900 times slower if passed these special numbers. That’s impressive, and it makes many legitimate uses of NaNs and infinities problematic.

[Arnold]

This is interesting. I was able to reproduce your results. Looking up Wikipedia (Division by zero) it seems you applied the IEEE 754 floating point standard for division? It is fascinating that depending on the programming environment different results can be generated. As I was active in the commercial sector, the result for division by zero was clear to me. But you showed that even this is not so clear.

[Charles Pegge]

Thanks for informing us about x87 performance, Jack. If infinity appears at run-time, it usually indicates a sensor failure, or maybe you have reached the event-horizon of a black hole.