Groups > comp.lang.c > #14217 > unrolled thread

casting constant value from float to unsigned short - compiler bugs?

Started by	"news.aon.at" <mario_semo@hotmail.com>
First post	2011-12-02 10:06 +0100
Last post	2011-12-02 16:26 +0100
Articles	20 on this page of 46 — 18 participants

Back to article view | Back to comp.lang.c

Page 1 of 3 [1] 2 3 Next page →

#14217 — casting constant value from float to unsigned short - compiler bugs?

From	"news.aon.at" <mario_semo@hotmail.com>
Date	2011-12-02 10:06 +0100
Subject	casting constant value from float to unsigned short - compiler bugs?
Message-ID	<4ed8950a$0$18699$91cee783@newsreader03.highway.telekom.at>

Hello,

I try to cast a constant value (-32766.5) to float and then to an unsigned 
short.
Once directly and once with an intermediate variable.

 unsigned short s=(unsigned short)((float)(-32766.5));

vs.

 float f=((float)(-32766.5));
 unsigned short s=(unsigned short)f;

I use different compilers for this:

a) IBM Visual Age 3.5 (very old, 1995)
b) Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 
80x86  (MS-C6)
c) Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 
80x86 (VS2010)
d) gcc version 2.95.2-6 19991024 (cygwin experimental)
e) mingw32-gcc (GCC) 3.4.5 (mingw special) [Copyright (C) 2004 Free Software 
Foundation, Inc.]
f) WindRiver Vxw6.7 CrossCompiler: ccpentium (Wind River VxWorks G++ 
DWARF-EH 4.1-131) 4.1.2 [Copyright (C) 2006 Free Software Foundation, Inc.]

a,b,c,d : give 0x8002 in both cases.

e,f give 0 (!) in the first case and 0x8002 in the 2nd cases

??

Note : when i cast to a SHORT instead of an unsigned short in the first 
case, ALL compilers give 0x8002
(cast to float to short to unsigned short)

unsigned short s=(short)((float)(-32766.5));
or
unsigned short s=(unsigned short)(short)((float)(-32766.5));

Any Comments?


-- 
mit freundlichen Grüßen

mario semo

[toc] | [next] | [standalone]

#14219

From	jacob navia <jacob@spamsink.net>
Date	2011-12-02 10:34 +0100
Message-ID	<jba62t$41l$1@speranza.aioe.org>
In reply to	#14217

Le 02/12/11 10:06, news.aon.at a écrit :
> Note : when i cast to a SHORT instead of an unsigned short in the first
> case, ALL compilers give 0x8002
> (cast to float to short to unsigned short)
>
> unsigned short s=(short)((float)(-32766.5));
> or
> unsigned short s=(unsigned short)(short)((float)(-32766.5));
>
> Any Comments?
>

Yes. The first one is that the range for unsigned short is
zero to USHORT_MAX. Your program has undefined behavior
since a negative value will not go into an unsigned short,
it is OUTSIDE its domain.

Using lcc-win (Macintosh version) I obtain:

~/tmp $ cat casting.c
#include <stdio.h>
int main(void)
{
	unsigned short s=(unsigned short)((float)(-32766.5));
	float f = -32766.5;
	short s1 = (short)f;
	printf("%g\n%d 0x%x\n%d 0x%x\n",f,s,s,s1,s1);
}
~/tmp $ lcc casting.c
Warning ~/tmp/casting.c: 4  overflow in constant expression
0 errors, 1 warning
~/tmp $ ./casting
-32766.5
32770 0x8002
-32766 0xffff8002
~/tmp $

[toc] | [prev] | [next] | [standalone]

#14234

From	Vincenzo Mercuri <vincenzo.mercuri@hotmail.it>
Date	2011-12-02 18:10 +0100
Message-ID	<h5mdncBVCuL0m0TTnZ2dnUVZ8hednZ2d@giganews.com>
In reply to	#14219

Il 02/12/2011 10:34, jacob navia ha scritto:
> Le 02/12/11 10:06, news.aon.at a écrit :
>> Note : when i cast to a SHORT instead of an unsigned short in the first
>> case, ALL compilers give 0x8002
>> (cast to float to short to unsigned short)
>>
>> unsigned short s=(short)((float)(-32766.5));
>> or
>> unsigned short s=(unsigned short)(short)((float)(-32766.5));
>>
>> Any Comments?
>>

