Always false float comparisons
Manu via Digitalmars-d
digitalmars-d at puremagic.com
Sun May 15 18:59:53 PDT 2016
On 16 May 2016 at 08:05, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 5/15/2016 1:49 PM, poliklosio wrote:
>
>> Also I think Adam is making a very good point about generl reproducibility
>> here.
>> If a researcher gets a little bit different results, he has to investigate
>> why,
>> because he needs to rule out all the serious mistakes that could be the
>> cause of
>> the difference. If he finds out that the source was an innocuous
>> refactoring of
>> some D code, he will be rightly frustrated that D has caused so much
>> unnecessary
>> churn.
>>
>> I think the same problem can occur in mission-critical software which
>> undergoes
>> strict certification.
>
>
>
> Frankly, I think you are setting unreasonable expectations. Today, if you
> take a standard compliant C program, and compile it with different switch
> settings, or run it on a machine with a different CPU, you can very well get
> different answers. If you reorganize the code expressions, you can very well
> get different answers.
The argument you used against me earlier was that it was unacceptable
for some C code pasted in D to behave differently than in C... but
here you've just destroyed your own argument by noting that C behaves
differently than itself.
The rest of us would never get away with this ;)
For reference:
> > I think it's the only reasonable solution.
> It may be, but it is unusual and therefore surprising behavior.
> > What is the problem with this behaviour I suggest?
> Code will do one thing in C, and the same code will do something unexpectedly different in D.
So let's reopen the discussion from my first post that you dismissed?
If the situation is that C compilers produce no predictable behaviour
(as you claim above, and I agree), what is the harm to applying a
behaviour that actually works?
More information about the Digitalmars-d
mailing list