Announcement

Collapse
No announcement yet.

How do I get full extended precision value?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • How do I get full extended precision value?

    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?

  • #2
    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
    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      This will display every bit:
      Code:
      #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: significand 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),16)
          s = LEFT$(s, 1) & "_" & MID$(s, 2, 15) & "_" & MID$(s, 17, 1) & "_" & RIGHT$(s, 63)
          ? s
      
      END FUNCTION
      Last edited by John Gleason; 20 May 2008, 04:13 PM. Reason: yet another error (my arithmetic, ow) 16>17 integer bit

      Comment


      • #4
        (deleted)
        Dale

        Comment


        • #5
          '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
          Michael Mattias
          Tal Systems Inc. (retired)
          Racine WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            >> Is that bit usage documented anywhere?

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

            Comment


            • #7
              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.
              Michael Mattias
              Tal Systems Inc. (retired)
              Racine WI USA
              mmattia[email protected]
              http://www.talsystems.com

              Comment


              • #8
                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)
                Engineer's Motto: If it aint broke take it apart and fix it

                "If at 1st you don't succeed... call it version 1.0"

                "Half of Programming is coding"....."The other 90% is DEBUGGING"

                "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                Comment


                • #9
                  Are we talking 63 bit precision then John?

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

                  Comment


                  • #10
                    >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?)
                    Michael Mattias
                    Tal Systems Inc. (retired)
                    Racine WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      >> 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.

                      Comment


                      • #12
                        Thanks, John.

                        Comment


                        • #13
                          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/pb...ad.php?t=16021

                          Paul.

                          Comment


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

                            Comment


                            • #15
                              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.

                              Comment


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

                                Comment


                                • #17
                                  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.
                                  Michael Mattias
                                  Tal Systems Inc. (retired)
                                  Racine WI USA
                                  [email protected]
                                  http://www.talsystems.com

                                  Comment


                                  • #18
                                    >> 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!"

                                    Comment


                                    • #19
                                      You cannot get a quart from a pint pot
                                      Unless the quart pot has been mis-labelled as a pint?

                                      Paul.

                                      Comment


                                      • #20
                                        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.

                                        Comment

                                        Working...
                                        X