Of course you are not referring to the part of the post you quoted.
You quoted the part that doesn't lead to UB.

>
> Yes. The first one is that the range for unsigned short is
> zero to USHORT_MAX. [...]

USHRT_MAX :)

> Your program has undefined behavior
> since a negative value will not go into an unsigned short,
> it is OUTSIDE its domain.

It must be said that this is true in the context of a conversion
from a real floating type to an integer type. But the behavior is
well defined when you convert any signed integer type to any
unsigned type.

...
> printf("%g\n%d 0x%x\n%d 0x%x\n",f,s,s,s1,s1);
> }
...
> -32766.5
> 32770 0x8002
> -32766 0xffff8002
...

The print of "ffff" can be avoided by using the proper length modifier
'h' for the short types (I'd also replace the first conversion specifier
'd' with 'u', because "s" is unsigned, provided, of course, that this
program would ever run. I am assuming the same compiler you used):

printf("%g\n"      "%hu\t"  "0x%hx\n"  "%hd\t"  "0x%hx\n",
        (double)f,  s,       s,         s1,      (unsigned short)s1);


-- 
Vincenzo Mercuri | www.backbox.org

[toc] | [prev] | [next] | [standalone]

#14247

From	Quentin Pope <qp19433@hotmail.NOSPAM.com>
Date	2011-12-02 22:36 +0000
Message-ID	<jbbjsk$ja4$2@speranza.aioe.org>
In reply to	#14219

On Fri, 02 Dec 2011 10:34:22 +0100, jacob navia wrote:
> Yes. The first one is that the range for unsigned short is zero to
> USHORT_MAX. Your program has undefined behavior since a negative value
> will not go into an unsigned short, it is OUTSIDE its domain.

Sorry, but this is nonsense. Negative numbers stored in unsigned integer 
types "wrap around" - there is NO overflow for unsigned types, but all 
arithmetic is done modulo USHORT_MAX+1. It is amazing that you are not 
aware of this as a compiler writer!

[toc] | [prev] | [next] | [standalone]

#14248

From	jacob navia <jacob@spamsink.net>
Date	2011-12-03 00:45 +0100
Message-ID	<jbbnue$sau$1@speranza.aioe.org>
In reply to	#14247

Le 02/12/11 23:36, Quentin Pope a écrit :
> On Fri, 02 Dec 2011 10:34:22 +0100, jacob navia wrote:
>> Yes. The first one is that the range for unsigned short is zero to
>> USHORT_MAX. Your program has undefined behavior since a negative value
>> will not go into an unsigned short, it is OUTSIDE its domain.
>
> Sorry, but this is nonsense. Negative numbers stored in unsigned integer
> types "wrap around" - there is NO overflow for unsigned types, but all
> arithmetic is done modulo USHORT_MAX+1. It is amazing that you are not
> aware of this as a compiler writer!

The C standard specifies that when the

<quote> (C Standard 6.3.1.4)
  If the value being converted is outside the range of values that can 
be represented, the behavior is undefined.
<end quote>

A negative value can't be represented in an UNsigned integer.

By definition.

Therefore my compiler emits a warning and does its best (as all other 
compilers do) and produces exactly the same result as most other
compilers do.

I can't understand how you come to "overflow". There is nowhere an
"overflow" and I did not use that word at all. It is just that
the value can't be represented in the destination object.

Try putting 53765 into an 8 bit char... or a complex number
into a float...

[toc] | [prev] | [next] | [standalone]

#14253 — Re: casting constant value from float to unsigned short - compiler bugs?

From	pete <pfiland@mindspring.com>
Date	2011-12-02 19:43 -0500
Subject	Re: casting constant value from float to unsigned short - compiler bugs?
Message-ID	<4ED970C8.1F03@mindspring.com>
In reply to	#14248

