maths functions

[sospel]

Hello !

Looking for a BASIC language for personal use, I downloaded several software (ex: PureBasic-Demo some days ago) and I make small programs-tests in touch with my needs.
To test their "answer" to the mathematical functions, I execute the 3 loops below, by adapting them to the specificities of every language (declarations of variables - value.d - , printings of the results StrD(...), etc...) :

value = 1.0
FOR i=1 TO 10
FOR j=1 TO 1000
FOR k=1 TO 1000
value = Tan(ATan(Pow(10.00,Log10(Sqr(value*value))))) + 1.0
NEXT k
NEXT j
NEXT i

( take in an old "Sky & Telescope" review)

Calculations in all langages are made in "DOUBLE".
I deliver you the main results :

1/in FORTRAN 95 : value = 10000001.000593 , error in % = 0.000010005 [Reference calculation]
2/in GFA-Basic (WinXP) : value = 10000001.001222 , error in % = 0.000010001 [remarkable for a "BASIC"!!]
3/in Visual-Basic6 : value = 9999818.448501 , error in % = 0.001815515 [acceptable]
4/in Emergence BASIC : value = 9999818.448501 , error in % = 0.001815515 [NB: idem than VB6].
5/in XBLite : value = 9999818.448501 , error in % = 0.001815515 [NB: idem than VB6].

To my great surprise, the calculation in PureBasic is FALSE :

a/ with "value.f" : value = 4095.73364
b/ with "value.d" : value = 1708221.50000

Is one of you can say myself if I made an error of programming or if it is an "intrinsic" fault in the functions of PureBASIC ?
Thank you in advance for any remark !
Cordially
SosPel

[Froggerprogger]

All the math-functions (as Tan, ATan, Pow, Log10, Sqr) in PB do only work with single precision. There is atm no implementation for doubles.
[edit]According to the help which says e.g. Result.f = Tan(Angle.f) [/edit]

[Trond]

All the math-functions (as Tan, ATan, Pow, Log10, Sqr) in PB do only work with single precision. There is atm no implementation for doubles.

That is not true.

Code: Select all

; value.d = Tan(ATan(Pow(10.00,Log10(Sqr(value*value))))) + 1.0

Here:
Sqr() works with extended precision (full fpu usage, no extra truncation at all)
Log10() and Pow() works with single precision().
ATan() works with double precision.
Tan() works with extended precision.

[Helle]

With Doubles:

Code: Select all

value.d = 1.0 
For i=1 To 10 
  For j=1 To 1000 
    For k=1 To 1000 
      T1.d=Log10(Sqr(value*value))
      T2.d=Pow(10.00, T1)
      value = Tan(ATan(T2)) + 1.0
    Next k 
  Next j 
Next i 

Debug value   ;10000001.001298055
;--------------------------------------
value.d = 1.0 
For i=1 To 10 
  For j=1 To 1000 
    For k=1 To 1000 
      T1.d=Log10(Sqr(value*value))
      T2.d=Pow(10.00, T1)
      T3.d=ATan(T2)
      value = Tan(T3) + 1.0
    Next k 
  Next j 
Next i 

Debug value   ;9999818.4040938206

Hmmm....

Gruss
Helle

[blueznl]

I think it's a bug, caused by wrong type conversion / enforcement.

Here's the culprit:

Code: Select all

value.d = 1.0
For i.l=1 To 10
  For j.l=1 To 1000
    For k.l=1 To 1000
      ;
      ; value = Tan(ATan(Pow(10.00,Log10(Sqr(value*value))))) + 1.0
      ;
      t5.d = value*value
      t4.d = Sqr(t5.d)
      
      ; t3.d = Log10(t4.d)
      ; t2.d = Pow(10.00,t3)
      
      t2.d = Pow(10.00,Log10(t4.d))
      
      t1.d = ATan(t2)
      t0.d = Tan(t1)
      value.d = t0 + 1.0
    Next k
  Next j
Next i
Debug value

[blueznl]

And I've boiled it down to this:

Code: Select all

t3.d = Log10(2.00)
t2.d = Pow(10.00,t3)
x1.d = t2
Debug x1

t2.d = Pow(10.00,Log10(2.00))
x2.d = t2
Debug x2

