tada@athena.mit.edu (Michael J Zehr) (09/17/89)
In article <2110@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes: >This will >give similar trouble on machines with VAX arithmetic (some bit patterns >when considered as floats are "invalid operands" which trap when/if you >touch them) and on machines with IEEE arithmetic and traps enabled (the >IEEE default is _not_ to enable traps!) where some bit patterns (called >Signalling NaNs) trap. I once wasted a lot of code dealing with something like: (hopefully this example will save someone else time recognizing it in the future...) if (data == 0) {zero_cnt++; continue;} if NaN(data) {nan_cnt++; continue;} do_something(data); the problem was that do_something() was getting garbage results. the reason was that if data was a bit pattern which was invalid, the comparison of it to 0 would change it's value to a particular number!!! (i think it was the maximum value for it's data type, but i never verified that.) the solution, of course, was to switch the two lines. -michael j zehr
diamond@csl.sony.co.jp (Norman Diamond) (09/18/89)
In article <14344@bloom-beacon.MIT.EDU> tada@athena.mit.edu (Michael J Zehr) writes: >I once wasted a lot of code dealing with something like: > if (data == 0) {zero_cnt++; continue;} > if NaN(data) {nan_cnt++; continue;} > do_something(data); >if data was a bit pattern which was invalid, the >comparison of it to 0 would change it's value to a particular number!!! That seems like a somewhat illegal implementation. I don't see an "&" in front of data, and you didn't say you're using C++. So the NaN function can only get its hands on a COPY of data, and change its COPY to a different value (according to K&R-*, ANSI, Version 6, etc.) -- -- Norman Diamond, Sony Corporation (diamond@ws.sony.junet) The above opinions are inherited by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo or Anterior, then their administrators must have approved of these opinions.