jacob navia wrote:
> 
> Le 02/12/11 23:36, Quentin Pope a Ã©crit :
> > On Fri, 02 Dec 2011 10:34:22 +0100, jacob navia wrote:
> >> Yes. The first one is that the range for unsigned short is zero to
> >> USHORT_MAX. Your program has undefined behavior
> >> since a negative value
> >> will not go into an unsigned short, it is OUTSIDE its domain.
> >
> > Sorry, but this is nonsense.
> > Negative numbers stored in unsigned integer
> > types "wrap around" - there is NO overflow for unsigned types,
> > but all arithmetic is done modulo USHORT_MAX+1.
> > It is amazing that you are not
> > aware of this as a compiler writer!
> 
> The C standard specifies that when the
> 
> <quote> (C Standard 6.3.1.4)
>   If the value being converted is outside the range of values that can
> be represented, the behavior is undefined.
> <end quote>
> 
> A negative value can't be represented in an UNsigned integer.
> 
> By definition.

You got that all wrong.

Section 6.3.1.4 is
    6.3.1.4 Real floating and integer

and the quote that you quoted applies to this case:
    "When a value of integer type 
     is converted to a real floating type, ..."


The relevant section is

6.3.1.3 Signed and unsigned integers
    1 When a value with integer type is converted
      to another integer type other than _Bool, 
      if the value can be represented by the new type,
      it is unchanged.
    2 Otherwise, if the new type is unsigned, 
      the value is converted by repeatedly adding or
      subtracting one more than the maximum value
      that can be represented in the new type
      until the value is in the range of the new type.

... which amounts to exactly what Quentin Pope said.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#14254 — Re: casting constant value from float to unsigned short - compiler bugs?

From	pete <pfiland@mindspring.com>
Date	2011-12-02 19:49 -0500
Subject	Re: casting constant value from float to unsigned short - compiler bugs?
Message-ID	<4ED971FE.7646@mindspring.com>
In reply to	#14253

pete wrote:
> 
> jacob navia wrote:
> >
> > Le 02/12/11 23:36, Quentin Pope a Ã©crit :
> > > On Fri, 02 Dec 2011 10:34:22 +0100, jacob navia wrote:
> > >> Yes. The first one is that the range for unsigned short is zero to
> > >> USHORT_MAX. Your program has undefined behavior
> > >> since a negative value
> > >> will not go into an unsigned short, it is OUTSIDE its domain.
> > >
> > > Sorry, but this is nonsense.
> > > Negative numbers stored in unsigned integer
> > > types "wrap around" - there is NO overflow for unsigned types,
> > > but all arithmetic is done modulo USHORT_MAX+1.
> > > It is amazing that you are not
> > > aware of this as a compiler writer!
> >
> > The C standard specifies that when the
> >
> > <quote> (C Standard 6.3.1.4)
> >   If the value being converted is outside the range of values that can
> > be represented, the behavior is undefined.
> > <end quote>
> >
> > A negative value can't be represented in an UNsigned integer.
> >
> > By definition.
> 
> You got that all wrong.

Sorry about that.
I got that all wrong.
I hadn't read back far enough into thread 
to realise what you were talking about.

6.3.1.4 Real floating and integer
   1 When a finite value of real floating type 
     is converted to an integer type other than _Bool,
     the fractional part is discarded 
     (i.e., the value is truncated toward zero). 
     If the value of the integral part 
     cannot be represented by the integer type, 
     the behavior is undefined.)

-- 
pete

[toc] | [prev] | [next] | [standalone]

#14255

From	Vincenzo Mercuri <vincenzo.mercuri@yahoo.it>
Date	2011-12-03 01:51 +0100
Message-ID	<squdnRldpaA_70TTnZ2dnUVZ8radnZ2d@giganews.com>
In reply to	#14248

jacob navia ha scritto:
> Le 02/12/11 23:36, Quentin Pope a écrit :
>> On Fri, 02 Dec 2011 10:34:22 +0100, jacob navia wrote:
>>> Yes. The first one is that the range for unsigned short is zero to
>>> USHORT_MAX. Your program has undefined behavior since a negative value
>>> will not go into an unsigned short, it is OUTSIDE its domain.
>>
>> Sorry, but this is nonsense. Negative numbers stored in unsigned integer
>> types "wrap around" - there is NO overflow for unsigned types, but all
>> arithmetic is done modulo USHORT_MAX+1. It is amazing that you are not
>> aware of this as a compiler writer!
>
>
> The C standard specifies that when the
>
> <quote> (C Standard 6.3.1.4)
> If the value being converted is outside the range of values that can be
> represented, the behavior is undefined.
> <end quote>
>

