Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

What is truncation for (singed) integer in C ?

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

Contents

  What is truncation for (singed) integer in C ? fl <rxjwg98@gmail.com> - 2015-09-19 12:25 -0700
    Re: What is truncation for (singed) integer in C ? fir <profesor.fir@gmail.com> - 2015-09-19 12:55 -0700
      Re: What is truncation for (singed) integer in C ? fir <profesor.fir@gmail.com> - 2015-09-19 13:20 -0700
    Re: What is truncation for (singed) integer in C ? Geoff <geoff@invalid.invalid> - 2015-09-19 13:05 -0700
    Re: What is truncation for (singed) integer in C ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-19 21:28 +0100
      Re: What is truncation for (singed) integer in C ? Tim Prince <tprince@computer.org> - 2015-09-19 16:38 -0400
        Re: What is truncation for (singed) integer in C ? James Kuyper <jameskuyper@verizon.net> - 2015-09-19 16:52 -0400
    Re: What is truncation for (singed) integer in C ? Keith Thompson <kst-u@mib.org> - 2015-09-19 13:45 -0700
    Re: What is truncation for (singed) integer in C ? James Kuyper <jameskuyper@verizon.net> - 2015-09-19 16:46 -0400
    Re: What is truncation for (singed) integer in C ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-19 16:47 -0400
    Re: What is truncation for (singed) integer in C ? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-09-19 22:55 -0600
    Re: What is truncation for (singed) integer in C ? James Kuyper <jameskuyper@verizon.net> - 2015-09-20 10:54 -0400
      Re: What is truncation for (singed) integer in C ? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-09-20 10:11 -0600

#70929 — What is truncation for (singed) integer in C ?

Hi,

I see the following on wikipedia and doubt about negative integer when
 truncating.

https://en.wikipedia.org/wiki/Type_conversion
///////
 Data can be lost when floating-point representations are converted to integer
 representations as the fractional components of the floating-point values
 will be truncated (rounded towards zero)
.......

I agree for positive integer, truncation in C is towards 0. But for negative
integer, it looks like away from '0'. For example, for a unsigned char 83H,
one bit (LSB) truncation result will be 41H, whose non-truncation value 
(8-bit) is equal to 82H. The real value of 82H plus '1' is 83H. That is,
82H < 83H. For these negative numbers, it is not rounded towards zero.

Is the above link not talking the same thing with my understanding?


Thanks,

[toc] | [next] | [standalone]

#70932

W dniu sobota, 19 września 2015 21:25:22 UTC+2 użytkownik fl napisał:
> Hi,
> 
> I see the following on wikipedia and doubt about negative integer when
>  truncating.
> 
> https://en.wikipedia.org/wiki/Type_conversion
> ///////
>  Data can be lost when floating-point representations are converted to integer
>  representations as the fractional components of the floating-point values
>  will be truncated (rounded towards zero)
> .......
> 
> I agree for positive integer, truncation in C is towards 0. But for negative
> integer, it looks like away from '0'. For example, for a unsigned char 83H,
> one bit (LSB) truncation result will be 41H, whose non-truncation value 
> (8-bit) is equal to 82H. The real value of 82H plus '1' is 83H. That is,
> 82H < 83H. For these negative numbers, it is not rounded towards zero.
> 
> Is the above link not talking the same thing with my understanding?
> 

as far as i know truncation (when casting, conversion, flots->int) is toward zero

you must be doing something wron probably, i dont understand what you are talking by "example, for a unsigned char 83H, one bit (LSB) truncation result will be 41H, whose non-truncation value  (8-bit) is equal to 82H. The real value of 82H plus '1' is 83H. That is, 82H < 83H. For these negative numbers, it is not rounded towards zero."

sounds crazy, i dont at all know what its about.. When speaking about truncation 
you should talk about floats and ints

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

#70936

W dniu sobota, 19 września 2015 21:56:03 UTC+2 użytkownik fir napisał:
> W dniu sobota, 19 września 2015 21:25:22 UTC+2 użytkownik fl napisał:
> > Hi,
> > 
> > I see the following on wikipedia and doubt about negative integer when
> >  truncating.
> > 
> > https://en.wikipedia.org/wiki/Type_conversion
> > ///////
> >  Data can be lost when floating-point representations are converted to integer
> >  representations as the fractional components of the floating-point values
> >  will be truncated (rounded towards zero)
> > .......
> > 
> > I agree for positive integer, truncation in C is towards 0. But for negative
> > integer, it looks like away from '0'. For example, for a unsigned char 83H,
> > one bit (LSB) truncation result will be 41H, whose non-truncation value 
> > (8-bit) is equal to 82H. The real value of 82H plus '1' is 83H. That is,
> > 82H < 83H. For these negative numbers, it is not rounded towards zero.
> > 
> > Is the above link not talking the same thing with my understanding?
> > 
> 
> as far as i know truncation (when casting, conversion, flots->int) is toward zero
> 
> you must be doing something wron probably, i dont understand what you are talking by "example, for a unsigned char 83H, one bit (LSB) truncation result will be 41H, whose non-truncation value  (8-bit) is equal to 82H. The real value of 82H plus '1' is 83H. That is, 82H < 83H. For these negative numbers, it is not rounded towards zero."
> 

