Re: Hugs Humor

Jon Fairbairn comments //Steffen Mazanek//: Prelude> 0.1::Rational 13421773 % 134217728 Prelude> 13421773/134217728 0.1 I do not know how this fraction is calculated, but it does not fit my expectations :-) Remember that internally arithmetic is binary, and that 0.1 can't be expressed exactly as

Re: Hugs Humor

On Monday, 2003-07-07, 01:37, CEST, Andrew J Bromage wrote: > [...] > On Sat, Jul 05, 2003 at 07:43:18PM +0200, Steffen Mazanek wrote: > > Prelude> 0.1::Rational > > 13421773 % 134217728 > > That's allowed. The Rational only has to be correct to the limit of machine > precision. (Incidentally, i

Re: Hugs Humor

On 2003-07-07 at 12:01+0200 Jerzy Karczmarczuk wrote: > Jon Fairbairn comments //Steffen Mazanek//: > > >>Prelude> 0.1::Rational > >>13421773 % 134217728 > >>Prelude> 13421773/134217728 > >>0.1 > >> > >>I do not know how this fraction is calculated, but > >>it does not fit my expectations :-) > >

Re: Hugs Humor

On Mon, Jul 07, 2003 at 12:01:09PM +0200, Jerzy Karczmarczuk wrote: > This is less a bug than a Nessie monster which haunts Hugs > some centuries already, and on Internet the issue has been > discussed at least 4 times. The old, experimental Gofer > Prelude numeric functions were sometimes abominab

Re: Hugs Humor

On Monday, 2003-07-07, 13:05, CEST, Ross Paterson wrote: > [...] > In the case of 0.1::Rational, it shouldn't be using floating point. The > Report says this means fromRational (1%10), i.e. 1%10. In which paragraph of the report is this specified? > [...] Wolfgang _

Re: Hugs Humor

On Mon, Jul 07, 2003 at 01:09:53PM +0200, Wolfgang Jeltsch wrote: > On Monday, 2003-07-07, 13:05, CEST, Ross Paterson wrote: > > In the case of 0.1::Rational, it shouldn't be using floating point. The > > Report says this means fromRational (1%10), i.e. 1%10. > > In which paragraph of the report i

Re: Hugs Humor

Ross Paterson wrote: In the case of 0.1::Rational, it shouldn't be using floating point. The Report says this means fromRational (1%10), i.e. 1%10. Aha. Now I have a little chance to die less naïve. All my conversion proposals are simply out of place, since there should be nothing to convert. An

accessing Haskell-Cafe from oe

Hello,   I discovered recently (thanks google) that Haskell Cafe was also named "fa.haskell", but can't find a news server which would let me access it like any other newsgroup. If someone accesses haskell cafe using a free news server, could he say me which one ?   Thanks by advance.

Re: accessing Haskell-Cafe from oe

Jeff Aimt writes: > [haskell-cafe via news server] You can access the mailing list via NNTP under the name gmane.comp.lang.haskell.cafe on news.gmane.org. See for further details. Peter ___ Haskell-Cafe mailing list [EMAIL PRO

Representing cyclic data structures efficiently in Haskell

What is the best way to represent cyclic data structures in Haskell? Lists are trivial. Trees are trivial. But what if the thing you're trying to represent is shaped like an electronic circuit, with a (possibly large) number of nodes connected by multiple arrows to other nodes? In an imperative

RE: Representing cyclic data structures efficiently in Haskell

>From reading your message, it seems you want a graph library of sorts. I've used FGL extensively and found it to be very nice. It even provides both a purely functional interface as well as an imperative-esque interface. It also comes with a bunch of standard algorithms built in, though I don't

Re: Representing cyclic data structures efficiently in Haskell

Hi Sarah, Representing cyclic structures is indeed somewhat tricky in a pure functional language. The obvious representation (representing the link structure implicitly in an algebraic data type) doesn't work, because you can't obvserve cycles. I recommend checking out two pieces of work in t

Re: Representing cyclic data structures efficiently in Haskell

Why not just use a GUID to represent each node. Then a C pointer just becomes a GUID in a tuple alongside the node. The C pointer approach is just a method to have the memory system dole out GUIDs. And it can be generalised. Then all the tuples could be inserted in a hash table on the GUID compone

Re: Representing cyclic data structures efficiently in Haskell

From reading your message, it seems you want a graph library of sorts. The important bit is 'of sorts', unfortunately! Most graph libraries I've seen to date (although I must admit that they have been written in C and C++, including one I perpetrated personally) don't really work that well for

Re: Hugs Humor

On 2003-07-07 at 13:40+0200 Jerzy Karczmarczuk wrote: > [...] I believe (still naïvely??) that those socio-psycho-pragmatisms > which played some role in the definition of the language should > be better tuned. If I were to write > > pi = 3.1415926536 :: Rational > > I suppose that I would like t

Re: Representing cyclic data structures efficiently in Haskell

Lazy evaluation means that you can embed nodes directly in a cyclic structure, even though that would appear to create an indefinite regression. In order to detect cycles, one might add a node identifier. Here's a simple example: [[ -- spike-cyclicstructure.hs data Node = Node { nodeid :: Str

Re: Representing cyclic data structures efficiently in Haskell

--- Sarah Thompson <[EMAIL PROTECTED]> wrote: > What is the best way to represent cyclic data structures in Haskell? You _might_ find some useful ideas in Franklyn Turbak and J. B. Wells. Cycle Therapy: A Prescription for Fold and Unfold on Regular Trees. Third International Conference on Princ

Re: Hugs Humor

G'day all. On Mon, Jul 07, 2003 at 12:01:09PM +0200, Jerzy Karczmarczuk wrote: > I don't understand the remark that the internal arithmetic is > binary. Sure, it is, so what? The reason is that you can get the Rational representation even faster than using continued fractions. :-) toFrac ::

Re: Representing cyclic data structures efficiently in Haskell

G'day all. As you note, some kind of indirection is what you want here. On Mon, Jul 07, 2003 at 04:04:17PM +0100, Sarah Thompson wrote: > I would also need to implement efficient indexes into the data structure > -- flat searching will be too slow for non-trivial amounts of data. In > C++, I'd

Re: Representing cyclic data structures efficiently in Haskell

G'day all. On Mon, Jul 07, 2003 at 04:04:17PM +0100, Sarah Thompson wrote: > > I would also need to implement efficient indexes into the data structure > > -- flat searching will be too slow for non-trivial amounts of data. In > > C++, I'd implement one or more external (probably STL-based) ind

Re: Representing cyclic data structures efficiently in Haskell

G'day all. On Mon, Jul 07, 2003 at 04:37:46PM +0100, Sarah Thompson wrote: > I'd considered something like embedding the type in the IO monad, with > links between components implemented as IORefs, but I'd really prefer > something cleaner (pure functional). If the code ends up horribly > comp