On Wed, Oct 13, 2004 at 11:27:33PM +0200, Tomasz Zielonka wrote:

BTW, plural form of "child" is "children".

I also make such stupid mistakes, for example "gived" instead of "gave", etc.

In a second glance at childs documentation I saw that you also use "children". Is there some reason to use "childs" as a name for library? Anyway, it looks like a very useful library. Best regards, Tom -- .signature: Too many levels of symbolic links

On Thu, Oct 14, 2004 at 12:36:37AM +0200, Peter Simons wrote:

Benjamin Franksen writes:

...

milliseconds (1/10^6 seconds)

Duh! I meant microseconds of course. Thanks for catching that.

Tomasz, I just took "artistic liberties" with the module's name. Children.hs is too awfully long to type, IMHO. So there is no deeper reason, only laziness. :-)

However, to a native English speak, the word "Childs" doesn't come across as being multiple Children. On first glance, I see it as either Child's, with the apostrophe missing, or I try pronouncing it to sound like the vowel in chilled, and then stumble on the 'ds'. Dave

On Thu, Oct 14, 2004 at 12:36:37AM +0200, Peter Simons wrote:

Benjamin Franksen writes:

...

milliseconds (1/10^6 seconds)

Duh! I meant microseconds of course. Thanks for catching that.

Did you consider using floating-point Timeout type, with its values representing seconds, possibly fractional? This could have some negative performance impact, but would be elegant IMHO. I prepared a darcs patch with such changes, added timeoutDelay which is analogous to threadDelay, but works with Timeout values, and made threadDelay immune to delays which overflow Int with number of microseconds (2^31 microseconds is not such long). Feel free to reject it :) Best regards, Tom -- .signature: Too many levels of symbolic links

Peter Simons writes:

...

Did you consider using floating-point Timeout type, with its values representing seconds, possibly fractional? This could have some negative performance impact, but would be elegant IMHO.

It certainly is more elegant, but I personally would rather not have these calculations from Double to Int in the low-level routines.

I would hope that they are not that expensive. Remembering which API uses ms, us or ns, worrying about overflows, and having problems when a potential resolution of something increases after a few years but the API is stuck with a lower resolution - this disappears when we just use floating-point seconds. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

On 2004-10-14 at 19:46+0200 Peter Simons wrote:

Marcin 'Qrczak' Kowalczyk writes:

...

this disappears when we just use floating-point seconds.

I agree that this is the superior approach. But at the same time I am not comfortable with hiding the actual resolution of the timer behind a Double. I believe this is something a wrapper for 'timeout' should do, not 'timeout' itself.

I haven't been following this discussion closely, but if the resolution of the timer were nanoseconds, wouldn't you run into trouble with Double for periods longer than about four months? 2**53==2**53+1 in Double on this machine. 2**53 is approx 9e15, but a year is only a little over 3e16ns. Integer is the answer. Incidentally, "Childs" is simply a surname. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk

On 2004-10-14 at 21:35+0200 Marcin 'Qrczak' Kowalczyk wrote:

Jon Fairbairn writes:

...

I haven't been following this discussion closely, but if the resolution of the timer were nanoseconds, wouldn't you run into trouble with Double for periods longer than about four months?

If you are going to wait four months, you don't care about nanoseconds.

No? Are you sure? To wait forty months expecting two things to happen ten nanoseconds apart and then have them happen simultaneously would be annoying. Right now, a nanosecond doesn't amount to a long time on a CPU, but I'm not willing to bet that it'll stay that way forever. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk

Tomasz Zielonka writes:

On Thu, Oct 14, 2004 at 09:09:04PM +0100, Jon Fairbairn wrote:

...

...

If you are going to wait four months, you don't care about nanoseconds.

No? Are you sure? To wait forty months expecting two things to happen ten nanoseconds apart and then have them happen simultaneously would be annoying.

Hmmm, that's right. Perhaps it would be best to use some fixed-point type with unbounded integral part, like those used for representing currency, but not necessarily decimal.

I'd go with ratios. Haskell has a built-in type, and they can give you as many digits of precision as you need--unless you're dealing with an irrational timeout value. -- David Menendez | "In this house, we obey the laws http://www.eyrie.org/~zednenem | of thermodynamics!"

The usage of ratio is also too slow. The disadvantage of Double and Float is that often the result of computation isn't correct. For example if we have a lot of small values then its sum will not be precise. This is very important in financial applications. For such reason in SQL is defined decimal data type. In MS COM there are DECIMAL and in .NET there are decimal types. I would like to see Decimal type in Haskell too. In the Mono project there is a free and portable implementation of decimals which we can adopt in Haskell. The Ratio type is simply too expensive in many cases. Of course to adopt Decimal properly in Haskell we need to have support in the compiler too. Cheers, Krasimir --- Tomasz Zielonka wrote:

On Fri, Oct 15, 2004 at 01:15:16AM -0400, David Menendez wrote:

...

Tomasz Zielonka writes:

...

Hmmm, that's right. Perhaps it would be best to use some fixed-point type with unbounded integral part, like those used for representing currency, but not necessarily decimal.

I'd go with ratios. Haskell has a built-in type, and they can give you as many digits of precision as you need--unless you're dealing with an irrational timeout value.

Unfortunately, they have the unpleasant tendency that after many operations even if the absolute value is small, the two integers that constitute the ratio can be very big. That's why (I think) it's not that good idea to solve linear equation systems using unbounded ratios.

Why not use typeclasses and let the user decide?

Best regards, Tom

-- .signature: Too many levels of symbolic links _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com

Tomasz Zielonka writes:

On Fri, Oct 15, 2004 at 01:15:16AM -0400, David Menendez wrote:

...

I'd go with ratios. Haskell has a built-in type, and they can give you as many digits of precision as you need--unless you're dealing with an irrational timeout value.

Unfortunately, they have the unpleasant tendency that after many operations even if the absolute value is small, the two integers that constitute the ratio can be very big. That's why (I think) it's not that good idea to solve linear equation systems using unbounded ratios.

No argument from me. But the original point had to do with setting a timeout value that retained microsecond precision after four months. Pretty much *any* way of doing this amounts to overkill. -- David Menendez http://www.eyrie.org/~zednenem/

On Thu, Oct 14, 2004 at 08:30:00PM +0100, Jon Fairbairn wrote:

I haven't been following this discussion closely, but if the resolution of the timer were nanoseconds, wouldn't you run into trouble with Double for periods longer than about four months? 2**53==2**53+1 in Double on this machine. 2**53 is approx 9e15, but a year is only a little over 3e16ns.

Integer is the answer.

Obviously, any counter will have to be implemented with discrete values. Floating point is actually handy here, since it allows the precision to change depending on the scale. It is important to implement it right, though. Dave