Announcement

Collapse
No announcement yet.

64-bit Precision for Extended Precision Variables Guaranteed?

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

  • #21
    Originally posted by Walter Henn View Post
    ...Your feeling that the parsing of the extended precision literal is the problem makes sense. I hadn't remembered that literals are converted at compile time.
    That is actually not crucial. If you enter the string from keyboard with LINE INPUT and convert to a number with VAL the result is just the same.
    Aldo Vitagliano
    alvitagl at unina it

    Comment


    • #22
      There is nothing to stop you from writing your own function...
      Code:
      FUNCTION StringToExt (S AS STRING) AS EXT
      ...
      END FUNCTION
      
         Extvar = StringToExt ("3.1415926535897932385")
        ....
      ... which would handle numeric literals to as many digits as desired up to the limit of the EXT data type.

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

      Comment


      • #23
        Originally posted by Michael Mattias View Post
        There is nothing to stop you from writing your own function...
        Absolutely correct!
        However if I apply the method of mathematical induction to this statement I am led to conclude: "There is nothing to stop anybody from writing his own compiler ... so why to buy any compiler at all ? ..."
        OK, that was a joke ... Turning serious, I must say I can't figure out how to do it, and the need is not so desperate to let me undertake the venture: I can live without it, and I am very happy of PB anyhow. However nobody can be blamed for expressing a wish, and I would certainly appreciate if the VAL and STR$ functions could in the future properly handle up to 20 digits, or if somebody writes efficient functions for doing the same.
        Regards
        Aldo Vitagliano
        alvitagl at unina it

        Comment


        • #24
          >I must say I can't figure out how to do it

          I can get you started...
          Code:
          FUNCTION SuperVal (S as string) AS EXT
          
           LOCAL wExt AS EXT  ' <<< where we build
           LOCAL dividend as EXT, divisor AS EXT 
           LOCAL Z AS LONG
          
            w = (string in before any decimal point)
            wExt =   VAL(W)     ' no problem with integers
          
            Divisor = 10#
            W    = StringAfter Decimal point
            FOR Z = 1 TO (number of digits in W) 
               Dividend = VAL (MID$(W, Z,1)   ' get the digit
               WExt      = WExt  + Dividend  / Divisor
               Divisor     =  Divisor * 10#
            NEXT
            FUNCTION = wExt
          
           ....
          Obviously will not handle big numbers BEFORE the decimal point, but you could play with that if needed...

          The idea here is I only used VAL on integers and have avoided any decimal division... meaning you should get full precision at all times.

          This simply MUST be worth a try.

          You can do the same kind of thing to create a "SuperSTR$()" or "SuperFormat$()" function.. use only whole numbers and build your string using integer math.

          Yes, when you have it working it would be nice of you to post these functions in the Source Code Forum.

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

          Comment


          • #25
            Aldo,
            properly handle up to 20 digits, or if somebody writes efficient functions for doing the same.
            the 20th digit is only valid 8% of the time so it's unwise to use it unless you really know you're in that 8%. 19 digits are always good.

            Code to format to 19 digits has already been posted here before:
            http://www.powerbasic.com/support/pb...ad.php?t=24224

            To go the other way, use Michael's approach.

            Paul.
            Last edited by Paul Dixon; 11 Dec 2007, 01:00 PM.

            Comment


            • #26
              There is nothing to stop you from writing your own function..
              Why should we have to write our own function? An EXT literal should have better precision than a DOUBLE literal. I don't think asking PB to take a look at this is asking too much.
              Last edited by Greg Lyon; 11 Dec 2007, 06:34 PM.

              Comment


              • #27
                The compiler makes no assumptions of the "accuracy" of numeric literals in your code. It is up to the programmer to cast those numeric literals into the intended precision.

                In other words, if accuracy is of importance to you, always add a type-specifier to a numeric literal.

                ------------------
                Lance
                PowerBASIC Support
                As suggested in this quote, it is the programmer's responsibility to cast [floating point] numeric literals with a type specifier [single, double, or ext] to achieve the desired degree of precision. Since it's a fully documented part of the PB language, I accept that responsibility. However, when I cast a floating point numeric literal as an extended precision type, it's PB's responsibility to ensure that I get extended precision for that literal. So, I am in total agreement with Greg's post above.

                In a previous post of mine, I indicated that the results for PBCC 4.03 and PBCC 4.04 are different when the same floating point literal is cast as extended precision. It now occurs to me that when PB shifted from the 16-bit compiler version (4.03) to the 32-bit compiler (4.04), this bug was obviously introduced into the newer compiler.

                As I have previously indicated, I intend to submit this problem to support in the next couple of days. In the meantime, I would appreciate any additional comments you wish to make.
                Last edited by Walter Henn; 12 Dec 2007, 04:39 AM.

                Comment


                • #28
                  Originally posted by Paul Dixon View Post
                  the 20th digit is only valid 8% of the time so it's unwise to use it unless you really know you're in that 8%.
                  Mmm ... not really ... at least from the "physical" point of view.
                  The "absolute" numerical accuracy of a given numerical representation of the real number X corresponds to the smallest number EPS you can add to X, getting a result Y = X+EPS different from X. The "relative" numerical accuracy is simply the ratio EPS/X.
                  Here is a very simple code that I encourage everybody to try, which determines the absolute and relative accuracy of the internal binary representation of whatever input decimal number. The code can be simply switched to test double precision or single precision accuracy as well.
                  Code:
                  DEFEXT A-Z 
                  ' DEFDBL A-Z
                  ' DEFSNG A-Z
                  FUNCTION PBMAIN()
                     DO
                        LINE INPUT "Enter a number: " NUM$
                        X = VAL(NUM$): IF X=0 THEN EXIT DO
                        EPS=X/2^22##
                        DO
                           Y=X+EPS
                           IF Y=X THEN EXIT DO
                           EPS=EPS/2
                        LOOP
                        DO
                           EPS=EPS*1.00781250 
                           Y=X+EPS     ' ... just used to fine-tuning EPS 
                           IF Y<>X THEN EXIT DO
                        LOOP
                        PRINT "Absolute accuracy on X is "; USING$("##.#^^^^", EPS)
                        PRINT " Relative accuracy on X is "; USING$("##.#^^^^",EPS/X)
                     LOOP
                  END FUNCTION
                  You will see that the maximum relative error on X is about 5E-20.
                  If the decimal mantissa is in the form 1.1... then the absolute error is at a minimum (about 5.5E-20) and corresponds to an uncertainty of 5 units on the 21th significant digit. If the decimal mantissa is in the form 9.9 ... then the absolute error is at a maximum (about 4.5E-19), and corresponds to an uncertainty of 4 units on the 20th decimal digit.
                  Even in this latter extreme case, from the point of view of error propagation, it is slightly better to have the 20th digit rather than to skip it.
                  Last edited by Aldo Vitagliano; 12 Dec 2007, 08:16 AM.
                  Aldo Vitagliano
                  alvitagl at unina it

                  Comment


                  • #29
                    An EXT literal should have better precision than a DOUBLE literal.
                    Literals don't have precision. But that's nitpickingthe semantics.
                    I don't think asking PB to take a look at this is asking too much.
                    I don't think so either.

                    However, if you need this feature ("greater number of significant digits in numeric literals") anytime before some next release, your choices are A) write it yourself; or B) Postpone the entire project. Your call.

                    (FWIW, you only have to write about two percent of it, since I posted the roadmap for you).

                    And since you feel so strongly it is worth a look by the publisher...

                    I assume I can bet the house you have actually invested the paltry 60 seconds or so to drop an email with this new feature suggestion to the designated address [email protected]?


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

                    Comment


                    • #30
                      See this
                      http://www.powerbasic.com/support/pb...ad.php?t=22141
                      "The trouble with quotes on the Internet is that you can never know if they are genuine." - Abraham Lincoln.

                      Comment


                      • #31
                        FWIW, here is some code which will handle generating the factorial of 100 with all signficant digits.... which you might call a "SuperFORMAT$()" function..
                        Tutorial and source code for Qbasic, QuickBASIC and PowerBASIC showing a technique to calculate large numbers to at least 154 significant digits. Freeware
                        http://www.talsystems.com/tsihome_ht...ads/Factor.zip

                        Ok, so it's not for Windows.. but it does compile/execute "as is" for all three BASIC language products listed above, so how hard could it be to port it to PB/Windows?

                        Complete list of downloadable stuff at my website: http://www.talsystems.com/tsihome_html/techcorner.html

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

                        Comment


                        • #32
                          Quote:
                          An EXT literal should have better precision than a DOUBLE literal.
                          Literals don't have precision. But that's nitpickingthe semantics.
                          It's not only nitpicking, but it's very unworthy of you, Michael.
                          Furthermore, you're wrong. Greg did not say that a literal has precision; he stated that an EXT literal and a DOUBLE literal have a precision. The obvious meaning of his statement is that the literal cast as an EXT should be stored with a better precision than a literal cast as a DOUBLE. And everyone knew what he was saying!

                          I assume I can bet the house you have actually invested the paltry 60 seconds or so to drop an email with this new feature suggestion to the designated address [email protected]?
                          You've completely missed the point, Michael. Greg is not suggesting a "new feature." He's asking that the implementation of the existing feature (casting floating point literals to extended precision) be implemented correctly, in accordance with the current PB documentation on this floating point type.

                          If you've read all of the posts on this thread, I indicated that I would submit this issue to support in a couple of days (to get the benefit of any additional constructive comments from the PB community).
                          Last edited by Walter Henn; 12 Dec 2007, 04:57 PM.

                          Comment


                          • #33
                            Originally posted by Michael Mattias
                            Literals don't have precision. But that's nitpickingthe semantics.
                            You know what I meant, yes, you are nitpicking.
                            Last edited by Greg Lyon; 12 Dec 2007, 11:22 PM.

                            Comment


                            • #34
                              ...(casting floating point literals to extended precision) be implemented correctly [bold mine. MCM]
                              The help file might shed some light here...
                              8. A numeric constant with a decimal point and more than six significant digits, but less than 17, or a whole number too large to be a Quad-integer but small enough to fall within the range of Double-precision floating-point, is stored in Double-precision floating-point format. Larger values (with up to 18 significant digits) are stored in Extended-precision format.
                              It appears to me that 18 significant [decimal] digits is the documented limit for numeric literals; ergo the compiler has implemented the storage of said numeric literals "correctly."
                              Michael Mattias
                              Tal Systems Inc. (retired)
                              Racine WI USA
                              [email protected]
                              http://www.talsystems.com

                              Comment


                              • #35
                                it's not elegant but works!
                                Code:
                                z = 3.1415926535## + 0.0000000000897932385## =  3.14159265358979324
                                memory contents:   40  00  C9  0F  DA  A2  21  68  C2  35
                                stored dec value:  3.141 5926 5358 9793 1160
                                pi:                3.141 5926 5358 9793 2385
                                
                                z = 4 * atn(1)=  3.14159265358979324
                                memory contents:   40  00  C9  0F  DA  A2  21  68  C2  35
                                stored dec value:  3.141 5926 5358 9793 2385
                                pi:                3.141 5926 5358 9793 2385
                                "The trouble with quotes on the Internet is that you can never know if they are genuine." - Abraham Lincoln.

                                Comment


                                • #36
                                  Michael,

                                  Yes but if you look above that list you will find ( at least in v4.04 )
                                  Code:
                                  If a type-specifier does not follow a numeric constant, the following rules are 
                                  used to determine the precision the value  will be stored in:
                                  and even further up it states
                                  Code:
                                  You can also force a literal value to be stored with a given precision by following 
                                  the constant with one of the variable type-specifiers (%, &, &&, ?, ??, ???, !, #, ##, @, @@). 
                                  This ability becomes very important when working with Currency and other floating-point numbers.

                                  I found this under Constants and Literals.

                                  So I'm throwing in my 2 cents for sending the matter on to support and
                                  hearing an official reply.
                                  Last edited by Paul D. Elliott; 13 Dec 2007, 02:23 PM.

                                  Comment


                                  • #37
                                    PBCC users are mathematicians, scientists, etc. to whom accuracy is not just a lofty ideal.
                                    Perhaps I'm way out of line here. Nevertheless, I want to point something out:

                                    Walter, throughout this thread you've been talking about "precision." Now you are equating precision with accuracy. 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. For example, what is the difference between "1" and "1.0?" Nothing except precision. The first is correct to one digit of precision, the second is correct to two digits of precision.

                                    However, if I have code that does:

                                    A## = 1. 00000000000000000
                                    PRINT FORMAT$(A##, 18)

                                    and I get a result of 1.000000000000000234

                                    then I can say that the number is incorrect past 15 digits of precision.

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

                                    Comment


                                    • #38
                                      Originally posted by Michael Mattias View Post
                                      It appears to me that 18 significant [decimal] digits is the documented limit for numeric literals; ergo the compiler has implemented the storage of said numeric literals "correctly."
                                      Michael, Michael, Michael!

                                      You've been shouting so loudly that I don't think you're able to listen to what others are saying. You claim that, "the compiler has implemented the storage of said [extended] numeric literals correctly." If so, can you please explain why the following code does not produce the same results (as it should) for the variable, z?

                                      Code:
                                       
                                      #COMPILE EXE
                                      #REGISTER NONE
                                      #DIM ALL
                                       
                                      FUNCTION PBMAIN () AS LONG
                                       
                                      DIM z AS EXT, value_string AS STRING
                                       
                                      z = 4 * ATN(1) 
                                      value_string = "z = 4 * ATN(1) = "
                                      PRINT TAB(32 - LEN(value_string));value_string;STR$(z,18)
                                       
                                      !finit
                                      !fldpi   'put the value of pi on the FPU stack
                                      !fstp z  'store that value in z
                                      value_string = "z = fldpi = "
                                      PRINT:PRINT TAB(32 - LEN(value_string));value_string;STR$(z,18)
                                       
                                      z = 3.141592653589793238## 'pi literal
                                      value_string = "z = 3.141592653589793238## = "
                                      PRINT:PRINT TAB(32 - LEN(value_string));value_string;STR$(z,18)
                                       
                                      WAITKEY$
                                       
                                      END FUNCTION
                                      The results are:
                                      z = 4 * ATN(1) = 3.14159265358979324
                                      z = fldpi = 3.14159265358979324
                                      z = 3.141592653589793238## = 3.14159265358979312

                                      The value of the literal, pi, cast to extended precisionl, 3.14159265358979312, has 18 significant digits, but is only accurate to 16 places. The values for "4 * ATN(1)" and "fldpi", 3.14159265358979324, have 18 significant digits and are accurate to 18 places.

                                      Had the result for the extended precision literal been, .14000000000000000, would you have argued that this result would have been the correct implementation of casting the literal, 3.141592653589793238, to extended precision because it has 18 significant digits?

                                      Comment


                                      • #39
                                        Originally posted by Walt Decker View Post
                                        Walter, throughout this thread you've been talking about "precision." Now you are equating precision with accuracy. 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..
                                        True. But, try getting an accuracy of 18 digits if the precision of the calculation is only 16 digits.

                                        However, if I have code that does:

                                        A## = 1. 00000000000000000
                                        PRINT FORMAT$(A##, 18)

                                        and I get a result of 1.000000000000000234

                                        then I can say that the number is incorrect past 15 digits of precision.
                                        You can also say that you're not using PowerBasic; otherwise your result would be 1.00000000000000000.

                                        I highly doubt that a scientist or mathematician who needed accurate results to greater than 15 digits of precision would us a PC.
                                        Really! You highly doubt that there are any scientists or mathematicians -- who need 18 digits of precision --who use PowerBasic? Furthermore, are you not aware that there are a myriad of PC math libraries that perform floating point calculations with much greater precision than 15 digits?
                                        Last edited by Walter Henn; 13 Dec 2007, 07:38 PM. Reason: Correction: 15 bits should have been 15 digits.

                                        Comment


                                        • #40
                                          Walter, nowhere in my post did I say anything about power basic nor did I say anything about bits. Folks who need accuracy greater than 15 significant digits use computers created for that and languages created for that.

                                          Yes, I'm aware that there are math libraries that perform calculations greater than 15 significant digits. 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?
                                          Walt Decker

                                          Comment

                                          Working...
                                          X