From: Michael Kilburn on
On Jul 18, 3:30 pm, Daniel Kr�gler <daniel.krueg...(a)googlemail.com>
wrote:
> > ...
> > As you see I am trying to extract ordered sequence (without
> > duplicates, values > 0) from stream of values produced by foo().
>
> > Now -- is it guaranteed that I'll end up with what I seek (ordered, no
> > duplicates)? I feel answer is "yes", but then more important question
> > arises -- where are those guarantees?
>
> I think this is already guaranteed by the basic requirements
> of a C++ program in 1.9/5:
>
> ...
>
> and p. 10:
>
> ...
>

Hmmm... Unless I am missing something these two points outlaw MSVC's
behaviour with respect to 'floating point consistency' compiler
options -- i.e. to write C++ programs using MSVC you *have* to use
strict fp option. Otherwise you'll get MSVC-specific flavor that is
not guaranteed to be portable (between hardware platforms and
compiling environments). Am I correct?

Well, in this case I could probably rest easy and if something goes
wrong blame compiler :-) .

Also, this might be a MSVC-specific question then, but... Which fp
flags guarantee correct execution of that code snippet? (i.e.
guarantee that compiler will properly round double before applying
comparison)
Imho, comparison of doubles is relatively rare operation -- if I was
designing compiler, I'd probably make it always consistent.

Thank you.
Michael.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Michael Kilburn on
On Jul 18, 3:28 pm, "Bo Persson" <b...(a)gmb.dk> wrote:
> > As you see I am trying to extract ordered sequence (without
> > duplicates, values > 0) from stream of values produced by foo().
>
> > Now -- is it guaranteed that I'll end up with what I seek (ordered,
> > no duplicates)? I feel answer is "yes", but then more important
> > question arises -- where are those guarantees?
>
> The answer will be Yes if you use proper settings for you compiler, so
> that it either doesn't use the 80 bit registers or forces the
> appropriate rounding before comparisons. Some compilers have a default
> setting that favors faster code, even if it means being slightly
> non-conforming.
>
> http://msdn.microsoft.com/en-us/library/e7s85ffb.aspx

Compiler can be either conforming or not in my opinion. :-) It does
not make it useless, of course, but obliges programmer (who relies on
some "slightly non-conforming" feature) to add large and scary ifdef
in his code that will prevent anyone compiling it in different
environment without careful analysis.


Thank you.
Michael.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Michael Kilburn on
On Jul 18, 3:30 pm, Zeljko Vrba <mordor.nos...(a)fly.srk.fer.hr> wrote:
> This is different than comparing two doubles that are already stored in
> memory (your original question). Here, the answer can be "no" because
> you don't know whether you're comparing 1) two doubles in memory, or 2)
> one long double in register and one double in memory, or 3) two long
> doubles in two registers (an advanced compiler might cache also the
> last element of the vector in a register).

I was having in mind guarantees provided by C++ standard when I
initially asked this question. standard manipulates with concepts like
"local variable" (not register, etc). For some reason I thought that
x87 "magic" is covered and allowed by standard and was looking for
some info related to guarantees related to "moving doubles around".

But as Daniel pointed out all x87 magic is already outlawed (and my
code will work), so question becomes more of "On given compiler what
are the flags that guarantee correct execution of my code" and
subsequently much less interesting -- i.e. I could relax and do my
work (probably with some extra comment in the code).

Thank you.
Michael.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: nmm1 on
In article <47907461-03be-4803-8bdd-be2b6c1ee9c1(a)w30g2000yqw.googlegroups.com>,
Michael Kilburn <crusader.mike(a)gmail.com> wrote:
>
>Hmmm... Unless I am missing something these two points outlaw MSVC's
>behaviour with respect to 'floating point consistency' compiler
>options -- i.e. to write C++ programs using MSVC you *have* to use
>strict fp option. Otherwise you'll get MSVC-specific flavor that is
>not guaranteed to be portable (between hardware platforms and
>compiling environments). Am I correct?

A good question. It depends a great deal on what the standard
means, what you mean and what Microsoft mean.

The C++ standard inherits far too much of this stuff, implicitly,
from C without making it clear exactly how its wording modifies
the wording in the C standard which is, in any case, thoroughly
confusing and different between C90 and C99. Traditionally, this
didn't matter, as few C++ programmers used floating-point except
in trivial ways.

As far as what you mean goes, it depends critically on what sort
of uses you are making of it - and I am sorry, but I simply can't
be more specific because the area is SO complicated and confusing!

And it is very unclear exactly what Microsoft mean by that statement
in their documentation - i.e. how much they are going to use that
licence to carry extra bits of precision around.

In your code fragment, the most likely issue would arise with the
function call. The following code is very likely to go wrong:

double x = sin(1.0);
if (x == sin(1.0)) ...

However, what you are doing is a lot safer:

double x = sin(1.0);
double y = sin(1.0);
if (x == y) ...

>Well, in this case I could probably rest easy and if something goes
>wrong blame compiler :-) .

True. But the root cause lies deeper, I am afraid.

>Imho, comparison of doubles is relatively rare operation -- if I was
>designing compiler, I'd probably make it always consistent.

You've clearly not seen many scientific programs!



Regards,
Nick Maclaren.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]