The problem is the type Double, which can not exactly represent numbers such as 0.1. You would have this same issue in any language where you're using binary floating point. How to work around this really depends on the use case. There are many approaches, such as using a type that can exactly represent all of the numbers in the domain you're working with, or just doing this sort of rounding on output. http://floating-point-gui.de/ On Sun, Apr 20, 2014 at 2:12 PM, Chapman, Anthony Sergio < a.s.chapman.10@aberdeen.ac.uk> wrote:

Good evening everyone.

I've made a percentage function for my application (with help from the internet) which is as follows.

-- Turns a number into a percentage toPerc :: Double -> Double toPerc x = 100*(myRound x 4) -- Rounds a number to s decimal points myRound n s = fromIntegral (round (n * factor)) / factor where factor = fromIntegral (10^s)

I would it to round to 2 decimal places no matter what the size of the input is

ei toPerc 0.22222222222222 --- = 22.22 toPerc 0.22342222222222 --- = 22.34

The problem is that what I actually get is 22.220000000000002

If anyone has any suggestions on how to solve this problem or know of a different/better way to convert to percentage please let me know.

Thanks _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Sun, Apr 20, 2014 at 5:12 PM, Chapman, Anthony Sergio < a.s.chapman.10@aberdeen.ac.uk> wrote:

I would it to round to 2 decimal places no matter what the size of the input is

ei toPerc 0.22222222222222 --- = 22.22 toPerc 0.22342222222222 --- = 22.34

The problem is that what I actually get is 22.220000000000002

Looks like typical floating point behavior to me. The last place can't be precisely controlled because you are printing in base 10 but the internal format (as defined by the CPU) is base 2 and very few base 10 decimals have exact base 2 representations. This is not a bug (unless you consider the existence of floating point to be a bug) and cannot be "fixed". -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Thank you very much, that worked a charm. The numbers crunching was done way before the printing so that's all I needed. Now it seems a bit peculiar to me that in your functions, you didn't define the input ie toPerc = printf "%.2f" . (*100) instead of toPerc number = printf "%.2f" . (*100) Would you might pointing me in the right direction to understand why you didn't have to give it a variable input when defining the function? Thanks again. ________________________________________ From: Haskell-Cafe on behalf of Tom Ellis Sent: 20 April 2014 22:45 To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Problem with percentage function? On Sun, Apr 20, 2014 at 09:12:29PM +0000, Chapman, Anthony Sergio wrote:

-- Turns a number into a percentage toPerc :: Double -> Double toPerc x = 100*(myRound x 4) -- Rounds a number to s decimal points myRound n s = fromIntegral (round (n * factor)) / factor where factor = fromIntegral (10^s)

I would it to round to 2 decimal places no matter what the size of the input is

ei toPerc 0.22222222222222 --- = 22.22 toPerc 0.22342222222222 --- = 22.34

The problem is that what I actually get is 22.220000000000002

The other replies, whilst correct, have been a bit oblique to your question. The upshot is you should do the rounding when displaying, not in the floating point value itself. import Text.Printf toPerc :: Double -> String toPerc = printf "%.2f" . (*100) *Main> toPerc 0.22222222222222 "22.22" *Main> toPerc 0.22342222222222 "22.34" Tom _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

since this seems to come up with some regularity, i'm curious, does the haskell standard or ghc implement Florian Loitsch, "Printing Floating-Point Numbers Quickly and Accurately with Integers" for floating types? it seems like that would go a long way towards preventing this kind of confusion. i seem to recall brian o'sullivan using this algorithm for aeson or something. b On Apr 20, 2014, at 3:00 PM, Tom Ellis wrote:

On Sun, Apr 20, 2014 at 09:50:43PM +0000, Chapman, Anthony Sergio wrote:

...

Now it seems a bit peculiar to me that in your functions, you didn't define the input ie toPerc = printf "%.2f" . (*100) instead of toPerc number = printf "%.2f" . (*100)

This expression uses the composition operator (.) rather than using function application directly. Note that for any functions 'f' and 'g', 'f . g' is defined to be the function '\x -> f (g x)'. Thus writing

toPerc = printf "%.2f" . (*100)

just means

toPerc = \x -> printf "%.2f" ((*100) x)

Desugaring the operator section gives

toPerc = \x -> printf "%.2f" (x * 100)

and moving the lambda to become an argument of 'toPerc' gives

toPerc x = printf "%.2f" (x * 100)

which is now in a form probably more familiar to you.

Tom _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Sun, Apr 20, 2014 at 06:01:33PM -0400, Carter Schonwald wrote:

