Bizarre math bug

[Lance Edmonds]

Did you note my emphasis on the word "usually"? Unless we start giving away products, upgrades and new purchases will continue to involve charges. However, in the past, updates (which are diffent from upgrades) have been issued for free to registered customers.

The SUPPORT section of this web site details the current edition/build of our products, which is determined by the file's date & time (the DAY indicates the release build number, and the time indicates the version number).

If your product is older than the relevant date shown in the SUPPORT page, then you can send a request to mailto:[email protected][email protected]</A> with your serial number and your zip code (US residents), and they will send you the relevant update. If (and the emphasis is on IF) there are any costs involved, Sales will sort it out with you at that time.

I hope this explains things...
http://www.powerbasic.com/support



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

Originally posted by Lance Edmonds:
Updates are usually free, Upgrades are not. There is expected to be an update to the current version of the compiler, but at this time, no information, pricing, or details are available..

If updates are free, why would "pricing" apply? By the way, where are past updates posted? Forgive me, I'm new around here. Thanks.


Sincerely,

Marcus


------------------

[Lance Edmonds]

Originally posted by Marcus Moore:
Also, remind them to create a patch for those who can't afford an update, and just want what they already have to work. Thank you.

Updates are usually free, Upgrades are not. There is expected to be an update to the current version of the compiler, but at this time, no information, pricing, or details are available..

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

>>
Its been years since I've done this but a negative power is an
imaginary number if I remember correctly.

sqr(-2) = sqr(2)i

I might be incorrect on the formula but I think that is somewhat
right.
>>

Yes, the square root of a negative requires complex math
and imaginary numbers. Negative square roots requires much
more then the SQR() function.

However, powers are just good old floating point math.

(-2) ^ 2 = (-2) * (-2) = 4

2 ^ (1) = 2
2 ^ (0) = 1
2 ^ (-1) = 0.5

. . . and we are just dealing with powers when it comes
to this problem. When a program made with PowerBasic raises
a negative number to a power and things are "just right" the
FPU stack gets messed up.

SQR() is not envolved with this.


------------------

Originally posted by Lance Edmonds:
Thanks guys... R&D tell me that this problem has been identified and will be sorted out in the next update to the compiler.

Also, remind them to create a patch for those who can't afford an update, and just want what they already have to work. Thank you.


Sincerely,

Marcus

[Gregery D Engle]

Originally posted by Tim Wisseman:
>>
Is the problem not with raising a negative number to a power?
This is how i would have done it.
MSGBOX STR$ (-1 +((ABS(-1) ^2)/1))
so that the negation is removed before raising to the power of 2.
Answer 0
>>

My tests show that the problem only hits when you raise
a negative number to a power. Using ABS() is a good work
around to the problem. Your code will work fine.

Tim

Its been years since I've done this but a negative power is an
imaginary number if I remember correctly.

sqr(-2) = sqr(2)i

I might be incorrect on the formula but I think that is somewhat
right.

------------------
-Greg

[Lance Edmonds]

R&D report that it is due to an FPU register stack overflow. It is now on the list. Thanks again guys!



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Lance Edmonds]

Charles, you have done some great detective work here. I've asked R&D to review this topic, guys, so thanks for the info! We'll see what "develops"



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Charles Dietz]

Daniel,

I have conducted many tests, and my results show that the exponent
is converted to the nearest integer so that:

(-2)^2.501 = -8
(-2)^2.499 = 4

And my test show that it doesn't matter what kind of data elenment
receives the answer. I believe that the problem has to do with the
automatic register assignments. For example:

#COMPILE EXE
FUNCTION PBMAIN
   DIM a AS EXT, b AS EXT, c AS EXT, d AS EXT
   MSGBOX STR$(-1 + (-2)^3.45)   'wrong ans
   MSGBOX STR$((-2)^3.45 - 1)    'right ans 
END FUNCTION

whereas...

#COMPILE EXE
FUNCTION PBMAIN
   DIM a AS DOUBLE, b AS DOUBLE, c AS DOUBLE, d AS DOUBLE
   MSGBOX STR$(-1 + (-2)^3.45)   'right ans
   MSGBOX STR$((-2)^3.45 - 1)    'right ans 
END FUNCTION

But if #REGISTER NONE is added, or if less than four unused variables
are allocated, the result is always right.

Therefore, it would appear to me that the problem rests totally on
how the registers are automatically assigned by the compiler.



------------------


[This message has been edited by Charles Dietz (edited August 25, 2000).]

[Daniel Corbier]

