Re: compression in floating point arithmetic

Jun Woong wrote:


In early postings of this thread, you misunderstood that contraction
of floating-point expressions was involved with the weird result of
your code. Jack Klein's explaining of it, he said to you that
introducing an intermediate variable solved the problem of the code:

If you want to force floating point values to the same type,
explicitly define objects of that type and assign the floating
point result to them.

For his answer, you asked the reason such a handling was necessary.

all correct.

Now, let's see what the standard says.

6.3.1.8p2 is the essential wording for allowing an implementation to
use a wider precision and/or range to represent a fp number than its
semantic type has.

right.

With no additional restriction on the wider
representation, an implementation is not obliged to give up it even
when a fp number is returned from a function.

that's the point. The standard is big: sometimes a footnote like the 52 helps you because it states something that represents a restriction and that is stated in a normative and formal way in another part of the standard, like for the cast truncation. I was thinking that the sequence point stuff could affect in some way this behaviour, it just seemed very reasonable reading the standard, even if not explicitally stated. I was wrong, as we discovered, and of course I'm cool with that. But the point in this case is that I needed what you said in the last sentence, that is, to be shown that the implementation is not forced to truncate the precision in the return. So, citing that paraghraph in my opinion is pointless (also because it had been already cited and we knew about that).

Now, if someone ask *why* the special handlings are necessary, then
it is a proper answer to give 6.3.1.8p2.

In my opinion is not enough, as I explained before.

On the contrary, if someone
ask *where* the standard specifies them, then it is a proper answer
to give 6.3.1.5 (and possibly the footnotes mentioned above).

Fair enough.

You asked why, not where:

Why should it be necessary?

which means, if you thought his answer didn't help, that means your
question failed to deliver your intent probably because you didn't
quite well understand how the standard made the augmented precision
and range work.

It just failed to address my question and I thought that the explanation was the correct answer to another question, while it was the wrong answer to the right question. I was wrong as well, I'm not denying that :)

And here is where you are wrong. In order to show me that the operation
is NECESSARY, he has to demonstrate that in the other way it wouldn't be
correct (and that's what I asked). This means that he should have
showed me that in the other way the augmented precision can be carried out.


The augmented precision can be carried out because 6.3.1.8p2 says so
and nothing else says it cannot be.

Ok. I was thinking that at some point there were something that said that it couldn't be. So, in order to show me that the cast is necessary, I would need to be shown that "nothing else says it cannot be", not that "6.3.1.8p2 says so". Of course you don't need to explain to me the entire standard, there was just a specific point I thought it was saying that the truncation was forbidden, so for me it would have been enough that someone could explain me that in this case that point doesn't apply (like for example Jack did when he showed me that the contraction thing was wrong).

That's it. Easy peasy, nothing really to argue about.


Yep, there had been nothing to argue about before you claimed those
unreasonable things.

It doesn't seem so unreasonable to me. Maybe, since we are still arguing about that, the whole thing is not so straightforward as it seemed to me at the beginning.

Regards,

Zeppe
.

Relevant Pages

  • Re: compression in floating point arithmetic
    ... the type is represented as long as the precision is wider. ... > that type and assign the floating point result to them. ... It's necessary to reduce the augmented precision of the expression result, because otherwise the standard allows the augmented precision to be returned by the return statement. ...
    (comp.std.c)
  • Re: Sine code for ANSI C
    ... >> shell script) fully conforming. ... limits mentioned in the standard. ... adding a few more translation limits. ... minimal accuracy requirements for the floating point operations. ...
    (comp.lang.c)
  • Re: Rfd: floating point truncation V1
    ... Some other standard I looked at makes "round towards zero" ... an internal representation of floating point negative zero, "-0E", which differs ... to go for an IEEE FP extension). ...
    (comp.lang.forth)
  • Re: Very weird resolution issue. Bug ????? Seriously !!
    ... That's a good example of gray area that IEEE standard cannot ... But floating point accuracy was not my issue. ... Assumption of consistency on 'scientific' software was my mistake? ... guarantees of the standards and documentation. ...
    (comp.soft-sys.matlab)
  • Re: [xpost] a new C/C++ type that when overflow i see it
    ... The standard defines clearly what happens with floating point overflow. ... Obviously there will be implementations of C where the machine has no ...
    (comp.lang.c)