ps if ya talking about division afaIk 83h/2
is 41h ;
83h is positive to get it negative write -83h/2 it is then -41h or    
((signed char) 0x83)/2 it is then -62

everything is okay here

(though this toward zero truncating i belive may lead to some sampling errors.. for example i once was writing "2d fill corcle 
drawing algorith" by storing precomputed NxN pixels image (256x256?) and downsampling it
with for for loops* (for example for 7x7 small image) If wrote it naively this truncating  probably resulted in deformed circles)

* im not sayin this algorith is good - im still not sure as to that, i was seeking something fast and at least it worked


> sounds crazy, i dont at all know what its about.. When speaking about truncation 
> you should talk about floats and ints

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

#70934

On Sat, 19 Sep 2015 12:25:05 -0700 (PDT), fl <rxjwg98@gmail.com>
wrote:

>Hi,
>
>I see the following on wikipedia and doubt about negative integer when
> truncating.
>
>https://en.wikipedia.org/wiki/Type_conversion
>///////
> Data can be lost when floating-point representations are converted to integer
> representations as the fractional components of the floating-point values
> will be truncated (rounded towards zero)
>.......
>
>I agree for positive integer, truncation in C is towards 0. But for negative
>integer, it looks like away from '0'. For example, for a unsigned char 83H,
>one bit (LSB) truncation result will be 41H, whose non-truncation value 
>(8-bit) is equal to 82H. The real value of 82H plus '1' is 83H. That is,
>82H < 83H. For these negative numbers, it is not rounded towards zero.
>
>Is the above link not talking the same thing with my understanding?
>

It's not talking about the same thing. The truncation they are talking
about is in conversion from one type to another and what happens to
their representations. (e.g., float to int)

Compile their example:

#include <stdio.h>

int main(void)
{
    int i_value   = 16777217;
    float f_value = 16777216.0;
    printf("The integer is: %d\n", i_value);
    printf("The float is:   %f\n", f_value);
    printf("Their equality: %d\n", i_value == f_value);
}

Then examine the variables in your debugger to see how they are
represented.

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

#70937

fl <rxjwg98@gmail.com> writes:

> I see the following on wikipedia and doubt about negative integer when
>  truncating.
>
> https://en.wikipedia.org/wiki/Type_conversion
> ///////
>  Data can be lost when floating-point representations are converted to integer
>  representations as the fractional components of the floating-point values
>  will be truncated (rounded towards zero)
> .......
>
> I agree for positive integer, truncation in C is towards 0. But for
> negative integer, it looks like away from '0'. For example, for a
> unsigned char 83H,

Something is already wrong here.  You say "but for negative integer" and
the then give an example of "unsigned char 83H".  unsigned char 83H is
not negative -- it's unsigned.

> one bit (LSB) truncation result will be 41H, whose non-truncation value 
> (8-bit) is equal to 82H. The real value of 82H plus '1' is 83H. That is,
> 82H < 83H. For these negative numbers, it is not rounded towards zero.
>
> Is the above link not talking the same thing with my understanding?

I think you are talking here about integer division by two.  The article
you cite is about converting floating point values to integers so there
is no direct connection.  The rules about integer division have changed
between old C (ANSI C or ISO C from 1990) and modern C (C99 and later)
but in modern C, the result is indeed truncated (rounded towards zero).

To use your example, signed char c = -125; will give c the bit-pattern
83 in hex.  Note that I can't say c == 0x83 because that is not correct
in C -- do you know why?  Now c/2 is -125/2 which, truncated towards
zero is -62.  That will "look like" C2 in hex, but, again, c/2 == 0xC2
is not correct in C.

-- 
Ben.

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

#70939

On 9/19/2015 4:28 PM, Ben Bacarisse wrote:
> fl <rxjwg98@gmail.com> writes:
> 
>> I see the following on wikipedia and doubt about negative integer when
>>  truncating.
>>
>> https://en.wikipedia.org/wiki/Type_conversion
>> ///////
>>  Data can be lost when floating-point representations are converted to integer
>>  representations as the fractional components of the floating-point values
>>  will be truncated (rounded towards zero)
>> .......
>>
>> I agree for positive integer, truncation in C is towards 0. But for
>> negative integer, it looks like away from '0'. For example, for a
>> unsigned char 83H,
> 
> Something is already wrong here.  You say "but for negative integer" and
> the then give an example of "unsigned char 83H".  unsigned char 83H is
> not negative -- it's unsigned.
> 
>> one bit (LSB) truncation result will be 41H, whose non-truncation value 
>> (8-bit) is equal to 82H. The real value of 82H plus '1' is 83H. That is,
>> 82H < 83H. For these negative numbers, it is not rounded towards zero.
>>
>> Is the above link not talking the same thing with my understanding?
> 
> I think you are talking here about integer division by two.  The article
> you cite is about converting floating point values to integers so there
> is no direct connection.  The rules about integer division have changed
> between old C (ANSI C or ISO C from 1990) and modern C (C99 and later)
> but in modern C, the result is indeed truncated (rounded towards zero).
> 
> To use your example, signed char c = -125; will give c the bit-pattern
> 83 in hex.  Note that I can't say c == 0x83 because that is not correct
> in C -- do you know why?  Now c/2 is -125/2 which, truncated towards
> zero is -62.  That will "look like" C2 in hex, but, again, c/2 == 0xC2
> is not correct in C.
> 
My references imply that the definition with truncation towards 0 came
in with C89.  Before that, i/2 might be considered interchangeable with
i>>1 regardless of whether 1's or 2's complement was in use, even though
they give different results.
I would assume that casting from a floating point type to unsigned char
would involve an intermediate int representation, but OP seemed to lose
track of what was the question.

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

#70944

On 09/19/2015 04:38 PM, Tim Prince wrote:
...
> My references imply that the definition with truncation towards 0 came
> in with C89.  Before that, i/2 might be considered interchangeable with
> i>>1 regardless of whether 1's or 2's complement was in use, even though
> they give different results.

Not quite. The change was made in C99, not C89. In C89, it was
unspecified whether fractions were rounded toward zero or toward
-infinity. I'm not sure whether it was implementation-defined, but I
think it was. There was no requirement that i/2 be the same as i>>1.

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

#70940

fl <rxjwg98@gmail.com> writes:
> I see the following on wikipedia and doubt about negative integer when
>  truncating.
>
> https://en.wikipedia.org/wiki/Type_conversion
> ///////
>  Data can be lost when floating-point representations are converted to
>  integer representations as the fractional components of the
>  floating-point values will be truncated (rounded towards zero)
> .......
>
> I agree for positive integer, truncation in C is towards 0. But for
> negative integer, it looks like away from '0'. For example, for a
> unsigned char 83H, one bit (LSB) truncation result will be 41H, whose
> non-truncation value (8-bit) is equal to 82H. The real value of 82H
> plus '1' is 83H. That is, 82H < 83H. For these negative numbers, it is
> not rounded towards zero.
>
> Is the above link not talking the same thing with my understanding?

The link is talking about conversion of *floating-point* values to
integers.

For example, (int)3.7 = 3, and (int)-3.7 == -3.

I'm not entirely clear on what your example is supposed to be.  For
starters, C expresses a hexadecimal value as 0x83, not 83H.  You appear
to be talking about truncating the result of dividing 0x83 by 2 (you
didn't mention the division).  0x83 / 2 == 0x41; for unsigned values,
integer division truncates.  There are other rules for negative values
-- but 0x83 is positive, so those rules don't apply.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#70941

On 09/19/2015 03:25 PM, fl wrote:
> Hi,
> 
> I see the following on wikipedia and doubt about negative integer when
>  truncating.
> 
> https://en.wikipedia.org/wiki/Type_conversion
> ///////
>  Data can be lost when floating-point representations are converted to integer
>  representations as the fractional components of the floating-point values
>  will be truncated (rounded towards zero)
> .......
> 
> I agree for positive integer, truncation in C is towards 0. But for negative
> integer, it looks like away from '0'. For example, for a unsigned char 83H,
> one bit (LSB) truncation result will be 41H, whose non-truncation value 
> (8-bit) is equal to 82H. The real value of 82H plus '1' is 83H. That is,

You have a LOT of confusion here.

The relevant clause in the C standard says: "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)

The truncation it's talking about here involves only floating point
values, and your example doesn't involve any floating point values. What
it's saying is that if, for instance, a floating point value of 3.21 is
converted to an integer type, the result is 3, obtained by truncating
the "21" at the end. Similarly, value of -5.67 is converted to an
integer type by truncating (removing) the "67", giving a value of -5. In
both cases, the truncated value is closer to 0, which is why it's
described as being truncated towards zero.

> 82H < 83H. For these negative numbers, it is not rounded towards zero.

What are "these negative numbers"? I don't see any negative numbers in
your message. The only data type you mentioned is unsigned char, which
is incapable of representing a negative number.

The form 83H has no special meaning in C. It would get parsed as a
pp-number during translation phase 4 (6.4.8p1), and then rejected during
translation phase 7 due to the fact that it doesn't match the form of
any of the five permitted types of tokens. I would guess that what you
mean by 83H is equivalent to the C hexadecimal constant 0x83. A key
point to remember about C is that decimal constants, octal constants,
and hexadecimal constants never have a negative value. -3 is NOT a
decimal constant. It is the unary negation operator applied to the
decimal constant 3. 0x83 therefore has the decimal value 131.

My best guess is that you're talking about an 8-bit signed char which is
represented by the same bit pattern that would represent a 0x83 as an
unsigned char; such a char object would represent a negative value: -125
if using 2's complement (by far the most common choice), -3 if using
sign-magnitude, and -124 if using 1's complement (assuming I did the
conversions correctly, which is not guaranteed). C allows for all three
possibilities. C also allows CHAR_BIT > 8; CHAR_BIT==16 is not uncommon
in C compilers targeting DSPs.