In the Visual Basic help file, it explains that the base argument
can be negative as long as the exponent argument is an integer
value. Looking at help files from other compilers, I see that
they do it the same way for equivalent Power functions. Although
the PB help file does not have an explanation for the ^ operator,
I assume that it has always used this same standard. Does
someone from PB care to shed some light on how the ^ operator is
implemented internally in PB? The mysterious result that I got
only appears under certain circumstances, so it appears not to
be the intended compiler behavior.

------------------
Daniel Corbier
UCalc Fast Math Parser
http://www.ucalc.com

[Hanns Ackermann]

John,

because of a=exp(log(a)), a=x^n=exp(n*log(x)) yields an error
if x<=0. I think the calculators are using something like that,
and of course, f.ex., (-2)^3=exp(3*log(-2)) fails. That is why
the formula must work not only for integers, but for real numbers,
too. Of course, f.ex., (-2)^3=(-2)*(-2)*(-2)=-8. That's not the
problem with complex numbers, but you need complex numbers if n
is not an integer.

In PB6, I tried >> msgbox str$( (-2)^3.45 ) << and, without an
error, got the result: -8, (2)^3.45=10.92 is ok. Evidently, PB6
uses the next integer for computation, perhaps a good (?) idea.

Daniel,

in your original post you computed (-1)^2, in terms of the above
formula this reads as exp(2*log(-1)), and of course log(-1) fails.
Substituting (-1)^2 with exp(2*log(-1))in your program yields the
same wrong result (without an error!), inserting (-1)*(-1)
correctly yields zero. Did John found the key to a solution?

Regards, Hanns.


------------------




[This message has been edited by Hanns Ackermann (edited August 23, 2000).]

[John Hutchins]

On all the calculators I have ever used, an error or overflow is always
returned when you try to raise a negative number to a power.
If I remember correctly, this involves complex numbers.

------------------

[Hanns Ackermann]

Thanks Lance,

seems that the right bracket ")" is erronously included in Daniel's URL.

Cheers, Hanns.

------------------

>>
Is the problem not with raising a negative number to a power?
This is how i would have done it.
MSGBOX STR$ (-1 +((ABS(-1) ^2)/1))
so that the negation is removed before raising to the power of 2.
Answer 0
>>

My tests show that the problem only hits when you raise
a negative number to a power. Using ABS() is a good work
around to the problem. Your code will work fine.

Tim


------------------

[Lance Edmonds]

it is right there in the faq forum:
http://www.powerbasic.com/support/pb...hread.php?t=45

------------------
lance
powerbasic support
mailto:[email protected][email protected]</a>

[Hanns Ackermann]

Daniel,

I'm very interested in that ASM fix - Is the code available
somewhere? Unfortunately, the URL given above yields HTTP
Error 404(Not found) ...

Thanks & Greetings
Hanns.

------------------


[This message has been edited by Hanns Ackermann (edited August 21, 2000).]

[John Hutchins]

Is the problem not with raising a negative number to a power?
This is how i would have done it.
MSGBOX STR$ (-1 +((ABS(-1) ^2)/1))
so that the negation is removed before raising to the power of 2.
Answer 0

------------------

[Lance Edmonds]

I'm not sure if I have any example code to test if the FPU is running in 54-bit precision mode, which I must stress is a behavior of Windows not PowerBASIC! I'll check when I get back to my DEV PC and post some if I still have any in my archives.

Regardless, R&D tell me that the next update to PB/CC and PB/DLL will automatically switch the FPU to 80-bit precision for you.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Daniel Corbier]

while on this subject, there's a message that was posted in the
faq section (at http://www.powerbasic.com/support/pb...hread.php?t=45
about the requirement of some assembly code so that extended
precision would work properly. i was never able to duplicate that
problem on my computer. so i haven't used the assembly code.
lance, can you give an example of code where that problem would
show up without the fix? also, will this be addressed in the
next version? the archives in these forums do not seem to go
prior to 1999. i may be wrong, but somehow, i seem to remember
reading about that asm fix well before version 6.0 was out.

also, although i couldn't verify the problem described in the
faq, there's another extended-precision problem that a few
customers who use my dll did notice. at least i think it's
different from the faq problem, because it doesn't do
calculations using 54-bit float. instead, on certain
computers it just crashes, with the error "invalid
floating-point operation". after searching around, i found
that apparently certain versions of particular popular
programs turn off the 80-bit mode. the remedy for c++ users
of my dll who encountered this problem was to add these
lines:

#include <float.h>
_fpreset();
_control87(mcw_em, mcw_em);

i don't know if the asm code from the faq solves this or not.
in any event, it would be nice for the next version to handle
things so that no asm code or external function call would be
required just to make extended precision work properly.

------------------
daniel corbier
ucalc fast math parser
http://www.ucalc.com

[Lance Edmonds]

Thanks guys... R&D tell me that this problem has been identified and will be sorted out in the next update to the compiler.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>