Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
On 2/21/11 6:08 PM, bearophile wrote:
Andrei Alexandrescu:
This is a long-standing myth. I worked on Wall Street and have friends
who have been doing it for years. Everybody uses double.
Unbrutal Python programmers are encouraged to
== Quote from Sean Kelly (s...@invisibleduck.org)'s article
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
On 2/21/11 6:08 PM, bearophile wrote:
Andrei Alexandrescu:
This is a long-standing myth. I worked on Wall Street and have friends
who have been doing it for years.
bearophile Wrote:
Andrei Alexandrescu:
This is a long-standing myth. I worked on Wall Street and have friends
who have been doing it for years. Everybody uses double.
Unbrutal Python programmers are encouraged to avoid the float type to manage
money values, and use decimal instead:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:ijuub9$tv5$1...@digitalmars.com...
On 2/21/11 4:48 AM, Jonathan M Davis wrote:
On Monday 21 February 2011 01:55:28 Walter Bright wrote:
Kevin Bealer wrote:
1. To solve the basic problem the original poster was asking --
On 02/21/2011 10:17 PM, so wrote:
If one doesn't know what floating point is and insists on using it, it is
his own responsibility to face the consequences.
I don't buy this argument.
Why not? A logical flaw on my part or the statement being somewhat harsh?
Because i don't think it is the
On 02/21/2011 05:32 AM, Walter Bright wrote:
Kevin Bealer wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Kevin Bealer wrote:
You could switch to this:
struct {
BigInt numerator;
BigInt denominator;
};
Bingo -- no compromise.
It cannot represent irrational numbers
On 02/21/2011 08:52 AM, Kevin Bealer wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
...
I do understand that if you have a full symbolic representation, you can do so
with zero losses. But Kevin's proposal was not that, it was for a ratio
representation.
All it
Kevin Bealer wrote:
1. To solve the basic problem the original poster was asking -- if you are
working
with simple decimals and arithmetic you can get completely accurate
representations
this way. For some cases like simple financial work this might work really
well.
e.g. where float would
spir wrote:
Naturally non-representable numbers (irrationals), or results of
naturally approximate operations (like trig), are not an issue because
they are expected to yield inaccuracy.
Huh, I regularly run into people who are befuddled by the trig functions not
conforming to the usual trig
On Monday 21 February 2011 01:55:28 Walter Bright wrote:
Kevin Bealer wrote:
1. To solve the basic problem the original poster was asking -- if you
are working with simple decimals and arithmetic you can get completely
accurate representations this way. For some cases like simple financial
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Kevin Bealer wrote:
A reasonable way to do financial work is to use longs to represent pennies.
After all, you don't have fractional cents in your accounts.
Using floating point to represent money is a disaster in the making.
Walter Bright newshou...@digitalmars.com wrote:
A reasonable way to do financial work is to use longs to represent
pennies. After all, you don't have fractional cents in your accounts.
I tend to favor using floating point, doing calculations in pennies, and
explicitly rounding result to
spir wrote:
On 02/21/2011 05:32 AM, Walter Bright wrote:
Kevin Bealer wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Kevin Bealer wrote:
You could switch to this:
struct {
BigInt numerator;
BigInt denominator;
};
Bingo -- no compromise.
It cannot represent
bearophile Wrote:
Jonathan M Davis:
The thing is, of course, that actual equality sucks for floating point
values.
So much, that some people have proposed to deprecate the normal FP equality.
MISRA-C disallows them. When you see a == among FP values is often a code
smell.
Is it
On Mon, 21 Feb 2011 10:15:28 -0500, Kagamin s...@here.lot wrote:
bearophile Wrote:
Jonathan M Davis:
The thing is, of course, that actual equality sucks for floating
point values.
So much, that some people have proposed to deprecate the normal FP
equality. MISRA-C disallows them. When
On Sat, 19 Feb 2011 14:06:38 +0200, spir denis.s...@gmail.com wrote:
Hello,
What do you think of this?
unittest {
assert(-1.1 + 2.2 == 1.1); // pass
assert(-1.1 + 2.2 + 3.3 == 4.4);// pass
assert(-1.1 + 3.3 + 2.2 == 4.4);// fail
assert(-1.1 + 3.3 == 2.2);
On Sun, 20 Feb 2011 14:53:03 +0200, bearophile bearophileh...@lycos.com
wrote:
Walter:
There's a total lack of evidence for that.
MISRA-C standard disallows the equality among FP values. I presume they
have some serious evidence for their choices, but I don't know such
evidence. Today
so:
I still think == should mean the exact equality test and must be
consistent in language.
Everyone in this thread has misunderstood what I have tried to say, so I will
try to explain again, see the bottom of this post.
My idea was to turn the == operator among FP values into a syntax
If one doesn't know what floating point is and insists on using it, it
is
his own responsibility to face the consequences.
I don't buy this argument.
Why not? A logical flaw on my part or the statement being somewhat harsh?
Because i don't think it is the former, i will give an example for
so:
Why not?
A system language has to allow the programmer to do everything the hardware is
capable to do, including comparing floats in the usual way. But in general for
a well designed language it's better to clearly denote dangerous/unsafe/bad
things, and to make the safer routes the
On 2/21/11 4:48 AM, Jonathan M Davis wrote:
On Monday 21 February 2011 01:55:28 Walter Bright wrote:
Kevin Bealer wrote:
1. To solve the basic problem the original poster was asking -- if you
are working with simple decimals and arithmetic you can get completely
accurate representations this
Andrei Alexandrescu:
This is a long-standing myth. I worked on Wall Street and have friends
who have been doing it for years. Everybody uses double.
Unbrutal Python programmers are encouraged to avoid the float type to manage
money values, and use decimal instead:
On 2/21/11 6:08 PM, bearophile wrote:
Andrei Alexandrescu:
This is a long-standing myth. I worked on Wall Street and have friends
who have been doing it for years. Everybody uses double.
Unbrutal Python programmers are encouraged to avoid the float type to manage
money values, and use
On Monday 21 February 2011 15:58:03 Andrei Alexandrescu wrote:
On 2/21/11 4:48 AM, Jonathan M Davis wrote:
On Monday 21 February 2011 01:55:28 Walter Bright wrote:
Kevin Bealer wrote:
1. To solve the basic problem the original poster was asking -- if you
are working with simple decimals
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
I worked on Wall Street and have friends who have been doing it for
years. Everybody uses double.
Makes sense. Not many people on earth has more than
4,503,599,627,370,496 pennies lying about.
--
Simen
Jonathan M Davis wrote:
Regardless, I'm glad that I don't generally have to do much in the way of math-
centric programming.
Why not? I enjoyed it.
On Sunday 20 February 2011 01:20:34 Walter Bright wrote:
Jonathan M Davis wrote:
Regardless, I'm glad that I don't generally have to do much in the way of
math- centric programming.
Why not? I enjoyed it.
There's way too much to worry about. I don't _want_ to have to be worrying
about
Walter:
There's a total lack of evidence for that.
MISRA-C standard disallows the equality among FP values. I presume they have
some serious evidence for their choices, but I don't know such evidence. Today
MISRA-C is one of the most serious attempts at fixing the holes in C language
to
On 02/20/2011 06:17 AM, Jonathan M Davis wrote:
On Saturday 19 February 2011 20:46:50 Walter Bright wrote:
bearophile wrote:
Walter:
That'll just trade one set of problems for another.
But the second set of problems may be smaller :-)
There's a total lack of evidence for that.
On Sunday 20 February 2011 05:21:12 spir wrote:
On 02/20/2011 06:17 AM, Jonathan M Davis wrote:
On Saturday 19 February 2011 20:46:50 Walter Bright wrote:
bearophile wrote:
Walter:
That'll just trade one set of problems for another.
But the second set of problems may be smaller :-)
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
...
It may be that you would still end up with situations where two values that
you
would think would be the same aren't due to rounding error or whatnot.
However,
with a fixed point value, you wouldn't have the problem where a
Jonathan M Davis wrote:
There's way too much to worry about. I don't _want_ to have to be worrying about
rounding error and that sort of thing. I generally want to do whatever
calculations I need to do for a particular task and be done with it. Math
doesn't interest me enough for me to want to
bearophile wrote:
There's a total lack of evidence for that.
MISRA-C standard disallows the equality among FP values. I presume they have
some serious evidence for their choices, but I don't know such evidence.
Today MISRA-C is one of the most serious attempts at fixing the holes in C
language
Jonathan M Davis wrote:
It may be that you would still end up with situations where two values that you
would think would be the same aren't due to rounding error or whatnot. However,
with a fixed point value, you wouldn't have the problem where a particular value
could not be held in it even
Kevin Bealer wrote:
You could switch to this:
struct {
BigInt numerator;
BigInt denominator;
};
Bingo -- no compromise.
It cannot represent irrational numbers accurately.
On 02/20/2011 09:43 PM, Walter Bright wrote:
Jonathan M Davis wrote:
It may be that you would still end up with situations where two values that
you would think would be the same aren't due to rounding error or whatnot.
However, with a fixed point value, you wouldn't have the problem where a
Kevin Bealer wrote:
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
...
It may be that you would still end up with situations where two values that
you
would think would be the same aren't due to rounding error or whatnot.
However,
with a fixed point value, you wouldn't
spir wrote:
Is there any plan for them in D2 in the future?
If you want to work on a library module that supports them, please have a go!
Walter:
MISRA is not suggesting having the language silently default to approximate
equality.
Right. But I am not suggesting that, in what I have suggested there is nothing
silent :-)
Given:
double x, y;
I have suggested in D:
x == y = syntax error.
x is y = the same FP equality as
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Kevin Bealer wrote:
You could switch to this:
struct {
BigInt numerator;
BigInt denominator;
};
Bingo -- no compromise.
It cannot represent irrational numbers accurately.
True but I did mention this a few
Kevin Bealer wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Kevin Bealer wrote:
You could switch to this:
struct {
BigInt numerator;
BigInt denominator;
};
Bingo -- no compromise.
It cannot represent irrational numbers accurately.
True but I did mention
On 2/20/2011 11:32 PM, Walter Bright wrote:
Kevin Bealer wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Kevin Bealer wrote:
You could switch to this:
struct {
BigInt numerator;
BigInt denominator;
};
Bingo -- no compromise.
It cannot represent irrational numbers
dsimcha wrote:
You, my friend, have obviously never used a computer algebra system (my
favorite is Maxima) at all seriously. I'm not saying it's a practical
solution in the context of this discussion, but it is a possible
solution in a lot of cases. Basically, if you can't compute something
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
...
I do understand that if you have a full symbolic representation, you can do so
with zero losses. But Kevin's proposal was not that, it was for a ratio
representation.
All it represents symbolically is division. There are
On Saturday 19 February 2011 04:06:38 spir wrote:
Hello,
What do you think of this?
unittest {
assert(-1.1 + 2.2 == 1.1); // pass
assert(-1.1 + 2.2 + 3.3 == 4.4);// pass
assert(-1.1 + 3.3 + 2.2 == 4.4);// fail
assert(-1.1 + 3.3 == 2.2); //
On 19.02.2011 13:06, spir wrote:
Hello,
What do you think of this?
unittest {
assert(-1.1 + 2.2 == 1.1); // pass
assert(-1.1 + 2.2 + 3.3 == 4.4); // pass
assert(-1.1 + 3.3 + 2.2 == 4.4); // fail
assert(-1.1 + 3.3 == 2.2); // fail
}
There is approxEquals in stdlib, right; but shouldn't builtin
Jonathan M Davis:
The thing is, of course, that actual equality sucks for floating point
values.
So much, that some people have proposed to deprecate the normal FP equality.
MISRA-C disallows them. When you see a == among FP values is often a code smell.
Bye,
bearophile
On 02/19/2011 01:21 PM, Jonathan M Davis wrote:
On Saturday 19 February 2011 04:06:38 spir wrote:
Hello,
What do you think of this?
unittest {
assert(-1.1 + 2.2 == 1.1); // pass
assert(-1.1 + 2.2 + 3.3 == 4.4);// pass
assert(-1.1 + 3.3 + 2.2 == 4.4);// fail
spir:
Well, about consistency, I meant cases 2 vs 3.
Floating point values are not the real values you are used in mathematics. They
are approximations, and generally for them associative and distributive
properties don't hold:
http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
spir wrote:
On 02/19/2011 01:21 PM, Jonathan M Davis wrote:
On Saturday 19 February 2011 04:06:38 spir wrote:
Hello,
What do you think of this?
unittest {
assert(-1.1 + 2.2 == 1.1); // pass
assert(-1.1 + 2.2 + 3.3 == 4.4);// pass
assert(-1.1 + 3.3 + 2.2 ==
On 02/19/2011 02:41 PM, bearophile wrote:
spir:
Well, about consistency, I meant cases 2 vs 3.
Floating point values are not the real values you are used in mathematics. They
are approximations, and generally for them associative and distributive
properties don't hold:
On 2/19/11 8:30 PM, spir wrote:
Right, but then what are we supposed to do?
Just check for strict equality if you are sure you need it, and use a
fuzzy comparison in all other cases? Sorry, I don't quite get your problem…
David
On 02/19/2011 04:40 PM, Don wrote:
spir wrote:
On 02/19/2011 01:21 PM, Jonathan M Davis wrote:
On Saturday 19 February 2011 04:06:38 spir wrote:
Hello,
What do you think of this?
unittest {
assert(-1.1 + 2.2 == 1.1); // pass
assert(-1.1 + 2.2 + 3.3 == 4.4); // pass
assert(-1.1 + 3.3 + 2.2
spir wrote:
So, maybe, default '==' should
perform approxEqual if needed?
That'll just trade one set of problems for another.
Walter:
That'll just trade one set of problems for another.
But the second set of problems may be smaller :-) This happens all the time.
Bye,
bearophile
bearophile wrote:
Walter:
That'll just trade one set of problems for another.
But the second set of problems may be smaller :-)
There's a total lack of evidence for that. Furthermore,
1. Roundoff error is not of a fixed magnitude.
2. A user may choose to ignore roundoff errors, but that
On Saturday 19 February 2011 20:46:50 Walter Bright wrote:
bearophile wrote:
Walter:
That'll just trade one set of problems for another.
But the second set of problems may be smaller :-)
There's a total lack of evidence for that. Furthermore,
1. Roundoff error is not of a fixed
Jonathan M Davis wrote:
Honestly, the more that I learn about and deal with floating point numbers, the
more I wonder why we don't just use fixed point. Obviously that can be a bit
limiting for the size of the number (on either side of the decimal) -
particularly in 32-bit land - but with
Walter Bright wrote:
Bottom line is, if you work with numbers, you've got to pay attention to
roundoff error and other mechanical issues in deriving answers, whether
you're using a calculator, a computer, a slide rule, by hand, whatever.
If you don't, you are incompetent.
I mean you
On Saturday 19 February 2011 23:09:51 Walter Bright wrote:
Walter Bright wrote:
Bottom line is, if you work with numbers, you've got to pay attention to
roundoff error and other mechanical issues in deriving answers, whether
you're using a calculator, a computer, a slide rule, by hand,
60 matches
Mail list logo
