Rounding error, (100.0 * 9.95).to_i == 994

[trans. (T. Onoma)]

| > 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?
|
| Hal

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.

 

[trans. (T. Onoma)]

On Friday 29 October 2004 03:00 am, Hal Fulton wrote:
| If you volunteer to pay for it, great things will happen.

Unfortunately I only have 2 cents

T.

 

[Hal Fulton]

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.


Hal

 

[trans. (T. Onoma)]

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.

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.

 

[Hal Fulton]

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.

End of thread for me.


Hal Fulton

 

[trans. (T. Onoma)]

| > 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.
|
| End of thread for me.

Why are you getting so pissy about it? What grade are you in, Hal?

A good craftsman knows that better tools are er... better. Like Ruby.

Bye, bye.
T.

 

[trans. (T. Onoma)]

| > 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.
|
| End of thread for me.

And by the way, pg. 41 of your book the Ruby Way, has a couple of those
"misunderstandings" on it.

T.

 

[Steven Jenkins]

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.

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

 

[trans. (T. Onoma)]

On Saturday 30 October 2004 03:14 am, Steven Jenkins wrote:
| > 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.

Just a joke. I don't doubt your arithmetic abilities at all. You work for
NASA?

T.

BTW/FYI do you know that your subject line has a spam in it? Like this:

Re: Rounding error, (100.0 2000 2001 Desktop Money Projects Protege.png
Protege_2.1 Q3.DIR Quicken RCS Screenshot-1.png Screenshot-2.png
Screenshot-3.png Screenshot.png afs-backup afshome amixer.works b basic.edl
bin bruin-woods c4isr.owl c4isr.pprj cellphones.sxc comedi comedilib config
config-n6uni config.austin conv-factors.sxc debian drvinfo.txt dry.xml
ds-tools emachines evolution float.sxc fnfix foomatic-db-current.tar.gz
grp-backup iFog-Aqua20-1.tar.gz id_dsa.pub income jimo-core-sjenkins
job-search ken-cole latex2docbook letters lfront log mbse modules
n6uni-etc.tar.gz n6uni-home.tar.gz n6uni.tar.gz nasa nisotr old-ruby-tools
openafs photos pickaxe2.pdf rdtmerge resume rexml.sxc ruby-bug ruby-oscon.sxi
ruby-tidal ruby-tools smbmount.3.0.7 software themes tidal-3-11
tidal-3-5-patches tidal-cvsroot-archive tidal-data tidal-head
tidal-poster-corrected.ppt tidal-poster.ppt tidal-web tidal-xdemo
tidalsim.tar.gz uuid vim-ruby-snapshot-2003-10-12 wet.xml yepp 9.95).to_i ==
994

 

[Lloyd Zusman]

On Saturday 30 October 2004 12:00 am, Hal Fulton wrote:
|
| [ ... ]
|
| 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.

[ ... ]

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.

In addition to being completely in agreement with Mr. Jenkins, I want to
add that in my Introduction to Computer Programming course in 1969, we
were taught about fixed-point and floating-point arithmetic. We were
required to master these and other numerical concepts before we were
taught any computer language, and we were expected to know the strengths
and weaknesses of the various numerical techniques that are available in
computers.

In other words, the understanding of fixed-point and floating-point
numbers is so basic and fundamental to programming that I believe that
these topics should be mastered before anyone learns to write even one
line of code.

Sadly, it seems that many texts and professors nowadays do not teach
these important concepts, at least not in introductory courses.

I believe that a fuller understanding of the strengths and limitations
of various numerical methods, including floating-point arithmetic, would
have greatly lowered the probability that the "Ha ha! ..." statement
above would ever have been written. This also applies to a number of
other assertions that have been made in this thread.

 

[trans. (T. Onoma)]

On Saturday 30 October 2004 03:46 am, Lloyd Zusman wrote:
| In addition to being completely in agreement with Mr. Jenkins, I want to
| add that in my Introduction to Computer Programming course in 1969, we
| were taught about fixed-point and floating-point arithmetic. We were
| required to master these and other numerical concepts before we were
| taught any computer language, and we were expected to know the strengths
| and weaknesses of the various numerical techniques that are available in
| computers.
|
| In other words, the understanding of fixed-point and floating-point
| numbers is so basic and fundamental to programming that I believe that
| these topics should be mastered before anyone learns to write even one
| line of code.
|
| Sadly, it seems that many texts and professors nowadays do not teach
| these important concepts, at least not in introductory courses.
|
| I believe that a fuller understanding of the strengths and limitations
| of various numerical methods, including floating-point arithmetic, would
| have greatly lowered the probability that the "Ha ha! ..." statement
| above would ever have been written. This also applies to a number of
| other assertions that have been made in this thread.

Everyone, obviously, has their own particular perspective on the world. You
have yours, and it has been colored by your experiences, including your
Introduction to Computer Programming course in 1969. That's good. But mine is
quite different. And I think people should respect differences. You plainly
infer that I am uneducated and hence, if I were, would not have a) made such
joke and b) made other assertions. Such things are relative. I could say for
instance that the foundations of geometry are fundamental to modern
mathematics and hence likewise to programming, and that you have no right to
write a single line of code until you've worked every proof of all 13 books
of Euclid's Elements (as I have). I'm sure many others could fill in the
blanks here with their own experiences. But that's not fair --to any of us.

I'm not claiming to be a mathematical expert. I have a fair grasp of many
concepts including floating-point arithmetic --but it's certainly not
perfect. I simply _believe_ that it can be done. That's my opinion, I may be
wrong, but I may also be right. You can have your opinion as well. But please
do not belittle my _attempt_. At least I'm trying a better world. An
introductory Computer Programming course in 1969 is certainly not the last
word on such matters.

