Let's vote for suggestions and bugs

[Joe Horn]

(09-23-2018 05:39 AM)sasa Wrote:  The claim that program shows 44 exact digits of PI with only available 48-bit mantissa obviously made a confusion...

But no such claim is made. The claim is that the 'dec' program always shows ALL the digits (no matter how many there are) of ANY CAS floating-point value. And that's what it does. It neither claims nor attempts to show 44 digits of the actual mathematical constant of pi, which is DIFFERENT from the CAS floating-point approximation of pi. Perhaps there is a language barrier here?

(09-23-2018 09:20 AM)CyberAngel Wrote:  Joe insists that all the dec digits represents the pi approximation exactly.

Correct. That is precisely what it does.

(09-23-2018 09:20 AM)CyberAngel Wrote:  The problem is that that after those 14.4 digits the number is wrong.
No reason whatsoever for 50 digits yet along 1000 digits.

"Wrong" because it differs from the mathematical constant of pi? THAT'S NOT ITS PURPOSE. I'll try one more time to explain this before giving up in frustration. When you type approx(pi) in Home, you get 3.14159265359, and that's EXACTLY the value that's sitting in Ans at that time. Those digits, and no more. But when you type approx(pi) in CAS, it *shows* 3.14159265359 as the result, but that is NOT the value in Ans. The ACTUAL value can be seen by typing format(pi,"a12"), which yields "0x1.921fb54442d0p+1" which is the EXACT hex representation of CAS's approximation of pi. What is the EXACT DECIMAL representation of "0x1.921fb54442d0p+1"? THAT is what dec(pi) returns. EVERY DIGIT in its output is significant and correct, so I don't know why you say that there is no reason to show the digits which differ from the decimal expansion of pi. Showing THOSE digits is the PURPOSE of the 'dec' program.

I hope that's clear. If not, I know no way of explaining it more clearly.