The text you quote is 6.3.1.4 *Real floating and integer*

p2:
     When _a value of integer type is converted to a real floating type_,
     [...]
     If the value being converted is outside the range of values that
     can be represented, the behavior is undefined.

But now we are dealing with a real floating type being converted to 
integer types, not the contrary!

> A negative value can't be represented in an UNsigned integer.
>
> By definition.

See my reply to Quentin.

[...]

-- 
Vincenzo Mercuri | www.backbox.org

[toc] | [prev] | [next] | [standalone]

#14266

From	James Kuyper <jameskuyper@verizon.net>
Date	2011-12-03 11:51 -0500
Message-ID	<jbdk1p$pgh$1@dont-email.me>
In reply to	#14255

On 12/02/2011 07:51 PM, Vincenzo Mercuri wrote:
> jacob navia ha scritto:
...
>> The C standard specifies that when the
>>
>> <quote> (C Standard 6.3.1.4)
>> If the value being converted is outside the range of values that can be
>> represented, the behavior is undefined.
>> <end quote>
>>
> 
> The text you quote is 6.3.1.4 *Real floating and integer*
> 
> p2:
>      When _a value of integer type is converted to a real floating type_,
>      [...]
>      If the value being converted is outside the range of values that
>      can be represented, the behavior is undefined.
> 
> But now we are dealing with a real floating type being converted to 
> integer types, not the contrary!

His conclusion was correct, and he cited the right section of the
standard, but his quotation is from the wrong paragraph in that section.
What he should have cited was 6.3.1.4p1, which does cover conversion of
a real floating type to an integer: "If the value of the integral part
cannot be represented by the integer type, the behavior is undefined."
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#14267

From	Vincenzo Mercuri <vincenzo.mercuri@hotmail.it>
Date	2011-12-03 19:08 +0100
Message-ID	<IcOdneGVp6Y3-EfTnZ2dnUVZ8k6dnZ2d@giganews.com>
In reply to	#14266

Il 03/12/2011 17:51, James Kuyper ha scritto:
> On 12/02/2011 07:51 PM, Vincenzo Mercuri wrote:
...
>> But now we are dealing with a real floating type being converted to
>> integer types, not the contrary!
>
> His conclusion was correct, and he cited the right section of the
> standard, but his quotation is from the wrong paragraph in that section.
> What he should have cited was 6.3.1.4p1, which does cover conversion of
> a real floating type to an integer: "If the value of the integral part
> cannot be represented by the integer type, the behavior is undefined."

Yes, of course. That's what I wanted to point out indeed: the right
context in the Standard. I do believe that Jacob intended the right
thing, but he expressed it in the form of a very general rule about
conversion from "negative value"s to unsigned types that will
eventually lead to undefined behavior. He said:

"Your program has undefined behavior since a negative value will not
go into an unsigned short, it is OUTSIDE its domain. "

and

"<quote> (C Standard 6.3.1.4)
  If the value being converted is outside the range of values that
  can be represented, the behavior is undefined.
<end quote>

A negative value can't be represented in an UNsigned integer. "

One who didn't read the Standard might have been convinced of the
general rule for which a conversion of *any* type of negative
value to an unsigned type invokes UB. This is not true (even if
the context looks clear to most, but it may not be so to everyone).
This is the reason of my replies. :)

-- 
Vincenzo Mercuri | www.backbox.org

[toc] | [prev] | [next] | [standalone]

#14268

From	Quentin Pope <qp19433@hotmail.NOSPAM.com>
Date	2011-12-03 19:06 +0000
Message-ID	<jbdruv$90g$1@speranza.aioe.org>
In reply to	#14267

On Sat, 03 Dec 2011 19:08:42 +0100, Vincenzo Mercuri wrote:

> Il 03/12/2011 17:51, James Kuyper ha scritto:
>> On 12/02/2011 07:51 PM, Vincenzo Mercuri wrote:
> ...
>>> But now we are dealing with a real floating type being converted to
>>> integer types, not the contrary!
>>
>> His conclusion was correct, and he cited the right section of the
>> standard, but his quotation is from the wrong paragraph in that
>> section. What he should have cited was 6.3.1.4p1, which does cover
>> conversion of a real floating type to an integer: "If the value of the
>> integral part cannot be represented by the integer type, the behavior
>> is undefined."
> 
> Yes, of course. That's what I wanted to point out indeed: the right
> context in the Standard. I do believe that Jacob intended the right
> thing, but he expressed it in the form of a very general rule about
> conversion from "negative value"s to unsigned types that will eventually
> lead to undefined behavior. He said:
> 
> "Your program has undefined behavior since a negative value will not go
> into an unsigned short, it is OUTSIDE its domain. "
> 
> and
> 
> "<quote> (C Standard 6.3.1.4)
>   If the value being converted is outside the range of values that can
>   be represented, the behavior is undefined.
> <end quote>
> 
> A negative value can't be represented in an UNsigned integer. "
> 
> One who didn't read the Standard might have been convinced of the
> general rule for which a conversion of *any* type of negative value to
> an unsigned type invokes UB. This is not true (even if the context looks
> clear to most, but it may not be so to everyone). This is the reason of
> my replies. :)

Yes! This is exactly the point I was making. The clear implication of 
Jacob's words is that he was referring generally to all conversions of 
numeric types to unsigned short, not just to floating point types.

[toc] | [prev] | [next] | [standalone]

#14269

From	Kaz Kylheku <kaz@kylheku.com>
Date	2011-12-03 19:14 +0000
Message-ID	<20111203111349.739@kylheku.com>
In reply to	#14268

On 2011-12-03, Quentin Pope <qp19433@hotmail.NOSPAM.com> wrote:
> Yes! This is exactly the point I was making.

It's perfectly clear to everyone you were making a fucking ass of yourself.

You should apologize to Navia.

[toc] | [prev] | [next] | [standalone]

#14313

From	Phil Carmody <thefatphil_demunged@yahoo.co.uk>
Date	2011-12-04 17:19 +0200
Message-ID	<87wrac1i05.fsf@bazspaz.fatphil.org>
In reply to	#14268

Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:
> Yes! This is exactly the point I was making. The clear implication of 
> Jacob's words is that he was referring generally to all conversions of 
> numeric types to unsigned short, not just to floating point types.

From the look of the two lines of C he was commenting on,
it looks like he's only refering to conversion of short to
unsigned short only:

:> Note : when i cast to a SHORT instead of an unsigned short in the first
:> case, ALL compilers give 0x8002
:> (cast to float to short to unsigned short)
:>
:> unsigned short s=(short)((float)(-32766.5));
:> or
:> unsigned short s=(unsigned short)(short)((float)(-32766.5));

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

[toc] | [prev] | [next] | [standalone]

#14315

From	James Kuyper <jameskuyper@verizon.net>
Date	2011-12-04 10:39 -0500
Message-ID	<jbg47g$joa$1@dont-email.me>
In reply to	#14313

On 12/04/2011 10:19 AM, Phil Carmody wrote:
> Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:
>> Yes! This is exactly the point I was making. The clear implication of 
>> Jacob's words is that he was referring generally to all conversions of 
>> numeric types to unsigned short, not just to floating point types.
> 
> From the look of the two lines of C he was commenting on,
> it looks like he's only refering to conversion of short to
> unsigned short only:
> 
> :> Note : when i cast to a SHORT instead of an unsigned short in the first
> :> case, ALL compilers give 0x8002
> :> (cast to float to short to unsigned short)
> :>
> :> unsigned short s=(short)((float)(-32766.5));
> :> or
> :> unsigned short s=(unsigned short)(short)((float)(-32766.5));

I didn't see jacob's message, but the OP was asking primarily about
double->float->unsigned short, and was asking about
double->float->short->unsigned short only for the purpose of wondering
why it gave different results.

It suspect that double->float was part of the conversion chain only
because the OP was not aware of the fact that you can write float
constants directly, as -32766.5F.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#14252

From	Vincenzo Mercuri <vincenzo.mercuri@yahoo.it>
Date	2011-12-03 01:41 +0100
Message-ID	<f_ydnS3uiPzU7UTTnZ2dnUVZ8lqdnZ2d@giganews.com>
In reply to	#14247

Quentin Pope ha scritto:
> On Fri, 02 Dec 2011 10:34:22 +0100, jacob navia wrote:
>> Yes. The first one is that the range for unsigned short is zero to
>> USHORT_MAX. Your program has undefined behavior since a negative value
>> will not go into an unsigned short, it is OUTSIDE its domain.
>
> Sorry, but this is nonsense. Negative numbers stored in unsigned integer
> types "wrap around" [...]

This is not correct. The Standard refers to *integer types* being
converted to an *unsigned integer type* :

ISO/IEC 9899/TC3 - 6.3.1.3 *Signed and unsigned integers*

p2:
      Otherwise, if the new type is unsigned, the value is converted
      by repeatedly adding or subtracting one more than the maximum
      value that can be represented in the new type until the value
      is in the range of the new type.


                  - 6.3.1.4 *Real floating and integer*

p1:
      When a finite value of real floating type is converted to an
      integer type other than _Bool, the fractional part is discarded
      (i.e., the value is truncated toward zero). If the value of the
      integral part cannot be represented by the integer type,
      the behavior is undefined.[^50]


[footnote 50]:
         The remaindering operation performed when a value of integer
         type is converted to unsigned type need not be performed when
         a value of real floating type is converted to unsigned type.
         Thus, the range of portable real floating values is (−1, 
U/type/_MAX+1).

-- 
Vincenzo Mercuri | www.backbox.org

[toc] | [prev] | [next] | [standalone]

#15383

From	Michael Press <rubrum@pacbell.net>
Date	2012-01-03 12:31 -0800
Message-ID	<rubrum-5D58A3.12315703012012@news.albasani.net>
In reply to	#14252

In article <f_ydnS3uiPzU7UTTnZ2dnUVZ8lqdnZ2d@giganews.com>,
 Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> wrote:

> p1:
>       When a finite value of real floating type is converted to an
>       integer type other than _Bool, the fractional part is discarded
>       (i.e., the value is truncated toward zero). If the value of the
>       integral part cannot be represented by the integer type,
>       the behavior is undefined.[^50]

Note that this wording is at variance with standard mathematcal definitions.

The floor function is defined as

    floor(x) = maximum integer m such that m <= x.

Hence floor(x) <= x.

The fractional part of x is defined to be

    frac(x) = x - floor(x).

Hence frac(x) >= 0.

By the C standard's implied definition the fractional
part of x is less than or equal to zero for x <= 0.

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

#15384

From	blp@cs.stanford.edu (Ben Pfaff)
Date	2012-01-03 12:38 -0800
Message-ID	<87ty4cfro5.fsf@blp.benpfaff.org>
In reply to	#15383

Michael Press <rubrum@pacbell.net> writes:

> In article <f_ydnS3uiPzU7UTTnZ2dnUVZ8lqdnZ2d@giganews.com>,
>  Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> wrote:
>
>> p1:
>>       When a finite value of real floating type is converted to an
>>       integer type other than _Bool, the fractional part is discarded
>>       (i.e., the value is truncated toward zero). If the value of the
>>       integral part cannot be represented by the integer type,
>>       the behavior is undefined.[^50]
>
> Note that this wording is at variance with standard mathematcal definitions.

If http://mathworld.wolfram.com/FractionalPart.html is to be
believed, there is no single standard mathematical definition of
"fractional part", but the one used in the C standard matches one
common definition.
-- 
"Some people *are* arrogant, and others read the FAQ."
--Chris Dollin

[toc] | [prev] | [next] | [standalone]

#15492

From	Michael Press <rubrum@pacbell.net>
Date	2012-01-06 11:38 -0800
Message-ID	<rubrum-6AA2D0.11382006012012@news.albasani.net>
In reply to	#15384

In article <87ty4cfro5.fsf@blp.benpfaff.org>,
 blp@cs.stanford.edu (Ben Pfaff) wrote:

