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

Discussion in 'C Programming' started by news.aon.at, Dec 2, 2011.

  1. news.aon.at

    news.aon.at Guest

    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
     
    news.aon.at, Dec 2, 2011
    #1
    1. Advertising

  2. news.aon.at

    jacob navia Guest

    Re: casting constant value from float to unsigned short - compilerbugs?

    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 $
     
    jacob navia, Dec 2, 2011
    #2
    1. Advertising

  3. news.aon.at

    James Kuyper Guest

    Re: casting constant value from float to unsigned short - compilerbugs?

    On 12/02/2011 04:06 AM, news.aon.at wrote:
    > 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
    >
    > ??


    "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)" (6.3.1.4p1), so -32766.5 is converted to
    -32766. That section goes on to say that "If the value of
    the integral part cannot be represented by the integer type, the
    behavior is undefined." Since -32766 cannot be represented in any
    unsigned type, all of the results you've gotten are equally conforming.
    A conforming implementation could also have formatted your hard disk or
    sent pornographic e-mail to your boss, though those are far less likely
    to occur.

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


    That's because short can can represent -32766. There is still a
    conversion to unsigned short, which can't represent that value; but for
    conversions from signed integer types to unsigned integer types, the
    rules are different than for floating point types. If a value cannot be
    represented in the new type, "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.3p2). In this case, that means adding or subtracting one
    more than USHORT_MAX, which is commonly 65536 (though it could be
    larger). 65536-32766 == 0x8002.
    --
    James Kuyper
     
    James Kuyper, Dec 2, 2011
    #3
  4. news.aon.at

    Quentin Pope Guest

    Re: casting constant value from float to unsigned short - compilerbugs?

    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!
     
    Quentin Pope, Dec 2, 2011
    #4
  5. news.aon.at

    jacob navia Guest

    Re: casting constant value from float to unsigned short - compilerbugs?

    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...
     
    jacob navia, Dec 2, 2011
    #5
  6. Quentin Pope <> writes:

    > 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!


    It most certainly is not nonsense. I would have put it differently, but
    it is a more accurate summary /of the code in question/ than your
    remarks. You cut that context, which was of a conversion from float to
    unsigned short. This conversion in *not* done modulo USHRT_MAX+1. To
    be more accurate, it need not be done that way -- some implementations
    may choose to do so since the result is undefined when the modulo
    operation would kick in.

    Jacob's "Your program has undefined behavior since a negative value will
    not go into an unsigned short" is quite correct (assuming a 16-bit
    unsigned short as everyone has been doing so far).

    --
    Ben.
     
    Ben Bacarisse, Dec 3, 2011
    #6
  7. news.aon.at

    James Kuyper Guest

    Re: casting constant value from float to unsigned short - compilerbugs?

    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
     
    James Kuyper, Dec 3, 2011
    #7
  8. news.aon.at

    Quentin Pope Guest

    Re: casting constant value from float to unsigned short - compilerbugs?

    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.
     
    Quentin Pope, Dec 3, 2011
    #8
  9. news.aon.at

    Kaz Kylheku Guest

    Re: casting constant value from float to unsigned short - compilerbugs?

    On 2011-12-03, Quentin Pope <> 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.
     
    Kaz Kylheku, Dec 3, 2011
    #9
  10. news.aon.at

    Phil Carmody Guest

    Quentin Pope <> 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
     
    Phil Carmody, Dec 4, 2011
    #10
  11. news.aon.at

    James Kuyper Guest

    Re: casting constant value from float to unsigned short - compilerbugs?

    On 12/04/2011 10:19 AM, Phil Carmody wrote:
    > Quentin Pope <> 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
     
    James Kuyper, Dec 4, 2011
    #11
  12. In article <>,
    Vincenzo Mercuri <> 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
     
    Michael Press, Jan 3, 2012
    #12
  13. news.aon.at

    Ben Pfaff Guest

    Michael Press <> writes:

    > In article <>,
    > Vincenzo Mercuri <> 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
     
    Ben Pfaff, Jan 3, 2012
    #13
  14. Michael Press <> writes:
    > In article <>,
    > Vincenzo Mercuri <> 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) <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"
     
    Keith Thompson, Jan 3, 2012
    #14
  15. news.aon.at

    Nobody Guest

    On Tue, 03 Jan 2012 12:31:57 -0800, Michael Press wrote:

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


    I read it as treating a floating-point value as:

    sign * (integer_part + fractional_part)

    where both integer_part and fractional_part are non-negative. Converting
    to an integer discards fractional_part.
     
    Nobody, Jan 4, 2012
    #15
  16. In article <>,
    Keith Thompson <> wrote:

    > Michael Press <> writes:
    > > In article <>,
    > > Vincenzo Mercuri <> 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?


    Yes. Why? Do you have a source that states otherwise?




















































































































    Knuth, ACP, 1.2.4.

    Oxford Dictionary of Mathematics
    <http://books.google.com/books?id=UTCenrlmVW4C&pg=PT192&lpg=PT192&dq=Dictionary+mathematics+fractional+part+-function&source=bl&ots=ezjia_b9uW&sig=Tojsd5nB2_gcZixDfGfB8SRVjAo&hl=en>

    --
    Michael Press
     
    Michael Press, Jan 4, 2012
    #16
  17. news.aon.at

    James Kuyper Guest

    Re: casting constant value from float to unsigned short - compilerbugs?

    On 01/04/2012 06:14 PM, Michael Press wrote:
    > In article <>,
    > Keith Thompson <> wrote:
    >
    >> Michael Press <> writes:

    ....
    >>> 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?

    >
    > Yes. Why? Do you have a source that states otherwise?


    At the time Keith posted, Ben Pfaff had already given a URL for a
    Mathematica web site indicating that "Spanier and Oldham (1987) use the
    same definition as Mathematica", which is (probably not coincidentally)
    the same as C's definition.

    ....
    [snip 116 blank lines]
    What was the purpose of those blank lines?

    > Knuth, ACP, 1.2.4.
    >
    > Oxford Dictionary of Mathematics
    > <http://books.google.com/books?id=UTCenrlmVW4C&pg=PT192&lpg=PT192&dq=Dictionary+mathematics+fractional+part+-function&source=bl&ots=ezjia_b9uW&sig=Tojsd5nB2_gcZixDfGfB8SRVjAo&hl=en>
     
    James Kuyper, Jan 5, 2012
    #17
  18. In article <>,
    James Kuyper <> wrote:

    > On 01/04/2012 06:14 PM, Michael Press wrote:
    > > In article <>,
    > > Keith Thompson <> wrote:
    > >
    > >> Michael Press <> writes:

    > ...
    > >>> 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?

    > >
    > > Yes. Why? Do you have a source that states otherwise?

    >
    > At the time Keith posted, Ben Pfaff had already given a URL for a
    > Mathematica web site indicating that "Spanier and Oldham (1987) use the
    > same definition as Mathematica", which is (probably not coincidentally)
    > the same as C's definition.
    >
    > ...
    > [snip 116 blank lines]
    > What was the purpose of those blank lines?


    I will wait until Keith asks.

    >
    > > Knuth, ACP, 1.2.4.
    > >
    > > Oxford Dictionary of Mathematics
    > > <http://books.google.com/books?id=UTCenrlmVW4C&pg=PT192&lpg=PT192&dq=Dictionary+mathematics+fractional+part+-function&source=bl&ots=ezjia_b9uW&sig=Tojsd5nB2_gcZixDfGfB8SRVjAo&hl=en>


    --
    Michael Press
     
    Michael Press, Jan 5, 2012
    #18
  19. In article <>,
    Nobody <> wrote:

    > On Tue, 03 Jan 2012 12:31:57 -0800, Michael Press wrote:
    >
    > > By the C standard's implied definition the fractional
    > > part of x is less than or equal to zero for x <= 0.

    >
    > I read it as treating a floating-point value as:
    >
    > sign * (integer_part + fractional_part)
    >
    > where both integer_part and fractional_part are non-negative. Converting
    > to an integer discards fractional_part.


    What is your point here?
    What definition of fractional part does your reading imply?

    --
    Michael Press
     
    Michael Press, Jan 5, 2012
    #19
  20. Michael Press <> writes:
    > In article <>,
    > James Kuyper <> wrote:
    >> On 01/04/2012 06:14 PM, Michael Press wrote:
    >> > In article <>,
    >> > Keith Thompson <> wrote:
    >> >> Michael Press <> writes:

    [...]
    >> >>> Hence frac(x) >= 0.
    >> >>
    >> >> Can you cite a source that says that that's what "fractional part"
    >> >> means in mathematics?
    >> >
    >> > Yes. Why? Do you have a source that states otherwise?

    >>
    >> At the time Keith posted, Ben Pfaff had already given a URL for a
    >> Mathematica web site indicating that "Spanier and Oldham (1987) use the
    >> same definition as Mathematica", which is (probably not coincidentally)
    >> the same as C's definition.
    >>
    >> ...
    >> [snip 116 blank lines]
    >> What was the purpose of those blank lines?

    >
    > I will wait until Keith asks.


    Ok, what was the purpose of those blank lines? And why would you feel
    the need to wait until I ask about it?

    When I read your response, I didn't even realize that those blank lines
    were there. I went to the next article thinking that you had said that
    you have a source but weren't going to share it (and was about to remark
    on that.

    My working hypothesis is that you were being deliberately difficult.

    >> > Knuth, ACP, 1.2.4.
    >> >
    >> > Oxford Dictionary of Mathematics
    >> > <http://books.google.com/books?id=UTCenrlmVW4C&pg=PT192&lpg=PT192&dq=Dictionary+mathematics+fractional+part+-function&source=bl&ots=ezjia_b9uW&sig=Tojsd5nB2_gcZixDfGfB8SRVjAo&hl=en>


    Ok. My point is that "mathematics" is a very large field, and I'm
    skeptical that there's a single definition for a term like "fractional
    part" that all mathematicians would accept.

    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, Jan 5, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. bd
    Replies:
    0
    Views:
    634
  2. Replies:
    4
    Views:
    831
    Kaz Kylheku
    Oct 17, 2006
  3. fancyerii
    Replies:
    21
    Views:
    1,497
    Roedy Green
    Nov 5, 2007
  4. Ioannis Vranos

    unsigned short, short literals

    Ioannis Vranos, Mar 4, 2008, in forum: C Programming
    Replies:
    5
    Views:
    683
    Eric Sosman
    Mar 5, 2008
  5. Carsten Fuchs
    Replies:
    45
    Views:
    1,559
    James Kanze
    Oct 8, 2009
Loading...

Share This Page