Skip to content
Snippets Groups Projects

some results not expected with the addition

    • Closed Issue created by vanto @trac-vanto 
    Prelude> 1.1+2.2
3.3000000000000003
Prelude> 1.11+2.22
3.33
Prelude> 1.111+2.222
3.333
Prelude> 1.1111+2.2222
3.3333
Prelude> 1.11111+2.22222
3.33333
Prelude> 1.111111+2.222222
3.3333329999999997
Prelude> 1.1111111+2.2222222
3.3333333
Prelude> 1.11111111+2.22222222
3.33333333
Prelude> 1.111111111+2.222222222
3.333333333
Prelude> 1.1111111111+2.2222222222
3.3333333333
Prelude> 1.11111111111+2.22222222222
3.33333333333
Prelude> 1.111111111111+2.222222222222
3.333333333333
Prelude> 1.1111111111111+2.2222222222222
3.3333333333333
Prelude> 1.11111111111111+2.22222222222222
3.3333333333333304
Prelude> 1.111111111111111+2.222222222222222
3.333333333333333

    Given the other additions, three results can be improved.

    Trac metadata
    Trac field Value
    Version 8.2.1
    Type Bug
    TypeOfFailure OtherFailure
    Priority normal
    Resolution Unresolved
    Component Compiler
    Test case
    Differential revisions
    BlockedBy
    Related
    Blocking
    CC
    Operating system
    Architecture
    Edited
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • vanto changed weight to 5

      changed weight to 5

    • vanto added Tbug Trac import labels

      added Tbug Trac import labels

    • nickkuk closed

      closed

    • nickkuk
      nickkuk @trac-nickkuk ·

      Please, use Rational instead of float arithmetics:

      Prelude> fromRational (1.1 + 2.2)
3.3
Prelude> fromRational (1.111111+2.222222)
3.333333
Prelude> fromRational (1.11111111111111+2.22222222222222)
3.33333333333333
      Trac metadata
      Trac field Value
      Resolution Unresolved → ResolvedInvalid
    • vanto reopened

      reopened

    • vanto
      vanto @trac-vanto ·
      Author

      Replying to [[span(style=color: #FF0000, nickkuk )]]:\\ Thank you.

      Prelude> :t 1.1+2.2
1.1+2.2 :: Fractional a => a

      I know the failures with real numbers in calculations on computers. OK, but overall we could be sure of the result by decreasing the number of decimal places in real number, for example. should we use your method with all real numbers? I think not at all. example:\\

      Prelude> 2.71828182846**3.14159265359
23.14069263280959

      it's a good result.\\ Another example:\\

      Prelude> fromRational(2.71828182846**3.14159265359)

<interactive>:18:14: error:
    * Could not deduce (Floating Rational) arising from a use of `**'
      from the context: Fractional a
        bound by the inferred type of it :: Fractional a => a
        at <interactive>:18:1-42
    * In the first argument of `fromRational', namely
        `(2.71828182846 ** 3.14159265359)'
      In the expression: fromRational (2.71828182846 ** 3.14159265359)
      In an equation for `it':
          it = fromRational (2.71828182846 ** 3.14159265359)

      I am not convinced by your answer. it works in a specific example but not in a general way. I think we could do better. I am doubtful, I reopen this ticket to have other opinions.\\ look at the difference with Hugs (Haskell 98 Compatability):\\

      Hugs> 1.1+2.2
3.3 :: Double
(32 reductions, 75 cells)
Hugs> 1.111111+2.222222
3.333333 :: Double
(27 reductions, 41 cells)
Hugs> 1.11111111111111+2.22222222222222
3.33333333333333 :: Double
(27 reductions, 49 cells)
Hugs> :t 1.1+2.2
1.1 + 2.2 :: Double

      Hugs calculates a lot better.

      Trac metadata
      Trac field Value
      Resolution ResolvedInvalid → Unresolved
    • vanto changed title from false result in the addition to some results not expected with the addition

      changed title from false result in the addition to some results not expected with the addition

    • vanto
      vanto @trac-vanto ·
      Author

      \\ \\\\

      I changed the title that did not seem appropriate. The word "false" was not suitable for these results.

    • vanto
      vanto @trac-vanto ·
      Author

      I discovered that OCaml computes with the same errors. maybe a shared file?\\

      $ ocaml
        OCaml version 4.04.0

# 1.1+.2.2;;
- : float = 3.3000000000000003
# 1.11+.2.22;;
- : float = 3.33
# 1.111+.2.222;;
- : float = 3.333
# 1.1111+.2.2222;;
- : float = 3.3333
# 1.11111+.2.22222;;
- : float = 3.33333
# 1.111111+.2.222222;;
- : float = 3.3333329999999997
# 1.1111111+.2.2222222;;
- : float = 3.3333333
# 1.11111111+.2.22222222;;
- : float = 3.33333333
# 1.111111111+.2.222222222;;
- : float = 3.333333333
# 1.1111111111+.2.2222222222;;
- : float = 3.3333333333
# 1.11111111111+.2.22222222222;;
- : float = 3.33333333333
# 1.111111111111+.2.222222222222;;
- : float = 3.333333333333
# 1.1111111111111+.2.2222222222222;;
- : float = 3.3333333333333
# 1.11111111111111+.2.22222222222222;;
- : float = 3.3333333333333304
# 1.111111111111111+.2.222222222222222;;
- : float = 3.333333333333333
#

      while the other interpreters all give an expected result.\\

      T h e   M i r a n d a   S y s t e m

      version 2.041 last revised 15 August 2008

      Copyright Research Software Ltd 1985-2008

        World Wide Web: http://miranda.org.uk


new file script.m
for help type /h
Miranda 1.1+2.2
3.3
Miranda 1.111111+2.222222
3.333333
Miranda 1.11111111111111+2.22222222222222
3.333333333333
Miranda

      \\

      Standard ML of New Jersey v110.81 [built: Thu May 04 14:21:06 2017]
- 1.1+2.2;
val it = 3.3 : real
- 1.111111+2.222222;
val it = 3.333333 : real
- 1.11111111111111+2.22222222222222;
val it = 3.33333333333 : real
-

      \\

      >       Caml Light version 0.74

#1.1+.2.2;;
- : float = 3.3
#1.111111+.2.222222;;
- : float = 3.333333
#1.11111111111111+.2.22222222222222;;
- : float = 3.33333333333
#

      You can read the difference between Caml Light and OCaml.

    • vanto
      vanto @trac-vanto ·
      Author

      After making several calculations it seems to me that this is more a display error rather than a miscalculation (mathematical error). I think it could be repaired easily.

    • Sven Panne
      Sven Panne @svenpanne ·

      A tiny bit of googling would have showed that the problem is not easy at all, see e.g. the 2nd part of https://cs.stackexchange.com/a/81039 or the 2nd volume of Knuth's TAOCP (Radix Conversions). Apart from the fact that numeric algorithms are notoriously hard, there are tradeoffs here, e.g. speed vs. "minimality" of the resulting string. Different implementations just choose different points in the design space, so GHC's behavior is not a bug at all and I propose to close this ticket. Remember: If there was a single, universally "right" way to convert binary floats to a decimal string, people probably wouldn't write papers/blogs/etc. about it for several decades...

    • vanto
      vanto @trac-vanto ·
      Author

      It has nothing to do with what you say otherwise why other languages give correct results and not GHC? Maybe there is something in common between OCaml and GHC. And that produces this error. We need to find.\\ This problem, you says, began to manifest itself from the 1950s, and we still talk about it. In the past we managed to get results as we wanted.\\ So two things:

      • the way followed by GHC (in computation) is not the right one.\\ or\\

      • there is a breakdown somewhere. and as you can see, the other systems stand out from GHC. if it is the fault of the base on which GHC is built then it is necessary to change the base.\\ look again at this result, do you think it is reasonable? while the other languages write a good result that is consistent with our expectations? These results are repetitive, so why always the same poorly written results?\\

      Prelude> 16.0/0.2
80.0
Prelude> 16.0/0.02
800.0
Prelude> 16.0/0.002
8000.0
Prelude> 16.0/0.0002
80000.0
Prelude> 16.0/0.00002
799999.9999999999
Prelude> 16.0/0.000002
8000000.0
Prelude> 16.0/0.0000002
8.0e7
Prelude> 16.0/0.00000002
8.0e8
Prelude> 16.0/0.000000002
7.999999999999999e9
Prelude> 16.0/0.0000000002
8.0e10
Prelude> 16.0/0.00000000002
8.0e11
Prelude> 16.0/0.000000000002
8.0e12
Prelude> 16.0/0.0000000000002
8.0e13
Prelude> 16.0/0.00000000000002
8.0e14
Prelude> 16.0/0.000000000000002
7.999999999999999e15
Prelude> 16.0/0.0000000000000002
8.0e16
Prelude> 16.0/0.00000000000000002
8.0e17
Prelude> 16.0/0.000000000000000002
7.999999999999999e18
Prelude> 16.0/0.0000000000000000002
8.0e19
    • vanto closed

      closed

    • vanto
      vanto @trac-vanto ·
      Author

      In this other example, you can see that the calculation results between OCaml and GHC occur for the same numbers. For me there is a relationship between these two systems. It is necessary to do another search to find it and thus to eliminate this miscalculation.\\

      $ ocaml
        OCaml version 4.04.0

# 16.0/.0.2;;
- : float = 80.
# 16.0/.0.02;;
- : float = 800.
# 16.0/.0.002;;
- : float = 8000.
# 16.0/.0.0002;;
- : float = 80000.
# 16.0/.0.00002;;
- : float = 799999.99999999988
# 16.0/.0.000002;;
- : float = 8000000.
# 16.0/.0.0000002;;
- : float = 80000000.
# 16.0/.0.00000002;;
- : float = 800000000.
# 16.0/.0.000000002;;
- : float = 7999999999.999999
# 16.0/.0.0000000002;;
- : float = 80000000000.
# 16.0/.0.00000000002;;
- : float = 800000000000.
# 16.0/.0.000000000002;;
- : float = 8e+012
# 16.0/.0.0000000000002;;
- : float = 8e+013
# 16.0/.0.00000000000002;;
- : float = 8e+014
# 16.0/.0.000000000000002;;
- : float = 7999999999999999.
# 16.0/.0.0000000000000002;;
- : float = 8e+016
# 16.0/.0.00000000000000002;;
- : float = 8e+017
# 16.0/.0.000000000000000002;;
- : float = 7.999999999999999e+018
# 16.0/.0.0000000000000000002;;
- : float = 8e+019
# 16.0/.0.00000000000000000002;;
- : float = 8e+020
#

      Today I decided to close this ticket as invalid because I do not know what else to choose to close this ticket. But of course you can reopen it. Thank you for reading this.

      Trac metadata
      Trac field Value
      Resolution Unresolved → ResolvedInvalid
    • Sven Panne
      Sven Panne @svenpanne ·

      Replying to [ticket:14377#comment:144276 vanto]:

      It has nothing to do with what you say otherwise why other languages give correct results and not GHC? [...]

      Within Double's precision, all the results are correct. They might not be minimal in the sense that they output the minimum number of characters necessary, but they are nevertheless correct: The Haskell Report doesn't require minimality AFAICT.

      If we wanted such minimality, this would be a feature request, not a bug report. One would have to make detailed performance measurements for such a change: It's easy to get more than an order of magnitude slower here, which might be a deal-breaker for lots of people.

      I propose you google for "What Every Computer Scientist Should Know About Floating-Point Arithmetic" and/or have a look at the papers and blogs mentioned in the previous Stack Exchange link.

    • vanto
      vanto @trac-vanto ·
      Author

      look at these calculations:\\

      a) 
Prelude> (16.0/0.00002)
799999.9999999999
it :: Fractional a => a

b)
Prelude> fromRational(16.0/0.00002)
800000.0
it :: Fractional a => a

c)
Prelude> (16.0/0.00002)**2.1
2.491661103847512e12
it :: Floating a => a

d)
Prelude> (fromRational(16.0/0.00002))**2.1
2.491661103847512e12
it :: Floating a => a

