is Python-syntax-in-CAS less accurate than PPL?

[StephenG1CMZ]

I have just attempted an implementation of the Savage benchmark using Python-syntax-in-CAS.
The results seem to be less accurate than the version implemented in PPL.
Is a loss of accuracy in Pythonesque to be expected?
Or have a mis-coded something?
http://www.hpmuseum.org/forum/thread-962...#pid104888

[Albert Chan]

Hi, StephenG1CMZ

Python range(1, 2499) == [1, 2, ..., 2498]

BTW, noticed all other benchmarks does not do indirect lookup via math.xxx
To be fair, Python version should do likewise.

atan, tan, ... = math.atan, math.tan, ... before use it inside loop

[StephenG1CMZ]

Oh, silly me - I adjusted the 0 and overlooked the upper limit.

My thoughts on including the "math" prefix were to ensure I was getting "Python" tan, rather than conceivably being given the PPL tan or the CAS tan.

In pure Python I believe it should be more efficient to import once before the FOR loop, but I haven't got that to compile yet on the Prime.

[Tim Wessman]

(09-28-2018 11:18 PM)StephenG1CMZ Wrote:  Oh, silly me - I adjusted the 0 and overlooked the upper limit.

My thoughts on including the "math" prefix were to ensure I was getting "Python" tan, rather than conceivably being given the PPL tan or the CAS tan.

In pure Python I believe it should be more efficient to import once before the FOR loop, but I haven't got that to compile yet on the Prime.

I don't believe there is a"python tan". Really, it is wrapping around CAS objects and functions with a pre-parser wrapper that compiles it to equivalent CAS syntax. It probably is just the equivalent internally of tan(<approx_num>) and so on.

[Albert Chan]

(09-28-2018 11:18 PM)StephenG1CMZ Wrote:  My thoughts on including the "math" prefix were to ensure I was getting "Python" tan,
rather than conceivably being given the PPL tan or the CAS tan.

Python will not get confused with tan = math.tan
Python local variables always have priority over globals (even if global tan exist).

Is it even possible to call PPL/CAS tan directly from Python code ?
What happened if all the "math." were removed ?

[parisse]

Nothing, tan or math.tan is the same. You don't need all the math import or math. stuff, they are just here to improve compatibility for people who would like to run existing Python scripts or are comfortable with Python and want to write Xcas programs.
Floating point numbers are CAS floats, i.e. 48 bits of mantissa instead of 53, therefore you will not have full accuracy but almost, like in CAS.

[StephenG1CMZ]

I have now corrected that incorrect range, and removed all the unneccesary "math" references.
http://www.hpmuseum.org/forum/thread-9626.html
The Python syntax now not only seems more accurate, but also faster than the PPL version, which was unexpected.

[cyrille de brébisson]

Hello,

CAS uses 56 bit floating point numbers (64 bits with 8 bits being taken over for some other information). Thus leading to a somewhat low precision (the idea being that if you want precision, you can use integers)...

PPL uses 64 bits BCD reals with 12 digits of mantissa.

So, PPL will always have higher precision on floating points than the CAS... Python or otherwise.

Cyrille

[parisse]

(10-01-2018 05:47 AM)cyrille de brébisson Wrote:  Hello,

CAS uses 56 bit floating point numbers (64 bits with 8 bits being taken over for some other information). Thus leading to a somewhat low precision (the idea being that if you want precision, you can use integers)...

Actually it's 59 (48 bits of mantissa).

[John Keith]

(10-01-2018 05:47 AM)cyrille de brébisson Wrote:  Hello,

CAS uses 56 bit floating point numbers (64 bits with 8 bits being taken over for some other information). Thus leading to a somewhat low precision (the idea being that if you want precision, you can use integers)...

PPL uses 64 bits BCD reals with 12 digits of mantissa.

So, PPL will always have higher precision on floating points than the CAS... Python or otherwise.

Cyrille

That's why it would be really great if the Prime CAS had something like LongFloat or the variable-precision floats of NewRPL.

[Albert Chan]

(10-01-2018 05:47 AM)cyrille de brébisson Wrote:  PPL will always have higher precision on floating points than the CAS... Python or otherwise.

Although PPL had 64 bits, roughly speaking, it got 12 * 3.322 ~ 40 bits precision.
Due to roundings in decimals, PPL probably had even less precision than 40 bits.

For this Savage test, Python simulation, CAS float precision ~ 42 bits, PPL ~ 37 bits.
StephenG1CMZ Android emulator produce similar numbers.

PPL may eventually be more accurate, but it take huge chain of calculations ...