Send Beginners mailing list submissions to
        [email protected]

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
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."


Today's Topics:

   1.  A question on seq (Klaus Gy)
   2. Re:  A question on seq (Felipe Lessa)
   3.  Padding List with Zeros (Lorenzo Isella)
   4. Re:  Padding List with Zeros (Antoine Latter)
   5.  Re: Padding List with Zeros (Ertugrul Soeylemez)
   6.  The cost of generality,  or how expensive is realToFrac? (Greg)


----------------------------------------------------------------------

Message: 1
Date: Tue, 14 Sep 2010 23:26:47 +0200
From: Klaus Gy <[email protected]>
Subject: [Haskell-beginners] A question on seq
To: [email protected]
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1

Hi!

Inspred from the discussion
http://www.haskell.org/pipermail/beginners/2010-February/003396.html ,
I just try to understand the seq function a bit better. When I compare
these two functions:

firstSum :: Num a => a -> [a] -> a
firstSum s []     = s
firstSum s (x:xs) = seq help (firstSum help xs)
  where help      = x + s

secondSum :: Num a => [a] -> a
secondSum []      = 0
secondSum (x:xs)  = seq help (x + help)
  where help      = secondSum xs

What should be the difference? In my opinion both functions do not
return a complete unevaluated thunk (secondSum returns a thunk of the
form (THUNK + b) where THUNK contains a single numeral value). But it
seems to me that the first function computes the output somehow linear
in the sense that it does just a set of substitutions while the second
functions has to create a tree to handle all the recursive calls of
seq (sorry, my terminology is for sure a bit poor). So I would say the
first function delivers a better performance. (In the discussion I
mentioned, the second function was not discussed in this form with the
seq implementation). Am I right with my thoughts?

Thanks, fweth


------------------------------

Message: 2
Date: Tue, 14 Sep 2010 19:40:47 -0300
From: Felipe Lessa <[email protected]>
Subject: Re: [Haskell-beginners] A question on seq
To: Klaus Gy <[email protected]>
Cc: [email protected]
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 14, 2010 at 6:26 PM, Klaus Gy <[email protected]> wrote:
> What should be the difference?

There's at least one big difference.  'secondSum' keeps the whole list
in memory, because it only starts summing after it got to the tail of
the list.  This causes bad behaviour when the list doesn't need to be
kept around:

*Main> secondSum (replicate 1000000 0)
0
(32.34 secs, 503758400 bytes)
*Main> firstSum 0 (replicate 1000000 0)
0
(0.98 secs, 243311272 bytes)

Cheers!

-- 
Felipe.


------------------------------

Message: 3
Date: Wed, 15 Sep 2010 01:35:06 +0200
From: Lorenzo Isella <[email protected]>
Subject: [Haskell-beginners] Padding List with Zeros
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Dear All,
I still have to find my way with immutable lists and list comprehension.
Consider the following lists

A=[0,10,20,30,40,50]
B=[0,10,50] (i.e. B is a subset of list A; list A is already ordered in 
increasing order and so is B).
C=[2,1,-5] i.e. there is a corresponding element in C for every element 
in B.

Now, I would like to define a new list D having length equal to the 
length of A. The elements of D in the position of the elements of A in 
common with B are equal to the corresponding entries in C, whereas the 
other ones are zero i.e.
D=[2,1,0,0,0,-5]. How can I achieve that? The first thought that comes 
to my mind is to define a list of zeros which I would modify according 
to my needs, but that is not allowed...
Many thanks

Lorenzo


------------------------------

Message: 4
Date: Tue, 14 Sep 2010 18:55:24 -0500
From: Antoine Latter <[email protected]>
Subject: Re: [Haskell-beginners] Padding List with Zeros
To: Lorenzo Isella <[email protected]>
Cc: [email protected]
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="utf-8"

Are these truly lists, or would you be better suited using Sets, Maps or
IntMaps?

Then you can use some of the unionWith functions to decide what to insert,
or you can simply wrap the looking functions to return zero on failure.

Antoine

On Sep 14, 2010 6:35 PM, "Lorenzo Isella" <[email protected]> wrote:
> Dear All,
> I still have to find my way with immutable lists and list comprehension.
> Consider the following lists
>
> A=[0,10,20,30,40,50]
> B=[0,10,50] (i.e. B is a subset of list A; list A is already ordered in
> increasing order and so is B).
> C=[2,1,-5] i.e. there is a corresponding element in C for every element
> in B.
>
> Now, I would like to define a new list D having length equal to the
> length of A. The elements of D in the position of the elements of A in
> common with B are equal to the corresponding entries in C, whereas the
> other ones are zero i.e.
> D=[2,1,0,0,0,-5]. How can I achieve that? The first thought that comes
> to my mind is to define a list of zeros which I would modify according
> to my needs, but that is not allowed...
> Many thanks
>
> Lorenzo
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://www.haskell.org/pipermail/beginners/attachments/20100914/0690e212/attachment-0001.html

------------------------------

Message: 5
Date: Wed, 15 Sep 2010 02:34:28 +0200
From: Ertugrul Soeylemez <[email protected]>
Subject: [Haskell-beginners] Re: Padding List with Zeros
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII

Lorenzo Isella <[email protected]> wrote:

> Dear All,
> I still have to find my way with immutable lists and list
> comprehension.  Consider the following lists
>
> A=[0,10,20,30,40,50]
> B=[0,10,50] (i.e. B is a subset of list A; list A is already ordered
> in increasing order and so is B).
> C=[2,1,-5] i.e. there is a corresponding element in C for every
> element in B.
>
> Now, I would like to define a new list D having length equal to the
> length of A. The elements of D in the position of the elements of A in
> common with B are equal to the corresponding entries in C, whereas the
> other ones are zero i.e.
> D=[2,1,0,0,0,-5]. How can I achieve that? The first thought that comes
> to my mind is to define a list of zeros which I would modify according
> to my needs, but that is not allowed...