e)
Prelude> 800000.0**2.1
2.491661103847512e12
it :: Floating a => a

f)
Prelude> let a = (16.0/0.00002)
a :: Fractional a => a

g)
Prelude> a
799999.9999999999
it :: Fractional a => a

h)
Prelude> a**2.1
2.491661103847512e12
it :: Floating a => a

      the reference calculation will be the expression in e). the results from c), d), e) and h) are equal and yet their calculations are different.\\ compare results from a) and b). the results are not identical. then compare the results from c) and d). the results are identical.\\ first observation: it is not obligatory to write fromRational in front of the numerical expression to have a correct result. second observation: look at f) and g) and the result in h) which is identical to the other results in c), d) or e).\\ as I said above, this demonstration shows that GHC calculates well but the result provided in a) does not conform to our view and this result does not come from an error due to the calculation of Floats. I think this can be fixed. No?

    • Sven Panne
      Sven Panne @svenpanne ·

      Just a few more hints why this is not a bug (all from the Haskell Report):

      • Numerical literals with a dot in it have an implicit fromRational around it.
      • Not surprisingly, fromRational forces its 1st argument to be a Rational.
      • The default default is default (Integer, Double).
      • (**) :: Floating a => a -> a -> a.

      With that information you can figure out why e.g. the division in a) is a different kind of division than the one in b).

    • vanto reopened

      reopened

    • vanto
      vanto @trac-vanto ·
      Author

      I just figured out how to fix that. that's why I re-open this ticket. This idea came to me when calculating numbers with my HP Prime calculator.\\ as I said above, GHC calculates well. it's a matter of displaying a number. we can give ourselves a limit in the display of the number which will be for example 5 digits of precision after the decimal point. in a new request ticket I talked about 11 precision digits in the display.\\ I specify for those who have not understood anything yet that it is a precision in the display and not in the internal calculation. \\ 5 digits may seem sufficient considering that GHC is more used in the functional part more than in the intensive mathematical calculation. example:\\ if the number is:79.999999 he can become 80

      Trac metadata
      Trac field Value
      Resolution ResolvedInvalid → Unresolved
    • Sven Panne closed

      closed

    • Sven Panne
      Sven Panne @svenpanne ·

      I fully understand that you want to change the standard way of Showing Doubles, but this won't happen: There is an informal understanding that read and show are a (weak) kind of inverses:

      almostIdentity x = read (show x) `asTypeOf` x

      There is no formal requirement in the Haskell Report for this, but you can be sure that lots of code out there would break for no good reason if the standard Show instance would simply lower the precision. Improving the implementation so that it would output as few characters as possible while retaining precision and performance would be another story, as has already been pointed out. Again: If you want some special formatting, use e.g.:

      Prelude> Text.Printf.printf "%.5g\n" 12.3456789
