classify ok spam test = spamCount div (spamCount + okCount) where okCount = xInY (xmost ok 50) (words test) spamCount = xInY (xmost spam 50) (words test) Couldn't match expected type `(a -> a -> a) -> Int -> t' against inferred type `Int' In the expression: spamCount div (spamCount + okCount) In the definition of `classify': classify ok spam test = spamCount div (spamCount + okCount) where okCount = xInY (xmost ok 50) (words test) spamCount = xInY (xmost spam 50) (words test) Failed, modules loaded: none. Prelude> and why does this work and not complaning about / with ints: classify ok spam test = spamCount / (spamCount + okCount) where okCount = weigh ok test spamCount = weigh spam test

0 |

7/18/2008 9:20:42 PM

ssecorp <circularfunc@gmail.com> writes: > classify ok spam test = spamCount div (spamCount + okCount) (snip) > Couldn't match expected type `(a -> a -> a) -> Int -> t' > against inferred type `Int' (snip) div is a prefix operator because it's letters, not a symbol. To make it infix, write `div`. And, indeed, it's defined to do integer division. > and why does this work and not complaning about / with ints: > > classify ok spam test = spamCount / (spamCount + okCount) where (snip) / is defined to work with numbers that can be fractional. I don't know how much sense it makes. Haskell 98's numeric typeclasses can be a bit oddly arranged so I don't automatically assume they're yet perfect. You should notice that div and / have different type signatures. Following the signatures to the types and classes can be quite illuminating. Mark

0 |

7/18/2008 10:05:07 PM

On Jul 19, 12:05=A0am, "Mark T.B. Carroll" <Mark.Carr...@Aetion.com> wrote: > ssecorp <circularf...@gmail.com> writes: > > classify ok spam test =3D spamCount div (spamCount + okCount) > (snip) > > =A0 =A0 Couldn't match expected type `(a -> a -> a) -> Int -> t' > > =A0 =A0 =A0 =A0 =A0 =A0against inferred type `Int' > > (snip) > > div is a prefix operator because it's letters, not a symbol. To make it > infix, write `div`. > > And, indeed, it's defined to do integer division. > > > and why does this work and not complaning about / with ints: > > > classify ok spam test =3D spamCount / (spamCount + okCount) where > > (snip) > > / is defined to work with numbers that can be fractional. > > I don't know how much sense it makes. Haskell 98's numeric typeclasses > can be a bit oddly arranged so I don't automatically assume they're yet > perfect. > > You should notice that div and / have different type signatures. > Following the signatures to the types and classes can be quite > illuminating. > > Mark I want a float as a result though. My result will always be between 0 and 1 and now I will always get 0 which makes the program useless. How would I divide 2 ints and return a float? What I dont get is that / works in the second classify function since they are essentially the same, I am dividing integers.

0 |

7/18/2008 10:14:18 PM

intToFloat :: Int -> Float intToFloat n = fromInteger (toInteger n) is that a heresy to haskellers or it is perfectly okay to do typeconversions? it makes life easier...

0 |

7/18/2008 10:40:28 PM

ssecorp <circularfunc@gmail.com> writes: > is that a heresy to haskellers or it is perfectly okay to do > typeconversions? It's sometimes quite necessary to. (-: Just use fromIntegral if you want Int -> Float. Mark

0 |

7/18/2008 10:55:25 PM

ssecorp <circularfunc@gmail.com> writes: > On Jul 19, 12:05 am, "Mark T.B. Carroll" <Mark.Carr...@Aetion.com> > wrote: >> ssecorp <circularf...@gmail.com> writes: (snip) >> > classify ok spam test = spamCount / (spamCount + okCount) where (snip) > What I dont get is that / works in the second classify function since > they are essentially the same, I am dividing integers. If you try writing a type signature for classify that has Ints in it, you'll find it doesn't work. You might be dividing floating point numbers that happen to have integer values. (-: 2 / 3 will compile okay, but you'll find that (2::Int) / 3 doesn't because / doesn't work for Ints. Mark

0 |

7/18/2008 10:57:32 PM

ssecorp <circularfunc@gmail.com> wrote: > intToFloat :: Int -> Float > intToFloat n = fromInteger (toInteger n) > is that a heresy to haskellers or it is perfectly okay to do > typeconversions? It's not a heresy, but you must do it explicitely (because, for example, you might loose precision when converting from Integer to a float. So if you really want that, you have to tell the compiler). The above function is called "fromIntegral", BTW: fromIntegral :: (Integral a, Num b) => a -> b fromIntegral = fromInteger . toInteger Using that instead of your own has the additional advantage that it will specialize to internal functions for a lot of the common conversions in GHC, so it's much more efficient. - Dirk

0 |

7/19/2008 12:40:03 PM