
While haskell's type system is usually a delight to work with.
However, every once and a while I need to do mixed mode programming in
spite of Kernighan and Plauger's advice, and wind up cursing the
numeric type stack. I was wondering it there was a writeup on it
somewhere? Preferably one aimed at practical programming. A chapter in
Real World Haskell would have been ideal, but it doesn't seem to
exist.
Thanks,

On Wed, Dec 28, 2011 at 8:54 PM, Mike Meyer
While haskell's type system is usually a delight to work with. However, every once and a while I need to do mixed mode programming in spite of Kernighan and Plauger's advice, and wind up cursing the numeric type stack. I was wondering it there was a writeup on it somewhere? Preferably one aimed at practical programming. A chapter in Real World Haskell would have been ideal, but it doesn't seem to exist.
For shear comprehensiveness, there's always the language report: http://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1350006.... I don't know of anything that lays out and introduction with best practices and common pitfalls. Antoine
Thanks,
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

On Wed, 28 Dec 2011 22:23:12 -0600
Antoine Latter
On Wed, Dec 28, 2011 at 8:54 PM, Mike Meyer
wrote: While haskell's type system is usually a delight to work with. However, every once and a while I need to do mixed mode programming in spite of Kernighan and Plauger's advice, and wind up cursing the numeric type stack. I was wondering it there was a writeup on it somewhere? Preferably one aimed at practical programming. A chapter in Real World Haskell would have been ideal, but it doesn't seem to exist. For shear comprehensiveness, there's always the language report: http://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1350006....
Not to bad. Then again, I'm a long-time language lawyer, so others may disagree.
I don't know of anything that lays out and introduction with best practices and common pitfalls.
Given reading the report, and a little experimentation, I figured out
the problem I was having. I probably will in the future as well.
I wanted a percentage value rounded to the nearest integer. No
problem, it's just:
(%) a b = round $ 100 * a / b
And that works in ghci. However, it has the type
(%) :: (RealFrac a, Integral b) => a -> a -> b
Which means that the argument from length was of the wrong type for
this. And naturally, declaring the argument types that matched the
result from length caused type problems inside (%).
So, is there a reasonable way to get the value of two Integral types
divided by each other and rounded? How about one integral type and one
RealFrac? I know I can get it truncated towards either 0 or negative
infinity, but that's not what I want here.
Thanks,

On Thu, Dec 29, 2011 at 00:33, Mike Meyer
So, is there a reasonable way to get the value of two Integral types divided by each other and rounded? How about one integral type and one RealFrac? I know I can get it truncated towards either 0 or negative infinity, but that's not what I want here.
You have two options: (1) use fromIntegral to coerce an Integral value to a RealFrac; (2) use (div) (division on Integrals) instead of (/). Which to use depends on what you're planning to do with the result. In this case, I'd probably use (/) and (fromIntegral). -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On Thu, 29 Dec 2011 04:49:53 -0500
Brandon Allbery
On Thu, Dec 29, 2011 at 00:33, Mike Meyer
wrote: So, is there a reasonable way to get the value of two Integral types divided by each other and rounded? How about one integral type and one RealFrac? I know I can get it truncated towards either 0 or negative infinity, but that's not what I want here. You have two options: (1) use fromIntegral to coerce an Integral value to a RealFrac;
Yup. that's what I did.
(2) use (div) (division on Integrals) instead of (/).
Not an option, because div doesn't round, it truncates. Figuring out
whether to add one to get it to round would be a lot messier than just
using fromIntegral.
The other half of this is that one of the two values is computed from
constants in the code. So the code works if I don't coerce it. But all
the computation for that value is done using floats.
Seems like a violation of POLA to me.
participants (3)
-
Antoine Latter
-
Brandon Allbery
-
Mike Meyer