Re: RFC: Higher resolution time values
Dan Sugalski <[EMAIL PROTECTED]> writes: >>Why - the 1/10 of second is not exact anyway (unless you happen to >>have an atomic clock in an appropriate physical enviroment attached to >>your machine). A double's mantissa is better than your typical oscillator. > >While it may not be correct, at least it's exact. The importance of the distinction escapes me - where the errors come from does not matter in the real world. >If we go with an inexact >representation, we run the risk of accumulating errors and eventually >ending up with a number that's both inexact and incorrect. But computer time is always inexact and incorrect - thats why we need NTP. -- Nick Ing-Simmons
Re: RFC: Higher resolution time values
Dan Sugalski wrote: > While it may not be correct, at least it's exact. If we go with an inexact > representation, we run the risk of accumulating errors and eventually > ending up with a number that's both inexact and incorrect. > > Dan Sugalski the even samurai Why not introduce "precision" in a chemistry (or engineering?) sense to our language? Precision is widely misunderstood in computer circles. What if the generic perl6 floating point datum gets not only an exponent and a mantissa, but an exponent, a mantissa, and a precision? Those who need incredible precision could crank it up, those who need correct precision would have it (provided all their tools are precision-compliant) -- David Nicol 816.235.1187 [EMAIL PROTECTED] On hold for tech support since 1995
Re: RFC: Higher resolution time values
At 08:18 PM 8/9/00 +, Nick Ing-Simmons wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > >At 06:16 PM 8/9/00 +, Nick Ing-Simmons wrote: > >>Dan Sugalski <[EMAIL PROTECTED]> writes: > >> >> > >> >>As an engineer I would really like to know when you are going to > >> >>run out of precision in double - that is forty something bits of > mantissa. > >> >>That is more precision than you have in the real world. > >> > > >> >It's not precision, it's resolution. What do you do if your timers return > >> >values in 1/10ths of a second? > >> > >>What is the problem with that? > > > >You can't accurately represent a tenth of a second with floating point > >numbers. > >You could if you made 1/10th second the "unit" of the float internally. > > >If we're going to handle them, we might as well be exact. > >Why - the 1/10 of second is not exact anyway (unless you happen to >have an atomic clock in an appropriate physical enviroment attached to >your machine). A double's mantissa is better than your typical oscillator. While it may not be correct, at least it's exact. If we go with an inexact representation, we run the risk of accumulating errors and eventually ending up with a number that's both inexact and incorrect. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC: Higher resolution time values
Dan Sugalski <[EMAIL PROTECTED]> writes: >At 06:16 PM 8/9/00 +, Nick Ing-Simmons wrote: >>Dan Sugalski <[EMAIL PROTECTED]> writes: >> >> >> >>As an engineer I would really like to know when you are going to >> >>run out of precision in double - that is forty something bits of mantissa. >> >>That is more precision than you have in the real world. >> > >> >It's not precision, it's resolution. What do you do if your timers return >> >values in 1/10ths of a second? >> >>What is the problem with that? > >You can't accurately represent a tenth of a second with floating point >numbers. You could if you made 1/10th second the "unit" of the float internally. >If we're going to handle them, we might as well be exact. Why - the 1/10 of second is not exact anyway (unless you happen to have an atomic clock in an appropriate physical enviroment attached to your machine). A double's mantissa is better than your typical oscillator. -- Nick Ing-Simmons
Re: RFC: Higher resolution time values
At 06:16 PM 8/9/00 +, Nick Ing-Simmons wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > >> > >>As an engineer I would really like to know when you are going to > >>run out of precision in double - that is forty something bits of mantissa. > >>That is more precision than you have in the real world. > > > >It's not precision, it's resolution. What do you do if your timers return > >values in 1/10ths of a second? > >What is the problem with that? You can't accurately represent a tenth of a second with floating point numbers. If we're going to handle them, we might as well be exact. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC: Higher resolution time values
Dan Sugalski <[EMAIL PROTECTED]> writes: >> >>As an engineer I would really like to know when you are going to >>run out of precision in double - that is forty something bits of mantissa. >>That is more precision than you have in the real world. > >It's not precision, it's resolution. What do you do if your timers return >values in 1/10ths of a second? What is the problem with that? -- Nick Ing-Simmons
Re: RFC: Higher resolution time values
Dan Sugalski <[EMAIL PROTECTED]> writes: > At 09:34 PM 8/5/00 +, Nick Ing-Simmons wrote: > >Dan Sugalski <[EMAIL PROTECTED]> writes: > > >At 10:55 AM 8/2/00 +0200, Gisle Aas wrote: > > >>All functions that return time values (seconds since epoch) should use > > >>floating point numbers to return as much precision as the platform > > >>supports. All functions that take time values as arguments should > > >>work for fractional seconds if the platform supports it. > > > > > >Floats have resolution issues that exacerbate sub-second resolution issues. > > > >As an engineer I would really like to know when you are going to > >run out of precision in double - that is forty something bits of mantissa. > >That is more precision than you have in the real world. > > It's not precision, it's resolution. What do you do if your timers return > values in 1/10ths of a second? We might provide some additional API (via some module) where you can make queries about the precision of timers. --Gisle
Re: RFC: Higher resolution time values
Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> writes:
> >At 10:55 AM 8/2/00 +0200, Gisle Aas wrote:
> >>All functions that return time values (seconds since epoch) should use
> >>floating point numbers to return as much precision as the platform
> >>supports. All functions that take time values as arguments should
> >>work for fractional seconds if the platform supports it.
> >
> >Floats have resolution issues that exacerbate sub-second resolution issues.
>
> As an engineer I would really like to know when you are going to
> run out of precision in double - that is forty something bits of mantissa.
> That is more precision than you have in the real world.
If I measure the duration of something with code like this:
my $before = time;
do_something();
my $duration = time - $before;
print "$duration";
Then the use of double will limit the precision to something like 1e-6
sec. I'm not sure that this is enough for the future, but I don't
really know. What is the precision of the real world?
I used this simple script to experiment with double time precision:
$prec = shift || 6;
die if $prec < 2;
my $t = int(time) . "." . ("0" x ($prec - 2));
my $t1 = $t . "34";
my $t2 = $t . "35";
printf "$t2 - $t1 = %.4e\n", $t2 - $t1;
Perhaps this only measure how precise strtod() is?
--Gisle
Re: RFC: Higher resolution time values
At 09:34 PM 8/5/00 +, Nick Ing-Simmons wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > >At 10:55 AM 8/2/00 +0200, Gisle Aas wrote: > >>All functions that return time values (seconds since epoch) should use > >>floating point numbers to return as much precision as the platform > >>supports. All functions that take time values as arguments should > >>work for fractional seconds if the platform supports it. > > > >Floats have resolution issues that exacerbate sub-second resolution issues. > >As an engineer I would really like to know when you are going to >run out of precision in double - that is forty something bits of mantissa. >That is more precision than you have in the real world. It's not precision, it's resolution. What do you do if your timers return values in 1/10ths of a second? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC: Higher resolution time values
Dan Sugalski <[EMAIL PROTECTED]> writes: >At 10:55 AM 8/2/00 +0200, Gisle Aas wrote: >>All functions that return time values (seconds since epoch) should use >>floating point numbers to return as much precision as the platform >>supports. All functions that take time values as arguments should >>work for fractional seconds if the platform supports it. > >Floats have resolution issues that exacerbate sub-second resolution issues. As an engineer I would really like to know when you are going to run out of precision in double - that is forty something bits of mantissa. That is more precision than you have in the real world. -- Nick Ing-Simmons
Re: Ops versus subs (Was: Re: RFC: Higher resolution time values)
At 09:06 PM 8/3/00 +0200, Johan Vromans wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > > > At 07:21 PM 8/3/00 +0200, Johan Vromans wrote: > > >Larry Wall <[EMAIL PROTECTED]> writes: > > > > Theoretically, we'd like to make subs run as fast as ops. > > >I'd say that the distinction between subs and ops should be dropped > > >completely. Ops can be used as subs, subs as ops. The only > > >distinction in the way either is used. > > > > Whoa there. I don't think that's possible. (Not the least of which > > because subs are written in perl, and ops are in some compiled > > language) > >Thats implementation. This is perl6-language. > >My point is that from language perspective, there is (or should be) no >difference. Ah, I was looking bottom up, not top down. (It was the speed comment that got me) Wrong set of glasses, sorry. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Ops versus subs (Was: Re: RFC: Higher resolution time values)
Dan Sugalski <[EMAIL PROTECTED]> writes: > At 07:21 PM 8/3/00 +0200, Johan Vromans wrote: > >Larry Wall <[EMAIL PROTECTED]> writes: > > > Theoretically, we'd like to make subs run as fast as ops. > >I'd say that the distinction between subs and ops should be dropped > >completely. Ops can be used as subs, subs as ops. The only > >distinction in the way either is used. > > Whoa there. I don't think that's possible. (Not the least of which > because subs are written in perl, and ops are in some compiled > language) Thats implementation. This is perl6-language. My point is that from language perspective, there is (or should be) no difference. -- Johan
Re: Ops versus subs (Was: Re: RFC: Higher resolution time values)
At 07:21 PM 8/3/00 +0200, Johan Vromans wrote: >Larry Wall <[EMAIL PROTECTED]> writes: > > > Theoretically, we'd like to make subs run as fast as ops. > >I'd say that the distinction between subs and ops should be dropped >completely. Ops can be used as subs, subs as ops. The only >distinction in the way either is used. Whoa there. I don't think that's possible. (Not the least of which because subs are written in perl, and ops are in some compiled language) Sub calls should be faster than they are, certainly, and its reasonable to split the entersub op up into pieces which the bytecode builder can leave out when needed. Calling into a sub, though, will be slower than calling into something written in XS++, which will be slower than calling into an add-on op, which will be (slightly) slower than calling an op. I've got an PCR on this. :-) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Ops versus subs (Was: Re: RFC: Higher resolution time values)
Larry Wall <[EMAIL PROTECTED]> writes: > Theoretically, we'd like to make subs run as fast as ops. I'd say that the distinction between subs and ops should be dropped completely. Ops can be used as subs, subs as ops. The only distinction in the way either is used. We may need a better way to define function prototypes, though. -- Johan
Re: RFC: Higher resolution time values
At 10:55 AM 8/2/00 +0200, Gisle Aas wrote: >All functions that return time values (seconds since epoch) should use >floating point numbers to return as much precision as the platform >supports. All functions that take time values as arguments should >work for fractional seconds if the platform supports it. Floats have resolution issues that exacerbate sub-second resolution issues. Could we consider: 1) Defining it to be a larger integer (64-bit, say) 2) Defining a smaller resolution (ns, 10ns, or 100ns resolution) 3) Changing the base date to something more meaningful? The smithsonian base date, the astronomical base date, year 0 of the Chinese calendar, or Larry's birthday, say? Heck, Even Jan 1, 1900 would be better. (Or Jan 1, 2000, I suppose) 4) Allowing negative times Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC: Higher resolution time values
Graham Barr writes: : On Wed, Aug 02, 2000 at 11:50:10AM -0400, Sam Tregar wrote: : > On 2 Aug 2000, Gisle Aas wrote: : > : > > =head1 PERL5 PORTABILITY : > > : > > Calls to time() could be transformed to int(time()) when converting : > > perl5 programs to perl6. : > : > Unless there's a: : > : >use HiRes::Time qw(time); : > : > in effect! : : Well theres a difference there when you look at the op tree. That is a call : to a sub, whereas otherwise it is a op. Theoretically, we'd like to make subs run as fast as ops. Larry
Re: RFC: Higher resolution time values
Graham Barr <[EMAIL PROTECTED]> writes: > Well theres a difference there when you look at the op tree. That is a call > to a sub, whereas otherwise it is a op. Isn't that an internals issue? -- Johan
Re: RFC: Higher resolution time values
On Wed, Aug 02, 2000 at 11:50:10AM -0400, Sam Tregar wrote: > On 2 Aug 2000, Gisle Aas wrote: > > > =head1 PERL5 PORTABILITY > > > > Calls to time() could be transformed to int(time()) when converting > > perl5 programs to perl6. > > Unless there's a: > >use HiRes::Time qw(time); > > in effect! Well theres a difference there when you look at the op tree. That is a call to a sub, whereas otherwise it is a op. Graham.
Re: RFC: Higher resolution time values
On 2 Aug 2000, Gisle Aas wrote: > =head1 PERL5 PORTABILITY > > Calls to time() could be transformed to int(time()) when converting > perl5 programs to perl6. Unless there's a: use HiRes::Time qw(time); in effect! -sam
