64-bit Precision for Extended Precision Variables Guaranteed?

[Walter Henn]

Folks who need accuracy greater than 15 significant digits use computers created for that and languages created for that.

Your statement is absolute and totally unsupported!

I also notice that you used the result for PI you obtained from "toy maker." How do you know the result is accurate even though it is carried out to 16 digits?

The value of the PI literal that I used was obtained from Microsoft's Power Toy Calculator. The precision of this calculator can be set from 32 decimal digits to as high as 512 decimal digits. I used the 64-digit result and rounded it to 19 digits (20 digits in a previous posting). The value of PI, rounded to 64 places, is: 3.141592653589793238462643383279502884197169399375105820974944592. This value was obtained from the Internet. (If you wish, you can obtain a million digits for PI at: http://www.piday.org/million.php). If you doubt the correctness of the rounded result of PI that I used in my posts, you do the math.

As for the results of casting the PI literal to extended precision using the PowerBasic code, I converted the hexadecimal memory contents of the extended precision z variable (containing the extended precision PI literal) to decimal using the Power Toy Calculator (64 decimal digits precision). I rounded the results to 20 decimal places. If you have any doubt about the accuracy of this computation by the Power Toy Calculator, just note that when rounded to 18 places, it compares exactly with the PB result using STR$(z, 18) obtained from my code. So we are left with the conclusion that we will obtain only 16-digit accuracy when converting literals to extended precision instead of the expected 18 digits. On the other hand, loading an extended precision variable with fldpi or 4 * ATN(1) results in the full 18-digit accuracy.

Members, I have explained this problem in several different ways. Frankly, I don't think I can make it any clearer. If there is anyone who feels that they can present this better, I truly welcome your input. I just think it's unfair to gloss over the problem that I'm presenting, by sniping at me for minor semantic or philosophical differences, instead of addressing the real issue at hand. And yes, I know there are workarounds that will permit members to obtain greater accuracy. However, I feel that the basic problem still has to be addressed by PB some time in the future.

[Aldo Vitagliano]

I highly doubt that a scientist or mathematician who needed accurate results to greater than 15 digits of precision would us a PC.

I am one of those guys ...
Back in the early 90ties I was starting to develop the foundations of an astronomical application based on very long numerical integrations. PCs were adequate, but it was mandatory to have the highest possible numerical precision, and 15 digits were not enough. In those days the only DOS compiler providing extended precision was Microsoft C/C++ 7.0, allowing reading/writing of numerical ASCII data with even 20 significant digits into/from 80 bits LONG DOUBLE (i.e. EXT) variables.
I had to learn enough of C to write a few thousand lines of code, which was really a pain in the neck (C must have been invented by a sadist to be used by masochists ). Later on, to my great relief I came across PB and I was very happy to back-translate my code. Now 18 digits are enough but I would still be happier to have 19!
Forgive me for telling a personal story ...

[Michael Mattias]

Those are horses of a different color. Precision has to do with the number of digits displayed. Accuracy has to do with the "correctness" of the displayed digits..

And someone went on record agreeing with this? Sheesh, this generation of programmers has gone straight down the toilet.

Precision refers to arithmetic accuracy; display is output.

Precision matters BEFORE you display and before you display only. This is a fundamental principle of programming. While it is most meaningful in the proper handling of intermediate results of complex calculations, it could be applied in this example.

