How do I get full extended precision value?

[Tom Ulrich]

Extended precision is 80 bits long.

With STR$(a##,18) or Format$ commands one can get 18 digits.

I want to get all the digits.

The mantisa is a binary number and rounded to display 18 digits.

How do I get the full value?

[Michael Mattias]

There are no more significant decimal digits to get. Anything past 18 is 'pot luck' (see help file).

This has come up here before,with long threads resulting. Try a search on "EXT" and/or "extended precision"

MCM

[John Gleason]

This will display every bit:

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG

    LOCAL extVar AS EXT, evPtr AS LONG, s AS STRING
    evPtr = VARPTR(extVar)
    extVar = -38847.32737 * 227738489.33221

                  'Added 5/16, terminology correction: [COLOR="Red"]significand[/COLOR] consists of integer bit & fraction 63 bits.
                                                                        |<--------------significand--------------->|
    'here are all 80 bits divided into sign (1 bit), exponent (15 bits), integer bit (1 bit), and fraction (63 bits)
    s = BIN$(PEEK(LONG,evPtr + 6),32) & BIN$(PEEK(LONG,evPtr + 2),32) & BIN$(PEEK(WORD,evPtr),[COLOR="Red"]16[/COLOR])
    s = LEFT$(s, 1) & "_" & MID$(s, 2, 15) & "_" & MID$(s, [COLOR="Red"]17[/COLOR], 1) & "_" & RIGHT$(s, 63)
    ? s

END FUNCTION

[Dale Yarker]

(deleted)

[Michael Mattias]

'here are all 80 bits divided into sign (1 bit), exponent (15 bits),
integer bit (1 bit), and significand (63 bits)

Is that bit usage documented anywhere? It sounds familiar but darned if I can find anything in the PB/WIN 8.03 help file about it.

MCM

[John Gleason]

>> Is that bit usage documented anywhere?

It is from the Intel Software Developer's Manual (Vol. 1 of gosh knows how many)

[Michael Mattias]

Oh, I see, it's an IEEE extended precision float.

It used to be in the PB manuals and/or help files that PB 'single' and 'double' were, in fact, IEEE single and double precison floats, but don't see any of those references in the current version of the help file. A full-text search on "IEEE" turns up only " Like most modern compilers, PowerBASIC uses the IEEE standard for all floating-point arithmetic."

It makes a lot of sense for PB to use the IEEE data types; it makes less sense that they would not put that fact in the help file.

[Cliff Nichols]

Its like one of the caveats, (99% will NEVER see), but I wish PB update a few things of documenting "Under THESE conditions thennnnn..."

Hey, maybe its a time for a NFS like you are so fond of mentioning?
(not sure how high on the list it would get, but worthwhile since, not asking, is not telling that a feature could make a product better)

[David Roberts]

Are we talking 63 bit precision then John?

If so then we have 18.96 decimal; 63 x log(2)

[Michael Mattias]

>Hey, maybe its a time for a NFS like you are so fond of mentioning?

I often send in "documentation update needed" notes in addition to new feature suggestions; and those are acknowledged, too.

I for one think "help file only" updates would be nice to get between actual compiler updates, but we ain't seen them. (Yet?)

[John Gleason]

>> Are we talking 63 bit precision then John?

Yes, even tho Intel lumps the integer bit under the heading of "Precision bits" only 63 bits are used for the fraction. That indeed looks jussst shy of 19 decimal digits.

[David Roberts]

Thanks, John.

[Paul Dixon]

This topic comes up regularly.
The EXT format has 64 bits of precision, the 1 bit leading integer plus the 63 bit fraction.
This gives 19 decimal digits all the time and a 20th digit which is ocassionaly correct.

http://www.powerbasic.com/support/pbforums/showthread.php?t=16021

Paul.

[David Roberts]

Had a look at that link, Paul. It got a bit 'hairy' didn't it?

[John Gleason]

That did get a bit hairy! If you're interested, I do have code that you can run yourself which gives perfect 19 digit accuracy up to ~4.5E+18 but loses the 19th digit everywhere above that. Tho I must admit, it ain't purdy--it was pure research strictly for my curiosity.

[David Roberts]

Fancy slaving over a 19th digit - you should go out more, John.

[Michael Mattias]

Unless I am badly mistaken, someone here actually markets some kind of "many digits of precision" piece of software.

EXT data type is documented to give you a maximum of eighteen decimal digits precision.

Need more? Don't use EXT. You cannot get a quart from a pint pot.

[John Gleason]

>> Fancy slaving over a 19th digit - you should go out more, John.

That I should, that I should. Or at least close the PB 8 IDE for a couple minutes a day. Got the shakes pretty bad last time I shut it down tho.

>> Need more? Don't use EXT.

I did a bunch of arbitrary precision functions quite a while ago, so I can't really explain why I'd try. "SIR, I have no excuse, SIR!"

[Paul Dixon]

You cannot get a quart from a pint pot

Unless the quart pot has been mis-labelled as a pint?

Paul.

[Tom Ulrich]

John Gleason posted some code so I used it (thankyou). I also used a symbolic algebra program to obtain all digits to compare.

The program has the following line to generate an extended value.
extVar = -38847.32737 * 227738489.33221

The binary result:
"11000000001010101000000010111101110000101101110001100010110110011101010100001001"
Exact decimal from binary = -8847031649837.61451053619384765625
For ref. the exact multiply = -8847031649837.6145555877
The result of PB multiply = -8847031649837.61"
The result of PB multiply = -8847031649837.61451 (18 digits displayed)

Since PB converts the constants to lowest precision needed ... it used double precision. I forced it to use extended precision constants.
extVar = -38847.32737## * 227738489.33221##"

The only change in results is in the last 6 bits.
The binary result:
"11000000001010101000000010111101110000101101110001100010110110011101010100111000"
Exact decimal from binary = -8847031649837.61455535888671875"
For ref. the exact multiply = -8847031649837.6145555877
The result of PB multiply = -8847031649837.61"
The result of PB multiply = -8847031649837.61456 (18 digits displayed)"

The reason for the numerical differences is that the computer uses base 2 and the input/display are in base 10. There is not an exact conversion going on. The mantissa or significand is not binary integer but binary fraction. The resulting binary fraction represents a large number of decimal digits aligned to base 2 fraction numbers.

Some explanation of binary fraction follows:
0.10110... = 1/2^1+1/2^3+1/2^4 = 1/2 + 1/8 + 1/16 +...
The 63rd bit is 1/2^63 = 1/9223372036854775808 which is:
=0.000000000000000000108420217248550443400745280086994171142578125 = 1.08420...e-19
Each bit fraction is added up to get the mantissa. Next 1 is added to the mantissa fraction and then it is multiplied by 2^exponent. (The exponent is 43 for the example run above for variable extVar.)

result = sign*mantissa*2^exponent

PB has to convert decimal base 10 number to a binary floating-point number that represents it as close as it can get. Integer values translate exactly if within each range. The numbers that can be represented more precisely have small magnitude exponent. If one has a huge number exponent of say 16380 then 2^16380 multiplies the error. The range of exponent is about +16383 to -16382 and that multiplied by the mantisa results in a decimal exponent 10^-4932 to 10^4932.

There are I believe 5 ways to round and there will be some loss going from one base to another base. If a base ten number is represented exactly in base 2 fraction then results will be excellent in floating-point math.