T.

 

[Simon Strandgaard]

On Saturday 30 October 2004 11:01, trans. (T. Onoma) wrote:
[snip]

I could say for instance that the foundations of geometry are fundamental to
modern mathematics and hence likewise to programming, and that you have no
right to write a single line of code until you've worked every proof of all
13 books of Euclid's Elements (as I have). I'm sure many others could fill
in the blanks here with their own experiences. But that's not fair --to any
of us.

Euclid's Elements is online here:
http://www.sunsite.ubc.ca/DigitalMathArchive/Euclid/byrne.html

It looks interesting.

 

[Brian Schröder]

This could make a great Ruby Quiz, if written up correctly, I think...

James Edward Gray II

Why not just use integer valued cent-counts?

Regards,

Brian

 

[Brian Schröder]

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

Don't want to be picky, but what about: 1, 01, 001, 0001, 00001...

Regards,

Brian

PS: I guess, that is picky and smartassed, but I just could not resist Sorry.

 

[Francis Hwang]

Why not just use integer valued cent-counts?

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.

 

[Sam Goldman]

And the subject takes up the whole first section of Test Driven
Development by Kent Beck.

- Sam (new to the list)

 

[Hal Fulton]

And by the way, pg. 41 of your book the Ruby Way, has a couple of those
"misunderstandings" on it.

I am always glad to be informed of errors or misstatements
in the book.

Hal Fulton

 

[trans. (T. Onoma)]

| > And by the way, pg. 41 of your book the Ruby Way, has a couple of those
| > "misunderstandings" on it.
|
| I am always glad to be informed of errors or misstatements
| in the book.

Cool. Sorry for getting a little short with you.

If you'd like me to point them out, to save you the trouble, hit me up private
mail.

Laters,
T.

 

[Mark Hubbart]

BTW/FYI do you know that your subject line has a spam in it? Like this:

Re: Rounding error, (100.0 2000 2001 Desktop Money Projects Protege.png
Protege_2.1 Q3.DIR Quicken RCS Screenshot-1.png Screenshot-2.png
Screenshot-3.png Screenshot.png afs-backup afshome amixer.works b basic.edl
bin bruin-woods c4isr.owl c4isr.pprj cellphones.sxc comedi comedilib config
config-n6uni config.austin conv-factors.sxc debian drvinfo.txt dry.xml
ds-tools emachines evolution float.sxc fnfix foomatic-db-current.tar.gz
grp-backup iFog-Aqua20-1.tar.gz id_dsa.pub income jimo-core-sjenkins
job-search ken-cole latex2docbook letters lfront log mbse modules
n6uni-etc.tar.gz n6uni-home.tar.gz n6uni.tar.gz nasa nisotr old-ruby-tools
openafs photos pickaxe2.pdf rdtmerge resume rexml.sxc ruby-bug ruby-oscon.sxi
ruby-tidal ruby-tools smbmount.3.0.7 software themes tidal-3-11
tidal-3-5-patches tidal-cvsroot-archive tidal-data tidal-head
tidal-poster-corrected.ppt tidal-poster.ppt tidal-web tidal-xdemo
tidalsim.tar.gz uuid vim-ruby-snapshot-2003-10-12 wet.xml yepp 9.95).to_i ==
994

Looks like shell expansion, not spam, to me.

cheers,
Mark

 

[Lloyd Zusman]

Everyone, obviously, has their own particular perspective on the
world. You have yours, and it has been colored by your experiences,
including your Introduction to Computer Programming course in
1969. That's good. But mine is quite different. And I think people
should respect differences. You plainly infer that I am uneducated and
hence, if I were, would not have a) made such joke and b) made other
assertions. Such things are relative. I could say for instance that
the foundations of geometry are fundamental to modern mathematics and
hence likewise to programming, and that you have no right to write a
single line of code until you've worked every proof of all 13 books of
Euclid's Elements (as I have). I'm sure many others could fill in the
blanks here with their own experiences. But that's not fair --to any
of us.

I'm not claiming to be a mathematical expert. I have a fair grasp of
many concepts including floating-point arithmetic --but it's certainly
not perfect. I simply _believe_ that it can be done. That's my
opinion, I may be wrong, but I may also be right. You can have your
opinion as well. But please do not belittle my _attempt_. At least I'm
trying a better world. An introductory Computer Programming course in
1969 is certainly not the last word on such matters.

T.

The "better world" you are talking about already exists. I will explain
that point below.

People who understand the concepts of fixed-point and floating-point
arithmetic would not expect the "to_i" operator to do _rounding_. That
operation is defined as one which performs _truncation_. People who
never learned these numerical concepts or who incorrectly expect
truncation operators to do rounding should not be writing code to handle
the navigation of Mars landers.

If someone wants the two floating-point numbers 100.00 and 9.95 to be
multiplied together to yield the integer result 995, then rounding will
_have to_ be performed. In order to do that, different procedures,
other than (100.00 * 9.95).to_i, need to be used. For example, one of
many ways to do it is this:

irb(main):001:0> sprintf('%.0f', 100.00 * 9.95).to_i
=> 995

That's because the "%f" format for sprintf is _defined_ as specifying
that rounding gets done when it converts a floating-point number to its
string representation. The to_i operator alone is not defined in that
way.

There are other algorithms and packages that already are in existence
that will also perform rounding. In other words, we already live in
this "better world". Someone who needs to use representations of
decimal numbers that are forced into a fixed precision should learn that
these various algorithms and packages exist, and they should learn how
to make use of them.

For example, see the "mathx" package in RAA. Also, see the BigDecimal
and Rational packages, which already have been mentioned in this
thread, I believe.