(I'd call this example 'Programming 101' but I don't think it's quite that advanced).

If you don't like/can't live with the display functions provided (PRINT[#], STR$, FORMAT$ and USING$), write your own, for which you may provide as many digits as you want, significant - that is, within the documented limit of precision provided - or as many as will float your boat and make you happy.


MCM

[Walter Henn]

And someone went on record agreeing with this? Sheesh, this generation of programmers has gone straight down the toilet.

Precision refers to arithmetic accuracy; display is output.

Precision matters BEFORE you display and before you display only. This is a fundamental principle of programming. While it is most meaningful in the proper handling of intermediate results of complex calculations, it could be applied in this example.

(I'd call this example 'Programming 101' but I don't think it's quite that advanced).

If you don't like/can't live with the display functions provided (PRINT[#], STR$, FORMAT$ and USING$), write your own, for which you may provide as many digits as you want, significant - that is, within the documented limit of precision provided - or as many as will float your boat and make you happy.


MCM

.... :talktohand:

[Walter Henn]

I am one of those guys ...
I had to learn enough of C to write a few thousand lines of code, which was really a pain in the neck (C must have been invented by a sadist to be used by masochists ). Later on, to my great relief I came across PB and I was very happy to back-translate my code. Now 18 digits are enough but I would still be happier to have 19!
Forgive me for telling a personal story ...

Actually, Aldo, it is C++ that was invented by a sadist to be used by masochists. I sort of liked C (I always liked learning programming languages). But, when they tried to pawn off C++ on me, that's when I deserted the "C" ship. Thanks for sharing a bit of your experience.

[Walt Decker]

Precision refers to arithmetic accuracy; display is output.

That is not entirely correct. Precision refers to the number of digits. It has nothing to do with the correctness of those digits. A measurement or calculation may have a precision of Y digits, but it may be correct only to X digits. It then becomes necessary to qualify the answer to the number of significant digits.

As an example, using PBCC 8.04:

#COMPILE EXE
DEFLNG A - Z

FUNCTION PBMAIN () AS LONG

LOCAL Ny AS EXTENDED
LOCAL Nt AS EXTENDED
LOCAL My AS EXTENDED
Ny = .130000000000000000
Nt = 10^16
PRINT FORMAT$(Ny, 18), FORMAT$(Nt, 18)
PRINT FORMAT$(Ny * Nt, 18)
PRINT Nt/Ny
WAITKEY$
END FUNCTION

You will see that Ny is .130000000000000004 has a precision to 18 digits but is correct to 17 digits. If you change Ny to .13 instead of padding to 18 digits you will see that there is still 18 digits but is correct to only one significant digit (.129999995231628418) instead of the original two.

[Walter Henn]

The following message was sent today to [email protected]. I will keep the forum posted on any responses from PowerBasic.

The most recent version of PowerBasic Console Compiler, PBCC, 4.04, appears to have introduced an error when casting literals to extended precision. The code included below illustrates this problem. When PI is stored in the extended variable, z, by performing an extended precision calculation , such as 4 * ATN(1), or storing it directly through the assembler instruction, fldpi, the result is that z contains the value, 3.14159265358979324, which is accurate to 18 places. If, however, you cast the value of PI -- with 18-digit accuracy (or more) -- to extended precision, the value is stored as 3.14159265358979312, which is only accurate to 16 places. If you cast PI with 18-digit accuracy to double precision, the stored result is exactly the same as the result of casting PI to extended precision. Several additional examples in the code, using natural log base e and sqr(2), illustrate that, in all cases, the cast of a literal to extended precision is erroneously cast to double precision. Thank you for your assistance in this matter.

Walter Henn

[FONT=Courier][FONT=Courier]#COMPILE EXE[/FONT]
[FONT=Courier]#DIM ALL[/FONT]
 
[FONT=Courier]SUB display_memory(BYVAL z AS EXT)[/FONT]
[FONT=Courier]'display 10- byte contents of extended variable z[/FONT]
 
[FONT=Courier]DIM address AS LONG, value AS LONG[/FONT]
[FONT=Courier]address = VARPTR(z)[/FONT]
[FONT=Courier]value = 20[/FONT]
[FONT=Courier]PRINT "memory contents: ";[/FONT]
[FONT=Courier]FOR address = address + 9 TO address STEP -1[/FONT]
[FONT=Courier]PRINT TAB(value);HEX$(PEEK(BYTE, address),2);[/FONT]
[FONT=Courier]value = value + 4[/FONT]
[FONT=Courier]NEXT address[/FONT]
[FONT=Courier]PRINT:PRINT[/FONT]
[FONT=Courier]END SUB[/FONT]
 
[FONT=Courier]FUNCTION PBMAIN () AS LONG[/FONT]
 
[FONT=Courier]DIM z AS EXT[/FONT]
 
[FONT=Courier]z = 4 * ATN(1)[/FONT]
[FONT=Courier]PRINT "z = 4 * atn(1)"[/FONT]
[FONT=Courier]PRINT "result: ";STR$(z,18)[/FONT]
[FONT=Courier]CALL display_memory(z)[/FONT]
 
[FONT=Courier]!fldpi   'put the value of pi on the FPU stack[/FONT]
[FONT=Courier]!fstp z  'store that value in z[/FONT]
[FONT=Courier]PRINT "z = fldpi "[/FONT]
[FONT=Courier]PRINT "result: "; STR$(z,18)[/FONT]
[FONT=Courier]CALL display_memory(z)[/FONT]
 
[FONT=Courier]z = 3.14159265358979324##[/FONT]
[FONT=Courier]PRINT "z = 3.14159265358979324## (18-digit PI cast as extended)"[/FONT]
[FONT=Courier]PRINT "result: ";STR$(z,18)[/FONT]
[FONT=Courier]CALL display_memory(z)[/FONT]
 
[FONT=Courier]z = 3.14159265358979324#[/FONT]
[FONT=Courier]PRINT "z = 3.14159265358979324# (18-digit PI literal cast as double)"[/FONT]
[FONT=Courier]PRINT "result: ";STR$(z,18)[/FONT]
[FONT=Courier]CALL display_memory(z)[/FONT]
 
[FONT=Courier]z = SQR(2)[/FONT]
[FONT=Courier]PRINT "z = sqr(2)"[/FONT]
[FONT=Courier]PRINT "result: ";STR$(z,18)[/FONT]
[FONT=Courier]CALL display_memory(z)[/FONT]
 
[FONT=Courier]z = 1.41421356237309505##[/FONT]
[FONT=Courier]PRINT "z = 1.41421356237309505## (18-digit sqr(2) literal cast as extended )"[/FONT]
[FONT=Courier]PRINT "result: ";STR$(z,18)[/FONT]
[FONT=Courier]CALL display_memory(z)[/FONT]
 
[FONT=Courier]z = 1.41421356237309505#[/FONT]
[FONT=Courier]PRINT "z = 1.41421356237309505# (18-digit sqr(2) literal cast as double)"[/FONT]
[FONT=Courier]PRINT "result: ";STR$(z,18)[/FONT]
[FONT=Courier]CALL display_memory(z)[/FONT]
 
[FONT=Courier]z = EXP(1)[/FONT]
[FONT=Courier]PRINT "z = EXP(1)"[/FONT]
[FONT=Courier]PRINT "result: ";STR$(z,18)[/FONT]
[FONT=Courier]CALL display_memory(z)[/FONT]
 
[FONT=Courier]z = 2.71828182845904524##[/FONT]
[FONT=Courier]PRINT "z = 2.71828182845904524##  (18-digit e literal cast as extended )"[/FONT]
[FONT=Courier]PRINT "result: ";STR$(z,18)[/FONT]
[FONT=Courier]CALL display_memory(z)[/FONT]
 
[FONT=Courier]z = 2.71828182845904524#[/FONT]
[FONT=Courier]PRINT "z = 2.71828182845904524# (18-digit e literal cast as double)"[/FONT]
[FONT=Courier]PRINT "result: ";STR$(z,18)[/FONT]
[FONT=Courier]CALL display_memory(z)[/FONT]
 
[FONT=Courier]WAITKEY$[/FONT]
 
[FONT=Courier]END FUNCTION[/FONT]
[/FONT]

[Michael Mattias]

The following message was sent today to [email protected]...

Now that wasn't so hard, was it?

Not to mention, now you KNOW it will be addressed by someone who can actually do something about it - If .. and that's a IF - it is not behaving "as advertised."

(Big 'If.' get it? I even thought of that all by myself!)

MCM

[Francis Reddy]

Thanks, Walter, for running down that problem.

Frank

[Walter Henn]

:blah:

Now that wasn't so hard, was it?

Not to mention, now you KNOW it will be addressed by someone who can actually do something about it - If .. and that's a IF - it is not behaving "as advertised."

(Big 'If.' get it? I even thought of that all by myself!)

MCM

[Steve Rossell]

Microsoft altered the 32-bit sub-system of Windows, so that the FPU is initialized to a limited precision of 53 bits of mantissa. Previously, the FPU was initialized to a 64-bit mantissa as designed by Intel.

We implemented an internal change to compiled executables so that extended precision is guaranteed in run time code. However, evaluation of numeric literals in your compiled programs are currently limited to double precision. This will be increased to extended precision in the next version of PowerBASIC For Windows and the PowerBASIC Console Compiler.

[Walter Henn]

Microsoft altered the 32-bit sub-system of Windows, so that the FPU is initialized to a limited precision of 53 bits of mantissa. Previously, the FPU was initialized to a 64-bit mantissa as designed by Intel.

We implemented an internal change to compiled executables so that extended precision is guaranteed in run time code. However, evaluation of numeric literals in your compiled programs are currently limited to double precision. This will be increased to extended precision in the next version of PowerBASIC For Windows and the PowerBASIC Console Compiler.

I appreciate Steve Rossell's fast response to my e-mail and look forward to the next version of PB/CC.

Nevertheless, his response is a bit troubling. PB knew back in 2000 that Microsoft altered the 32-bit sub-system of Windows, so that the FPU was initialized to a limited precision of 53 bits of mantissa. And, in versions PB/CC 3.0 and PB/Win 7.0 of the compilers (dating back to 2003), the highest FPU precision was enforced in the compiled executables:

Well, for starters it's always a good idea to add a type-specifier to ensure these kind of numeric literals are actually being given the precision you actually want. See "Numeric Literals" in the "Data Types: Numbers, Strings, Constants and Literals" topic of the help file. Also, your code to set the FPU precision is redundant in PB/CC 3.0 and PB/Win 7.0, as these compilers enforce the highest FPU precision for you anyway.

All of this begs the question: Why has PB -- throughout the ensuing years -- remained oblivious to the problem that literals (including those cast with extended precision) were limited to double precision? Utilizing double precision literals with extended precision variables in one's calculations sort of defeats the purpose of using extended precision, don't you think? Unless, of course, you need the extended range.

--WH

[Rodney Hicks]

Perhaps nobody brought it to their attention sooner with a clear enough explanation of the problem.

Perhaps maybe their focus was on getting us a 32 bit compiler so you could handle the extended precision quicker(when you get it.).
And maybe handling a lot of other issues that pop up from time to time and can be solved sooner.
Maybe priorities that we as users of their product have no concept of.

Thank you for grinding this axe, and I'm sure the Powers that Be at PB will let us have it once they've sharpened it.

[Walter Henn]

Hi Rodney --

Thanks for your response. If I were PB, I would certainly want you in my corner.

Perhaps maybe their focus was on getting us a 32 bit compiler so you could handle the extended precision quicker(when you get it.).
And maybe handling a lot of other issues that pop up from time to time and can be solved sooner.
Maybe priorities that we as users of their product have no concept of.

But 5 years, Rodney? :hmmm: Besides, IMO, one of the highest priorities should be assuring that the precision obtained by programming with the compiler is in accordance with the stated precision in the documentation (both for variables and literals). Programmers, who develop computational programs, depend on that.

--WH

[Michael Mattias]

>But 5 years, Rodney?

Sure. I had a bug in one of my pieces of software which was not brought to my attention for nine (9) years.

Took me close to, oh, 20 minutes to fix...once I knew about it.

MCM

[Walter Henn]

>But 5 years, Rodney?

Sure. I had a bug in one of my pieces of software which was not brought to my attention for nine (9) years.

Took me close to, oh, 20 minutes to fix...once I knew about it.MCM

:blah:

If you're going to quote me, at least don't take me out of context:

Rodney Hicks:
Perhaps maybe their focus was on getting us a 32 bit compiler so you could handle the extended precision quicker(when you get it.).
And maybe handling a lot of other issues that pop up from time to time and can be solved sooner.
Maybe priorities that we as users of their product have no concept of.

Walter Henn:
But 5 years, Rodney?

Do you ever get the point, Michael? Or is self-worship your specialty?

[Rodney Hicks]

You can take a horse to water, but you can't make him drink. So you-

[Michael Mattias]

What the hell is the problem here?

I read what you posted as a sense of surprise that something might not get found and/or changed in five years. I merely provided an example of where five years is not unreasonable.

And I will thank you to cease and desist casting personal aspersions on your own before I am forced to ask the authorities to intervene.


MCM

[Walter Henn]

And someone went on record agreeing with this? Sheesh, this generation of programmers has gone straight down the toilet.

(I'd call this example 'Programming 101' but I don't think it's quite that advanced).

MCM

And I will thank you to cease and desist casting personal aspersions on your own before I am forced to ask the authorities to intervene.

Do what you have to, Michael. Like most bullies, you can dish it out, but you can't take it!

[Walter Henn]

As indicated in Steve Rossell's post in the thread “64-bit Precision for Extended Precision Variables Guaranteed?,” the precision of floating point literals cast to extended precision results in only double precision. Therefore, the precision is limited to ~ 16 decimal digits. We will have to wait till the next version of PB/CC to obtain extended precision (18 decimal digits) for literals cast as extended precision.

In the meantime, however, the following procedure illustrates a simple method for obtaining higher precision (18 decimal digits) for your floating point numeric literals....

Please click on link (blue arrow) in the above quote for an interim solution to obtaining 18-digit precision for your floating point literals.

--WH