Re: what does NEAREST(0.,1.) return?



In article <d3hevi$hou$1@xxxxxxxxxxxxxxxxxxxxxxx>,
kargl@xxxxxxxxxxxxxxxxxxxxxxxxxxxx (Steven G. Kargl) wrote:

> In article <nospam-9E5F60.13240212042005@xxxxxxxxxxxxxxxxxx>,
> Richard E Maine <nospam@xxxxxxxxxxxxx> writes:

> > You seem to be assuming that "machine representable number" and "model
> > number" mean the same thing.
>
> No, I'm not assuming the two are the same. I'm simply noting
> that a fortran model number by definition can not support
> subnormal numbers.

Yes, I'd agree with that. But I think it irrelevant. I don't think that
model numbers have any relevance at all. Model numbers are just that -
models. In no way does anything about model numbers restrict what the
processor can have for its representable numbers. Yes, there are
machine-representable numbers that are not equal to model numbers - if
that weren't the case, then there wouldn't be a need to make the
distinction.

At the other extreme (huge instead of tiny), I think I recall a recent
interp about whether there could be representable numbers larger than
huge. I think the answer was "yes". I don't recall whether this was a
formal interp or just an email exchange.

> Is fraction(nearest(0.,1.)) legal?

Assuming IEEE or something similar here (otherwise it is trivial)...

That's a tricky one, mixing representable numbers and model numbers. I
won't stand behind my answer, as I haven't researched it enough, but
almost off the top of my head (i.e. I did a quick look at the standard,
but have not carefully researched it or looked into past discussions of
related questions), I'd guess that it is probably legal and returns zero
because zero is the model number that most closely approximates the
machine-representable nearest(0.,1.).

If someone else has thought about this more carefully than I have, feel
free to contradict me on this. (Well, feel free to contradict me on
anything, but I'm particularly inviting it on this aspect. :-)).

> So, now we have "machine representable number", "processor number"
> and "model number".

I believe that "machine representable number" and "processor number" are
just different wordings for the same thing.

If you want to say that the standard shouldn't use multiple words for
the same thing, particularly without even mentioning that they mean the
same thing, then I'll agree with you. I'll also agree that lots of other
things should be different than they are. :-(

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
.



Relevant Pages

  • Re: Requesting advice how to clean up C code for validating string represents integer
    ... Linkname: c standard - clc-wiki ... with a signed zero (including all IEC 60559 implementations) ... that follow the specification of annex G, the sign of zero ... between brake pedal and brake pads being through a complicated ...
    (comp.lang.c)
  • Re: NULL and zeros
    ... The machine's bizarre internal representation does not excuse the implementation from its obligations. ... standard. ... The standard indeed does not specify what an "all bytes zero" or "all ... the originator of this calloc() is clueless -- my personal ...
    (comp.lang.c)
  • Re: A dead subject
    ... >> made the formula easier, ... > BTW - how many subtractions are required to transform my standard ... Some are already set equal to zero and MOST are not. ... think it is about time that mathematicians stop worshipping zero. ...
    (sci.math)
  • Re: NULL and zeros
    ... Standard says in 7.20.3.1: "The calloc function allocates space for an array of nmemb objects, ... If you are excluding such machines, you are in the wrong newsgroup.", and it's no good. ... bits zero by a call to callocif deemed necessary. ...
    (comp.lang.c)
  • Re: On writing negative zero - with or without sign
    ... interpretations to the standard as written. ... but I see the phrase "the representation of a positive or zero ... required to be no prefix for positive values. ...
    (comp.lang.fortran)