True, the power serie somme of 9*10^(-n) does converge to 1. But the
point I was making is that we usually take for granted that the
representaion of real numbers as decimals is a one to one mapping to the
set of real numbers, but it is not. The set of real numbers is 'smaller'
than the set of possible representations.
The set of all words of finite size with characters in 0-9 has a one to
one mapping to the positive integers (0, 1, ..., 10, 11, ...). The
fraction notation n/m, with n and m two integers (positive or negative)
is NOT a one to one mapping to the rational numbers (-2/3 == 4/-6), but
it is if you add some constraints on n and m (remove all common factors,
have m positive not null). We just easily forget that to get a one to
one mapping to the real numbers you must add some constraint on the
suite of decimals.
Guillaume.
···
On Thu, 2004-10-28 at 14:29, Steven Jenkins wrote:
Guillaume Marcais wrote:
> Another funny failing of the notation is that not everything that looks
> like a number actually represents a number. The following is quite
> intriging:
>
> x = 0.99999... (infinite serie of 9s)
> 10*x = 9.99999...
> 10*x - x = 9*x = 9
> So x = 1!
>
> IIRC, any 'word' that ends with an infinite serie of 9s does not
> represent an actual real number.
Sure it does. As you just showed, .9999... == 1.0.
Decimal notation is just convention. We take it for granted, but it's
convention. Any infinite decimal expanson is interpreted as a power
series. Such series always converge, and you can show (as you just did)
that any repeating decimal expansion converges to a rational number.
> Has there been any consideration of using a Numeric class that is fixed
> point? Something that is more like 995/100 representation internally?
> There is sense is storing money in pennies instead of decimal dollars,
> but it makes things a little more messy.
How 'bout a good Money class ?
Ruby needs a good Money class.
I went about implementing one the other day, a subclass of BigDecimal,
and ran into a snag: SubclassOfBigdecimal.new always returns a
BigDecimal. It doesn't use initialize and alloc or any equivalent,
making subclassing next to impossible.
It'd be nice to have a way to subclass BigDecimal -- the code change
needed on the C side isn't that great. I'd like to do it when I get
time, but would welcome someone beating me to the punch.
No doubt, there are some difficulties, but it certainly seems completely doable. And #6 sounds about right! Leave it to human beings to go on and on bitching and dealing with rounding issues and what not, rather then taking stock and fixing the problem.
If you volunteer to pay for it, great things will happen.
I sympathize with this "let's just move forward" attitude, but it ignores
the real world to a large extent. I hear undergraduates talk this way all
the time. Are you an undergrad?
Nice paper. Thank you. A summary for those who don't have the time:
"Clearly 0.9* = 1 + 0¯, so 0¯ is a sort of negative infinitesimal. On the
other hand, you can't solve the equation 0.9* + X = 1 because, ..., the
sum of a traditional real with any real is a traditional real."
Ironically, that's the second time I've read about -0 since I mentioned the
all so "obscure" idea the other day. The other was in the lastest IEEE
floating point revision --looks like they may support it.
Thanks again,
T.
···
On Friday 29 October 2004 05:23 am, Yohanes Santoso wrote:
Guillaume Marcais <guslist@free.fr> writes:
> x = 0.99999... (infinite serie of 9s)
> 10*x = 9.99999...
> 10*x - x = 9*x = 9
> So x = 1!
Alas, I don't have that class of Money to subscribe
T.
···
On Thursday 28 October 2004 12:52 pm, Charles Mills wrote:
On Oct 28, 2004, at 9:12 AM, trans. (T. Onoma) wrote:
> How 'bout a good Money class ?
IMHO a good Money class would be priceless
There was an interesting article in Dr. Dobbs about a java money class
a while back. Below is the extract (registration required for full
article).
Anyway if you do a lot of monetary calculations using floating point
you can get some pretty hefty round off error... as you guys have been
discussing.
This may be yet another case where the suggested way of implementing the class that is 'mostly a BigDecimal' is to wrap BigDecimal instances:
class MyMoney
def initialize( ... ) @internal_representation = BigDecimal.new( ... )
end
def +( n )
MyMoney.new( @internal_representation + n )
end
# etc.
end
···
On Oct 28, 2004, at 3:42 PM, Aredridel wrote:
I went about implementing one the other day, a subclass of BigDecimal,
and ran into a snag: SubclassOfBigdecimal.new always returns a
BigDecimal. It doesn't use initialize and alloc or any equivalent,
making subclassing next to impossible.
Sorry for not getting back to you sooner. I have to slow down! In fact I still
have a dangling thread with matz to finish. sigh.
Well, the short answer is "no".
I don't know why this happens to me exactly but that's the third or forth time
that someone has asked me if I was ___fill in the blank___. Probably b/c I
tend to be all over the map (I have far to many interests for my own good).
But in this case it simply a time issue. We as a community (the larger
computer science community) have certainly had enough time to iron the kinks
with rounding, for instance. Its really sad that we don't have a good
standard for such and are still plagued with it.
If that sounds undergrad, perhaps it's because I remain forever young, and
dare to dream
T.
···
On Friday 29 October 2004 03:00 am, Hal Fulton wrote:
trans. (T. Onoma) wrote:
> No doubt, there are some difficulties, but it certainly seems completely
> doable. And #6 sounds about right! Leave it to human beings to go on and
> on bitching and dealing with rounding issues and what not, rather then
> taking stock and fixing the problem.
If you volunteer to pay for it, great things will happen.
I sympathize with this "let's just move forward" attitude, but it ignores
the real world to a large extent. I hear undergraduates talk this way all
the time. Are you an undergrad?
I take it that BigDeciaml is techincally immutable then.
Is BigDeciaml an extra lib one has to install? ri seems to know nothing about
it, etc. etc.
Thanks,
T.
···
On Thursday 28 October 2004 09:45 pm, Gavin Kistner wrote:
On Oct 28, 2004, at 3:42 PM, Aredridel wrote:
> I went about implementing one the other day, a subclass of BigDecimal,
> and ran into a snag: SubclassOfBigdecimal.new always returns a
> BigDecimal. It doesn't use initialize and alloc or any equivalent,
> making subclassing next to impossible.
This may be yet another case where the suggested way of implementing
the class that is 'mostly a BigDecimal' is to wrap BigDecimal
instances:
But in this case it simply a time issue. We as a community (the larger computer science community) have certainly had enough time to iron the kinks with rounding, for instance. Its really sad that we don't have a good standard for such and are still plagued with it.
It's not a matter of computer science, but of economics.
Implementing those algorithms in silicon is expensive, esp. if we don't
have practice at it. Call it hundreds of millions, counting the research
that precedes it.
Convincing people to buy an expensive chip that their software doesn't
support is a huge PR task, not quite on a par with convincing al Qaeda
to become Methodists.
Rewriting the compilers and the runtime environments to support these
chips is another gargantuan task.
And all of this to solve a problem that is very minor and is chiefly
bothersome to those who have had fewer than four semesters of computer
science.
Given a choice between improved floating point and a mission to Mars,
I'd take the latter.
BigDecimal works by default on my ruby 1.8.2pre2 on PLD.
Yes, the class is technically immutable. I see no reason for this to
be the case, so I'd love to dive in and ~fix the C code.
···
On Fri, 29 Oct 2004 11:55:10 +0900, trans. (T. Onoma) <transami@runbox.com> wrote:
On Thursday 28 October 2004 09:45 pm, Gavin Kistner wrote:
> On Oct 28, 2004, at 3:42 PM, Aredridel wrote:
> > I went about implementing one the other day, a subclass of BigDecimal,
> > and ran into a snag: SubclassOfBigdecimal.new always returns a
> > BigDecimal. It doesn't use initialize and alloc or any equivalent,
> > making subclassing next to impossible.
>
> This may be yet another case where the suggested way of implementing
> the class that is 'mostly a BigDecimal' is to wrap BigDecimal
> instances:
I take it that BigDeciaml is techincally immutable then.
Is BigDeciaml an extra lib one has to install? ri seems to know nothing about
it, etc. etc.
Ha ha! When the spacecraft crashes and burns b/c of an overlooked rounding
error, I'll accept your apology
Honestly, you're way overstating this and undervaluing the problem. Many
persons have wasted hour upon hour compensating for this. This whole thread
kept going b/c of an overlooked rounding error, that could have easily
propagated into live code and been a real headache for someone --what value
do you put on all those efforts?
T.
···
On Saturday 30 October 2004 12:00 am, Hal Fulton wrote:
It's not a matter of computer science, but of economics.
Implementing those algorithms in silicon is expensive, esp. if we don't
have practice at it. Call it hundreds of millions, counting the research
that precedes it.
Convincing people to buy an expensive chip that their software doesn't
support is a huge PR task, not quite on a par with convincing al Qaeda
to become Methodists.
Rewriting the compilers and the runtime environments to support these
chips is another gargantuan task.
And all of this to solve a problem that is very minor and is chiefly
bothersome to those who have had fewer than four semesters of computer
science.
Given a choice between improved floating point and a mission to Mars,
I'd take the latter.
Sometimes that's not sufficient. If you're an organization that has to deal with quantities and amounts priced in multiple currencies, you have to store both the number and the currency itself. 5 Euros, 10 dollars, 42000 Korean won, etc. Then if you are adding or comparing them to one another you have to figure out how to sensibly model that. What's 5 Euros plus 10 dollars? Does it matter that the answer to that question changes over time, as exchange rates are constantly fluctuating?
It's a pretty interesting little domain. Martin Fowler devotes a few pages to it in Analysis Patterns.
F.
···
On Oct 30, 2004, at 9:05 AM, Brian Schröder wrote:
BigDecimal works by default on my ruby 1.8.2pre2 on PLD.
Hmm.. I'm running debian. Perhaps it is a separate package. I'll see.
Yes, the class is technically immutable. I see no reason for this to
be the case, so I'd love to dive in and ~fix the C code.
That's Matz' call. Interestingly we are talking a little about GMP on core and
have learned the the Ruby bindings to GMP show large improvements in speed
when operations are in place.
T.
···
On Friday 29 October 2004 04:11 pm, Aredridel wrote:
Honestly, you're way overstating this and undervaluing the problem. Many persons have wasted hour upon hour compensating for this. This whole thread kept going b/c of an overlooked rounding error, that could have easily propagated into live code and been a real headache for someone --what value do you put on all those efforts?
I'm not overstating or undervaluing anything.
Floating point arithmetic is a perfectly good tool with its limitations. Any
good craftsman knows the limitations of his tools. Too often nowadays we find
craftsmen who do not know those limitations. As for valuing efforts -- I value
efforts more highly when people understand the tools they are using and thus
use them appropriately. In those cases, the headaches you describle will not
happen.
> It's not a matter of computer science, but of economics.
>
> Implementing those algorithms in silicon is expensive, esp. if we don't
> have practice at it. Call it hundreds of millions, counting the research
> that precedes it.
>
> Convincing people to buy an expensive chip that their software doesn't
> support is a huge PR task, not quite on a par with convincing al Qaeda
> to become Methodists.
>
> Rewriting the compilers and the runtime environments to support these
> chips is another gargantuan task.
>
> And all of this to solve a problem that is very minor and is chiefly
> bothersome to those who have had fewer than four semesters of computer
> science.
>
> Given a choice between improved floating point and a mission to Mars,
> I'd take the latter.
Ha ha! When the spacecraft crashes and burns b/c of an overlooked rounding error, I'll accept your apology
I work in a place that actually sends missions to Mars, and I can assure you that floating-point arithmetic is a well-understood phenomenon here.
Honestly, you're way overstating this and undervaluing the problem. Many persons have wasted hour upon hour compensating for this. This whole thread kept going b/c of an overlooked rounding error, that could have easily propagated into live code and been a real headache for someone --what value do you put on all those efforts?
There is nothing you or anyone else can do to make a finite number of bits behave like the real number line. Whatever you do to fix things up for the utterly unimportant class of rationals whose binary expansion repeats in less than 64 bits will come at the expense of some other characteristics that genuine experts have agreed is more important. Unless you're a world-class numerical analyst, your odds of improving on 754 are smaller than roundoff error. Give it a rest.
Steve
···
On Saturday 30 October 2004 12:00 am, Hal Fulton wrote:
