help-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Help-glpk] bigmul in glblib05.c


From: Cheng,Jen-Min
Subject: RE: [Help-glpk] bigmul in glblib05.c
Date: Wed, 6 Jan 2010 09:59:33 -0800

In the code, I is declared as unsigned int.  

-----Original Message-----
From: Andrew Makhorin [mailto:address@hidden 
Sent: Wednesday, January 06, 2010 9:47 AM
To: Michael Hennebry
Cc: Cheng,Jen-Min; address@hidden
Subject: Re: [Help-glpk] bigmul in glblib05.c

>> The statement:
>>
>>   unsigned short c = (unsigned short)( i & USHRT_MAX);
>>
>> is absolutely equivalent to:
>>
>>   unsigned short c = (unsigned short)i;

> Actually it's not.
> The result of the latter statement can be determined
> from the value of i and the value of USHRT_MAX.
> If i is negative, the result of the former also
> depends on the representation of negative numbers.
> I'd go with the latter.
> Failing that, I'd put in a test for twos complement:
> unsigned short c = (unsigned short)( (i & USHRT_MAX) +
(1-1/(-1==1+~1)));

In a general sense you are right. And the ISO C standard also gives
a freedom to particular implementations (though in most cases it
just say that the result is implementation-defined). However, to-day
there are few programming models that are really used on practice;
see http://www.unix.org/version2/whatsnew/lp64_wp.html . So we can
assume that byte/char has 8 bits, short has 16 bits, negative numbers
are represented by two's complement, etc. Even floating-point numbers
are now standardized due to IEEE, and I don't think that all these
things will change in the future (at least for next 30 years) just
because there is no reason to change them. Computers with 47-bit words
have sunk into Lethe.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]