Announcement

Collapse
No announcement yet.

Math rounding...

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

  • Math rounding...

    Hi everybody,

    It's me again... sorry

    I have the following problem.

    Consider the function

    10 * ATN(10)

    which returns 14.7112767430373

    Then I would take the sinus of it by

    Sin(14.7112767430373) which results in .839676090553138

    Now, since I don't like to take those intermediate steps I like to do

    SIN(10 * ATN(10))

    which gives me almost the same result: .839676090553114

    Ok, it's minor but which one is now correct ?

    The .839676090553114 or the .839676090553138 ? Then, does it even matter if it's
    like 24 (ok, what do you call 15 numbers after the decimal ?)

    Sorry for disturbing this peaceful day

    Steven
    So here we are, this is the end.
    But all that dies, is born again.
    - From The Ashes (In This Moment)

  • #2
    I would have expected that these would provide slightly different results, but they all produce
    0.839676090553113542
    (which closely matches:
    0.83967609055311354153529611429164772360724355360757 )
    :

    Code:
        msgbox STR$(SIN(10 * ATN(10)), 18)
        msgbox STR$(SIN(10.0## * ATN(10.0##)), 18)
        aaa## = ATN(10.0##)
        aaa## = 10.0## * aaa##
        aaa## = SIN(aaa##)
        msgbox STR$(aaa##, 18)
    Kind regards
    Last edited by Eddy Van Esch; 9 Feb 2009, 03:49 AM.
    Eddy

    Comment


    • #3
      eh, sorry Eddy, it's Monday morning he... your point is ?
      So here we are, this is the end.
      But all that dies, is born again.
      - From The Ashes (In This Moment)

      Comment


      • #4
        Originally posted by Steven Pringels 3 View Post
        Ok, it's minor but which one is now correct ?
        The .839676090553114 or the .839676090553138 ?
        But to answer your question :
        0.839676090553114 is the better approximation of the two, but this:
        0.83967609055311354153529611429164772360724355360757
        is an even better one.

        Kind regards
        Eddy

        Comment


        • #5
          Forget about it. issue got solved.
          So here we are, this is the end.
          But all that dies, is born again.
          - From The Ashes (In This Moment)

          Comment


          • #6
            Steven,
            it's because the intermediate result has more digits than are displayed and when you type in the displayed value of 14.7112767430373 you've chopped off the remaining digits so you lose accuracy.
            Try this and you'll see some of the missing digits.
            Code:
            x##=10*ATN(10)
            PRINT x##
            PRINT STR$(x##,18)
            Paul.

            Comment


            • #7
              0.839676090553114 is the better approximation of the two, but []
              .839676090553113541535296114291647723607243553607 57
              is an even better one.
              No it is not a better approximation. Even using EXT types you can only rely on 18 decimal digits. In the above with its forty-nine decimal digits, the last thirty-one may as well be pot luck.

              >you've chopped off the remaining digits so you lose accuracy

              No, you didn't lose accuracy. You have lost display digits. (which may be meaningless anyway as per above).

              You cannot get neither blood from a turnip nor more than 18 accurate decimal digits from an EXTENDED data type.
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                Originally posted by Michael Mattias View Post
                No it is not a better approximation.
                Yes, it is ... because the large figure was not calculated using standard PB data types. I should have mentioned that.
                ..In the above with its forty-nine decimal digits, the last thirty-one may as well be pot luck.
                No, they are correct. I could have given you 5000 decimal digits and they would still be correct...

                Kind regards
                Eddy

                Comment


                • #9
                  > should have mentioned that.

                  Yes, you should have.

                  However, it is interesting to note the 'code-calculated' result is the rounded result from your tables or whatever you used.
                  Michael Mattias
                  Tal Systems (retired)
                  Port Washington WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    Originally posted by Michael Mattias View Post
                    ...from your tables or whatever you used.
                    I used my arbitrary precision floating point math library that I am developing.

                    Kind regards
                    Eddy

                    Comment


                    • #11
                      When variables are set to EXT type, id does not matter whether the computation is run in a single expression or intermediate results are stored into variables and then reused to complete the calculation.

                      On the other hand, when variables are set to DBL type, it does sometimes matter, and a better accuracy is generally attained if the computation is run in a single expression.

                      This because the FPU register use 80 bit precision anyhow, and when an expression is all evaluated inside the FPU registers, intermediate results are not rounded-off to 64 bits precision (as they are when transfer-to-memory takes place), resulting in a lower round-off error.

                      The following code shows the point:
                      Code:
                      [FONT="Courier New"][SIZE="3"]   
                      DEFDBL A-Z
                      FUNCTION PBMAIN()
                         A=10*ATN(10)
                         B=SIN(A)
                         PRINT USING$("##.################",B)
                         C=SIN(10*ATN(10))
                         PRINT USING$("##.################",C)
                         X##=10*ATN(10)
                         Y##=SIN(X##)
                         Z##=SIN(10*ATN(10))
                         PRINT USING$("##.#################",Y##)
                         PRINT USING$("##.#################",Z##)
                         WAITKEY$
                      
                      END FUNCTION  [/SIZE][/FONT]
                      Aldo Vitagliano
                      alvitagl at unina it

                      Comment

                      Working...
                      X