> Is the above link not talking the same thing with my understanding?

I'm not sure what you're understanding is, but your words make it pretty
clear that your understanding is incorrect, and that the above link is
referring to something quite different.

I'm not sure what your comments "one bit LSB truncation" are intended to
mean. There appears to be some resemblance between what you're talking
about and division by 2, so I'll use such a division in my example below.

There is a "toward zero" rule that applies to integers. It applies
specifically to integer division. "When integers are divided, the result
of the / operator is the algebraic quotient with any
fractional part discarded." (6.5.5p6). Thus, 8/3 is algebraically 2 2/3.
Discarding  the 2/3 leaves the C value of 8/3 == 2. Algebraically,
-125/2 is  -62 1/2; discarding the 1/2 leaves the C value of (-125)/2 ==
-62. In both cases, the result of integer division is closer to 0 than
the algebraic quotient would be, which is why footnote 105 says that
this rule 'is often called "truncation toward zero"'.

Note that the C rule is entirely in terms of the meaning of the value
being represented, it is not in terms of the bit pattern being used to
represent it. A signed char variable containing a value of -125 will,
when divided by 2, give a result of -62, regardless of whether it's
represented in 2's complement, 1's complement, or sign-magnitude, and
regardless of whether char has 8 bits, 9 bits, 16 bits, or any other
permitted size.

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

#70942

On 9/19/2015 3:25 PM, fl wrote:
> Hi,
>
> I see the following on wikipedia and doubt about negative integer when
>   truncating.
>
> https://en.wikipedia.org/wiki/Type_conversion
> ///////
>   Data can be lost when floating-point representations are converted to integer
>   representations as the fractional components of the floating-point values
>   will be truncated (rounded towards zero)
> .......
>
> I agree for positive integer, truncation in C is towards 0. But for negative
> integer, it looks like away from '0'. For example, for a unsigned char 83H,
> one bit (LSB) truncation result will be 41H, whose non-truncation value
> (8-bit) is equal to 82H. The real value of 82H plus '1' is 83H. That is,
> 82H < 83H. For these negative numbers, it is not rounded towards zero.
>
> Is the above link not talking the same thing with my understanding?

     The quote is about converting *floating-point* values to integer.

     It's true that C's integer types have a few traps for the unwary
and inexperienced, though.  Be especially careful of those singed
integers: They can *really* burn you!

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#70964

fl <rxjwg98@gmail.com> writes:

> Hi,
>
> I see the following on wikipedia and doubt about negative integer when
>  truncating.
>
> https://en.wikipedia.org/wiki/Type_conversion
> ///////
>  Data can be lost when floating-point representations are converted to integer
>  representations as the fractional components of the floating-point values
>  will be truncated (rounded towards zero)
> .......
>
> I agree for positive integer, truncation in C is towards 0. But for negative
> integer, it looks like away from '0'. For example, for a unsigned char 83H,
> one bit (LSB) truncation result will be 41H, whose non-truncation value 
> (8-bit) is equal to 82H. The real value of 82H plus '1' is 83H. That is,
> 82H < 83H. For these negative numbers, it is not rounded towards zero.
>
> Is the above link not talking the same thing with my understanding?

You're missing that a floating point format is (almost) completely
different from an integer format.  Truncation isn't a simple matter of
lopping the most significant bits off an integer representation, it's a
decision made as part of a fairly complicated conversion process.

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

#70974

With regard to the subject line: how did the integer got singed? :-)

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

#70981

James Kuyper <jameskuyper@verizon.net> writes:

> With regard to the subject line: how did the integer got singed? :-)

I'm guessing the CPU fan failed :)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web