Beginners Digest, Vol 42, Issue 15
Send Beginners mailing list submissions to
beginners@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Fwd: Averaging a string of numbers
(Dean Herington & Elizabeth Lacey)
--
Message: 1
Date: Mon, 12 Dec 2011 02:18:40 -0500
From: Dean Herington & Elizabeth Lacey
Subject: Re: [Haskell-beginners] Fwd: Averaging a string of numbers
To: Ben Kolera , beginners@haskell.org
Message-ID:
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 8:21 AM +1000 12/12/11, Ben Kolera wrote:
>That is just because you are calling min and max against the Maybe
>rather than on the values inside of your maybes. Max is working
>because there is an instance of Ord for Maybe and
>
>Nothing > Just n > Just ( n + 1 )
You have the right idea, but replace `>` above by `<`.
>
>This is certainly not the most elegant solution ( I am a beginner, too
>) but here is what I would do:
>
>instance Monoid Stats where
> mempty = Stats 0 Nothing Nothing 0
> mappend (Stats sm1 mn1 mx1 len1) (Stats sm2 mn2 mx2 len2) =
>Stats
>(sm1 + sm2)
>(chooseMaybe min mn1 mn2)
>(chooseMaybe max mx1 mx2)
>(len1 + len2)
>
>chooseMaybe _ Nothing Nothing = Nothing
>chooseMaybe _ (Just a) Nothing = Just a
>chooseMaybe _ Nothing (Just b) = Just b
>chooseMaybe f (Just a) (Just b) = Just $ f a b
>
>
>Hopefully this quick answer can get you on your way to solving your
>problem and we can both learn a better way of doing it when someone
>optimises my solution. ;)
You've got the principle just right. Here's a way to cast it that
makes it apparent that `Stats` is a monoid in a "componentwise"
fashion.
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
import Data.Monoid
import Control.Applicative
-- | Monoid under minimum.
newtype Minimum a = Minimum { getMinimum :: Maybe a }
deriving (Eq, Ord, Functor, Applicative, Read, Show)
instance Ord a => Monoid (Minimum a) where
mempty = Minimum Nothing
mappend = liftA2 min
-- | Monoid under maximum.
newtype Maximum a = Maximum { getMaximum :: Maybe a }
deriving (Eq, Ord, Functor, Applicative, Read, Show)
instance Ord a => Monoid (Maximum a) where
mempty = Maximum Nothing
mappend = liftA2 max
data Stats = Stats {
ct :: Sum Int,
sm :: Sum Double,
mn :: Minimum Double,
mx :: Maximum Double }
deriving (Eq, Show, Read)
instance Monoid Stats where
mempty = Stats mempty mempty mempty mempty
mappend (Stats ct1 sm1 mn1 mx1) (Stats ct2 sm2 mn2 mx2) =
Stats (ct1 `mappend` ct2)
(sm1 `mappend` sm2)
(mn1 `mappend` mn2)
(mx1 `mappend` mx2)
mkStats v = Stats (Sum 1) (Sum v) (Minimum (Just v)) (Maximum (Just v))
st0, st1, st2, st3 :: Stats
st0 = mempty
st1 = mkStats 1
st2 = mkStats 2
st3 = st1 `mappend` st2
main = mapM_ print [st0, st1, st2, st3]
--
___
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 42, Issue 15
*
Beginners Digest, Vol 42, Issue 16
2, st3, st4]
--
Message: 4
Date: Mon, 12 Dec 2011 16:47:37 +0100
From: Giacomo Tesio
Subject: Re: [Haskell-beginners] Pattern matching over functions
To: Felipe Almeida Lessa
Cc: simplex.math.servi...@gmail.com, beginners@haskell.org, Daniel
Fischer
Message-ID:
Content-Type: text/plain; charset="utf-8"
Actually, it looks like a dirty technological impedence.
Haskell makes functions first class values, but still data values are
easier to handle than functions, since their type can implement the Eq
typeclass, thanks to constructor matches.
While I got your point, I'm still wondering about functions as constructor
of other functions thus it would be possible to match to the function name
like we do for type constructors.
I can't have an insight about why this is wrong. Why can't we treat
functions as constructors?
The point, I guess, is that this would assign a kind of "identity" to
morphisms that belong to a category. I see how this might be wrong:
functions can be equivalent exactly like integers, but they are just harder
to implement.
Thus we are back to the dirty technical problem of evaluating function
equivalence.
Giacomo
On Mon, Dec 12, 2011 at 2:27 AM, Felipe Almeida Lessa <
felipe.le...@gmail.com> wrote:
> On Sun, Dec 11, 2011 at 8:09 PM, Graham Gill
> wrote:
> > Excellent, thanks Daniel and Felipe.
> >
> > We don't even need to invoke infinite or undecidable problems, since it's
> > easy to construct equal functions for which determining equality would be
> > prohibitively expensive. If then you can only check equality for some
> > functions, because you want compilation to finish, say, within the
> > programmer's lifetime, you lose referential transparency.
>
> Note that the time isn't spent on compilation time, but on run time!
> Which is actually worse ;-).
>
> Also note that it is possible to imagine something like
>
> obviouslyEqual :: a -> a -> Bool
>
> where 'obviouslyEqual x y' is 'True' when it's easy to see that they
> are equal or 'False' if you can't decide. Actually, with GHC you may
> say
>
> {-# LANGUAGE MagicHash #-}
>
> import GHC.Exts
>
> obviouslyEqual :: a -> a -> Bool
> obviouslyEqual a b =
>case I# (reallyUnsafePtrEquality# a b) of
> 0 -> False
> _ -> True
>
> However, this functions is *not* referentially transparent (exercise:
> show an example of how obviouslyEqual breaks referential
> transparency). reallyUnsafePtrEquality# is really unsafe for a reason
> =).
>
> Cheers,
>
> --
> Felipe.
>
> ___
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20111212/223d11fb/attachment-0001.htm>
--
Message: 5
Date: Mon, 12 Dec 2011 16:58:33 +0100
From: Ertugrul S?ylemez
Subject: Re: [Haskell-beginners] Pattern matching over functions
To: beginners@haskell.org
Message-ID: <20111212165833.7d867...@angst.streitmacht.eu>
Content-Type: text/plain; charset="us-ascii"
Graham Gill wrote:
> > > But then we would lose referential transparency.
> >
> > As I understand, this would be against lazy evaluation since it
> > would request to evaluate expressions in lambda, but I don't see how
> > this relates to referential transparency. Can you elaborate this a
> > little bit?
>
> I second the question.
Referential transparency /requires/ that
id x = x
even if 'x' is a function, and this can, as Brent already noted,
arbitrarily complicated. If pattern matching could tell f from id f,
then referential transparency is violated. The only possible way to
tell f from id f is very unsafe and needs IO, hence not usable in
pattern matching.
Greets,
Ertugrul
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20111212/543b59a0/attachment.pgp>
--
___
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 42, Issue 16
*
Beginners Digest, Vol 42, Issue 17
Send Beginners mailing list submissions to beginners@haskell.org To subscribe or unsubscribe via the World Wide Web, visit http://www.haskell.org/mailman/listinfo/beginners or, via email, send a message with subject or body 'help' to beginners-requ...@haskell.org You can reach the person managing the list at beginners-ow...@haskell.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Beginners digest..." Today's Topics: 1. Re: IO ( stuff ) (Paul Monday) 2. Re: Fwd: Averaging a string of numbers (Brent Yorgey) 3. Re: Fwd: Averaging a string of numbers (goodman@gmail.com) 4. In Search Of a clue... (Defining and making use of a type) (Allen S. Rout) 5. Re: In Search Of a clue... (Defining and making use of a type) (David McBride) 6. Re: In Search Of a clue... (Defining and making use of a type) (Thomas) 7. Re: In Search Of a clue... (Defining and making use of a type) (Brent Yorgey) -- Message: 1 Date: Mon, 12 Dec 2011 10:16:37 -0700 From: Paul Monday Subject: Re: [Haskell-beginners] IO ( stuff ) To: beginners@haskell.org Cc: dmcbr...@neondsl.com Message-ID: Content-Type: text/plain; charset=windows-1252 Thank you SO much for the discussion. I've learned quite a bit over the course of it. As one would expect, lifting wasn't my only issue ? I had some rather annoying Unbox / Boxed / [] problems with the recursion. I stepped way back finally this morning to think about the problem and the discussion points. I was able to make use of laziness with the randomRs function. randomRs is nice since there are no side-effects, I get an "infinite" list of random numbers that can easily be broken into rows and matrices lazily. So, here is how I generated two square matrices with rows and columns = n (some other artifacts are included here as well, like the Matrix type I'm using) data Matrix a = Matrix (V.Vector (U.Vector a)) deriving (Show, Eq) makematrix :: [Float] -> Int -> Int -> [U.Vector Float] makematrix xs n 0 = [] makematrix xs n r = (U.fromList $ ys) : makematrix zs n (r - 1) where (ys, zs) = splitAt n xs main :: IO () main = do args <- getArgs let n = read (args !! 0) :: Int let minrange = read (args !! 1) :: Float let maxrange = read (args !! 2) :: Float let s = read (args !! 3) :: Int let g = mkStdGen s let range = (minrange, maxrange) let all = randomRs range g let ma = Matrix $ (V.fromList (makematrix all n n)) let mb = Matrix $ (V.fromList (makematrix (drop (n*n) all) n n)) ... As with all Haskell I'm learning, I'm 100% sure there are quite a few better ways to write this ;-) Still, again, I can't thank you enough for the thoughtful discussion on IO and randomness. I have avoided running back to Java with my tail between my legs for another day. Paul Monday Parallel Scientific, LLC. paul.mon...@parsci.com On Dec 9, 2011, at 3:05 PM, David McBride wrote: > I wish I'd known this when I was first beginning, but it is possible > to do randomness outside of IO, surprisingly easily. I like to use > the monadRandom library, which provides some monads and monad > transformers for this task. I too became frustrated when I wrote a > roguelike but could not figure out how to inject randomness into it > when I wanted. A program you would write might be like this: > > data Obstacle = Mon (Int, Int) Monster | Door (Int, Int) | Trap (Int, > Int) deriving (Show, Enum) > data Monster = Orc | Wolf | Dragon deriving (Show, Enum) > > main = do > print =<< evalRandIO randomObstacle > > randomObstacle :: RandomGen g => Rand g Obstacle > randomObstacle = do > x <- getRandomR (0,2::Int) > case x of >0 -> Mon <$> randomLocation <*> randomMonster >1 -> Door <$> randomLocation >2 -> Trap <$> randomLocation > > randomLocation :: RandomGen g => Rand g (Int,Int) > randomLocation = do > x <- getRandomR (0,10) > y <- getRandomR (0,10) > return (x,y) > > randomMonster :: RandomGen g => Rand g Monster > randomMonster = do > x <- getRandomR (0,2::Int) > return $ case x of >0 -> Orc >1 -> Dragon >2 -> Wolf > > This way, even though my randomBlah functions do not have IO in them, > nor do they pass around a stdGen around, but they can be combined > willy nilly as needed, and only computed when you want them to. I > also could have made Random instances for Obstacle and Monster so that > I did not have to do the cases in the code, making things easier to > understand. > > On Fri, Dec 9, 2011 at 3:27 PM, Brent Yorgey wrote: >>> Does "impurity" from something >>> like a random number generator or file I/O have to move it's way all >>> the way through my code? >> >> No, only through the parts that actually have to do file I/O or >> generate random numbers or whatever. However, cleanly separating the >> IO code