12.34568

      Just for the record: Try the equivalent of your examples in Chrome's JavaScript console, in Firefox, Python 3.6's IDLE, in DrRacket's console etc. etc., and you will see the same results as in GHC(i), and for a good reason.

      Another thing: A bug tracker is not really the right place to discuss wild new ideas, IRC e.g. might be a better place to get some initial feedback and perhaps learn why things are done they way they are.

      Trac metadata
      Trac field Value
      Resolution Unresolved → ResolvedInvalid
    • vanto reopened

      reopened

    • vanto
      vanto @trac-vanto ·
      Author

      Replying to [[span(style=color: #FF0000, svenpanne )]]. \\ not at all. not at all.\\ in his book entitled "Thinking Functionally with Haskell" Richard Bird says page 12-13:\\

      One of the tools is an interactive calculator, called GHCi...You can 
now use GHCi as a super-calculator:
Prelude> 3^5
243

      when I write Prelude> 1.1+2.2, the answer is 3.3000000000000003 \\ But if I use Hugs 98 (Haskell 98 Compatability): \\ when I write Hugs> 1.1+2.2, the answer is \\ 3.3 :: Double(32 reductions, 75ells)

      that's all.\\ and you do not see any difference in these two results.\\ Stubborn?\\

      Trac metadata
      Trac field Value
      Resolution ResolvedInvalid → Unresolved
    • Sven Panne closed

      closed

    • Sven Panne
      Sven Panne @svenpanne ·

      Please stop re-opening tickets and try to gather some information from relevant papers/blogs, and ask on mailing lists. This is a bug tracker, not a learning tool.

      Trac metadata
      Trac field Value
      Resolution Unresolved → ResolvedInvalid
    • vanto reopened

      reopened

    • vanto
      vanto @trac-vanto ·
      Author

      This ticket shows a bug. I do not seek help in this ticket, I have all the help I need in the books I read. Please, svenpanne, stop to close this ticket. I re-open it.

      Trac metadata
      Trac field Value
      Resolution ResolvedInvalid → Unresolved
    • vanto closed

      closed

    • vanto
      vanto @trac-vanto ·
      Author

      I close this ticket permanently. the bug persists.

      Trac metadata
      Trac field Value
      Resolution Unresolved → ResolvedInvalid
    • Sven Panne mentioned in issue #14389 (closed)

      mentioned in issue #14389 (closed)

    • vanto
      vanto @trac-vanto ·
      Author

      Correction: there is no bug in this ticket. The results are consistent with the Floating-Point Arithmetic.

    • trac-import added incorrect runtime result label

      added incorrect runtime result label

    • Ben Gamari added Pnormal label

      added Pnormal label

    Please register or sign in to reply