Question for Parisse about CAS floating point

[jgoizueta]

I was curious about the reason for the 48-bit precision of the CAS floating point values, so I took a peek at the source code of GIAC.

I see the gen class, which (when DOUBLEVAL is defined), uses its space for a double overlapped with the 8-bit type field, and that the type is rewritten when the gen used as a double, and zeroed when returning its double value (so effectively truncating the mantissa).

But that would remove 8 bits from the 53-bit double mantissa, making it 45, not 48 bits, which is what I get playing with Joe Horn’s hex (and the exponent range of double seems to be preserved too).

So, what am I missing?

And, on a different note, is there any chance of having DOUBLEVAL (or BCD) in the Prime?

[parisse]

The type field was 8 bits large in the past, but it is now 5 bits large

Code:


    unsigned char type:5;  // 32 types is enough, keep 3 bits more for double

That leaves 48 bits (47+1 implicit) for mantissa (47+5+1 sign+11 exponent=64 bits, sizeof(gen)=8) if DOUBLEVAL is not defined.

[jgoizueta]

(04-06-2015 06:43 AM)parisse Wrote:  The type field was 8 bits large in the past, but it is now 5 bits large

Code:


    unsigned char type:5;  // 32 types is enough, keep 3 bits more for double

That leaves 48 bits (47+1 implicit) for mantissa (47+5+1 sign+11 exponent=64 bits, sizeof(gen)=8) if DOUBLEVAL is not defined.

Oh, I see... the code I was looking at (giac-0.9.5) didn't have the ":5" bitfield.

Thanks!!

[compsystems]

the nspire and ti68k calculators work with 12 digits, I think this should be the lower limit to improve accuracy, you say?

hp-prime calculator

approx(1519/99) => 15.3434343434 10 digits =(

nspire and ti68k calculators

approx(1519/99) => 15.343434343434 12 digits =)

////////////////

hp-prime calculator

approx(1222222/99000) => 12.3456767677 10 digits =(

nspire and ti68k calculators

approx(1222222/99000) => 12.345676767677 12 digits =)

[jgoizueta]

(04-06-2015 01:44 PM)compsystems Wrote:  hp-prime calculator

approx(1519/99) => 15.3434343434 10 digits =(

The 15.3434343434 result of the Prime uses 10 decimal places but has 12 digits of precision (counting the integer part).

Actually, the 48 internal bits of the approximate CAS numbers can hold 15 decimal digits (and preserve their value when converted back to decimal)

The actual CAS value 1519.0/99.0 could be presented as 15.3434343434343 with 15 digit precision, but the Prime refuses to do so. (you can check the actual internal value with Joe Horn's hex program and see that all those digits are there)

I don't care about the precision of the approximate numbers in the CAS (it is larger than the 12 digits of HOME). What worries me is that each result is truncated (after being computed with the accuracy of a IEEE double), so numeric computations in the CAS may not be as well behaved as in home...

Edited to mention the hex program

Edit: oh, now I realize that the CAS values are shown to 12 decimal digits for consistency with the HOME world.

[Joe Horn]

(04-06-2015 01:44 PM)compsystems Wrote:  the nspire and ti68k calculators work with 12 digits, I think this should be the lower limit to improve accuracy, you say?

hp-prime calculator

approx(1519/99) => 15.3434343434 10 digits =(

That's merely what's shown in the display. The internal value in CAS is exactly:
15.343434343434267930206260643899440765380859375
Count the underlined digits.

(04-06-2015 01:44 PM)compsystems Wrote:  nspire and ti68k calculators

approx(1519/99) => 15.343434343434 12 digits =)

Notice that the Prime's value is identical to 12 decimal places, and in fact its result is closer to the actual value of 1519/99 than the competitions'. So, Prime wins that round. =)

(04-06-2015 01:44 PM)compsystems Wrote:  ////////////////

hp-prime calculator

approx(1222222/99000) => 12.3456767677 10 digits =(

That's merely what's shown in the display. The internal value in CAS is exactly:
12.3456767676767498187473393045365810394287109375
Count the underlined digits.

(04-06-2015 01:44 PM)compsystems Wrote:  nspire and ti68k calculators

approx(1222222/99000) => 12.345676767677 12 digits =)

Notice that this time Prime's internal value is even more accurate than the competitions' results... 13 accurately rounded decimal places, not just 12. =)

