RE: Haskell 98 draft report

1998-12-23 Thread Hans Aberg
> p. 83 'Coercions and Component Extraction' > I find it quite odd that round 3.5 returns 4, but round 2.5 returns 2. > I always thought that round x.5 returns x+1 (instead of the > even integer). >> That's the behaviour in most math books and programming languages Thinking of it, "round" should

Re: Haskell 98 draft report

1998-12-22 Thread Matthew Donadio
Hans Aberg wrote: > Thinking of it, "round" should probably be viewed as a method to convert a > float to another float of less precision (and not a conversion to an > integer) To be picky, rounding a fixed point value to less bits is a very common procedure (at least it is in the DSP world) to a

Re: Haskell 98 draft report

1998-12-22 Thread Hans Aberg
At 17:22 + 1998/12/21, Keith Wansbrough wrote: >This is generally considered the most accurate kind of rounding, since it >avoids cumulative errors. If you get lots of values on the 0.5 boundary, >`round up' gives you an error of +0.5 for each, whereas round-to-even gives >you a mean error of

Re: Haskell 98 draft report

1998-12-21 Thread Lennart Augustsson
> It looks odd to me too. I think this is just taken from some other > standard, so I don't propose to alter it. Were you asleep during your numerical analysis classes? :-) If you always round x.5 up you will get numbers that are a little to big on the average since x.5 is exactly halfway inbe

Re: Haskell 98 draft report

1998-12-21 Thread Keith Wansbrough
> > p. 83 'Coercions and Component Extraction' > > I find it quite odd that round 3.5 returns 4, but round 2.5 returns 2. > > I always thought that round x.5 returns x+1 (instead of the > > even integer). > > That's the behaviour in most math books and programming languages > > It looks odd to m

RE: Haskell 98 draft report

1998-12-21 Thread Simon Peyton-Jones
> p. 83 'Coercions and Component Extraction' > I find it quite odd that round 3.5 returns 4, but round 2.5 returns 2. > I always thought that round x.5 returns x+1 (instead of the > even integer). > That's the behaviour in most math books and programming languages It looks odd to me too. I thi

RE: Haskell 98 draft report

1998-12-02 Thread Simon Peyton-Jones
> 3.11 (restricting monad comprehensions to list comprehensions) > Generally I don't like to lose generality without a strong > necessity. Can someone refer me to the rationale for that change? > I've found only a reference that there can be confusing (for people > in the process of learning Haske

Re: Haskell 98 draft report

1998-12-02 Thread Felix Schroeter
Hello! On Mon, Nov 23, 1998 at 08:42:39AM -0800, Simon Peyton-Jones wrote: > I have now completed the draft report on Haskell 98, both language and > libraries. I have dated them both 'Draft: 1 Dec 1998'. > [...] You wrote "comments welcome", so I'll write some, based on the list of changes.