I have rewritten the Huffman benchmark (see
http://cse.unl.edu/~sjanssen/huffman.hs), resulting in a significant
performance increase. On my computer it completes one iteration in
about 0.9 seconds. In comparison, the O'Caml version takes around 3.1
seconds. These samples seem to indicate that
It seems I have spoken too soon!
There is one infidelity in my implementation: the program writes the
output once per iteration, and this IO is included in the measured
time.
Due to a few changes, this caveat no longer applies. As a result
Haskell performs just a bit better. The code is
On Fri, Mar 24, 2006 at 06:54:54PM +, Aaron Denney wrote:
Without breaking compatibility?
But class instances become invalid if the hierarchy is modified.
No, compatibility will be broken. Hopefully not for most uses -- I
don't think most people define new instances, and those that do
On Mar 26, 2006, at 4:35 PM, Daniel McAllansmith wrote:
[Discussion of positive integers and Words]
I was thinking about several things in this thread, torsors, overflow
semantics, bounds checking...
I wonder if there would be any merit in being able to define
constrained
subsets of
For example, take UNIX nice levels -20 to 19. You could have
data ConstrainedInteger = CI {distToMax :: Natural, distToMin :: Natural}
this would ensure only the 40 integers can be represented.
Then you could have _something_ that defined what happened on overflow,
whether it wraps,
On Mon, Mar 27, 2006 at 05:02:20AM -0800, John Meacham wrote:
well, in interfaces you are going to end up with some specific class or
another concretely mentioned in your type signatures, which means you
can't interact with code that only knows about the alternate class. like
genericLength
Doesn't Ada have constrained number types which have similar behaviour?
Yes. Just for comparison, the behaviour of the Ada number is to throw
an exception at runtime if a number overflows its bounds. If these
checks can be eliminated statically, then they are. If an operation
will always give a
On Mon, 27 Mar 2006, Neil Mitchell wrote:
Doesn't Ada have constrained number types which have similar behaviour?
Yes. Just for comparison, the behaviour of the Ada number is to throw
an exception at runtime if a number overflows its bounds. If these
checks can be eliminated statically, then
Hi
Thanks to everyone that have helped, the runtimes for the haskell
programs have decreased significantly, presently they look like this
compared to O'Caml:
Benchmark haskell ocaml
drop3 5.786 3.151
five11 8.657 7.692
huffman 7.134 18.593
uudecode
On Mon, Mar 27, 2006 at 02:53:58PM +1200, Daniel McAllansmith wrote:
Is there a consensus on how anticipatable failure situations should be
handled?
There was a thread, haskell programming guidelines, from 2006-02-25 where
John Meacham and Cale Gibbard had a bit of back-and-forth about
How do I perform multiple computations on a long lazy list without introducing a space leak?Doing a single computation like this works great:
f = show . filter ( 1)But if I do something like this: f lst = show (filter ( 1) lst, filter ( 2) lst)then it looks like GHC won't garbage collect list
Hi Greg,
But if I do something like this:
f lst = show (filter ( 1) lst, filter ( 2) lst)
then it looks like GHC won't garbage collect list elements
until the first
filter has completely finished
There is a very good reason for this, show (a,b) is essentially
show (a,b) = ( ++ show a
hold a part of the data in memory while you show the first one,Here would be a better example then. f lst = show (sum (filter ( 1) lst), sum (filter ( 2) lst))It ought to be *possible* to compute both operations without holding onto any of the list elements.
In the imperative world, you'd say:
Hi, folks.
I've got a working class and instances thereof. I would now like to change
the class such that error behaviour is specified by MonadError, for the
moment throwing String errors. When I try to add MonadError into the types I
eventually hit the requirement for
John Hughes wrote:
...
Indeed, error messages in common cases would be worsened significantly,
because as Ross says, common errors (such as forgetting a parameter in a
recursive call) would lead to legal definitions that cause a type error
when applied. Partly for this reason, OCaml
Hi,
Here would be a better example then.
f lst = show (sum (filter ( 1) lst), sum (filter ( 2) lst))
I suspected that you actually wanted to do something cleverer with
the list, for the sake of argument, I'm going to change 1 to p1 and
2 to p2 - to show how this can be done in the general
Neil Mitchell wrote:
I suspected that you actually wanted to do something cleverer with
the list, for the sake of argument, I'm going to change 1 to p1 and
2 to p2 - to show how this can be done in the general case. With the
specific information you know about 1 vs 2 you can do better, but
Thanks Neil. How do I add in another ~10 computations, or map a list of a 100 computations to the same input?Isn't there a way to do this without one computation having to be aware of the other? This feels like a situation Parsec users would find themselves in all the time. When you have a bunch
Thanks Neil. How do I add in another ~10 computations, or map a list of a
100 computations to the same input?
Isn't there a way to do this without one computation having to be aware of
the other?
I guess they have to be aware at some level, perhaps arrows generalise
the awareness they need,
On 3/28/06, Neil Mitchell [EMAIL PROTECTED] wrote:
This feels like a situation Parsec users would find themselves in all the
time. When you have a bunch of parsers in a 'choice', does the start of the
input stream linger until the last parser is executed?
No, as soon as one token is
On Tuesday 28 March 2006 11:12, Daniel McAllansmith wrote:
Hi, folks.
I've got a working class and instances thereof. I would now like to change
the class such that error behaviour is specified by MonadError, for the
moment throwing String errors. When I try to add MonadError into the types
I'm working through Pierce's Types and Programming Languages on my own. I'm attempting to write the typecheckers in Haskell, instead of ML. However, when it comes to his eval function, I'm a little stuck. The original is
let rec eval t = try let t' = eval1 t in eval t' with NoRuleApplies - tWhere
Steve Downey wrote:
It makes eval1 a bit more complicated, and not as straightforward
translation from the type system being described, though.
e.g reducing If looks more like
eval1 (TmIfExpr t1 t2 t3) =
let t1' = eval1 t1
in case t1' of
{ Just t1'' - Just $ TmIfExpr t1''
On Mon, Mar 27, 2006 at 03:10:18PM -0800, Greg Fitzgerald wrote:
hold a part of the data in memory while you show the first one,
Here would be a better example then.
f lst = show (sum (filter ( 1) lst), sum (filter ( 2) lst))
It ought to be *possible* to compute both operations
Tomasz Zielonka wrote:
I wonder if it would be possible to remove the space-leak by running both
branches concurrently, and scheduling threads in a way that would
minimise the space-leak. I proposed this before
http://www.haskell.org/pipermail/haskell-cafe/2005-December/013428.html
Steve Downey wrote:
] I'm considering changing eval1 to be ArithExpr-Maybe ArithExpr
]
] If the expression is reducible, then I return Just t, and if it's not
] reducible, then Nothing
]
] It makes eval1 a bit more complicated, and not as straightforward
] translation from the type system being
26 matches
Mail list logo