Random thought: Saying that Prime's accuracy in Home view is less than TI's, is like saying that a race car in low gear is slower than a motorcycle. It's true, but pointless. Yes, Home's results are limited to 12 BCD digits, but CAS results are slightly wider at 48 bits. If you want to compare Prime's accuracy with other machines, be fair and use Prime's CAS, rather than falsely implying that Prime is less accurate than other machines.

Prime's internal values shown above were obtained by a version of my "hex" program, rewritten to output the exact decimal values. I'll post it in the Prime Software Gallery later this evening.

Edit: The "dec" program is HERE.

[jte]

(04-07-2015 02:44 AM)Joe Horn Wrote:  

(04-06-2015 01:44 PM)compsystems Wrote:  the nspire and ti68k calculators work with 12 digits, I think this should be the lower limit to improve accuracy, you say?

hp-prime calculator

approx(1519/99) => 15.3434343434 10 digits =(

That's merely what's shown in the display. The internal value in CAS is exactly:
15.343434343434267930206260643899440765380859375
Count the underlined digits.

My understanding of the CAS semantics for its is inexact numeric values is that they are not exactly equal to any rational or real number. That said, interpreting the CAS value as an IEEE 754 double I seem to get
15.3434343434342963519156910479068756103515625

In an Advanced Graphing app plot, the lower and upper bounds used for 1519/99 (when the fraction is worked with in an approximate manner) are
15.343434343434342537193515454418957233428955078125
and
15.3434343434343443135503548546694219112396240234375,
respectively.

[Joe Horn]

(04-10-2015 07:58 PM)jte Wrote:  

(04-07-2015 02:44 AM)Joe Horn Wrote:  That's merely what's shown in the display. The internal value in CAS is exactly:
15.343434343434267930206260643899440765380859375
Count the underlined digits.

My understanding of the CAS semantics for its is inexact numeric values is that they are not exactly equal to any rational or real number.

If by "inexact" you mean "floating-point reals", then you are not correct. In CAS, reals use 48 bits for the mantissa, and are therefore exactly equal to an exact integer divided by an exact power of 2, which is therefore representable as an exact terminating decimal number. For example, the value of approx(1519/99) is stored by CAS as 134962275764989/2^43, which can be written exactly as the terminating decimal number I gave above.

[parisse]

Inside Xcas (and the Prime CAS), a floating point value is always meant as an approximate representation of a real. This explains for example that gcd(1.25,0.25) returns 1 while gcd(5/4,1/4) returns 1/4, despite the fact that 5/4 and 1/4 are represented exactly with floating point numbers.

[jte]

(04-12-2015 12:36 PM)Joe Horn Wrote:  

(04-10-2015 07:58 PM)jte Wrote:  My understanding of the CAS semantics for its is inexact numeric values is that they are not exactly equal to any rational or real number.

If by "inexact" you mean "floating-point reals", then you are not correct. In CAS, reals use 48 bits for the mantissa, and are therefore exactly equal to an exact integer divided by an exact power of 2, which is therefore representable as an exact terminating decimal number. For example, the value of approx(1519/99) is stored by CAS as 134962275764989/2^43, which can be written exactly as the terminating decimal number I gave above.

I'm not 100% up to date on the terminology used by the CAS; I hope that isn't confusing matters. I hesitate to use the term "floating-point" as (it is my understanding that) the semantics intended by the author of the CAS does not follow that laid out by IEEE 754. (While the Advanced Graphing app does follow IEEE 754 semantics and views finite floating-point numbers as exact rational / real numbers, it is fairly common to have different interpretations of values produced using floating-point calculations.)

I was wondering exactly where the decimal number you gave above for 1519/99 came from, so I'm glad you clarified that. My intention was to do the same division, but I arrived at a different decimal answer.

[parisse]

To make things clearer, inside the CAS you have exact rationals to represent rationals, therefore there is no need to use floating point numbers to represent only a few rationals (included in the rationals that have a power of 2 as denominator), unlike for applications that do not have exact representation for rationals. Inside a CAS, floating point means approx data. And that's how they are used for in the vast majority of scientific computations.