From: Tony Williams 

Yep, when you're doing integer math you always have to watch the
sub-expressions to make sure you can't generate an overflow. That can be
the source of some really hard to track down bugs and coders generally get
in the habit of reordering calculations or even doing them in several steps
to defend against it.

C++ : coding without the training wheels (or seat belt, or air bag).

--
Tony

On 12/10/2004 03:35 PM, Geo wrote:
> This is really interesting, it means that any int math functions involving
> multiplication and division are not order neutral like they would be with
> float or double variables.
>
> Geo.
>
> "Paul Ranson"  wrote in message
news:41b991f6{at}w3.nls.net...
>
>>'rand()/RAND_MAX' will usually evaluate to 0. All integer arithmetic
>
> always
>
>>works and you never get an exception, that's just how CPUs go.
>>
>>If you write it as 'rand() * 9999 / RAND_MAX' then the multiplication will
>>be done first and you'll get a more sensible answer. I'm not convinved
>>though that the sensible answer will be a random number between 0 and
>
> 9999.
>
>>But this is nothing to do with C and everything to do with maths.
>>
>>For values of 'rand()' 0, 1, 2, 3 you'll get 0, for 4, 5, 6 you'll get 1,
>>for 7, 8, 9 you get 2 etc etc. Work it out on a calculator and conver to
>>'int' by rounding down.
>>
>>Paul
>>
>>"Geo"  wrote in message
news:41b97df5$1{at}w3.nls.net...
>>
>>>"John Beckett"
 wrote in message
>>>news:41b92073.3609980{at}216.144.1.254...
>>>
>>>>"Geo"  wrote in message
news::
>>>
>>>>>int n = (rand()/32767)*9999999999999
>>>>>
>>>>>That shouldn't generate a cpu error, the error would come when it
>
> goes
>
>>>to
>>>
>>>>>store a multibyte value in a single byte location (or maybe at
>
> compile
>
>>>>>time?)
>>>>
>>>>I don't follow your meaning. If you intend that the
"9999999999999" is
>>>>too
>>>>large for an int, the compiler would assume it is a long int. If the
>>>>value
>>>>is too large for a long int,
>>>
>>>What I was trying to say (and I haven't tested this yet due to lack of
>>>time)
>>>is that the computer will evaluate the right side of the above equation
>>>using 32 bits not 8 bits. If that's true then
>>>
>>>int n = (rand()/MAX_RAND)*9999
>>>
>>>should come out as
>>>
>>>int n = (0.123)*9999
>>>
>>>or something greater than 1 and so int n should come out to something
>>>other
>>>than zero, no? If not then this would be very limiting for doing
>
> anything
>
>>>using rand() and an int value since (rand()*9999)/MAX_RAND could also
>>>evaluate to something that blows int limits (for example if rand() is
>>>32000).
>>>
>>>Geo.
>>>
>>>
>>
>>
>
>

--- BBBS/NT v4.01 Flag-5