Re: [Haskell-cafe] Haskell interface file (.hi) format?
Hi Prelude :b Control.Concurrent.MVar module 'Control.Concurrent.MVar' is not interpreted :b now defaults to :breakpoint, you want :browse Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing cellular automata evaluation (round 2)
On Friday 30 November 2007 00:31, Justin Bailey wrote: I represent the automata as an array of integers, where each bit represents a cell. Mathematica uses a single arbitrary-precision integer to represent each generation of a 1D automaton. The rules to derive the next generation are compiled into arithmetic operations on the integer. The offloads all such work onto your big number library and, with GMP, will be as fast in Haskell as most other languages. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New slogan for haskell.org
Yitzchak Gale [EMAIL PROTECTED] writes: Guido is clearly not rejecting functional influences on Python, he is supporting them. But he feels that these specific instances do not fit in. I read some of his statements, and find that I disagree vehemently. But I wonder if partial evaluation is contributint to this? GvR thinks list comprehensions are better than map or filter, and wants nested functions instead of lambda. So where I like to write filter odd or(\xs - (filter odd xs, filter even xs)) he would prefer let filter_odd xs = [ x | x - xs, odd x ] in filter_odd and let map_even_odd xs = let filter_odd ys = [ y | y - ys, odd y ] filter_even ys = [ y | y - ys, even y ] in (filter odd xs, filter even xs) in map_even_odd I hope I'm not misrepresenting the Python way here, but it feels incredibly clunky. Maybe it looks better in Python? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing cellular automata evaluation (round 2)
On Nov 30, 2007 6:03 PM, Justin Bailey [EMAIL PROTECTED] wrote: On Nov 29, 2007 9:11 PM, Jon Harrop [EMAIL PROTECTED] wrote: Mathematica uses a single arbitrary-precision integer to represent each generation of a 1D automaton. The rules to derive the next generation are compiled into arithmetic operations on the integer. The offloads all such work onto your big number library and, with GMP, will be as fast in Haskell as most other languages. Does GHC already use the GMP library for Integer? It looks that way but I'm not positive. That'd be ironic, if the higher-level Integer representation is faster than a low-level bitwise one ... Still, I suspect accessing individual bits might kill me if I'm not able to move most of the calculation into a call to the library. Do you mind elaborating on how rules are compiled into 'arithmetic' operations or providing a link? Integer is an instance of Bits, so you can just use bitshifts and bitops to do any 1-D rule. There might be a more efficient way. For rule 110: 111 110 101 100 011 010 001 000 0 1 1 0 1 1 1 0 Algebraically, that's not (a b c || a not b not c || not a not b not c) So just translate that to: rule z = complement ((a .. b .. c) .|. (a .. b' .. c') .|. (a' .. b' .. c')) where a = z `shift` (-1) b = z c = z `shift` 1 a' = complement a b' = complement b c' = complement c Modulo some algebra to make it even better, but this should be pretty darn fast... Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Re: cabal-install
On Thu, 2007-11-29 at 23:56 +0100, Ben Franksen wrote: Duncan Coutts wrote: On Wed, 2007-11-28 at 21:00 +0100, Thomas Schilling wrote: On Wed, 2007-11-28 at 20:46 +0100, Ben Franksen wrote: [EMAIL PROTECTED]: .../software/haskell cd cabal [EMAIL PROTECTED]: .../haskell/cabal runhaskell Setup.lhs configure Distribution/Simple/NHC.hs:77:1: lexical error at character 'i' Ups. Cheers Ben (feels like a real beta-tester now ;-) Well, Cabal cannot automatically compile itself with itself. No actually it can, that was just a bug (which I've just fixed). Ah, I wondered. If even 'the monster' (ghc) can build itself from earlier versions it should be possible for cabal to pull the same trick. Ben is indeed being a beta tester by using Cabal HEAD. I'd recommend the 1.2 branch: I was using HEAD as per Don's suggestion for how to build cabal-install. Now, re-reading this thread I see that you already mentioned that upgrading on the 2.1 branch would have been enough. Apropos beta-testing, cabal-1.3 seems to have introduced an incompatible API change; for instance, it can't build MissingH any longer. Actually it was 1.2.x that made this change. One install of cabal-install later: same error with MissingH. So the package was broken to begin with an it wasn't related to the cabal upgrade! G. Yup. It's not been updated to work with ghc 6.8 and related libs. Not that it matters to me here at home (there is a debian package I can use), but at work we are still using debian /old-stable/ which is just a bit too outdated and anyway I don't have root access so I have to install everything from source. Unpacking MissingH and looking at the Setup.hs I see that I can simply replace it by a generic version, add unix dependency to the cabal file, and all works well. So much for never again runhaskell Setup blabla ;-) I expect it can use configurations to add the unix package dependency conditionally and not need a custom Setup.hs file at all. (I should add that for many packages cabal-install works perfectly well.) Thanks again for your help! Cheers Ben PS: a 'cabal remove' would also be nice to have. http://hackage.haskell.org/trac/hackage/ticket/106 Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fast Array operations: foldl, drop
lemming: On Fri, 30 Nov 2007, Ketil Malde wrote: Bryan O'Sullivan [EMAIL PROTECTED] writes: For higher dimensions, there are enough options in terms of traversal direction and what exactly e.g. a fold should fold over (single elements? lower-dimensional slices?) that a sensible API doesn't exactly leap out. How about a 'reduce' instead of 'foldl1'? I think that if you require a commutative operator, the order doesn't matter (except for efficiency and possible rounding issues, I guess). For what I have in mind the order of execution matters. I also think now that slices for higher dimensional arrays are useful, anyway. If you choose a subrange of indices in the most significant dimension this would be possible without copying. It would be also possible to 'reshape' (in MatLab terms) an array without copying, as long as the number elements remain the same. So you could first transform an array of arbitrary dimension to a two-dimensional one, say I forgot to mention this early, but possibly you could use the ndp array library. There are some people using its UArr type for (non parallel) strict arrays, that support map/fold/zip et al. http://darcs.haskell.org/packages/ndp/ This blog post recently, http://sequence.complete.org/node/371 shows at least one non-developer is using it :) Roman, what do you think -- are the unlifted, non-parallel arrays usably `beta'? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: Re: cabal-install
Duncan Coutts wrote: Apropos beta-testing, cabal-1.3 seems to have introduced an incompatible API change; for instance, it can't build MissingH any longer. Actually it was 1.2.x that made this change. Ok. I realized it wasn't 1.3 as I remarked later: One install of cabal-install later: same error with MissingH. So the package was broken to begin with an it wasn't related to the cabal upgrade! G. Yup. It's not been updated to work with ghc 6.8 and related libs. I tried this (as everything else in this thread) with ghc-6.6.1. It seems to me that MissingH-0.18.6 only builds with an earlier version of Cabal. Unpacking MissingH and looking at the Setup.hs I see that I can simply replace it by a generic version, add unix dependency to the cabal file, and all works well. So much for never again runhaskell Setup blabla ;-) I expect it can use configurations to add the unix package dependency conditionally and not need a custom Setup.hs file at all. That would be nice. (I should add that for many packages cabal-install works perfectly well.) Thanks again for your help! Cheers Ben PS: a 'cabal remove' would also be nice to have. http://hackage.haskell.org/trac/hackage/ticket/106 +1 from my side. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: Re: Waiting for thread to finish
Paul Moore wrote: On 28/11/2007, Ben Franksen [EMAIL PROTECTED] wrote: It was fun, too. For instance, the OP's question reminded me of a little generic wrapper I wrote -- more or less for my own amusement -- during the course of this project. It outputs dots during an operation that might take a little longer to finish (a database query in my case)... just so the user doesn't get nervous ;-) And because I enjoyed it so much (and to show off) I threw in the timing measurement... [...] I think nobody in his right mind would even try to do something like that in C or Perl or whatever, at least not if it wasn't strictly a requirement and correct operation is important (the script gets executed as part of our build process and a subtle concurrency bug could lead to a wrong configuration for the target control system). In Haskell it was so easy to do that I just couldn't resist. That's a neat idea. Just (a) because I like the idea, and (b) because I'm contrary :-) I coded up the equivalent in Python. It also looks beautifully clean: [snipped python code] Looks good to me. I' walk back on the or whatever with regard to Python... ;-) Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] trouble building unix-2.2.0.0 on cygwin
Hello, 0) All work being done on cygwin. Version 6.8.1 of ghc. 1) I ran runhaskell Setup.lhs configure and did a tail -f config.log in order to follow the config process. 2) Next I did the build runhaskell Setup.lhs build but there were many include files referenced in HsUnix.h that couldn't be found, e.g. sys/times.h, sys/resources.h, sys/wait.h, 3) I went back through the file config.log and all of the so-called missing include files had supposedly been found during the config process. 4) Next I went to c:/cygwin/usr/include/sys and found all of the so-called missing include files. I am trying to get my confidence level up with respect to the config/build/install (and along with darcs and haddock) process up high so I can make a significant contribution to the Haskell effort. please .. any help will be appreciated. Kind regards, Vasya ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rigid type-var unification failure in existentials used with parametrically polymorphic functions
It seems you've already figured this out, but here's a quick counterexample:
{-# LANGUAGE ExistentialQuantification, RankNTypes #-}
module Box where
data Box = forall a. B a
--mapBox :: forall a b. (a - b) - Box - Box -- incorrect type
mapBox f (B x) = B (f x)
then:
boxedInt :: Box
boxedInt = B (1 :: Int)
f :: [Int] - Int
f = sum
mf :: Box - Box
mapBox f -- this is well-typed according to the specified type of mapBox
But,
mf boxedInt :: Box
mf boxedInt
= mapBox f boxedInt
= mapBox sum (B (1 :: Int))
= B (sum (1 :: Int))
which is not well-typed.
The least specific type for MapBox is
mapBox :: forall b. (forall a. (a - b)) - Box - Box
There are non-bottom functions of this type, for example:
const (1 :: Int) :: forall a. a - Int
With this type,
ok :: Box
ok = mapBox (const 1) (B hello)
is well-typed.
-- ryan
On 11/30/07, Pablo Nogueira [EMAIL PROTECTED] wrote:
A question about existential quantification:
Given the existential type:
data Box = forall a. B a
in other words:
-- data Box = B (exists a.a)
-- B :: (exists a.a) - Box
I cannot type-check the function:
mapBox :: forall a b. (a - b) - Box - Box
--:: forall a b. (a - b) - (exists a.a) - (exists a.a)
mapBox f (B x) = B (f x)
Nor can I type check:
mapBox :: forall a. (a - a) - Box - Box
--:: forall a. (a - a) - (exists a.a) - (exists a.a)
mapBox f (B x) = B (f x)
The compiler tells me that in both functions, when it encounters the
expression |B (f x)|, it cannot unify the universally quantified |a|
(which generates a rigid type var) with the existentially quatified
|a| (which generates a different rigid type var) -- or so I interpret
the error message.
However, at first sight |f| is polymorphic so it could be applied to
any value, included the value hidden in |Box|.
Of course, this works:
mapBox :: (forall a b. a - b) - Box - Box
mapBox f (B x) = B (f x)
Because it's a tautology: given a proof of a - b for any a or b I can
prove Box - Box. However the only value of type forall a b. a - b is
bottom.
This also type-checks:
mapBox :: (forall a. a - a) - Box - Box
mapBox f (B x) = B (f x)
When trying to give an explanation about why one works and the other
doesn't, I see that, logically, we have:
forall a. P(a) = Q implies (forall a. P(a)) = Q when a does not
occur in Q.
The proof in our scenario is trivial:
p :: (forall a. (a - a) - (Box - Box)) - (forall a. a - a) - Box -
Box
p mapBox f b = mapBox f b
However, the converse is not true.
Yet, could somebody tell me the logical reason for the type-checking
error? In other words, how does the unification failure translate
logically. Should the first mapBox actually type-check?
Isn't the code for mapBox :: forall a. (a - a) - Box - Box
encoding the proof:
Assume forall a. a - a
Assume exists a.a
unpack the existential, x :: a = T for some T
apply f to x, we get (f x) :: a
pack into existential, B (f x) :: exists a.a
Discharge first assumption
Discharge second assumption
The error must be in step 3. Sorry if this is obvious, it's not to me
right now.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Working out which library to use
Bulat Ziganshin wrote: Hello Neil, Friday, November 30, 2007, 1:32:25 AM, you wrote: 1. For certain tasks, there are multiple possible packages, and it's not really clear which one to go for. Having more than one choice is good. This can be solved easily using blogs. If you use a package user comments system on hackage may be better I agree. Keep the information all in one place. (And what's more, one place where the library author is likely to see it too.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and DB : giving up
Bulat Ziganshin wrote: Hello Andrew, Thursday, November 29, 2007, 11:51:32 PM, you wrote: This is one of the more frustrating aspects of Haskell. It's not that nobody has written DB bindings - they most certainly have. It's not that nobody has written compression or cryptography bindings - they have. It's that there is a small zoo of them, and it's really hard to pick out which ones are the good ones. I really hope this does improve in time. (And I really wish I could do something positive to make this happen...) when i come to using ftp/http in my program, i wrote binding to wininet.dll in two days. this may be not reasonable for occasional scriptiong but at least works for larger apps I don't know C, so I can't write bindings to anything... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Progress indications
Brandon S. Allbery KF8NH wrote: On Nov 29, 2007, at 17:13 , Thomas Hartman wrote: but there's no risk using trace is there? If you're doing any other I/O, you may be surprised by where the trace output shows up relative to it. How about if the I/O is to write to a different stream? Then it wouldn't matter too much. Or perhaps updating a real progress bar widget on a GUI. Or - better still - frobnicate an MVar or something. (Then you can handle what you do with these update signals somewhere else without cluttering the main algorithm too much...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Design of a Physics Interface
There seems to be three salient benefits of using arrows, as I read the Abstract and Introduction of Benjamin Lerner, Arrow Laws and Efficiency in Yampa, 2003, http://zoo.cs.yale.edu/classes/cs490/03-04a/benjamin.lerner/ 1) The discipline of using arrows assists in avoiding space-leaks The reasons underlying this...primarily stemmed from the availability of signals as first-class values. [the ugly pain you experience up front saves you chronic pain later. Self-discipline is the key to a happy life.] 2) Arrow syntaxanalogous to circuit diagrams = Arrow semantics analogous to signal processing [a mental/software model that resembles a physical model helps intuitive reasoning by analogy] 3) Satisfying arrow laws guarantees soundness of signal function type [you can have faith in the results of your simulation if the basic plumbing has been stress-tested in advance.] * The stuff in brackets is my own interpretation The overall impression I get is that using arrows makes simulations more scalable as overall simulation complexity increases. It will be good to get another use-case for this domain of application. Luke Palmer wrote: I'm currently working on idioms for game programming using FRP. After going through several representations of physics as arrows[1] I decided that physics objects must not be implemented as arrows, because introducing new arrows in the middle of a computation[2] leads to ugly pain. So far the best approach I have is to represent the physics world as a single object World, with a function integrate :: TimeStep - World - World But I can't figure out a good way to represent bodies in this world. I considered: newBody :: (Position,Velocity) - World - (Body,World) Where Body is an ADT with an internal representation of an Integer or something. The problem with this is that (1) there is no way to guarantee that a Body actually exists in a World (which is a minor but still annoying issue), and (2) that there's a possibility that you could make a Body in one world and use it in another and there would be no way to detect the error. (2) could be solved using an internal representation of Data.Unique, but (1) still remains a problem. And as long as the function deleteBody :: Body - World - World exists, it will always remain a problem. Are there any clever idioms I can use for this interface or implementation? Is there a way to store the data for bodies along with the Body object instead of with the world in a way that the relationships between them respect different generations of the World (through integrate)? Any other ideas? Thanks, Luke [1] Once as SF () (Position,Velocity), and again as SF PhysIn PhysOut where PhysIn = (Impulse,Momentum) and PhysOut = (Position,Velocity). [2] Using the arrow joinSF :: SF (Event (SF [a] a)) [a], and other similar style functions taking streams of SF events... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing cellular automata evaluation (round 2)
On Nov 29, 2007 9:11 PM, Jon Harrop [EMAIL PROTECTED] wrote: Mathematica uses a single arbitrary-precision integer to represent each generation of a 1D automaton. The rules to derive the next generation are compiled into arithmetic operations on the integer. The offloads all such work onto your big number library and, with GMP, will be as fast in Haskell as most other languages. Does GHC already use the GMP library for Integer? It looks that way but I'm not positive. That'd be ironic, if the higher-level Integer representation is faster than a low-level bitwise one ... Still, I suspect accessing individual bits might kill me if I'm not able to move most of the calculation into a call to the library. Do you mind elaborating on how rules are compiled into 'arithmetic' operations or providing a link? Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing cellular automata evaluation (round 2)
On Nov 29, 2007 4:45 PM, Felipe Lessa [EMAIL PROTECTED] wrote: Why don't you use an UArray of Bools? They're implemented as bit arrays internally, AFAIK (e.g. see http://www.haskell.org/haskellwiki/Shootout/Nsieve ). And then you would get rid of a lot of shifts and masks in your code -- clearer and faster, the Haskell Way (TM). fill, fillE and fillS are all looking at a integer value, and not doing any array access. I'm skeptical that an array of bools, even if its internally a mask on an int, could be faster. Well, I guess it would be faster, but I can't really tell. Could you provide a main function implementing an use case for benchmark? Sure, here is one http://hpaste.org/4151#a1 Compile with: ghc -O2 --make Test.hs It runs a random rule for 1000 steps. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Design of a Physics Interface
I think your integrate function looks like a good idea:
integrate :: TimeStep - World - World
For bodies, I think you should have a BodyID type, and then to add a
body to the world you could have a function:
newBody :: (Position, Velocity) - World - (BodyID, World)
To delete a body:
deleteBody :: BodyID - World - World
So your World type will need to contain all of the bodies inside it,
something like this:
data World = World { gravity :: Vector, bodies :: [(BodyID, (Position,
Velocity, BodyProperties))]
This is pretty much the way things are done in the FRP paper The
Yampa Arcade, where they use an Identity List where the type ILKey
= Int. See section 5.5 of the paper:
http://www.haskell.org/yale/papers/haskell-workshop03/index.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A tale of Project Euler
On Fri, 30 Nov 2007, Daniel Fischer wrote: Am Freitag, 30. November 2007 14:39 schrieb Henning Thielemann: Is this thread still about the prime sieve? As I mentioned, I think one can avoid the mutable array, because if there is only a small number of array updates with much changes per update, it should be efficient enough to copy the array per update. I think in this case it's far less efficient than in-place update. Consider sieving primes up to 10^7, there are 446 primes with p^2 10^7, so you would have over 400 array updates. Even if you leave out the even numbers, an array going up to 10^7 would require some 800 KB memory (each odd number one bit), so overall, you'd allocate well over 300 MB (not at once, of course). not at once - that's the point. With some luck there are only two pieces of memory where the data is copied back and forth. It's obviously not the most efficient solution, but a non-monadic solution. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Re: Re: Hit a wall with the type system
On 30 Nov 2007, [EMAIL PROTECTED] wrote: Sure. To be more specific, here's the contract I would really like. 1. You need to pass in a polymorphic function a - a, where a is, at *most*, restricted to being an instance of Floating. This part I can already express via rank-N types. For example, the diffFloating function in my original post enforces this part of the contract. It seems to me that you need the type system to ensure that the function is differentiable. For this, you have to export the type (though not the constructor as long as you don't want users to be able to extend it). Am I missing something? Jed pgpuI1KZjZGHv.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Categories list in French (off-topic?)
Laurent Deniau escreveu: Maurício wrote: Hi, I'm learning about categories using Saunders Mac Lane book. I'm also learning French. Do you guys know of a nice French mailing list, or forum, where people discuss about categories (and where beginners are accepted)? newsgroup: fr.sci.math a+, ld. Nice tip. Do you know of a free news server that allows read and post for that group? Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A tale of Project Euler [ST]
Bulat Ziganshin wrote: Hello Andrew, Friday, November 30, 2007, 12:10:16 AM, you wrote: I don't understand the ST monad. From what I can tell, it's not definable without using strange language extensions. (I don't really like using things where it's unclear why it works.) this extension used only to guarantee referential transparency, so you don't need to understand it to use ST if you still want, it's not that hard - rank-2 forall type used here to guarantee that code executed by runST is compatible with *any* return type which makes it impossible to return innards of this computation and therefore forces your code to be referential transparent runST may be defined without rank-2 type. it doesn't change anything in its low-level working (this rank-2 type is just empty value, like RealWorld), but allows you to break referential transparency: main = do a - runST (do a - newArray return a) ... x - runST (do x - readArray a return x) ... low-level implementation of all ST-bound operations is just direct call to equivalent IO operation: newSTArray = unsafeIOtoST newIOArray readSTArray = unsafeIOtoST readIOArray where unsafeIOtoST - just code-less cast operation Mmm, so basically it's rank-2 types I don't understand. ;-) Well anyway, given the multiple replies I've had, I now have some idea how this stuff works... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing cellular automata evaluation (round 2)
Justin Bailey wrote: On Nov 29, 2007 9:11 PM, Jon Harrop [EMAIL PROTECTED] wrote: Mathematica uses a single arbitrary-precision integer to represent each generation of a 1D automaton. The rules to derive the next generation are compiled into arithmetic operations on the integer. The offloads all such work onto your big number library and, with GMP, will be as fast in Haskell as most other languages. Does GHC already use the GMP library for Integer? It looks that way but I'm not positive. That'd be ironic, if the higher-level Integer representation is faster than a low-level bitwise one ... Still, I suspect accessing individual bits might kill me if I'm not able to move most of the calculation into a call to the library. Do you mind elaborating on how rules are compiled into 'arithmetic' operations or providing a link? This would mean that you are able to extract a global rule from your local rules (plural if you include topological dependencies) which is not possible in the general case. Global behavior was characterized in term of information propagation (classification), which was far not enough to deduce a global rule. But I haven't look at the domain for a decade now ;-) a+, ld. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New slogan for haskell.org
I really like the friendly look of Ruby's homepage: http://www.ruby-lang.org/en/ * There's an interpreter download button in a high visibility position. * Visible news. * It's pretty! * A very short introduction. Ruby is... ... which is so generic, that we can copy it to the Haskell home page without modification. I didn't say I wanted the text. I just like the layout (and the pretty pixels.) :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A tale of Project Euler
Am Freitag, 30. November 2007 14:39 schrieb Henning Thielemann: Is this thread still about the prime sieve? As I mentioned, I think one can avoid the mutable array, because if there is only a small number of array updates with much changes per update, it should be efficient enough to copy the array per update. I think in this case it's far less efficient than in-place update. Consider sieving primes up to 10^7, there are 446 primes with p^2 10^7, so you would have over 400 array updates. Even if you leave out the even numbers, an array going up to 10^7 would require some 800 KB memory (each odd number one bit), so overall, you'd allocate well over 300 MB (not at once, of course). Using an STUArray runs easily within 1MB allocated once. And why avoid mutable arrays in the first place? What's bad about thing = runSTUArray (do work)? Granted, work tends to be far less elegant code than list comprehensions c, but also much faster. Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New slogan for haskell.org
On Fri, 30 Nov 2007, Johan Tibell wrote: On Nov 30, 2007 1:30 AM, Ivan Miljenovic [EMAIL PROTECTED] wrote: Speaking of Stackless Python, its homepage (http://www.stackless.com/) has a rather nice layout... maybe slightly less emphasis on the About section, but there you've got the links, the info and the news all on the one page. I really like the friendly look of Ruby's homepage: http://www.ruby-lang.org/en/ * There's an interpreter download button in a high visibility position. * Visible news. * It's pretty! * A very short introduction. Ruby is... ... which is so generic, that we can copy it to the Haskell home page without modification. * The most important links (documentation, libraries, community, etc.) are available to the right. I like the fact that there are no subcategories at this point. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Design of a Physics Interface
I'm currently working on idioms for game programming using FRP. After going through several representations of physics as arrows[1] I decided that physics objects must not be implemented as arrows, because introducing new arrows in the middle of a computation[2] leads to ugly pain. So far the best approach I have is to represent the physics world as a single object World, with a function integrate :: TimeStep - World - World But I can't figure out a good way to represent bodies in this world. I considered: newBody :: (Position,Velocity) - World - (Body,World) Where Body is an ADT with an internal representation of an Integer or something. The problem with this is that (1) there is no way to guarantee that a Body actually exists in a World (which is a minor but still annoying issue), and (2) that there's a possibility that you could make a Body in one world and use it in another and there would be no way to detect the error. (2) could be solved using an internal representation of Data.Unique, but (1) still remains a problem. And as long as the function deleteBody :: Body - World - World exists, it will always remain a problem. Are there any clever idioms I can use for this interface or implementation? Is there a way to store the data for bodies along with the Body object instead of with the world in a way that the relationships between them respect different generations of the World (through integrate)? Any other ideas? Thanks, Luke [1] Once as SF () (Position,Velocity), and again as SF PhysIn PhysOut where PhysIn = (Impulse,Momentum) and PhysOut = (Position,Velocity). [2] Using the arrow joinSF :: SF (Event (SF [a] a)) [a], and other similar style functions taking streams of SF events... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Progress indications
On Thu, 29 Nov 2007, Thomas Hartman wrote: but there's no risk using trace is there? 'trace' is really only for debugging. It should not appear in shipped libraries or programs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Functional dependencies / monotonic boolean functions in Haskell
I know there are Haskell people who are busy with hardware verification and relational algebra. (as indicated by http://www.haskell.org/haskellwiki/Relational_algebra http://www.haskell.org/haskellwiki/Applications_and_libraries/Hardware_verification ) Is there a Haskell library for working with functional dependencies, namely for computing minimal keys given a set of functional dependencies? Since this problem can also be posed in terms of monotonic boolean functions a library for processing monotonic boolean functions might also help. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] A tale of Project Euler
On Fri, 30 Nov 2007, Bulat Ziganshin wrote: Hello Andrew, Thursday, November 29, 2007, 9:43:48 PM, you wrote: Fifth thing: better use an STUArray, don't drag IO in if it's not necessary. I don't understand the ST monad. it's just a subset of IO monad, with renamed operations http://www.haskell.org/haskellwiki/Monad/ST ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Categories list in French (off-topic?)
Maurício wrote: Hi, I'm learning about categories using Saunders Mac Lane book. I'm also learning French. Do you guys know of a nice French mailing list, or forum, where people discuss about categories (and where beginners are accepted)? newsgroup: fr.sci.math a+, ld. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Over-allocation
Gracjan Polak wrote: My program is eating too much memory: copyfile source.txt dest.txt +RTS -sstderr Reading file... Reducing structure... Writting file... Done in 20.277s 1,499,778,352 bytes allocated in the heap 2,299,036,932 bytes copied during GC (scavenged) 1,522,112,856 bytes copied during GC (not scavenged) 17,846,272 bytes maximum residency (198 sample(s)) 2860 collections in generation 0 ( 10.37s) 198 collections in generation 1 ( 8.35s) 50 Mb total memory in use INIT time0.00s ( 0.00s elapsed) MUT time1.26s ( 1.54s elapsed) GCtime 18.72s ( 18.74s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time 19.98s ( 20.28s elapsed) ooh. May I have your program (the unfixed version) for benchmarking the parallel GC? Cheers, Simon, currently collecting space leaks ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Waiting for thread to finish
On Nov 28, 2007 11:07 PM, Maurício [EMAIL PROTECTED] wrote: Sorry, I don't agree. I try to write things in a way that when you read it you can get an intuition on why it's doing what it's doing; even when the That's what comment are for :) generate. So, instead of checking if threads have finished, I decided to check if files exist and are available for writing. When I read 'takeMVar Checking a file is non blocking, right ? So you have to loop until the file becomes available. taking a MVar, on the other hand, blocks your thread until the other one finishes, without using cpu time, etc. know of a benchmark where the task is some kind of situation where you actually get a result faster by using threads than by using a single thread? Threads won't give you a speedup unless you run the program on a multi-core/multi-proc machine. They help making the program simpler, IMHO. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fast Array operations: foldl, drop
On Fri, 30 Nov 2007, Ketil Malde wrote:
Bryan O'Sullivan [EMAIL PROTECTED] writes:
For higher dimensions, there are enough options in terms of
traversal direction and what exactly e.g. a fold should fold over
(single elements? lower-dimensional slices?) that a sensible API
doesn't exactly leap out.
How about a 'reduce' instead of 'foldl1'? I think that if you require
a commutative operator, the order doesn't matter (except for
efficiency and possible rounding issues, I guess).
For what I have in mind the order of execution matters.
I also think now that slices for higher dimensional arrays are useful,
anyway. If you choose a subrange of indices in the most significant
dimension this would be possible without copying. It would be also
possible to 'reshape' (in MatLab terms) an array without copying, as long
as the number elements remain the same. So you could first transform an
array of arbitrary dimension to a two-dimensional one, say
reshape :: (j,j) - Array i a - Array j a
specialised to
reshape :: ((i,(j,k)), (i,(j,k))) - Array (i,j,k) a - Array (i,(j,k)) a
then you could slice with respect to the first (most significant)
dimension.
slice :: (i,i) - Array (i,j) a - Array (i,j) a
{- | slice with respect to the first dimension and
start indices of the slice with number of type 'k' -}
sliceRemap :: (i,i) - k - Array (i,j) a - Array (k,j) a
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New slogan for haskell.org
The Haskell code works with arbitrary precision
Integer, the C code with a fixed size int.
This is also a work for a library (BTW like Haskell does), you can use
gmp or mpfr. This will just add one line to store x/2 in y and avoid its
recomputation. You will also have to switch from intset to set. And
there one can start to see the difference. The code refactoring will be
longer since C doesn't support parametric polymorphism nor operator
overloading.
Yes, Haskell is just great, so many things are hard-wired. Even if you
use arbitrary precision Integer and appropriate set implementations,
there is still no infinite, lazy list that avoids recomputation... I
guess your C code either uses some non-standard includes or does not fit
on a single page anymore.
Just for the record: Using a 64-bit machine (1.5GHz Itanium2) and a well
scaling intset (Judy1), (something like) your C code calculates:
* within 1GB and in about 25 mins:
a_{892163852} = 11314755057
max seen so far:
a_{846081651} = 770163004735488 (50 bit)
* and within 32GB and in about 22 hours:
a_{28515445370} = 165480993670
max seen so far:
a_{25880571766} = 32905425960566784 (55 bit)
I guess that a Haskell program that verifies these values will depend on
an external intset implementation. Or uses another data structure, for
example some Set_of_Intervals...
/BR, Mirko Rahn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell interface file (.hi) format?
Claus Reinke [EMAIL PROTECTED] writes: you might find it easier to use GHCi's :browse command While ghc -e works, this no longer work within GHCi? Prelude :b Control.Concurrent.MVar module 'Control.Concurrent.MVar' is not interpreted -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] A tale of Project Euler
Hello Sebastian, Friday, November 30, 2007, 11:31:22 AM, you wrote: I don't see Data.Array.Base documented anywhere. (How did you know it exists?) i use library sources as reference. it allows to study implementation and learn good programming style -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A tale of Project Euler
Sebastian Sylvan wrote: On Nov 29, 2007 9:10 PM, Andrew Coppin [EMAIL PROTECTED] wrote: How do you avoid accidentally recomputing the list multiple times? What do you mean? It's exactly the same as your original program but with ST instead of IO? Why would it get accidentally recomputed in this scenario and not before? Because before the moment when it gets executed relative to the main I/O thread is explicitly defined, and now it isn't. I don't see Data.Array.Base documented anywhere. (How did you know it exists?) Hmm.. I don't remember. But now you know too! :-) I think it may be a secret GHC library that you're not supposed to know about... Hmm. Secret... library... How do you guys find out about all this stuff? (And if it's secret, should we be playing with it?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hit a wall with the type system
On Thu, Nov 29, 2007 at 04:25:43PM -0800, Dan Weston wrote: I must be missing something, because to me the contract seems to be much simpler to express (than the Functor + Isomorphism route you seem to me to be heading towards): ... diff f a = if dx == dx' then error Zero denom else dydx where a' = addEpsilon a dx = a' `takeAway` a dx' = a`takeAway` a' dy = f a' `takeAway` f a dydx = dy `divide` dx But this is just a finite-difference derivative, which is generally accurate to... well, a lot less than an analytic derivative. e.g try computing diff cos 1e-30 you'll get a garbage answer, while AD or symbolic differentiation will give you the correct answer, 1e-30. So for derivatives you actually intend to use, it's much better to use AD or symbolic differentiation, or just compute the derivatives by hand. Anything but finite difference (except at a carefully examined check for better derivatives). -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Strings and utf-8
Am I wrong to think that UTF8 should be THE standard? I believe it can encode anything encoded by other encodings. All the UTF-* encodings can encode the same code points. There are different trade offs though. Can't we consider non-utf8 text as legacy? I don't like that word, but I do think it is the right way to go for text. If you know your text has a diferent encoding, just use 'iconv' to convert it, or a special Haskell library for conversion. The important thing (I think) is to have an abstract concept that encompasses all the necessary characters (i.e. Unicode) and then a few well specified encodings with different trade offs. A Unicode Haskell library should handle at least a few of them (and more importantly keep track of the encoding.) -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Strings and utf-8
Language of messages is quite different from language of a file you read. (...) Yes, it's a fundamental limitation of the unix locale system and multi-user systems. However it's no less wrong than just picking UTF8 all the time. (...) Am I wrong to think that UTF8 should be THE standard? I believe it can encode anything encoded by other encodings. Can't we consider non-utf8 text as legacy? I don't like that word, but I do think it is the right way to go for text. If you know your text has a diferent encoding, just use 'iconv' to convert it, or a special Haskell library for conversion. That will make life difficult for a few, but make life a lot easier for programers and users. Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rigid type-var unification failure in existentials used with parametrically polymorphic functions
On Nov 30, 2007 12:20 PM, Pablo Nogueira [EMAIL PROTECTED] wrote: A question about existential quantification: Given the existential type: data Box = forall a. B a [...] I cannot type-check the function: mapBox :: forall a b. (a - b) - Box - Box --:: forall a b. (a - b) - (exists a.a) - (exists a.a) mapBox f (B x) = B (f x) However, at first sight |f| is polymorphic so it could be applied to any value, included the value hidden in |Box|. f is not polymorphic here; mapBox is. Of course, this works: mapBox :: (forall a b. a - b) - Box - Box mapBox f (B x) = B (f x) Here f is polymorphic. Because it's a tautology: given a proof of a - b for any a or b I can prove Box - Box. However the only value of type forall a b. a - b is bottom. Yes, but that is only because your Box type is trivial. It can contain any value, so you can never extract any information from it. Let's detrivialize your box and see where that leads us: data Box = forall a. (Num a) = B a Then: mapBox :: (forall a b. (Num a) = a - a) - Box - Box Should work fine, and there are functions which you can give to mapBox which are not bottom. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rigid type-var unification failure in existentials used with parametrically polymorphic functions
Stupid of me: Isn't the code for mapBox :: forall a. (a - a) - Box - Box encoding the proof: Assume forall a. a - a Assume exists a.a unpack the existential, x :: a = T for some T apply f to x, we get (f x) :: a pack into existential, B (f x) :: exists a.a Discharge first assumption Discharge second assumption The error must be in step 3. Sorry if this is obvious, it's not to me right now. The proof outlined is that of (forall a. a - a) - Box - Box, my apologies. We have to prove a universally quantified formula and that requires forall-introduction. If someone has the proof in the tip of their fingers, I'm grateful if you could let me know. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New slogan for haskell.org
On Nov 30, 2007 1:30 AM, Ivan Miljenovic [EMAIL PROTECTED] wrote: Speaking of Stackless Python, its homepage (http://www.stackless.com/) has a rather nice layout... maybe slightly less emphasis on the About section, but there you've got the links, the info and the news all on the one page. I really like the friendly look of Ruby's homepage: http://www.ruby-lang.org/en/ * There's an interpreter download button in a high visibility position. * Visible news. * It's pretty! * A very short introduction. Ruby is... * The most important links (documentation, libraries, community, etc.) are available to the right. I like the fact that there are no subcategories at this point. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Editorial error or something meaningful?
Hi taken from ch.8.3 in the Hutton book: Whereas return v always succeeds, the dual parser failure always fails regardless of the contents of the input string: The dual parser failure? Cheers, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Rigid type-var unification failure in existentials used with parametrically polymorphic functions
A question about existential quantification: Given the existential type: data Box = forall a. B a in other words: -- data Box = B (exists a.a) -- B :: (exists a.a) - Box I cannot type-check the function: mapBox :: forall a b. (a - b) - Box - Box --:: forall a b. (a - b) - (exists a.a) - (exists a.a) mapBox f (B x) = B (f x) Nor can I type check: mapBox :: forall a. (a - a) - Box - Box --:: forall a. (a - a) - (exists a.a) - (exists a.a) mapBox f (B x) = B (f x) The compiler tells me that in both functions, when it encounters the expression |B (f x)|, it cannot unify the universally quantified |a| (which generates a rigid type var) with the existentially quatified |a| (which generates a different rigid type var) -- or so I interpret the error message. However, at first sight |f| is polymorphic so it could be applied to any value, included the value hidden in |Box|. Of course, this works: mapBox :: (forall a b. a - b) - Box - Box mapBox f (B x) = B (f x) Because it's a tautology: given a proof of a - b for any a or b I can prove Box - Box. However the only value of type forall a b. a - b is bottom. This also type-checks: mapBox :: (forall a. a - a) - Box - Box mapBox f (B x) = B (f x) When trying to give an explanation about why one works and the other doesn't, I see that, logically, we have: forall a. P(a) = Q implies (forall a. P(a)) = Q when a does not occur in Q. The proof in our scenario is trivial: p :: (forall a. (a - a) - (Box - Box)) - (forall a. a - a) - Box - Box p mapBox f b = mapBox f b However, the converse is not true. Yet, could somebody tell me the logical reason for the type-checking error? In other words, how does the unification failure translate logically. Should the first mapBox actually type-check? Isn't the code for mapBox :: forall a. (a - a) - Box - Box encoding the proof: Assume forall a. a - a Assume exists a.a unpack the existential, x :: a = T for some T apply f to x, we get (f x) :: a pack into existential, B (f x) :: exists a.a Discharge first assumption Discharge second assumption The error must be in step 3. Sorry if this is obvious, it's not to me right now. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rigid type-var unification failure in existentials used with parametrically polymorphic functions
mapBox :: forall a b. (a - b) - Box - Box --:: forall a b. (a - b) - (exists a.a) - (exists a.a) mapBox f (B x) = B (f x) However, at first sight |f| is polymorphic so it could be applied to any value, included the value hidden in |Box|. f is not polymorphic here; mapBox is. I see, it's a case of not paying proper attention. I presume this will reflect in the imposibility of introducing the forall when trying to prove the type. Yes, but that is only because your Box type is trivial. It can contain any value, so you can never extract any information from it. Indeed, I was just trying to play with unconstrained existentials. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Design of a Physics Interface
On Fri, 30 Nov 2007, Luke Palmer wrote: But I can't figure out a good way to represent bodies in this world. I considered: newBody :: (Position,Velocity) - World - (Body,World) Where Body is an ADT with an internal representation of an Integer or something. The problem with this is that (1) there is no way to guarantee that a Body actually exists in a World (which is a minor but still annoying issue), and (2) that there's a possibility that you could make a Body in one world and use it in another and there would be no way to detect the error. Is it ok to have phantom types for Body and World? This would work if the number of worlds is fixed at compile time. newBody :: (Position,Velocity) - World worldId - (Body worldId, World worldId) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A tale of three shootout entries
Sterling Clover wrote: I'm still curious if the pre-calculation of partial sums that I did works well across processors, as I don't see why it shouldn't. My less-strictified version of Don's code is attached, and below are the functions you'll need to insert/replace to make the partial-sums optimization work. Hello Sterling, I've timed your new Fasta with optimised bangs - it's the fastest so far. But the pre-calculated partial-sums version seems to go a bit slower for some unknown reason. Seconds Optimised bangs program11.20compiled ghc --make Optimised bangs program10.73compiled with -O -fglasgow-exts -optc-mfpmath=sse -optc-msse2 -optc-march=pentium4 Partial-sums program 11.97compiled ghc --make Partial-sums program 11.14compiled with -O -fglasgow-exts -optc-mfpmath=sse -optc-msse2 -optc-march=pentium4 This is on my GHC 6.6.1, W2K, Intel Core 2 Duo 2.33GHz machine - same as for the previous timings I gave in this thread. Richard. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A tale of three shootout entries
Was this with tossing the partial sums code into the optimised bangs program? Weird. I wonder if profiling will help explain why? In any case, If nobody comes up with any other tweaks, I'll probably submit the optimised bangs version to the shootout this weekend. --S On Nov 30, 2007 1:30 PM, Richard Kelsall [EMAIL PROTECTED] wrote: Sterling Clover wrote: I'm still curious if the pre-calculation of partial sums that I did works well across processors, as I don't see why it shouldn't. My less-strictified version of Don's code is attached, and below are the functions you'll need to insert/replace to make the partial-sums optimization work. Hello Sterling, I've timed your new Fasta with optimised bangs - it's the fastest so far. But the pre-calculated partial-sums version seems to go a bit slower for some unknown reason. Seconds Optimised bangs program11.20compiled ghc --make Optimised bangs program10.73compiled with -O -fglasgow-exts -optc-mfpmath=sse -optc-msse2 -optc-march=pentium4 Partial-sums program 11.97compiled ghc --make Partial-sums program 11.14compiled with -O -fglasgow-exts -optc-mfpmath=sse -optc-msse2 -optc-march=pentium4 This is on my GHC 6.6.1, W2K, Intel Core 2 Duo 2.33GHz machine - same as for the previous timings I gave in this thread. Richard. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell interface file (.hi) format?
Rob Hoelz wrote: Hello fellow Haskellers, Does anyone know if/where I can find a specification for the .hi files generated by GHC? I ask because I want to write an omni-completion plugin for Vim to make Haskell hacking a bit nicer. You don't want to do that. The .hi files can expose internal implementation details that shouldn't be visible to callers of the library. (E.g., so that GHC can inline things across module boundaries.) What you want to play with is the :browse command. ;-) (Thinking about it... some kind of tool for easily producing a propper interface file that 3rd party tools can use would probably be quite a useful thing... I wonder how hard it would be to implement?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the role of $!?
On Thu, 2007-11-29 at 07:29 +, Thomas Davie wrote: On 29 Nov 2007, at 06:32, PR Stanley wrote: Hi Thanks for the response. JCC: In most languages, if you have some expression E, and when the computer attempts to evaluate E it goes in to an infinite loop, then when the computer attempts to evaluate the expression f(E), it also goes into an infinite loop, regardless of what f is. That's the definition of a strict language. PRS: Does that mean that a strict language is also imperative? Nope, not at all. Just a strict language has slightly fewer programs it can evaluate correctly, as more will loop infinitely. A -pure- strict language. $ does not mean do lazy evaluation it means apply. It's a function, like any other: f ($) x = f x The syntax for defining an infix operator is: f $ x = f x -- or ($) f x = f x The latter form more clearly illustrates something that drives home the fact that ($) is completely trivial, namely, a third definition for ($) is: ($) = id $! is the special case, which means strictly apply. It evaluates its argument first, *then* does the application. This may or may not be faster (and usually isn't, due to evaluating more of the argument): f ($!) x = seq x (f x) Again, f $! x = seq x (f x) -- or x `seq` f x This is the definition according to the Report. seq is a special function that says first fully evaluate my first argument, then return my second argument, it breaks non-strict semantics. Personally, my only use for such functions is a little bit of debugging work [...] seq, or something that forces evaluation, is more important than that (though I wouldn't mind it being put back in a class.) E.g. (assuming no strictness analysis which can't be relied upon to -always- work), both sum = foldr (+) 0 and sum = foldl (+) 0 will stack overflow on a large enough input list, while sum = foldl' (+) 0 will not. The difference between foldl and foldl' is that, via seq, foldl' is a bit more strict. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A tale of Project Euler
On Nov 30, 2007 5:39 PM, Andrew Coppin [EMAIL PROTECTED] wrote: Hmm. Secret... library... How do you guys find out about all this stuff? There's http://www.haskell.org/haskellwiki/Arrays#Unsafe_indexing.2C_freezing.2Fthawing.2C_running_over_array_elements . Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: trouble building unix-2.2.0.0 on cygwin
More elaboration ... 1) i checked HsUnixConfig.h and the macro HAVE_SYS_TIMES_H is set to 1 On Nov 30, 2007 8:28 PM, Galchin Vasili [EMAIL PROTECTED] wrote: Hello, 0) All work being done on cygwin. Version 6.8.1 of ghc. 1) I ran runhaskell Setup.lhs configure and did a tail -f config.log in order to follow the config process. 2) Next I did the build runhaskell Setup.lhs build but there were many include files referenced in HsUnix.h that couldn't be found, e.g. sys/times.h, sys/resources.h, sys/wait.h, 3) I went back through the file config.log and all of the so-called missing include files had supposedly been found during the config process. 4) Next I went to c:/cygwin/usr/include/sys and found all of the so-called missing include files. I am trying to get my confidence level up with respect to the config/build/install (and along with darcs and haddock) process up high so I can make a significant contribution to the Haskell effort. please .. any help will be appreciated. Kind regards, Vasya ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Design of a Physics Interface
On Nov 30, 2007 7:26 PM, Dan Weston [EMAIL PROTECTED] wrote: There seems to be three salient benefits of using arrows, as I read the Abstract and Introduction of Benjamin Lerner, Arrow Laws and Efficiency in Yampa, 2003, http://zoo.cs.yale.edu/classes/cs490/03-04a/benjamin.lerner/ 1) The discipline of using arrows assists in avoiding space-leaks The reasons underlying this...primarily stemmed from the availability of signals as first-class values. [the ugly pain you experience up front saves you chronic pain later. Self-discipline is the key to a happy life.] I experienced the chronic pain in my initial comonadic implementation of FRP. It was pretty, but ran in quaadratic time :-(. To be clear, I am not abandoning arrows in FRP. I am abandoning using an arrow to represent *each* object in favor of moving objects into the value level rather than the signal level. i.e. the following dies: ball :: Position - Velocity - SF PhysIn PhysOut ... In favor of game = proc () - do rec world - integrate initWorld - trajectory world ... I have an idea for an external solution though that I'm going to play with now. I'll report on how it goes :-) Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
