I searched through the newsgroup for this and found the answer but
wanted to make sure because of something that came up.
I want the absolute value of a 'short int' so to avoid the dangers of
overflow I am doing the follow:
short int x = -4; /* want abs(x) */
unsigned short int abs_val;
....
/* already performed check to make sure x is negative */
abs_val = -(unsigned short int)x;
I take it that the above is how I should safely get the absolute value
of a negative number. I want to confirm this because my Lint package
says that there is a:
"Loss of sign(assignment)(int to unsigned short)."
Thanks! 17 1945
joshc wrote: /* already performed check to make sure x is negative */ abs_val = -(unsigned short int)x;
I take it that the above is how I should safely get the absolute
value of a negative number. I want to confirm this because my Lint package says that there is a: "Loss of sign(assignment)(int to unsigned short)."
I just wanted to add that if I cast that whole thing to an unsigned
short int then I don't get that message but I'm still curious why Lint
warns me without the cast.
joshc wrote: ... I want the absolute value of a 'short int' so to avoid the dangers of overflow I am doing the follow:
short int x = -4; /* want abs(x) */ unsigned short int abs_val;
...
/* already performed check to make sure x is negative */ abs_val = -(unsigned short int)x;
I take it that the above is how I should safely get the absolute value of a negative number.
Let's see what happens in this expression.
Initially, the operand ('x') is implicitly promoted to type 'int' (the
value is preserved). Then the conversion to 'unsigned short' causes the
original value to wrap around zero/SHORT_MAX+1 limit in accordance with
the rules of modulo arithmetics, i.e. the original negative value turns
into the positive value 'SHORT_MAX+1+x'. This value is once again
implicitly promoted to type 'int' (the value is preserved). And now the
unary '-' is applied to the operand, resulting in a negative value
'-SHORT_MAX-1-x' of 'int' type. Now, this final value is squeezed into a
variable of type 'unsigned short'. This will cause another wraparound.
The final value is positive '-SHORT_MAX-1-x+SHORT_MAX+1'. It is indeed
equal to '-x'.
It appears to be working (I hope I didn't miss anything), but if I were
you I wouldn't jump through all those hoops and employ all that
wraparound trickery to get to the negation of the original value. I
would do it this way instead
/* already performed check to make sure x is negative */
abs_val = -x;
This just makes more sense than the original version.
--
Best regards,
Andrey Tarasevich
joshc wrote: joshc wrote:
/* already performed check to make sure x is negative */ abs_val = -(unsigned short int)x;
I take it that the above is how I should safely get the absolute value of a negative number. I want to confirm this because my Lint package says that there is a: "Loss of sign(assignment)(int to unsigned short)."
I just wanted to add that if I cast that whole thing to an unsigned short int then I don't get that message but I'm still curious why Lint warns me without the cast.
I don't exactly understand why the above cast helps you to get rid of
the warning. But if you really want to use the cast, it would probably
make more sense to do it like this
abs_val = (unsigned short int) -x;
Read my previous message for more details.
--
Best regards,
Andrey Tarasevich
Andrey Tarasevich wrote: Let's see what happens in this expression.
Initially, the operand ('x') is implicitly promoted to type 'int'
(the value is preserved). Then the conversion to 'unsigned short' causes
the original value to wrap around zero/SHORT_MAX+1 limit in accordance
with the rules of modulo arithmetics, i.e. the original negative value
turns into the positive value 'SHORT_MAX+1+x'. This value is once again implicitly promoted to type 'int' (the value is preserved). And now
the
I don't see why after the negation the value would be "implicity
promoted to type 'int'." I cast x to an (unsigned short int) so why
would it be cast back to a signed int? It appears to be working (I hope I didn't miss anything), but if I
were you I wouldn't jump through all those hoops and employ all that wraparound trickery to get to the negation of the original value. I would do it this way instead
/* already performed check to make sure x is negative */ abs_val = -x;
This just makes more sense than the original version.
The problem with that way is that you can have overflow if x =
SHRT_MIN because abs(SHRT_MIN) can be greater than SHRT_MAX.
Andrey Tarasevich wrote: joshc wrote:
joshc wrote:
/* already performed check to make sure x is negative */ abs_val = -(unsigned short int)x;
I take it that the above is how I should safely get the absolute value of a negative number. I want to confirm this because my Lint
package says that there is a: "Loss of sign(assignment)(int to unsigned short)."
I just wanted to add that if I cast that whole thing to an unsigned short int then I don't get that message but I'm still curious why
Lint warns me without the cast.
I don't exactly understand why the above cast helps you to get rid of the warning. But if you really want to use the cast, it would
probably
What I meant was if I do the following:
abs_val = (unsigned short int)(-(unsigned short int)x);
That seems to get rid of the warning.
thx.
joshc wrote: ... Let's see what happens in this expression.
Initially, the operand ('x') is implicitly promoted to type 'int' (the value is preserved). Then the conversion to 'unsigned short' causes the original value to wrap around zero/SHORT_MAX+1 limit in accordance with the rules of modulo arithmetics, i.e. the original negative value turns into the positive value 'SHORT_MAX+1+x'. This value is once again implicitly promoted to type 'int' (the value is preserved). And now the
I don't see why after the negation the value would be "implicity promoted to type 'int'." I cast x to an (unsigned short int) so why would it be cast back to a signed int?
Speaking informally, C never performs any arithmetical computations on
types smaller than 'int'. Whenever you get a value of smaller type, that
value is immediately implicitly promoted to 'int' (or 'unsigned int', if
'int' is too narrow). This process is called 'integral promotion'. In
many cases it is purely conceptual, i.e. it doesn't really take place in
the final code, but it is still important to take it into account in
general case, because it can affect the final result. It appears to be working (I hope I didn't miss anything), but if I
were you I wouldn't jump through all those hoops and employ all that wraparound trickery to get to the negation of the original value. I would do it this way instead
/* already performed check to make sure x is negative */ abs_val = -x;
This just makes more sense than the original version.
The problem with that way is that you can have overflow if x = SHRT_MIN because abs(SHRT_MIN) can be greater than SHRT_MAX.
Not really that simple. The original value of 'x', as I said above, is
promoted to 'int' before '-' is applied. And '-' is computed within the
bounds of type 'int', not within the bounds of type 'short'. However,
the overflow you describe is still possible if, for example, INT_MIN ==
SHORT_MIN and INT_MAX == SHOT_MAX. But that's more of a question of what
do you want to have as the final result in this case, not the problem
with this particular approach.
--
Best regards,
Andrey Tarasevich
Andrey Tarasevich wrote: ... I want the absolute value of a 'short int' so to avoid the dangers of overflow I am doing the follow:
short int x = -4; /* want abs(x) */ unsigned short int abs_val;
...
/* already performed check to make sure x is negative */ abs_val = -(unsigned short int)x;
I take it that the above is how I should safely get the absolute value of a negative number. Let's see what happens in this expression.
A couple of important corrections follow.
Initially, the operand ('x') is implicitly promoted to type 'int' (the value is preserved). Then the conversion to 'unsigned short' causes the original value to wrap around zero/SHORT_MAX+1 limit in accordance with
Should be "... wrap around zero/USHORT_MAX+1 limit ..."
the rules of modulo arithmetics, i.e. the original negative value turns into the positive value 'SHORT_MAX+1+x'. This value is once again
USHORT_MAX+1+x
implicitly promoted to type 'int' (the value is preserved).
It is possible that at this stage the value is promoted to type
'unsigned short'. The choice depends on whether 'int' is large enough to
represent all 'unsigned short' values. If it is (USHORT_MAX <= INT_MAX),
'int' is chosen. Otherwise (USHORT_MAX > INT_MAX), 'unsigned int' is chosen.
And now the unary '-' is applied to the operand, resulting in a negative value '-SHORT_MAX-1-x' of 'int' type.
'-USHORT_MAX-1-x' of type 'int' if the previous promotion was to 'int'.
Otherwise, if the previous promotion was to 'unsigned int', the result
of unary '-' application is a positive value 'UINT_MAX-USHORT_MAX-x' of
type 'unsigned int'.
Now, this final value is squeezed into a variable of type 'unsigned short'. This will cause another wraparound. The final value is positive '-SHORT_MAX-1-x+SHORT_MAX+1'. It is indeed equal to '-x'.
'-USHORT_MAX-1-x+USHORT_MAX+1' in case of 'int' promotion and the final
result is '-x'.
In case of 'unsigned int' promotion, the value of
'UINT_MAX-USHORT_MAX-x' will be wrapped around 'USHORT_MAX + 1' boundary
and it appears that it does not give the desired result in general case,
unless I'm missing something.
--
Best regards,
Andrey Tarasevich
Andrey Tarasevich wrote: Andrey Tarasevich wrote: ... I want the absolute value of a 'short int' so to avoid the dangers
of overflow I am doing the follow:
short int x = -4; /* want abs(x) */ unsigned short int abs_val;
...
/* already performed check to make sure x is negative */ abs_val = -(unsigned short int)x;
I take it that the above is how I should safely get the absolute
value of a negative number. Let's see what happens in this expression.
A couple of important corrections follow.
Initially, the operand ('x') is implicitly promoted to type 'int'
(the value is preserved). Then the conversion to 'unsigned short' causes
the original value to wrap around zero/SHORT_MAX+1 limit in accordance
with Should be "... wrap around zero/USHORT_MAX+1 limit ..."
the rules of modulo arithmetics, i.e. the original negative value
turns into the positive value 'SHORT_MAX+1+x'. This value is once again
USHORT_MAX+1+x
implicitly promoted to type 'int' (the value is preserved).
It is possible that at this stage the value is promoted to type 'unsigned short'. The choice depends on whether 'int' is large enough
to represent all 'unsigned short' values. If it is (USHORT_MAX <=
INT_MAX), 'int' is chosen. Otherwise (USHORT_MAX > INT_MAX), 'unsigned int' is
chosen. And now the unary '-' is applied to the operand, resulting in a negative value '-SHORT_MAX-1-x' of 'int' type. '-USHORT_MAX-1-x' of type 'int' if the previous promotion was to
'int'. Otherwise, if the previous promotion was to 'unsigned int', the
result of unary '-' application is a positive value 'UINT_MAX-USHORT_MAX-x'
of type 'unsigned int'.
Now, this final value is squeezed into a variable of type 'unsigned short'. This will cause another
wraparound. The final value is positive '-SHORT_MAX-1-x+SHORT_MAX+1'. It is
indeed equal to '-x'. '-USHORT_MAX-1-x+USHORT_MAX+1' in case of 'int' promotion and the
final result is '-x'.
In case of 'unsigned int' promotion, the value of 'UINT_MAX-USHORT_MAX-x' will be wrapped around 'USHORT_MAX + 1'
boundary and it appears that it does not give the desired result in general
case, unless I'm missing something.
-- Best regards, Andrey Tarasevich
Thanks for reminding me about integer promotions. That kind of
complicates things for the short int case. My reasoning was based on
what I had read about calculating the absolute value of an "int" but as
you correctly pointed out that doesn't apply to short int.
So basically I have a bunch of typedef'd types like uint16, uint32,
int16, int32, etc. How can I make safe absolute value functions for
these types since their base types can be changed(so I don't know if
integer promotions will be applicable or not)?
I have seen plenty of threads on absolute value functions for "int" but
in light of the issues you brought up I am not clear as to how to
proceed.
Thanks.
joshc wrote: Andrey Tarasevich wrote: joshc wrote:
joshc wrote:
> /* already performed check to make sure x is negative */ > abs_val = -(unsigned short int)x; > > I take it that the above is how I should > safely get the absolute value > of a negative number. I want to > confirm this because my Lint package > says that there is a: > "Loss of sign(assignment)(int to unsigned short)."
I just wanted to add that if I cast that whole thing to an unsigned short int then I don't get that message but I'm still curious why Lint warns me without the cast. I don't exactly understand why the above cast helps you to get rid of the warning. But if you really want to use the cast, it would probably
What I meant was if I do the following:
abs_val = (unsigned short int)(-(unsigned short int)x);
That seems to get rid of the warning.
I recomend that you don't use small arithmetic types:
float, unsigned short, short, signed char, unsigned char, and char
in any way other than as array element types or string characters,
unless you have a special reason.
Also for
I want the absolute value of a 'short int' so to avoid the dangers of overflow I am doing the follow:
short int x = -4; /* want abs(x) */ unsigned short int abs_val;
It is not guaranteed that there is an integer type
which is capable of representing the magnitude SHORT_MIN.
--
pete
pete wrote: joshc wrote: I want the absolute value of a 'short int' so to avoid the dangers of overflow I am doing the follow:
short int x = -4; /* want abs(x) */ unsigned short int abs_val;
It is not guaranteed that there is an integer type which is capable of representing the magnitude SHORT_MIN.
ITYM: SHRT_MIN
--
Peter
Peter Nilsson wrote: pete wrote: joshc wrote: I want the absolute value of a 'short int' so to avoid the dangers of overflow I am doing the follow:
short int x = -4; /* want abs(x) */ unsigned short int abs_val;
It is not guaranteed that there is an integer type which is capable of representing the magnitude SHORT_MIN.
ITYM: SHRT_MIN
That's what I think too.
--
pete
pete wrote: joshc wrote: Andrey Tarasevich wrote: joshc wrote:
> joshc wrote: > >> /* already performed check to make sure x is negative */ >> abs_val = -(unsigned short int)x; >> >> I take it that the above is how I should >> safely get the absolute value >> of a negative number. I want to >> confirm this because my Lint package >> says that there is a: >> "Loss of sign(assignment)(int to unsigned short)." > > I just wanted to add that if I cast that > whole thing to an unsigned > short int then I don't get that message > but I'm still curious why Lint > warns me without the cast.
I don't exactly understand why the above cast helps you to get rid of the warning. But if you really want to use the cast, it would probably What I meant was if I do the following:
abs_val = (unsigned short int)(-(unsigned short int)x);
That seems to get rid of the warning.
I recomend that you don't use small arithmetic types: float, unsigned short, short, signed char, unsigned char, and
char in any way other than as array element types or string characters, unless you have a special reason.
Also for
I want the absolute value of a 'short int' so to avoid the dangers
of overflow I am doing the follow:
short int x = -4; /* want abs(x) */ unsigned short int abs_val;
It is not guaranteed that there is an integer type which is capable of representing the magnitude SHORT_MIN.
-- pete
Things seem to get less clear... The code I'm working on has typedefs
like I mentioned for 16-bit, 32-bit, etc integer types, signed and
unsigned. The problem is that since the actual type, i.e. short or int,
etc. is hidden under the typedef how can I safely calculate the
absolute value of a negative number for type int16 and int32?
I think I understand from reading other threads that calculating the
absolute value of an 'int' can be achieved by: -(unsigned int)x;
The problem is for short ints like Andrey mentioned integer promotions
occur so it will be promoted to an int or unsigned int and this seems
to complicate things, especially when I don't know if the type I am
dealing with is actually a short or just an int since I am dealing with
int16, int32, etc.
Thanks.
pete wrote: joshc wrote: I want the absolute value of a 'short int' so to avoid the dangers
of overflow I am doing the follow:
short int x = -4; /* want abs(x) */ unsigned short int abs_val;
It is not guaranteed that there is an integer type which is capable of representing the magnitude SHORT_MIN.
Hmm, yes, after reading over 5.2.4.2.1 it seems that you are correct
about no guarantee that an integer type exists capable of representing
SHRT_MIN.
If you read my post further down below then I think I might not have to
deal with this problem because I am dealing with derived types such as
int16, int32, etc. and they are defined such that uint16_MAX = 65535
and int16_min = -32768... However, I am still confused about how to
achieve what I asked initially- computing the absolute value of int16
and int32...
joshc wrote: pete wrote: joshc wrote: I want the absolute value of a 'short int' so to avoid the
dangers of overflow I am doing the follow:
short int x = -4; /* want abs(x) */ unsigned short int abs_val; It is not guaranteed that there is an integer type which is capable of representing the magnitude SHORT_MIN.
Hmm, yes, after reading over 5.2.4.2.1 it seems that you are correct about no guarantee that an integer type exists capable of
representing SHRT_MIN.
If you read my post further down below then I think I might not have
to deal with this problem because I am dealing with derived types such
as int16, int32, etc. and they are defined such that uint16_MAX = 65535 and int16_min = -32768... However, I am still confused about how to achieve what I asked initially- computing the absolute value of int16 and int32...
After looking at 6.2.6.2 in the Standard, it seems that maybe there is
an implication that USHRT_MAX >= abs(SHRT_MIN) because unsigned short
and short have to occupy the same amount of storage and signed shorts
require 1 sign bit. I am a newcomer to actually reading the standard so
my explanation above is very likely incorrect and I'm looking for
feedback.
joshc wrote:
.... snip ... Hmm, yes, after reading over 5.2.4.2.1 it seems that you are correct about no guarantee that an integer type exists capable of representing SHRT_MIN.
How can you say that? The follow excerpt from N869 shows that
INT_MIN has to be capable of handling SHRT_MIN at their respective
minimums, and no implementor in his right mind would make a short
have a greater range than an int.
-- minimum value for an object of type short int
SHRT_MIN -32767 // -(215-1)
-- maximum value for an object of type short int
SHRT_MAX +32767 // 215-1
-- maximum value for an object of type unsigned short int
USHRT_MAX 65535 // 216-1
-- minimum value for an object of type int
INT_MIN -32767 // -(215-1)
--
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
CBFalconer wrote: joshc wrote: ... snip ... Hmm, yes, after reading over 5.2.4.2.1 it seems that you are correct about no guarantee that an integer type exists capable of representing SHRT_MIN.
How can you say that? The follow excerpt from N869 shows that INT_MIN has to be capable of handling SHRT_MIN at their respective minimums, and no implementor in his right mind would make a short have a greater range than an int.
-- minimum value for an object of type short int SHRT_MIN -32767 // -(215-1)
-- maximum value for an object of type short int SHRT_MAX +32767 // 215-1
-- maximum value for an object of type unsigned short int USHRT_MAX 65535 // 216-1
-- minimum value for an object of type int INT_MIN -32767 // -(215-1)
-- "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare
Nice, I was hoping for input from yourself or Eric Sosman who seem to
be the authority around here :). As you can tell I am rather new to
actually reading the standard and understanding it but I think I
corrected myself in a later post.
How can you say that? The follow excerpt from N869 shows that INT_MIN has to be capable of handling SHRT_MIN at their respective minimums, and no implementor in his right mind would make a short have a greater range than an int.
Anyways, isn't this not even up to the implementor?
6.2.5.8:
"8 For any two integer types with the same signedness and different
integer conversion rank
(see 6.3.1.1), the range of values of the type with smaller integer
conversion rank is a
subrange of the values of the other type."
Doesn't this guarantee what you are saying about INT_MIN having to be
at least as big as SHRT_MIN? I think what Andrey was saying though was
that no integer has to be capable of handling abs(SHRT_MIN). In my
later post I gave my understanding of this situation but I need it
confirmed.
Thanks.
CBFalconer <cb********@yahoo.com> writes: joshc wrote: ... snip ... Hmm, yes, after reading over 5.2.4.2.1 it seems that you are correct about no guarantee that an integer type exists capable of representing SHRT_MIN.
How can you say that? The follow excerpt from N869 shows that INT_MIN has to be capable of handling SHRT_MIN at their respective minimums, and no implementor in his right mind would make a short have a greater range than an int.
pete's comment upthread (which joshc inadvertentliy misrepresented)
was:
] It is not guaranteed that there is an integer type
] which is capable of representing the magnitude SHORT_MIN.
Obviously short (and all longer signed types) can represent SHORT_MIN,
but there may not be a type that can represent the absolute magnitude
of SHORT_MIN. For example, if short is 64 bits, SHORT_MIN could be
-2**63; they may not be a type that can represent +2**63. (I've used
systems where this is the case.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Carlos Ribeiro |
last post by:
I was checking the Prolog recipe in the Cookbook:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/303057
It's a clever implementation that explores some aspects of Python that
I wasn't...
|
by: Dave Theese |
last post by:
Am I correct in saying that it is not possible to overload unary + and
unary -?
|
by: John J |
last post by:
To write a unary operator- operation that returns the negative of a value is
it just as simple as subtracting the value from itself?
ie.
{
return (value - value);
}
Thanks
|
by: Ruben Campos |
last post by:
Some questions about this code:
template <typename T> class MyTemplate;
template <typename T> MyTemplate <T> operator- (const MyTemplate <T> &
object);
template <typename T> MyTemplate <T>...
|
by: Javier Estrada |
last post by:
1. For types smaller than int, when I compile:
class MyClass
{
static void Main(string args)
{
x = 10;
y = -x;
}
|
by: Heloise |
last post by:
Hi all,
I'm trying to write an overloaded operator for unary negation e.g.,
MyClass a(5);
MyClass b(0);
b = -a;
Here is my class implementation:
|
by: Marc |
last post by:
Hi,
I've been lurking on clc for a few months now, and want to start by
thanking the regulars here for opening my eyes to a whole new dimension
of "knowing c". Considering I had never even...
|
by: dspfun |
last post by:
I'm trying to get a good understanding of how unary operators work and
have some questions about the following test snippets.
int *p;
~!&*++p--;
It doesn't compile, why? The problem seems to be...
|
by: JoseMariaSola |
last post by:
How may operators and operands does (typename) expression has?
I'd say one operator, the cast operator, and two operands: typename
and expression.
But everywhere I read, cast is categorized as...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |