lrint(INT_MAX) != INT_MAX

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

lrint(INT_MAX) != INT_MAX

Jan Stary
This is what happens on my relatively current
OpenBSD bbb.stare.cz 6.5 GENERIC#0 armv7 (BeagleBone Black)
OpenBSD ppc.stare.cz 6.5 GENERIC#0 macppc (an old MacMini)

#include <stdint.h>
#include <stdio.h>
#include <math.h>

int
main()
{
        long l;
        double d = INT_MAX;

        l = lrint(d);
        printf("%f is %ld\n", d, l);

        l = lround(d);
        printf("%f is %ld\n", d, l);

        return 0;
}

2147483647.000000 is -1
2147483647.000000 is -1

That doesn't seem right: isn't INT_MAX representable as a long,
even on these machines where sizeof(int) == sizeof(long)?
If so, shouldn't lrint(INT_MAX) == INT_MAX = lround(INT_MAX)?

On i386 (an ALIX), I see

2147483647.000000 is 2147483647
2147483647.000000 is -1

so lrint() returns the expected value but lround() does not.

On the amd64s I have, I see the expected:
2147483647.000000 is 2147483647
2147483647.000000 is 2147483647

Is this a bug or am I missing something obvious?

        Jan

Reply | Threaded
Open this post in threaded view
|

Re: lrint(INT_MAX) != INT_MAX

Boudewijn Dijkstra-3
Op Tue, 30 Jul 2019 17:12:56 +0200 schreef <[hidden email]>:

> This is what happens on my relatively current
> OpenBSD bbb.stare.cz 6.5 GENERIC#0 armv7 (BeagleBone Black)
> OpenBSD ppc.stare.cz 6.5 GENERIC#0 macppc (an old MacMini)
>
> #include <stdint.h>
> #include <stdio.h>
> #include <math.h>
>
> int
> main()
> {
> long l;
> double d = INT_MAX;
>
> l = lrint(d);
> printf("%f is %ld\n", d, l);
>
> l = lround(d);
> printf("%f is %ld\n", d, l);
>
> return 0;
> }
>
> 2147483647.000000 is -1
> 2147483647.000000 is -1
>
> That doesn't seem right: isn't INT_MAX representable as a long,
> even on these machines where sizeof(int) == sizeof(long)?

If it is less than LONG_MAX, then yes.

> If so, shouldn't lrint(INT_MAX) == INT_MAX = lround(INT_MAX)?

If the double type provides enough mantisse (which I think it does on all  
platforms), and if I read a few C standards correctly, then yes.

> On i386 (an ALIX), I see
>
> 2147483647.000000 is 2147483647
> 2147483647.000000 is -1
>
> so lrint() returns the expected value but lround() does not.
>
> On the amd64s I have, I see the expected:
> 2147483647.000000 is 2147483647
> 2147483647.000000 is 2147483647
>
> Is this a bug or am I missing something obvious?

I'd say it's a bug. Also with a float variable and with lrintf/lroundf the  
outcome should ideally be 2147483647.



--
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

Reply | Threaded
Open this post in threaded view
|

Re: lrint(INT_MAX) != INT_MAX

Jan Stary
On Jul 31 14:40:42, [hidden email] wrote:

> Op Tue, 30 Jul 2019 17:12:56 +0200 schreef <[hidden email]>:
> > This is what happens on my relatively current
> > OpenBSD bbb.stare.cz 6.5 GENERIC#0 armv7 (BeagleBone Black)
> > OpenBSD ppc.stare.cz 6.5 GENERIC#0 macppc (an old MacMini)
> >
> > #include <stdint.h>
> > #include <stdio.h>
> > #include <math.h>
> >
> > int
> > main()
> > {
> > long l;
> > double d = INT_MAX;
> >
> > l = lrint(d);
> > printf("%f is %ld\n", d, l);
> >
> > l = lround(d);
> > printf("%f is %ld\n", d, l);
> >
> > return 0;
> > }
> >
> > 2147483647.000000 is -1
> > 2147483647.000000 is -1
> >
> > That doesn't seem right: isn't INT_MAX representable as a long,
> > even on these machines where sizeof(int) == sizeof(long)?
>
> If it is less than LONG_MAX, then yes.

Less than, as in strictly less?
Why? Do you mean <= ?

> > If so, shouldn't lrint(INT_MAX) == INT_MAX = lround(INT_MAX)?
>
> If the double type provides enough mantisse (which I think it does on all
> platforms), and if I read a few C standards correctly, then yes.
>
> > On i386 (an ALIX), I see
> >
> > 2147483647.000000 is 2147483647
> > 2147483647.000000 is -1
> >
> > so lrint() returns the expected value but lround() does not.
> >
> > On the amd64s I have, I see the expected:
> > 2147483647.000000 is 2147483647
> > 2147483647.000000 is 2147483647
> >
> > Is this a bug or am I missing something obvious?
>
> I'd say it's a bug. Also with a float variable and with lrintf/lroundf the
> outcome should ideally be 2147483647.

OK, how can I help debug this?
(The code in lib/libm/src/*rint*.c seems a bit over my head.)

        Jan

Reply | Threaded
Open this post in threaded view
|

Re: lrint(INT_MAX) != INT_MAX

Otto Moerbeek
On Fri, Aug 09, 2019 at 07:19:14PM +0200, Jan Stary wrote:

> On Jul 31 14:40:42, [hidden email] wrote:
> > Op Tue, 30 Jul 2019 17:12:56 +0200 schreef <[hidden email]>:
> > > This is what happens on my relatively current
> > > OpenBSD bbb.stare.cz 6.5 GENERIC#0 armv7 (BeagleBone Black)
> > > OpenBSD ppc.stare.cz 6.5 GENERIC#0 macppc (an old MacMini)
> > >
> > > #include <stdint.h>
> > > #include <stdio.h>
> > > #include <math.h>
> > >
> > > int
> > > main()
> > > {
> > > long l;
> > > double d = INT_MAX;
> > >
> > > l = lrint(d);
> > > printf("%f is %ld\n", d, l);
> > >
> > > l = lround(d);
> > > printf("%f is %ld\n", d, l);
> > >
> > > return 0;
> > > }
> > >
> > > 2147483647.000000 is -1
> > > 2147483647.000000 is -1
> > >
> > > That doesn't seem right: isn't INT_MAX representable as a long,
> > > even on these machines where sizeof(int) == sizeof(long)?
> >
> > If it is less than LONG_MAX, then yes.
>
> Less than, as in strictly less?
> Why? Do you mean <= ?
>
> > > If so, shouldn't lrint(INT_MAX) == INT_MAX = lround(INT_MAX)?
> >
> > If the double type provides enough mantisse (which I think it does on all
> > platforms), and if I read a few C standards correctly, then yes.
> >
> > > On i386 (an ALIX), I see
> > >
> > > 2147483647.000000 is 2147483647
> > > 2147483647.000000 is -1
> > >
> > > so lrint() returns the expected value but lround() does not.
> > >
> > > On the amd64s I have, I see the expected:
> > > 2147483647.000000 is 2147483647
> > > 2147483647.000000 is 2147483647
> > >
> > > Is this a bug or am I missing something obvious?
> >
> > I'd say it's a bug. Also with a float variable and with lrintf/lroundf the
> > outcome should ideally be 2147483647.
>
> OK, how can I help debug this?
> (The code in lib/libm/src/*rint*.c seems a bit over my head.)
>
> Jan
>

A way would be to check with Net and FreeBSD to se if they have
anything fixed in that area.

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: lrint(INT_MAX) != INT_MAX

Boudewijn Dijkstra-3
In reply to this post by Jan Stary
Op Fri, 09 Aug 2019 19:19:14 +0200 schreef Jan Stary <[hidden email]>:

> On Jul 31 14:40:42, [hidden email] wrote:
>> Op Tue, 30 Jul 2019 17:12:56 +0200 schreef <[hidden email]>:
>> > This is what happens on my relatively current
>> > OpenBSD bbb.stare.cz 6.5 GENERIC#0 armv7 (BeagleBone Black)
>> > OpenBSD ppc.stare.cz 6.5 GENERIC#0 macppc (an old MacMini)
>> >
>> > #include <stdint.h>
>> > #include <stdio.h>
>> > #include <math.h>
>> >
>> > int
>> > main()
>> > {
>> > long l;
>> > double d = INT_MAX;
>> >
>> > l = lrint(d);
>> > printf("%f is %ld\n", d, l);
>> >
>> > l = lround(d);
>> > printf("%f is %ld\n", d, l);
>> >
>> > return 0;
>> > }
>> >
>> > 2147483647.000000 is -1
>> > 2147483647.000000 is -1
>> >
>> > That doesn't seem right: isn't INT_MAX representable as a long,
>> > even on these machines where sizeof(int) == sizeof(long)?
>>
>> If it is less than LONG_MAX, then yes.
>
> Less than, as in strictly less?
> Why? Do you mean <= ?

My statement is true for both < and <=, but I guess it would have been  
less confusing if I had written "less then or equal to".

>> > If so, shouldn't lrint(INT_MAX) == INT_MAX = lround(INT_MAX)?
>>
>> If the double type provides enough mantisse (which I think it does on  
>> all
>> platforms), and if I read a few C standards correctly, then yes.
>>
>> > On i386 (an ALIX), I see
>> >
>> > 2147483647.000000 is 2147483647
>> > 2147483647.000000 is -1
>> >
>> > so lrint() returns the expected value but lround() does not.
>> >
>> > On the amd64s I have, I see the expected:
>> > 2147483647.000000 is 2147483647
>> > 2147483647.000000 is 2147483647
>> >
>> > Is this a bug or am I missing something obvious?
>>
>> I'd say it's a bug. Also with a float variable and with lrintf/lroundf  
>> the
>> outcome should ideally be 2147483647.
>
> OK, how can I help debug this?
> (The code in lib/libm/src/*rint*.c seems a bit over my head.)

What Otto said. You could download {Free,Net}BSD code and expand your  
program to compare different variants.



--
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/