On Mon, Feb 19, 2007 at 12:52:10PM -0800, Shankar Unni wrote:
> Andrew Makhorin wrote:
>
> >{ double t0 = get_time(), t1 = get_time();
>
> [Maybe OT?]
>
> 1. I can't remember if C guarantees that comma-separated *declarations*
> are initialized in order or not.. And to think I used to be
Andrew Makhorin wrote:
{ double t0 = get_time(), t1 = get_time();
[Maybe OT?]
1. I can't remember if C guarantees that comma-separated *declarations*
are initialized in order or not.. And to think I used to be an ANSI C
guru :-(.
2. The reason that the "t0 > t1" fails, but t0 and t
On 16 February 2007 13:36, Andrew Makhorin wrote:
> The irony is that I usually give the same standard explanation about
> floating-point to people who do not understand that :) *Unfortunately*,
> you are right, and the difference really appears because the second
> value returned by get_time bei
On 2/16/07, Andrew Makhorin wrote:
Nevertheless, you agree that if t0 > t1 then t0 - t1 cannot be exact
zero in *any* floating-point model, don't you? Even if optimization is
used, the compiler must not arbitrarily change the precision of the
same floating-point variable.
The -ffloat-store com
Thank you for your response.
>> But then I would like to know why comparison of two floating-point
>> numbers leads to different results: t0 is *exactly* the same as t1,
>> nevertheless the condition t0 > t1 is true (sometimes). That is the
>> question.
>
> The multiplier 1e-6 cannot be represent
--On 16 February 2007 04:12 +0300 Andrew Makhorin <[EMAIL PROTECTED]> wrote:
double get_time(void)
{ struct timeval tv;
gettimeofday(&tv, NULL);
return (double)tv.tv_sec + 1e-6 * (double)tv.tv_usec;
}
I would be suspicious of floating-point rounding errors here for the
original p
On Fri, Feb 16, 2007 at 04:12:31AM +0300, Andrew Makhorin wrote:
> > I would be suspicious of floating-point rounding errors here for the
> > original problem you described. Why don't you try a test case that just
> > checks if one tv is ever less than a previous tv, without the conversions.
>
>
> I would be suspicious of floating-point rounding errors here for the
> original problem you described. Why don't you try a test case that just
> checks if one tv is ever less than a previous tv, without the conversions.
Because I could not reproduce the bug concerning gettimeofday out of
a com
Andrew Makhorin wrote:
> double get_time(void)
> { struct timeval tv;
> gettimeofday(&tv, NULL);
> return (double)tv.tv_sec + 1e-6 * (double)tv.tv_usec;
> }
I would be suspicious of floating-point rounding errors here for the
original problem you described. Why don't you try a tes
I would like to add to my previous message that the test fails
*sometimes*, approx. once for 7-8 runs.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:
>>>I detected a strange bug in the standard function gettimeofday.
>>>It *sometimes* reports the time which being expressed as the integer
>>>number of milliseconds is *less* than the time obtained *earlier* with
>>>the same function.
>>If you mean that you call gettimeofday twice and you get diff
Andrew Makhorin wrote:
>> Hi,
>>
>> I detected a strange bug in the standard function gettimeofday.
>> It *sometimes* reports the time which being expressed as the integer
>> number of milliseconds is *less* than the time obtained *earlier*
>> with the same function.
>>
>> The expression 100 *
Andrew Makhorin wrote:
I detected a strange bug in the standard function gettimeofday.
It *sometimes* reports the time which being expressed as the integer
number of milliseconds is *less* than the time obtained *earlier* with
the same function.
...how often is "often"? Also what version of Win
On Mon, 12 Feb 2007, Carlo Florendo wrote:
> Windows could be accurate up to 15 ms or perhaps a little bit more.
> However, it is very difficult to achieve less than 15 ms or microsecond
> accuracy with windows due to the limitation on the OS itself. Our
> extensive tests on windows clocks and ti
On Mon, Feb 12, 2007 at 11:00:38AM +0800, Carlo Florendo wrote:
>Andrew Makhorin wrote:
>>Hi,
>>
>>I detected a strange bug in the standard function gettimeofday.
>>It *sometimes* reports the time which being expressed as the integer
>>number of milliseconds is *less* than the time obtained *earlie
Andrew Makhorin wrote:
Hi,
I detected a strange bug in the standard function gettimeofday.
It *sometimes* reports the time which being expressed as the integer
number of milliseconds is *less* than the time obtained *earlier* with
the same function.
If you mean that you call gettimeofday twice
On 2/11/07, Christopher Faylor wrote:
On Sun, Feb 11, 2007 at 07:20:14PM +0300, Andrew Makhorin wrote:
>Hi,
>
>I detected a strange bug in the standard function gettimeofday.
>It *sometimes* reports the time which being expressed as the integer
>number of milliseconds is *less* than the time obta
On Sun, Feb 11, 2007 at 07:20:14PM +0300, Andrew Makhorin wrote:
>Hi,
>
>I detected a strange bug in the standard function gettimeofday.
>It *sometimes* reports the time which being expressed as the integer
>number of milliseconds is *less* than the time obtained *earlier* with
>the same function.
Hi,
I detected a strange bug in the standard function gettimeofday.
It *sometimes* reports the time which being expressed as the integer
number of milliseconds is *less* than the time obtained *earlier* with
the same function.
The expression 100 * tv.tv_sec + tv.tv_usec is calculated in
64-bi
19 matches
Mail list logo