Here is a simple approach using Data.Map:

  import qualified Data.Map as M

  substSubset :: (Num b, Ord a) => [a] -> [b] -> [a] -> [b]
        substSubset ys zs =
    map (\x -> M.findWithDefault 0 x (M.fromList $ zip ys zs))

First build a map from [0, 10, 50] to [2, 1, -5], then map a function
over [0, 10 .. 50], which tries to find each corresponding number in the
map with a default of 0.

But do you really need zero values?  If your zeroes actually represent
lack of a value, consider using Maybe instead:

  [Just 2, Just 1, Nothing, Nothing, Nothing, Just (-5)]

instead of:

  [2, 1, 0, 0, 0, -5]


Greets,
Ertugrul


-- 
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/




------------------------------

Message: 6
Date: Wed, 15 Sep 2010 00:51:01 +0000 (GMT)
From: Greg <[email protected]>
Subject: [Haskell-beginners] The cost of generality,    or how expensive
        is realToFrac?
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

First, to anyone who recognizes me by name, thanks to the help I've been 
getting here I've managed to put together a fairly complex set of code files 
that all compile together nicely, run, and do exactly what I wanted them to do. 
 Success!

The trouble is that my implementation is dog slow

Fortunately, this isn't the first time I've been in over my head and I started 
by putting up some simpler scaffolding- which runs much more quickly.  Working 
backwards, it looks like the real bottle neck is in the data types I've 
created, the type variables I've introduced, and the conversion code I needed 
to insert to make it all happy.

I'm not sure it helps, but I've attached a trimmed down version of the relevant 
code.  What should be happening is my pair  is being converted to the canonical 
form for Coord2D which is Cartesian2D and then converted again to Vertex2.  
There shouldn't be any change made to the values, they're only being handed 
from one container to another in this case (Polar coordinates would require 
computation, but I've stripped that out for the time being).  However, those 
handoffs require calls to realToFrac to make the type system happy, and that 
has to be what is eating up all my CPU.

I think there are probably 4 calls to realToFrac.  If I walk through the  code, 
the result, given the pair p, should be:
Vertex2 (realToFrac (realToFrac (fst p)))  (realToFrac (realToFrac (snd p)))

I'd like to maintain type independence if possible, but I expect most uses of 
this code to feed Doubles in for processing and probably feed GLclampf (Floats, 
I believe) to the OpenGL layer.  If there's a way to do so, I wouldn't mind 
optimizing for that particular set of types.  I've tried GLdouble, and it 
doesn't really improve things with the current code.

Is there a way to short circuit those realToFrac calls if we know the input and 
output are the same type?  Is there a way merge the nested calls?

Any other thoughts on what I can do here?  The slow down between the two 
implementations is at least 20x, which seems like a steep penalty to pay.

And while I'm at it, is turning on FlexibleInstances the only way to create an 
instance for (a,a)?

Thanks--
 Greg




--I want to scatter plot a list of pairs of Doubles
data ScatterPlot = ScatterPlot {scatterPoints :: [(Double,Double)] }   

--this way is plenty fast
    GL.renderPrimitive GL.Points $ mapM_ GL.vertex (map pair2vertex $ 
scatterPoints plot)

--using this function in the map
pair2vertex :: (a,a) -> GL.Vertex2 a
pair2vertex (x,y) = GL.Vertex2 x y 

--then I started to get fancy and build custom types for coordinates, hoping to 
start developing a library useful for 
--cartesian, polar, 3D, etc.  I needed to create this trivial function to 
resolve a type ambiguity

coordToVertex2 :: Coord2D a => a -> (GL.Vertex2  GL.GLclampf)
coordToVertex2 = coordToCoord2D

--which I call instead of pair2vertex
    GL.renderPrimitive GL.Points $ mapM_ GL.vertex (map coordToVertex2 $ 
scatterPoints plot)

--Coord2D is a typeclass I created to hold 2D data
data Cartesian2D a = Cartesian2D a a deriving (Show, Eq, Read)  

class Coord2D a where
  xComponent :: (RealFloat b) => a -> b
  yComponent :: (RealFloat b) => a -> b
  toCartesian2D :: (RealFloat b) => a -> Cartesian2D b
  toCartesian2D p = Cartesian2D (xComponent p) (yComponent p)
  fromCartesian2D :: (RealFloat b) => Cartesian2D b -> a

--and this function allows conversion between coordinate representations
coordToCoord2D :: (Coord2D a, Coord2D b) => a -> b
coordToCoord2D = fromCartesian2D . toCartesian2D


--I think the only other interesting bit of code is the instance definitions:

{- Pair instances -}
instance (RealFloat a, RealFloat b) => Coord2D (a,b) where
  xComponent = realToFrac . fst
  yComponent = realToFrac . snd
  fromCartesian2D p = ((xComponent p),(yComponent p))

{- Cartesian 2D instances -}
instance (RealFloat a) => Coord2D (Cartesian2D a) where
  xComponent (Cartesian2D x _) = realToFrac x
  yComponent (Cartesian2D _ y) = realToFrac y
  fromCartesian2D p = Cartesian2D (xComponent p) (yComponent p)

{- Vertex2 instance -}
instance (RealFloat a) => Coord2D (Vertex2 a) where
  xComponent (Vertex2 x _) = realToFrac x
  yComponent (Vertex2 _ y) = realToFrac y
  fromCartesian2D p = Vertex2 (xComponent p) (yComponent p)

-------------- next part --------------
Skipped content of type multipart/related

------------------------------

_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners


End of Beginners Digest, Vol 27, Issue 33
*****************************************

Reply via email to