[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JULDAY 5.4 not same as 5.3?
"Craig Markwardt" <craigmnet@cow.physics.wisc.edu> wrote in message
onzoezonz8.fsf@cow.physics.wisc.edu">news:onzoezonz8.fsf@cow.physics.wisc.edu...
> pit@phys.uu.nl (Peter Suetterlin) writes:
> ...
> > I'm still not sure who's to blame, me (i.e. the programmer) or
> > IDL/RSI, but in general it does not make sense to take a negative of a
> > unsigned number, and IMHO there should also occur an automatic type
> > conversion as soon as a minus sign is involved. Currently, you get e.g.
> >
> > IDL> x=5b
> > IDL> print,-x
> > 251
>
> We can argue all day about what is correct mathematically.
>
> However I think it is correct from a microprocessor standpoint (ie,
> that's what the processor does). Further more it satisfies certain
> identities like:
>
> (-x) + x EQ 0
Actually, under Peter's proposal (-x) + x would equal 0 for unsigned x.
> And what would you do with a number like -('ffffffff'xul), ie a number
> that to begin with is too large to fit into a signed type.
Now, that is a good point.
There are other situations where auto-magical type conversion could save
programmers' skins but is not done by IDL, e.g. 32767S + 1S evaluates
to -32767S, not 32768L. Hands up who hasn't been stung by that one!
On the whole I agree with Craig that type conversion should be done
sparingly by the core language, because it opens up a can of worms. If -5B
is promoted to an unsigned integer, what about (0B-5B)? If the latter is
promoted, then what about (6B-5B)?
---
Mark Hadfield
m.hadfield@niwa.cri.nz http://katipo.niwa.cri.nz/~hadfield
National Institute for Water and Atmospheric Research