> Michael Press <rubrum@pacbell.net> writes:
> 
> > In article <f_ydnS3uiPzU7UTTnZ2dnUVZ8lqdnZ2d@giganews.com>,
> >  Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> wrote:
> >
> >> p1:
> >>       When a finite value of real floating type is converted to an
> >>       integer type other than _Bool, the fractional part is discarded
> >>       (i.e., the value is truncated toward zero). If the value of the
> >>       integral part cannot be represented by the integer type,
> >>       the behavior is undefined.[^50]
> >
> > Note that this wording is at variance with standard mathematcal definitions.
> 
> If http://mathworld.wolfram.com/FractionalPart.html is to be
> believed, there is no single standard mathematical definition of
> "fractional part", but the one used in the C standard matches one
> common definition.

Mathematica is not mathematics. C is not mathematics.

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

#15495

From	James Kuyper <jameskuyper@verizon.net>
Date	2012-01-06 15:10 -0500
Message-ID	<4F07553B.8040803@verizon.net>
In reply to	#15492

On 01/06/2012 02:38 PM, Michael Press wrote:
> In article <87ty4cfro5.fsf@blp.benpfaff.org>,
>  blp@cs.stanford.edu (Ben Pfaff) wrote:
> 
>> Michael Press <rubrum@pacbell.net> writes:

>> If http://mathworld.wolfram.com/FractionalPart.html is to be
>> believed, there is no single standard mathematical definition of
>> "fractional part", but the one used in the C standard matches one
>> common definition.
> 
> Mathematica is not mathematics. C is not mathematics.

This isn't a question about whether Mathematica "is mathematics"; no one
claimed that it was. It isn't even a question of whether Mathematica's
web site is authoritative on such issues - no one made that claim,
either. The Mathematica web site claims that there are multiple
definitions in use by mathematicians. The key question is whether or not
that claim is correct, an issue that is completely independent of who
made that claim. The Mathematica web site provides a citation in support
of this claim. Any of the following would be relevant counter-arguments:

1. Present evidence indicating that the cited text does not exist.
2. Present evidence indicating that the cited text does not, in fact,
say what Mathematica's web site says that it says.
3. Argue that the authors of the cited text cited are insufficiently
influential for their use of a different definition to support a claim
that it is "one common definition". This is necessarily a judgement
call, but it can at least reasonably be argued about.

Personally, I'd consider 3 to be the most reasonable target to attack -
I certainly have no idea who those authors were, which places a (very
high) upper limit on how influential they could be.

But you didn't choose any of those approaches. Instead you argue
irrelevancies, like "Mathematica is not mathematics".

[toc] | [prev] | [next] | [standalone]

#15385

From	Keith Thompson <kst-u@mib.org>
Date	2012-01-03 12:49 -0800
Message-ID	<lnmxa45x6c.fsf@nuthaus.mib.org>
In reply to	#15383

Michael Press <rubrum@pacbell.net> writes:
> In article <f_ydnS3uiPzU7UTTnZ2dnUVZ8lqdnZ2d@giganews.com>,
>  Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> wrote:
>
>> p1:
>>       When a finite value of real floating type is converted to an
>>       integer type other than _Bool, the fractional part is discarded
>>       (i.e., the value is truncated toward zero). If the value of the
>>       integral part cannot be represented by the integer type,
>>       the behavior is undefined.[^50]
>
> Note that this wording is at variance with standard mathematcal definitions.
>
> The floor function is defined as
>
>     floor(x) = maximum integer m such that m <= x.
>
> Hence floor(x) <= x.

Yes, and that's consistent with the C standard's floor(), floorf(),
and floorl() functions in <math.h>.

> The fractional part of x is defined to be
>
>     frac(x) = x - floor(x).
>
> Hence frac(x) >= 0.

Can you cite a source that says that that's what "fractional part"
means in mathematics?

> By the C standard's implied definition the fractional
> part of x is less than or equal to zero for x <= 0.

Yes.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

Page 1 of 3 [1] 2 3 Next page →

csiph-web

casting constant value from float to unsigned short - compiler bugs?

Contents

#14217 — casting constant value from float to unsigned short - compiler bugs?

#14219

#14234

#14247

#14248

#14253 — Re: casting constant value from float to unsigned short - compiler bugs?

#14254 — Re: casting constant value from float to unsigned short - compiler bugs?

#14255

#14266

#14267

#14268

#14269

#14313

#14315

#14252

#15383

#15384

#15492

#15495

#15385