[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