Andrew Wiley Wrote:
What programmer? What algorithm? As far as I can tell, this was found when
testing a library explicitly for accuracy, not in an application, so your
argument doesn't apply.
Hmm... Really... I've messed this.
Kagamin wrote:
It's not me, it's the programmer. He was disgusted that his
algorithm produced garbage, which means, the error was
unacceptable. Mat be it was 1%, may be 80%, I don't, that was
his decision, that the result was unacceptable. The bug
description assumes the problem was in the
Walter Bright Wrote:
How do you decide how many bits should be enough for any algorithm?
The thing is, the FPU has 53 bits of precision and so ought to be correct to
the
last bit.
It's not me, it's the programmer. He was disgusted that his algorithm produced
garbage, which means, the
On Tue, Nov 30, 2010 at 1:43 PM, Kagamin s...@here.lot wrote:
Walter Bright Wrote:
How do you decide how many bits should be enough for any algorithm?
The thing is, the FPU has 53 bits of precision and so ought to be correct
to the
last bit.
It's not me, it's the programmer. He was
import std.conv: to;
void main() {
auto r = to!real(0x1.0076fc5cc7933866p+40L);
auto d = to!double(0x1.0076fc5cc7933866p+40L);
auto f = to!float(0x1.0076fc5cc7933866p+40L);
}
Regarding unit tests, I should really use them :(
Yep, and DbC too, and compile your D code with -w.
The same question goes to you. Why do you call this bug?
It is approximate, but approximation is not an undefined behavior.
It is same as 2 + 1 = 4.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
On 27/11/2010 06:26, Don wrote:
I haven't seen any examples of values which are calculated differently
between the processors. I only found one vague reference in a paper from
CERN.
And because of that comment, I've once again checked
http://hasthelargehadroncolliderdestroyedtheworldyet.com/
so:
I have an unrelated question, this is not a criticism but an honest one.
Why don't you write these 3 lines like:
auto r = to!real (0x1.0076fc5cc7933866p+40L);
auto d = to!double(0x1.0076fc5cc7933866p+40L);
auto f = to!float (0x1.0076fc5cc7933866p+40L);
I have a certain
On Monday, November 29, 2010 12:36:00 bearophile wrote:
so:
I have an unrelated question, this is not a criticism but an honest one.
Why don't you write these 3 lines like:
auto r = to!real (0x1.0076fc5cc7933866p+40L);
auto d = to!double(0x1.0076fc5cc7933866p+40L);
Walter Bright Wrote:
Really? I think, the answer is neither correct nor wrong. It's approximate.
The rules for rounding the mathematical value to the representation are
precise,
and so there is such a thing as the correctly rounded result and the wrong
result.
Well, maybe, but the
On Monday 29 November 2010 21:30:31 s...@so.do wrote:
LOL. I couldn't figure out what was different about those lines (the
extra space
apparently; the fact that the text isn't monospaced makes it harder to
see
though). But no one's over going to get people to agree on spacing any
more
but I wouldn't have thought that it would be worth calling someone on
it. It
just seems nitpicky, honestly.
- Jonathan M Davis
I am sorry if it seems that way, wasn't my intention.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Don Wrote:
The Intel CPU gives the correct answer, but AMD's is wrong. They should
both give the correct result.
Really? I think, the answer is neither correct nor wrong. It's approximate.
If your friend's program operates on ~0x1p+40 values and critically depends on
on the value of the last
If it happens once its a bug, if its repeatable its a feature ;-)
-=mike=-
Kagamin s...@here.lot wrote in message
news:icth6h$1nq...@digitalmars.com...
Don Wrote:
The Intel CPU gives the correct answer, but AMD's is wrong. They should
both give the correct result.
Really? I think, the
Kagamin wrote:
Don Wrote:
The Intel CPU gives the correct answer, but AMD's is wrong. They should
both give the correct result.
Really? I think, the answer is neither correct nor wrong. It's approximate.
The rules for rounding the mathematical value to the representation are precise,
and
On Nov 27, 10 05:25, Simen kjaeraas wrote:
Don nos...@nospam.com wrote:
The difference was discovered through the unit tests for the
mathematical Special Functions which will be included in the next
compiler release. Discovery of the discrepancy happened only because
of several features of D:
On 26.11.2010 23:02, Don wrote:
The code below compiles to a single machine instruction, yet the
results are CPU manufacturer-dependent.
import std.math;
void main()
{
assert( yl2x(0x1.0076fc5cc7933866p+40L, LN2)
== 0x1.bba4a9f774f49d0ap+4L); // Pass on Intel, fails on AMD
}
Don Wrote:
The great tragedy was that an early AMD processor gave much accurate sin
and cos than the 387. But, people complained that it was different from
Intel! So, their next processor duplicated Intel's hopelessly wrong trig
functions.
The same question goes to you. Why do you call
On 28-11-2010 5:49, Dmitry Olshansky wrote:
On 26.11.2010 23:02, Don wrote:
The code below compiles to a single machine instruction, yet the
results are CPU manufacturer-dependent.
import std.math;
void main()
{
assert( yl2x(0x1.0076fc5cc7933866p+40L, LN2)
== 0x1.bba4a9f774f49d0ap+4L); //
Kagamin wrote:
Don Wrote:
The great tragedy was that an early AMD processor gave much accurate sin
and cos than the 387. But, people complained that it was different from
Intel! So, their next processor duplicated Intel's hopelessly wrong trig
functions.
The same question goes to you. Why
The code below compiles to a single machine instruction, yet the results
are CPU manufacturer-dependent.
import std.math;
void main()
{
assert( yl2x(0x1.0076fc5cc7933866p+40L, LN2)
== 0x1.bba4a9f774f49d0ap+4L); // Pass on Intel, fails on AMD
}
The results for
== Quote from Don (nos...@nospam.com)'s article
The code below compiles to a single machine instruction, yet the results
are CPU manufacturer-dependent.
import std.math;
void main()
{
assert( yl2x(0x1.0076fc5cc7933866p+40L, LN2)
== 0x1.bba4a9f774f49d0ap+4L); // Pass on
Don wrote:
The code below compiles to a single machine instruction, yet the results
are CPU manufacturer-dependent.
This is awesome work, Don. Kudos to you, David and Dmitry.
BTW, I've read that fine-grained CPU detection can be done, beyond what CPUID
gives, by examining slight differences
%u wrote:
Slightly related, do you have some code to convert a hex float string to float?
Hex float literals are supported by D.
Walter:
%u wrote:
Slightly related, do you have some code to convert a hex float string to
float?
Hex float literals are supported by D.
hex float string != Hex float literal.
Bye,
bearophile
Walter Bright wrote:
Don wrote:
The code below compiles to a single machine instruction, yet the
results are CPU manufacturer-dependent.
This is awesome work, Don. Kudos to you, David and Dmitry.
BTW, I've read that fine-grained CPU detection can be done, beyond what
CPUID gives, by
26 matches
Mail list logo