yup. go crazy :)

What other packages that are shipped with Ghc can I update without running into the diamond-dependency problem? Package | Safe to update ================================= Cabal | ✓ array | base | bin-package-db | binary | bytestring | containers | deepseq | directory | filepath | ghc-prim | haskell2010 | haskell98 | hoopl | hpc | integer-gmp | old-locale | old-time | pretty | process | rts | template-haskell | time | transformers | unix | /M

On Sun, Apr 20, 2014 at 12:11 PM, Magnus Therning wrote:

...

I'm working on the packaging of Ghc for Arch Linux and the packaging of Ghc 7.8 was in place about a week ago. It was delivered with `Cabal` 1.18, and already now there's a 1.20 available, which is required by the latest version of `cabal-install` :(

Ghc 7.8 comes with quite a few other basic libraries. Are there any dependencies between these libraries besides the obvious one on `base`?

In other words, can I update Cabal without running into the diamond-dependency problem?

/M

-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Code as if whoever maintains your program is a violent psychopath who knows where you live. -- Anonymous

On Mon, Apr 21, 2014 at 10:38:51AM +0200, Herbert Valerio Riedel wrote:

On 2014-04-21 at 07:35:32 +0200, Magnus Therning wrote:

...

On Sun, Apr 20, 2014 at 06:01:33PM -0400, Carter Schonwald wrote:

...

yup. go crazy :)

What other packages that are shipped with Ghc can I update without running into the diamond-dependency problem?

Package | Safe to update ================================= Cabal | ✓

Problems can arise though, if you install packages which start linking against the newer Cabal package, and then you happen to need to link those together with the 'ghc' package (which currently depends on the Cabal lib bundled with the GHC distro), then you got yourself a diamond-dep problem nevertheless

Yes, that would be exactly the kind of problem that prompted me to ask the question. So, in short, it is not safe to upgrade Cabal. Then I have to say it is rather irritating that there is no way for me to safely provide the latest version of cabal-install!

If that poses no problem to you, many of the packages listed below (except for the wired-in packages, namely: base, ghc-prim, integer-gmp, and template-haskell), could be regarded similarly "safe to update" (more so in a Cabal sandbox)

Unfortunately I'm not talking about a Cabal sandbox, but rather of packages in an Arch Linux repository. So the problems caused by my actions affect not only me but every user of the repository. Well, the dependency graph produced by `ghc-pkg dot --global` seems to indicate that upgrading a single one of the packages-that-comes-with-ghc is akin to wandering into a proper mine field. AFAIU I can't upgrade a single package that `ghc` depends on: "ghc-7.8.2" -> "Cabal-1.18.1.3" "ghc-7.8.2" -> "array-0.5.0.0" "ghc-7.8.2" -> "base-4.7.0.0" "ghc-7.8.2" -> "bin-package-db-0.0.0.0" "ghc-7.8.2" -> "bytestring-0.10.4.0" "ghc-7.8.2" -> "containers-0.5.5.1" "ghc-7.8.2" -> "directory-1.2.1.0" "ghc-7.8.2" -> "filepath-1.3.0.2" "ghc-7.8.2" -> "hoopl-3.10.0.1" "ghc-7.8.2" -> "hpc-0.6.0.1" "ghc-7.8.2" -> "process-1.2.0.0" "ghc-7.8.2" -> "template-haskell-2.9.0.0" "ghc-7.8.2" -> "time-1.4.2" "ghc-7.8.2" -> "transformers-0.3.0.0" "ghc-7.8.2" -> "unix-2.7.0.1" On top of that I'd have to re-compile all packages that depend on the package I do upgrade. But then all packages come together as dependencies of `base`, which is hard-wired which I suppose will make it problematic to even recompile the same version. In short that would mean that none of the packages bundled with Ghc are "safe to update". No? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus As long as there are ill-defined goals, bizarre bugs, and unrealistic schedules, there will be Real Programmers willing to jump in and Solve The Problem, saving the documentation for later. Long live Fortran! -- Ed Post

Hi, Am Montag, den 21.04.2014, 11:38 +0200 schrieb Magnus Therning:

Then I have to say it is rather irritating that there is no way for me to safely provide the latest version of cabal-install!

