Announcement

Collapse
No announcement yet.

Printing EXT numbers

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

  • Printing EXT numbers

    hello !

    i take back here the pbwin thread http://www.powerbasic.com/support/pb...ead.php?t=7755

    my wish would be that pb implements a 20 digit string representation of extended precision floats, and this both for output and input of data.
    in the meantime here is an example of a function which seems to solve the output problem.
    note that in the given example 20 digits of pi are given, and the last one is wrong by 1 unit.
    the function is ugly and sloppy, involving many math and string operation, and probably buggy as well (i did very few tests).
    is someone willing to take the challenge and write a better one ... and maybe write one for input ...?

    Code:
    declare function strext$(byval x as ext)
    defext a-z
    function pbmain()
    
       pi=4*atn(1)
       print "correct value of pi is  3.141592653589793238462643..."
       print "pwbasic printed  pi is ";str$(pi,18)
       print "extended precis. pi is ";strext$(pi)
       print
       print "-0.01 - 1e-21 is  ";
       print strext$(-0.01##-1e-21#)
       waitkey$
    
    end function
    
    function strext$(byval x as ext)
    
       sg&=sgn(x): x=abs(x)
       a=int(log10(x))
       b=100*x/10^a
       c=int(b)
       d=(b-c)*1e17#
       function=left$(str$(sg&),1)+"."+format$(c)+format$(d,"00000000000000000")+"e"+format$(a+1,"000")
       
    end function
    regards


    ------------------
    aldo vitagliano
    mailto:[email protected][email protected]</a>
    Aldo Vitagliano
    alvitagl at unina it

  • #2
    My wish would be that PB implements a 20 digit string representation of extended precision floats, and this both for output and input of data.
    Call me simple, but wouldn't it be kind of foolish to try to implement a 20-digit string representation of a number which intrinsically has but 18 digits of accuracy?

    Maybe what you want is a "twenty (decimal) digits of accuracy float with a matching display (string representation) feature."

    MCM




    [This message has been edited by Michael Mattias (edited March 01, 2003).]
    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      Michael,

      > Call me simple, but wouldn't it be kind of foolish to try to implement a 20-digit string representation of a number which
      > intrinsically has but 18 digits of accuracy?

      Sorry, but my point is that extended precision numbers intrinsically have MORE than 18 digit precision !
      Actually the ratio of their least significant digit to their most significant one is 2^-63 = 1E-19.
      If you check the example you will see this rather clearly.



      ------------------
      Aldo Vitagliano
      mailto:[email protected][email protected]</A>
      Aldo Vitagliano
      alvitagl at unina it

      Comment


      • #4
        my point is that extended precision numbers intrinsically have MORE than 18 digit precision
        I may be a humble country boy; but my version of the PB/Win help file says this about EXT vars:

        Extended-precision values require 10 bytes of storage each. They have a range of approximately 3.4x10^-4932 to 1.2x10^4932, and offer 18 digits of precision. All 18 digits can be "displayed" using the extended STR$ format (eg, STR$(var##,18)).
        So, sorry, but no, <U>PowerBASIC</U> extended precision numbers do not have more than 18 digits of precision.

        MCM



        [This message has been edited by Michael Mattias (edited March 01, 2003).]
        Michael Mattias
        Tal Systems Inc. (retired)
        Racine WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          Michael,

          Being a little less humble, I can say that in the vast ocean of my ignorance there are a few little islands, and I believe to be sitting on one of them just now.
          It is quite true that in PB, extended float variables "offer 18 digits of precision". There is no direct way of get more digits.
          Perhaps the documentation of my old PBDLL 5 is more precise, stating that extended precision values "... can be displayed with up to 18 significant digits". Both statements refer to the output format of the variables, and not to their internal storage format.
          Extended precision values are stored in 80 bits: 1 bit for the sign, 15 bits for the exponent, 63 bits for the mantissa and 1 "implied bit".
          It should be so in PB as it was for ex. in the old Microsoft C 7.0, and some competent guy from PB might confirm it.
          63 bits means a range 0 - 2^63 -1, or 0 - 10^19, that is 1 followed by 19 zeros, or 20 total digits.
          The total significant digits will be 19 if the number is like 9,000,000,000,000,000,000.

          If these arguments look to abstract to be convincing, I can offer the experimental proof of them:
          Code:
          FUNCTION PBMAIN()
          
             EPS# = 1E-19 '... This is the smallest positive number such that (1 + EPS) > 1
             X## = 1
             Y## = X## + EPS#  '... if 1.000,000,000,000,000,000,1 is stored in memory with 19 decimal digits ...
             DELTA# = Y##-X##
             PRINT DELTA#      '... then DELTA must be > 0
             Y## = X## + EPS#/2 '... 1.000,000,000,000,000,000,05 cannot be stored with all digits ....
             DELTA# = Y## - X## '... so DELTA = 0
             PRINT DELTA#
             
             WAITKEY$
          
          END FUNCTION
          Best regards



          ------------------
          Aldo Vitagliano
          mailto:[email protected][email protected]</A>
          Aldo Vitagliano
          alvitagl at unina it

          Comment


          • #6
            ..some competent guy from PB might confirm
            I'm not with PowerBASIC, but I'm reasonably competent...

            A 63 bit binary mantissa allows for a maximum value of 2^62 - remembering that the first bit is the units bit : 2^0.

            2^62 = 4611686018427387904 (19 decimal digits).

            Except that if you add one to 2^62, (decimal result 4611686018427387905) you just overflowed your 63 bits.

            Ergo, you can only trust a 19-digit decimal digit numbers in the range:
            1000000000000000000-4611686018427387904.

            Meaning: since not all 19 digit decimal numbers are "trustable", the maximum decimal precision is 18 digits.

            Q.E.D. (?)

            MCM
            Michael Mattias
            Tal Systems Inc. (retired)
            Racine WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              All,
              from the Intel manual, the limit of extended real numbers is 64 bits = 2^64= 1.8446744 x10^19.

              That's 19 useful digits. i.e digits which are always worth looking at.

              0.8446744 out of 10 times, there is a 20th digit worth looking at.

              Paul.

              Comment


              • #8
                Michael,
                <
                < A 63 bit binary mantissa allows for a maximum value of 2^62 - remembering that the first bit is the units bit : 2^0.
                <
                I don't blame you for falling in this trap, because I myself did.
                For unsigned numbers (remember the sign is given by an extra bit):
                Code:
                with  1 bit  you can represent 0 to   1
                      2 bits                   0 to   3
                      3 bits                   0 to   7
                      4 bits                   0 to  15
                      .................................
                      8 bits                   0 to 255
                      .................................
                      N bits                   0 to 2^N - 1
                      .................................
                     63 bits                   0 to 9,223,372,036,854,775,808 (0 - 9*10^18 or 0 - 10^19)
                      .................................
                i.e. 19 to 20 digits "worth looking at" as Paul correctly writes.

                Regards


                ------------------
                Aldo Vitagliano
                mailto:[email protected][email protected]</A>



                [This message has been edited by Aldo Vitagliano (edited March 02, 2003).]
                Aldo Vitagliano
                alvitagl at unina it

                Comment


                • #9
                  Code:
                  63 bits                   0 to 9,223,372,036,854,775,808
                  OK, say I accept your math.

                  If you add one (1) to the above, the result is still 19 decimal digits, but has overflowed; meaning, you cannot trust this particular 19 decimal digit number. You can only trust 18 decimal digits.

                  A 63 bit mantissa therefore yields eighteen (18) decimal digit precision.


                  MCM


                  Michael Mattias
                  Tal Systems Inc. (retired)
                  Racine WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    To quote Paul from earlier:

                    All,
                    from the Intel manual, the limit of extended real numbers is 64 bits = 2^64= 1.8446744 x10^19.
                    That's 19 useful digits. i.e digits which are always worth looking at.

                    0.8446744 out of 10 times, there is a 20th digit worth looking at.

                    Paul.
                    There are 64 bits, not 63. The 19th digit is always good. The 20th digit is only good 8% of the time so it's better not to use it.
                    I suspect, without having checked, that PB limits the printout to 18 digits because there's a quick way to convert binary to decimal but it only works upto 18 digits.

                    Paul.

                    Comment


                    • #11
                      According to my notes, Extended-precision has 63 bits of normalized mantissa, not 64 bits. The 64th bit is always set, but is not a part of the mantissa as such.

                      Hence, there will always be at least 18 digits of accuracy in Extended precision. The 19th digit is accurate sometimes, and the 20th digit even less often.

                      Therefore, there is no advantage to displaying the 19th digit (or beyond) due to the fact that the accuracy of those digits is always questionable, hence its preferable to display such large values using scientific format instead.

                      If you do wish to display such a large value, then you might use something like the routine given by Aldo at the start of this topic.



                      ------------------
                      Lance
                      PowerBASIC Support
                      mailto:[email protected][email protected]</A>
                      Lance
                      mailto:[email protected]

                      Comment


                      • #12
                        Lance,
                        <<The 64th bit is always set, but is not a part of the mantissa as such.>>

                        The 64th bit is always set (i.e not 0) but it is still part of the number.
                        It is, in fact, the MOST significant digit/bit.

                        If I was writing decimal one hundred or ninety nine then I'd use 100 99 not 100 099.
                        i.e. the leading digit is always non-zero (as with extended reals) but you would never consider it be not part of the number.

                        Paul.

                        Comment


                        • #13
                          Makes no difference what the Intel manual says. At least not until if and when PowerBASIC explicitly says its "EXT" datatypes "follow the Intel manual."

                          If there ever was a case for "RTFM" this is it. The compiler vendor says datatype EXT is good to 18 significant decimal digits. If you can show that this is not true, then you have found a bug and should report it. If you don't like the way PB implements its EXT datatypes, don't use them. (Duh!)

                          MCM


                          Michael Mattias
                          Tal Systems Inc. (retired)
                          Racine WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment


                          • #14
                            Lance,

                            It is true that the 19th digit (after rounding) might not be accurate (not so often).
                            However, it could at most be inaccurate by one unit.
                            The important point is that in ALL cases the difference between the stored binary value and the 19 or 20 digits decimal representation will be smaller than the corresponding difference with the 18 digits representation.
                            In other words, the overall roundoff error in the 18 digit representation is ALLWAYS larger (or at most equal) to that of the 19 digits representation.
                            I can only see benefits in allowing PB to display 19 or 20 digits.
                            Old Microsoft C 7.0 could do that, and in PB you can actually display 18 digits of a double precision number. Nobody is ashamed of that, even if the last digit is certainly wrong.

                            Even more important is the INPUT of ASCII data, taking in account the 19th and 20th digit.
                            If you try this, the number is truncated, not even rounded to the 18th, with a doubtless althouh tiny loss of information.
                            To write a custom output function was rather easy, but so far I haven't solved the problem for the input.

                            Michael,
                            I am just giving suggestions. It is up to PB to consider them or throw them in wastepaper basket.
                            I consider the addition of two more digits an improvement, but I have no idea about the effort required by such improvement.
                            Everything is a matter of ratio between costs and benefits.

                            Apart from the above considerations, I am surprised that apparently nobody checked the code examples I have given, which show practical examples of the whole thing.
                            Here is another example, especially selected to show the worse case (the most favorable to the "not more than 18 digits" point of view.
                            Still you can see that the roundoff error in the 20 digits representation is much smaller than for the 18 digits one.
                            Code:
                            DECLARE FUNCTION STREXT$(BYVAL X AS EXT)
                            
                            DEFEXT A-Z
                            FUNCTION PBMAIN()
                               CLS
                               X=10: Y=13: Z=X/Y
                               PRINT "Correct value of 10/13 is:  .769230769230769230769230...."
                               PRINT "PB printed value is:       ";STR$(Z,18)
                               PRINT "20 digits string is:       ";STREXT$(Z)
                               PRINT
                               WAITKEY$
                            END FUNCTION
                            
                            FUNCTION STREXT$(BYVAL X AS EXT)
                            
                               SG&=SGN(X): X=ABS(X)
                               A#=INT(LOG10(X))
                               B##=100*X/10^A#
                               C##=INT(B##)
                               D##=(B##-C##)*1E17#
                               FUNCTION=LEFT$(STR$(SG&),1)+"."+FORMAT$(C##)+FORMAT$(D##,"00000000000000000")+"E"+FORMAT$(A#+1,"000")
                            
                            END FUNCTION
                            Regards



                            ------------------
                            Aldo Vitagliano
                            mailto:[email protected][email protected]</A>
                            Aldo Vitagliano
                            alvitagl at unina it

                            Comment


                            • #15
                              Folks, I hate to have to point out the obvious, but after all these years writing compilers, would you really think that R&D would not have at least looked at the possibility and rammifications of displaying more than 18 digits? I think not. Therefore, we can conclude that there were specific reasons why an 18-digit limit was imposed.

                              But, as I explained above, if you need to display more than 18 digits, then it's possible to do so with discrete code as you show... problem solved.


                              ------------------
                              Lance
                              PowerBASIC Support
                              mailto:[email protected][email protected]</A>
                              Lance
                              mailto:[email protected]

                              Comment


                              • #16
                                OK Lance, I got the point.
                                I will try to invent a function for the input as well.
                                Thanks
                                Bye

                                ------------------
                                Aldo Vitagliano
                                mailto:[email protected][email protected]</A>
                                Aldo Vitagliano
                                alvitagl at unina it

                                Comment


                                • #17
                                  Folks, I hate to have to point out the obvious, but after all these years writing compilers, would you really think that R&D would not have at least looked at the possibility and rammifications of displaying more than 18 digits? I think not. Therefore, we can conclude ..there were specific reasons why an 18-digit limit was imposed
                                  No, we may not "conclude," as you have offered no evidence of the object. We may, however, "infer," not unreasonably.

                                  (Sheesh, you'd think the Queen's English would be spoken better in a former colony... oops, forgot... we're one of those former colonies, too....)


                                  MCM


                                  Michael Mattias
                                  Tal Systems Inc. (retired)
                                  Racine WI USA
                                  [email protected]
                                  http://www.talsystems.com

                                  Comment


                                  • #18
                                    Mr Mattias, you've been racking up a number of what I deem to be personal attacks lately. So far I've been gracious and chosen to ignore your "commentary", but enough is enough.

                                    So lets be clear about it: one more of these and you will find yourself suspended from the forums.

                                    ------------------
                                    Lance
                                    PowerBASIC Support
                                    mailto:[email protected][email protected]</A>
                                    Lance
                                    mailto:[email protected]

                                    Comment

                                    Working...
                                    X