#14377: false result in the addition -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: closed => new * resolution: invalid => Comment: 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14377#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14377: some results not expected with the addition -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14377#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14377: some results not expected with the addition -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by 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... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14377#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14377: some results not expected with the addition -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: new => closed * resolution: => invalid Comment: 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14377#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14377: some results not expected with the addition -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): 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? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14377#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14377: some results not expected with the addition -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: closed => new * resolution: invalid => Comment: 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}}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14377#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14377: some results not expected with the addition -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: closed => new * resolution: invalid => Comment: 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?\\ -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14377#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14377: some results not expected with the addition -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: closed => new * resolution: invalid => Comment: 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14377#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14377: some results not expected with the addition -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Correction: there is no bug in this ticket. The results are consistent with the Floating-Point Arithmetic. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14377#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler