Oxygen Basic
Programming => Problems & Solutions => Topic started by: Arnold on September 24, 2019, 04:11:13 AM

Hi Charles,
using version 0.2.8 I tried this little code:
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

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 zerohandling be included in the power algorithm, or should it be the responsibility of the programmer?

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 floatingpoint standard can be applied in O2 too?

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)
(
fldz
fucomip st2
jnz exit
fldz
fucomip st1
fstp st0
fstp st0
(
jnz exit
fld1
jmp fwd _npower
)
fldz
jmp fwd _npower
)
...

What is 0/0 :)
should it be 0, 1, or #inf ?

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

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
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

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/thatsnotnormaltheperformanceofoddfloats/
Performance implications on the x87 FPU
The performance of Intel’s x87 units on these NaNs and infinites is pretty bad. Doing floatingpoint 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.

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.

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