the same problem affects Debian, and I find it equally irritating. Not sure how Fedora handles this – Jens, did you find a problem around this? One possibility would be to manually bundle the Cabal and cabal-install sources into one (dpkg supports source packages with multiple original tarballs), build the new Cabal just to be used to build cabal-install and link that statically (which is the default). This would provide an up-to-date cabal-install binary without having to ship a new Cabal version as a library. Or does cabal-install require the matching version of Cabal to be registered to work? Alternatively it might be possible to build ghc with a newer Cabal. Not sure what that might break. I believe there was talk to avoid having ghc depend on Cabal (it uses very little of it anyways), and indeed, there is https://ghc.haskell.org/trac/ghc/ticket/8244 but work got stalled 7 months ago. Fixing tht would solve the problems for us distributions – maybe someone wants to pick up the work? Greetings, Joachim PS: https://ghc.haskell.org/trac/ghc/ticket/8947 is a related bug (though about ghc’s dependency on binary, not on Cabal). -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

* Jens Petersen [2014-04-22 11:37:44+0900]

...

Or does cabal-install require the matching version of Cabal to be registered to work?

I don't think so, but I believe some of the latest functionality needs Cabal >= 1.18 to work.

Unfortunately, it does. The reason being that in some cases (custom build type; -j) a setup script is compiled (against Cabal). If Cabal and cabal-install are of different versions, you'll get inconsistent behavior depending on whether, say, you build in parallel. Roman

On 2014-04-23 at 00:12:25 +0200, Joachim Breitner wrote:

...

...

Alternatively it might be possible to build ghc with a newer Cabal. Not sure what that might break.

Right that should work I guess.

can anyone comment on the chances of this to work? It seems that this would be a good way to solve the problem for the distributions.

you'd probably need to backport commits such as git.haskell.org/ghc.git/commitdiff/8992d5269804b727fb77249511e89df678526907 but other than that it would work

On 21 April 2014 20:18, Magnus Therning wrote:

On Mon, Apr 21, 2014 at 10:38:51AM +0200, Herbert Valerio Riedel wrote:

...

On 2014-04-21 at 07:35:32 +0200, Magnus Therning wrote:

...

On Sun, Apr 20, 2014 at 06:01:33PM -0400, Carter Schonwald wrote:

...

yup. go crazy :)

What other packages that are shipped with Ghc can I update without running into the diamond-dependency problem?

Package | Safe to update ================================= Cabal | ✓

Problems can arise though, if you install packages which start linking against the newer Cabal package, and then you happen to need to link those together with the 'ghc' package (which currently depends on the Cabal lib bundled with the GHC distro), then you got yourself a diamond-dep problem nevertheless

Yes, that would be the diamond-dependency problem, which I'm trying to avoid!

...

If that poses no problem to you, many of the packages listed below (except for the wired-in packages, namely: base, ghc-prim, integer-gmp, and template-haskell), could be regarded similarly "safe to update" (more so in a Cabal sandbox)

It does, since this isn't only my development environment but the development environment of everyone using the Arch Linux repository I upload packages to.

...

just look at the output of

ghc-pkg dot --global | dotty -

and look out for those packages that are only depended upon directly by GHC (minus the aforementioned wired-in packages)

Well, wouldn't I need to look at the transitive closure of `ghc` dependencies, since e.g. an upgrade of `array` would trigger a recompile of `Cabal` which is a dependency of `ghc` (a wired-in package)?

If I'm reading that graph correctly only packages that have no incoming arrows and aren't wired-in are safe to upgrade. That means only `haskell98` and `haskell2010` would be safe to upgrade.

What makes Cabal different is that most packages don't have an actually dependency on Cabal (in terms of their code); they just use Cabal to build themselves.

/M

-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

On Mon, Apr 21, 2014 at 08:18:20AM +1000, Ivan Lazar Miljenovic wrote:

On 21 April 2014 02:11, Magnus Therning wrote:

...

I'm working on the packaging of Ghc for Arch Linux and the packaging of Ghc 7.8 was in place about a week ago. It was delivered with `Cabal` 1.18, and already now there's a 1.20 available, which is required by the latest version of `cabal-install` :(

Ghc 7.8 comes with quite a few other basic libraries. Are there any dependencies between these libraries besides the obvious one on `base`?

In other words, can I update Cabal without running into the diamond-dependency problem?

The only time I've had a problem with Exherbo packages is that some of them (e.g. haskell-docs) require using the version of Cabal shipped with GHC (I think it was to have consistency with the version of Cabal that Haddock was built with); as long as the Arch packages can specify "use GHC's Cabal" for the few cases which it's necessary then you shouldn't have a problem.

That is exactly the kind of situation I want to avoid :) I have no problem re-compiling everything that depends on Cabal, but I want that recompile to result in a situation where neither the user (nor me) need to ever ask "Which of the installed Cabal versions should I use to compile this program?". /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Code as if whoever maintains your program is a violent psychopath who knows where you live. -- Anonymous