• is it a bug or don't I get it?

    From Marc Tee@21:1/5 to All on Wed Apr 13 01:14:29 2022
    Hello all
    I just wiped the dust off my old HP48GX in order to do some celestial navigation calculations. I like the function to convert HHMMSS into decimal hours, or degrees, if you will.
    Everything works fine, I can convert back and forth. But this morning I found a result that was obviously fairly off.
    When I calculate 11:54:54 minus 11:52:54 it should give me exactly 2 minutes, easy to see. But the operation on the HP results in 11.915 - 11.8816666667 = 0.333333333. This converted back to HHMMSS equals 0.015999999988, ie. 4 seconds off. Why?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From druid.bernard@gmail.com@21:1/5 to All on Wed Apr 13 06:32:28 2022
    Hello all
    I just wiped the dust off my old HP48GX in order to do some celestial navigation calculations. I like the function to convert HHMMSS into decimal hours, or degrees, if you will.
    Everything works fine, I can convert back and forth. But this morning I found a result that was obviously fairly off.
    When I calculate 11:54:54 minus 11:52:54 it should give me exactly 2 minutes, easy to see. But the operation on the HP results in 11.915 - 11.8816666667 = 0.333333333. This converted back to HHMMSS equals 0.015999999988, ie. 4 seconds off. Why?


    What is the actual code that you are using to make the calculation?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Irl@21:1/5 to druid.bernard@gmail.com on Wed Apr 13 18:57:28 2022
    Roundoff error. If you follow discussions of the cardinality of the reals or other such topics, you may recognize that 0.015999999999999999... is equivalent to .0160, i.e., 1 minute 60 seconds, i.e., 2 minutes. 0.015999999988 is a decent numerical
    approximation to that repeating decimal.
    On Wednesday, April 13, 2022 at 9:32:29 AM UTC-4, druid.bernard@gmail.com wrote:
    Hello all
    I just wiped the dust off my old HP48GX in order to do some celestial navigation calculations. I like the function to convert HHMMSS into decimal hours, or degrees, if you will.
    Everything works fine, I can convert back and forth. But this morning I found a result that was obviously fairly off.
    When I calculate 11:54:54 minus 11:52:54 it should give me exactly 2 minutes, easy to see. But the operation on the HP results in 11.915 - 11.8816666667 = 0.333333333. This converted back to HHMMSS equals 0.015999999988, ie. 4 seconds off. Why?
    What is the actual code that you are using to make the calculation?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Tee@21:1/5 to optic...@mindspring.com on Fri Apr 15 09:01:40 2022
    optic...@mindspring.com schrieb am Donnerstag, 14. April 2022 um 03:57:30 UTC+2:
    Roundoff error. If you follow discussions of the cardinality of the reals or other such topics, you may recognize that 0.015999999999999999... is equivalent to .0160, i.e., 1 minute 60 seconds, i.e., 2 minutes. 0.015999999988 is a decent numerical
    approximation to that repeating decimal.
    On Wednesday, April 13, 2022 at 9:32:29 AM UTC-4, druid....@gmail.com wrote:
    Hello all
    I just wiped the dust off my old HP48GX in order to do some celestial navigation calculations. I like the function to convert HHMMSS into decimal hours, or degrees, if you will.
    Everything works fine, I can convert back and forth. But this morning I found a result that was obviously fairly off.
    When I calculate 11:54:54 minus 11:52:54 it should give me exactly 2 minutes, easy to see. But the operation on the HP results in 11.915 - 11.8816666667 = 0.333333333. This converted back to HHMMSS equals 0.015999999988, ie. 4 seconds off. Why?
    What is the actual code that you are using to make the calculation?
    Hello

    I guess so. However, with all the calculations I have done so far, this has never occurred. When I convert HHMMSS into Decimals and add or subtract, then convert it back again into HHSSMM it is exact to the split second. But not in the specific example
    below. Moreover, on a HP41 it gives the proper result of 2 minutes..

    Here is what I do: Enter, for example, 3:55:59 (3.5559 ENTER, convert to decimals with the built in function (Time, HMS->) add 1:59:20 (1.5920) by converting and convert the result back (->HMS) I get 5:11:19 which is correct. So, I don’t get that
    rounding part, really.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Mitchell@21:1/5 to marc....@me.com on Sat Apr 16 02:56:05 2022
    On Friday, April 15, 2022 at 12:01:41 PM UTC-4, marc....@me.com wrote:
    optic...@mindspring.com schrieb am Donnerstag, 14. April 2022 um 03:57:30 UTC+2:
    Roundoff error. If you follow discussions of the cardinality of the reals or other such topics, you may recognize that 0.015999999999999999... is equivalent to .0160, i.e., 1 minute 60 seconds, i.e., 2 minutes. 0.015999999988 is a decent numerical
    approximation to that repeating decimal.
    On Wednesday, April 13, 2022 at 9:32:29 AM UTC-4, druid....@gmail.com wrote:
    Hello all
    I just wiped the dust off my old HP48GX in order to do some celestial navigation calculations. I like the function to convert HHMMSS into decimal hours, or degrees, if you will.
    Everything works fine, I can convert back and forth. But this morning I found a result that was obviously fairly off.
    When I calculate 11:54:54 minus 11:52:54 it should give me exactly 2 minutes, easy to see. But the operation on the HP results in 11.915 - 11.8816666667 = 0.333333333. This converted back to HHMMSS equals 0.015999999988, ie. 4 seconds off. Why?
    What is the actual code that you are using to make the calculation?
    Hello

    I guess so. However, with all the calculations I have done so far, this has never occurred. When I convert HHMMSS into Decimals and add or subtract, then convert it back again into HHSSMM it is exact to the split second. But not in the specific example
    below. Moreover, on a HP41 it gives the proper result of 2 minutes..

    Here is what I do: Enter, for example, 3:55:59 (3.5559 ENTER, convert to decimals with the built in function (Time, HMS->) add 1:59:20 (1.5920) by converting and convert the result back (->HMS) I get 5:11:19 which is correct. So, I don’t get that
    rounding part, really.


    How is the original question/answer _4_ seconds off? Isn't 0.015999999988 almost 0.02 ...which is 2 minutes?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Irl@21:1/5 to marc....@me.com on Sat Apr 16 08:57:55 2022
    The HP calculators, in general and as far as I know, use some rather clever internal tricks to figure out the expected value of a number given its finite-length (12 decimal digits, I believe, plus an exponent) representation. With the calculator in STD
    mode, try the following experiments: (given in pseudo-RPN code)
    1 9 divide 9 multiply: you get .999999999999 sort of not surprising but frustrating
    2 9 divide 9 multiply: you get 2. kind of a miracle
    In the case of your original question, the seconds part really has only about 9 or ten significant digits, so when you add and subtract two large numbers with a small difference, you should expect the result to be in error in the ninth or tenth digit.
    Usually the internal code does a good job of dealing with the problem, but not always.
    In the case of your original calculation, my HP50GX gives .000200000016. However, if you just use the built-in HMS-, you get simply .0002.
    I suggest you change your original calculation to use 1100 hours instead of 11 hours. You will find the errors are bigger. The machine has finite precision; it tries to generate results that would arise from a machine of infinite precision; it sometimes
    fails. Even for the brilliant team which programmed this device originally, back when HP was an intellectual force to be reckoned with, there's only so much you can do with a small amount of memory.
    I think I'm going to sign off of this thread. I hope this has been helpful!


    On Friday, April 15, 2022 at 12:01:41 PM UTC-4, marc....@me.com wrote:
    optic...@mindspring.com schrieb am Donnerstag, 14. April 2022 um 03:57:30 UTC+2:
    Roundoff error. If you follow discussions of the cardinality of the reals or other such topics, you may recognize that 0.015999999999999999... is equivalent to .0160, i.e., 1 minute 60 seconds, i.e., 2 minutes. 0.015999999988 is a decent numerical
    approximation to that repeating decimal.
    On Wednesday, April 13, 2022 at 9:32:29 AM UTC-4, druid....@gmail.com wrote:
    Hello all
    I just wiped the dust off my old HP48GX in order to do some celestial navigation calculations. I like the function to convert HHMMSS into decimal hours, or degrees, if you will.
    Everything works fine, I can convert back and forth. But this morning I found a result that was obviously fairly off.
    When I calculate 11:54:54 minus 11:52:54 it should give me exactly 2 minutes, easy to see. But the operation on the HP results in 11.915 - 11.8816666667 = 0.333333333. This converted back to HHMMSS equals 0.015999999988, ie. 4 seconds off. Why?
    What is the actual code that you are using to make the calculation?
    Hello

    I guess so. However, with all the calculations I have done so far, this has never occurred. When I convert HHMMSS into Decimals and add or subtract, then convert it back again into HHSSMM it is exact to the split second. But not in the specific example
    below. Moreover, on a HP41 it gives the proper result of 2 minutes..

    Here is what I do: Enter, for example, 3:55:59 (3.5559 ENTER, convert to decimals with the built in function (Time, HMS->) add 1:59:20 (1.5920) by converting and convert the result back (->HMS) I get 5:11:19 which is correct. So, I don’t get that
    rounding part, really.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Tee@21:1/5 to Richard Mitchell on Mon Apr 18 01:52:39 2022
    Richard Mitchell schrieb am Samstag, 16. April 2022 um 11:56:07 UTC+2:
    On Friday, April 15, 2022 at 12:01:41 PM UTC-4, marc....@me.com wrote:
    optic...@mindspring.com schrieb am Donnerstag, 14. April 2022 um 03:57:30 UTC+2:
    Roundoff error. If you follow discussions of the cardinality of the reals or other such topics, you may recognize that 0.015999999999999999... is equivalent to .0160, i.e., 1 minute 60 seconds, i.e., 2 minutes. 0.015999999988 is a decent numerical
    approximation to that repeating decimal.
    On Wednesday, April 13, 2022 at 9:32:29 AM UTC-4, druid....@gmail.com wrote:
    Hello all
    I just wiped the dust off my old HP48GX in order to do some celestial navigation calculations. I like the function to convert HHMMSS into decimal hours, or degrees, if you will.
    Everything works fine, I can convert back and forth. But this morning I found a result that was obviously fairly off.
    When I calculate 11:54:54 minus 11:52:54 it should give me exactly 2 minutes, easy to see. But the operation on the HP results in 11.915 - 11.8816666667 = 0.333333333. This converted back to HHMMSS equals 0.015999999988, ie. 4 seconds off. Why?
    What is the actual code that you are using to make the calculation?
    Hello

    I guess so. However, with all the calculations I have done so far, this has never occurred. When I convert HHMMSS into Decimals and add or subtract, then convert it back again into HHSSMM it is exact to the split second. But not in the specific
    example below. Moreover, on a HP41 it gives the proper result of 2 minutes..

    Here is what I do: Enter, for example, 3:55:59 (3.5559 ENTER, convert to decimals with the built in function (Time, HMS->) add 1:59:20 (1.5920) by converting and convert the result back (->HMS) I get 5:11:19 which is correct. So, I don’t get that
    rounding part, really.
    How is the original question/answer _4_ seconds off? Isn't 0.015999999988 almost 0.02 ...which is 2 minutes?
    You are right. Got a bit dizzy, obviously ;-) Thank you for putting me back into the picture :-)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)