It looks like Pow(...) is forcing Log10(...) to a lower precision. Which is, according to Fred's own rules not correct, type conversions were only allowed upwards, not downwards...

Who wants to have the honour to post this as a bug?

[Psychophanta]

Yes, look like a bug.

Who wants to have the honour to post this as a bug?

You have been the first one to discover it, which means you should have such a honour.

[blueznl]

Well, actually Sospel should, but okay, in Sospel's name then

Report is here:

http://www.purebasic.fr/english/viewtop ... 621#259621

[Helle]

Sospel´s Code tested with V4.30B1:
- 32-Bit: 1708221.5000000533
- 64-Bit: 9999818.1154463831

Gruss
Helle

[sospel]

Hello !

Thank you for answers, which are enlighten a little my problem:

1/ FROGGERPROGGER is right: the PB manual indeed says " Result.f = Tan ( Angle.f) " and not Tan ( Angle.d) .

2/ HELLE shows that by making calculation piece by piece, we arrive at the good result: 10000001.001298055!
But this is not satisfactory, because he shows that the result depends on the "division" of the instruction.

3 / BLUEZNL:
" I think of it has bug ": I agree!
" Well, actually Sospel should, drank okay, in Sospel name then "
-> seen well : my name = "S.O.S for Programs Et (and) Languages"

My opinion on this problem : the necessity of cutting the calculations according to "risky" manipulations is very bad, and unworthy of a language as PureBasic. In my tries, it is the only language which has this abnormality. Furthermore, there is no function "EXP", opposite of LOG. It is indeed about a bug .

The only solution is that the designer of the language replaces these functions by " generic " functions for variables in INT, FLOAT or DOUBLE. As comparison, the other languages –VB6, XBLITE, EMERGENGE - have no these problems, and they are free. Nevertheless, they must also be doubtless written too with C++...

Cordially
SosPel

[Psychophanta]

This is very important, no doubt.
I agree with sospel in the part that PB should be at least as GFA-BASIC (win32) for accuracy for calculations with floats, doubles, or any.
Imho, this issue is enough important to move this forum thread to "General discussion" section, and to suggest to the developpers to not pass over this necessary matter.

[blueznl]

> the necessity of cutting the calculations according to "risky"
> manipulations is very bad

You never tried Forth

Honestly, I don't think it's that bad. Splitting it to pieces is bad indeed, but there is a very clear logic behind the processing. Types are only converted upward when necessary. I had to wrap my mind around it a few times as well (and it is now so stretched you can poke holes through it ) but it makes sense from a speed perspective: no unnecessary up-conversions means MORE speed, and in the real world the limitations are limited. Simplest fix to turn everything to highest accuracy would be typecasting, which turns out to be very easy in PureBasic:

Code: Select all

float.d = 0
;
z.d = float + 1/3 + 1/3

Or (untested though )

Code: Select all

Procedure.d Float(float.d)
  ProcedureReturn float.d
EndProcedure
;
a.d = Float( 1/3 + 1/3 )

.

Unfortunately, the Pow( Log10( ) ) seems to be a bug. Eveything else can be put on the same line without any problems.

[Trond]

Hello !

Thank you for answers, which are enlighten a little my problem:

1/ FROGGERPROGGER is right: the PB manual indeed says " Result.f = Tan ( Angle.f) " and not Tan ( Angle.d) .

I simply looked at the asm output from PB 4.30b1, so what I wrote is how it was done in that code (of course it should not be this way, everything should be with double or extended precision).

[Road Runner]

PowerBASIC answer = 10000001.0010595

Why use 3 nested loops when a single loop counting from 1 to 10,000,000 would do the same thing?

Your calculation of the % error is wrong.
The exact answer is 10000001
So the % error will be (value-10000001)/10000001 * 100
In your first case value = 10000001.0010595 so
% error = (10000001.0010595 - 10000001)/10000001 * 100 = 0.000000010595 % and not 0.000010005 %

[Psychophanta]

% error = (10000001.0010595 - 10000001)/10000001 * 100 = 0.000000010595 % and not 0.000010005 %

That is also wrong, coz the correct calculation should be:
(10000001.0010595-10000001.0)/10000000.0*100
because the number of iterations is 10000000 and not 10000001

BTW, anyone tested it with blitz?