- Haskell-Cafe - Haskell.org

approximating pi
by ry dahl 01 May '08

01 May '08

By picking points randomly from a square one can calculate pi. Keep track of how many points from the square you pick lay in the inscribed circle. Supposing the square's edges are length 2, then the inscribed circle has radius 1. Thus the area of the circle is pi*r^2 = pi. The area of the square is 4. The ratio of points picked from the circle to the total number of picked points will converge to pi / 4. What is the best way to express this algorithm in Haskell? ry

7 9

[help] Program immplementing an alarm
by Antonio Regidor García 30 Apr '08

30 Apr '08

Hi, I'm trying to implement an alarm in Haskell and wrote the following code: http://hpaste.org/7201 But it doesn't work as expected. The expected behaviour is: The user enters a time in minutes. If the time is reached, a bell rings. If, before the time is reached, he press enter, the program finish and prints the elapsed time. The actual behaviour is: The user enters a time in minutes. If time is reached, nothing happens. If the user press enter, the elapsed time is printed and the program finish. Also, if he pressed enter after the time had elapsed, the bell rings. Some ideas? Antonio Regidor García ______________________________________________ Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.

2 2

ANN: Graphics.Rendering.Diagrams 0.1
by Brent Yorgey 30 Apr '08

30 Apr '08

Hi all! I am very pleased to announce the release of Graphics.Rendering.Diagrams, an embedded domain-specific language for creating simple pictures and diagrams, built on top of the Cairo vector graphics library. It's still somewhat in its infancy, but already beginning to be useful and I wanted to get something released as soon as possible. More info and examples here: http://byorgey.wordpress.com/2008/04/30/ new-haskell-diagrams-library/ Download the package here: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/diagrams-0.1 If it looks interesting to you, please give it a try, report bugs, request features, and so on. If it looks too simplistic to be of use to you -- just wait for a future version! I've got tons of ideas for features. If you're interested in contributing, I'll have a darcs repo up (most likely at http://code.haskell.org/diagrams/) as soon as someone creates a directory for me on code.haskell.org. Enjoy! -Brent

1 1

question about GHC and Unicode
by Daniel Gee 30 Apr '08

30 Apr '08

In GHC there's a GHC.Unicode library, but for a string such as "ΧΑΟΣΣ", a GHC compiled program prints it as a string of unknown characters, and in the interpreter, the string evaluates to a string of escape sequences instead of displaying properly. Is there a way to get/activate unicode support in GHC?

9 13

Bug or feature with -XFlexibleContects?
by John Goerzen 30 Apr '08

30 Apr '08

Hi, I noticed something odd yesterday. I had a function of this type: divByGeneric :: (Integral a, MonadError (DivByError a) m) => a -> [a] -> m [a] If I left off the type signature, ghci (with no command-line parameters) would load the file just fine, and :t would give this same type back. But if I put the type signature in there -- even an exact cut and paste from ghci's :t -- it would complain that it needs -XFlexibleContexts. It seems odd to me that ghci can infer a type that is illegal for the way it was run. Thoughts? This is GHC 6.8.2, BTW. -- John

2 2

Re: [Haskell-cafe] HaXml and the XHTML 1.0 Strict DTD
by Marc Weber 30 Apr '08

30 Apr '08

Also have a look at the HaXml page. A branch is listed there passing more tests if I recall correctly. Don't know wether those changes have been merged back yet. I haven't tried it. Marc Weber

1 0

Function Type Calculation (Take 2)
by PR Stanley 30 Apr '08

30 Apr '08

In case you missed it the first time here is my query again: Hi I know we've already looked at the topic of function type calculation though last time I didn't have the chance to go through it thoroughly. So here it is again. Apologies for the repetition. I've had a try at calculating function types for two examples below. So to start with I'd be grateful for an assessment of my efforts. All comments are welcome. Thanks, Paul [1] funk f x = f (funk f) x f :: a x :: b funk f x :: c therefore funk :: a -> b -> c RHS f (funk f) x :: c f (funk f) :: d -> c x :: d f :: e -> d -> c funk :: h -> e f :: h unification f :: a = h = (e -> d -> c) x b = d therefore funk :: ((h -> e) -> b -> c) -> b -> c [2] w f = f f Assigning Types f :: a w f :: b therefore w :: a -> b RHS f f :: b f :: c -> b f :: c f :: a = b = c = (c -> b) therefore w :: (a -> a) -> a

2 2

Re: [Haskell] Matrix multiplication
by Don Stewart 30 Apr '08

30 Apr '08

> droundy > On Wed, Apr 23, 2008 at 05:24:20PM +0100, Sebastian Sylvan wrote: > > On Wed, Apr 23, 2008 at 5:01 PM, Tillmann Vogt <Tillmann.Vogt <at> rwth-aachen.de> > > wrote: > > > > > Hi, > > > > > > I am currently experimenting with parallelizing C-programs. I have > > > therefore written a matrix vector multiplication example that needs 13 > > > seconds to run (5 seconds with OpenMP). Because I like Haskell I did the > > > same in this language, but it takes about 134 seconds. Why is it so slow? > > > Does someone have an idea? > > > > > Yes, in the C version you use unboxed arrays, in the Haskell version you use > > a linked list of linked lists. Naturally the latter will take up more space, > > require more work to index, and will thrash the cache quite a bit. > > In fact, I'm impressed that Haskell can come within a factor of 10, given > that it's using such a challenging data type! (I wonder if this may be due > to inefficiencies in the C code, although I haven't looked at it.) I had a look at this code, using the (unboxed, strict, fused) data parallel arrays library (http://darcs.haskell.org/packages/ndp) We get rather nice code. The original C program (modified, to sum the result, rather than just filling the array and throwing it out): #include <stdio.h> #include <stdlib.h> #include <time.h> #define M 4000 #define N 4000 #define IT 100 double a[M], b[M][N], c[N]; int main(int argc, char *argv[]) { double d; double sum; int i, j, l; time_t start,end; printf("Initializing matrix B and vector C\n"); for(j=0; j<N; j++) c[j] = 2.0; for(i=0; i<M; i++) for(j=0; j<N; j++) b[i][j] = j; printf("Executing %d matrix mult. for M = %d N = %d\n",IT,M,N); time (&start); sum = 0; for(i=0; i<M; i++) for (j=0; j<N; j++) sum += b[i][j]*c[j]; time (&end); printf ("result: %.2lf\n", sum ); d = difftime (end,start); printf ("calculation time: %.2lf seconds\n", d ); return 0; } And then rewritten in a data parallel style (but note, no parallelism here, just using the nice interface to STUArrays, with stream fusion): import Data.Array.Parallel.Unlifted import Text.Printf m = 4000 n = 4000 it = 100 main = printf "result: %2f\n" . sumU . zipWithU (*) (concatSU b) $ repeatU m c where -- c[N] c = replicateU n (2.0 :: Double) -- b[M][N] b = replicateCU m t where t = mapU fromIntegral (enumFromToU 0 (n-1)) :: UArr Double Finds 4 fusion sites, and runs in: $ time ./a result: 63984000000.0 ./a 0.10s user 0.00s system 112% cpu 0.089 total While the C program, $ time ./a.out Initializing matrix B and vector C Executing 100 matrix mult. for M = 4000 N = 4000 result: 63984000000.00 calculation time: 0.00 seconds ./a.out 0.14s user 0.09s system 92% cpu 0.248 total GHC rocks :) NDP programming encourages a nice combinator style too, which is interesting (and Haskell-ish). The compiler is able to fuse array most of the arrays, (and Roman reports this should do rather better with ghc head). Anyway, we've a few new (fast!) array options on the horizon, looking promising. For more info, check out the data parallel arrays page, http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell -- Don

1 0

Caching the Result of a Transaction?
by Jake Mcarthur 30 Apr '08

30 Apr '08

I have a problem I've been trying to work around using the existing STM API, and so far it seems that I may be unable to do it. For more background, see my blog post at <http://geekrant.wordpress.com/2008/04/25/stm-caching-need/ >. Here, for brevity, I will only describe exactly what I think I need, not what it's for. Say I have a function f :: STM a. The transaction reads from one or more TMVars, performs some computation, and returns the result in the STM monad. Also, in this scenario, it is known that once the TMVars have values, those values will never be changed again (write once, read many, somewhat like IVars before they were removed). Now say I try to use this function as so. liftM2 (,) f f So the desired result is a pair in the STM monad where both components are the result from f. The problem I have is that, in the above example, the TMVars are all read twice and the computations are all performed twice, once for each of the components of the resulting pair. In many cases, this may be the correct thing to do because the values of the TMVars may have changed, but what about this case where I _know_ that the values have not been modified? What I need is a way to cache the result of f so that future uses of f don't have to reread from the TMVars, even across multiple transactions, maybe even leading to the eventual garbage collection of the TMVars if they are not used elsewhere. Right now I think the only way to do this would be to change the STM implementation slightly and create a new primitive function. If there is a way to do something like this with the current STM API, I would love to hear suggestions. Any ideas? - Jake McArthur

5 14

Re: [Haskell-cafe] A bright future for Haskell
by Don Stewart 30 Apr '08

30 Apr '08

ajb: > G'day all. > > Quoting John Peterson <jpeterson(a)western.edu>: > > >Especially if SPJ decides to grow a beard. Unfortunately Paul is > >now clean shaven so maybe Haskell is in trouble. > > This explains why Clean never made it: Rinus Plasmeijer can't compete > with Phil Wadler in the beard department. > > I should point out, for fairness, tht Mark Jones has suitable facial > hair, and John Hughes and Ralf Hinze are not fair behind. John Peterson > clearly should complete his beard, though. And in the younger generation, Ian Lynagh is surely critical to Haskell's on going success... -- Don

1 0