Re: This calculation is just wrong / computer can't count!

Tech-Archive recommends: Fix windows errors by optimizing your registry

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:bk4tg3lnp25sb2i7cb92ral6jecjardjvh@xxxxxxxxxx
See below...

On Thu, 11 Oct 2007 17:08:48 +0100, "GT" <ContactGT_remove_@xxxxxxxxxxx>
wrote:


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:3bgsg35h8m7vkad06igv99d1k54lt1peod@xxxxxxxxxx
See below...
On Wed, 10 Oct 2007 11:07:43 +0100, "GT" <ContactGT_remove_@xxxxxxxxxxx>
wrote:

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:ad7og3pku6cssog2m6r5r3hrjnh2tj4s4t@xxxxxxxxxx
You really are continuing to be terminally stupid. Why do you think
that
the 7 represents
an error? It does not.

Yes is does. There is no 7 at the end of a decimal representation of
1/3.
If
you include a 7 on the end and then do some subsequent calculations, you
get
an invalid answer.

Tell me: did you REALLY use the Floating Point Explorer to look at
this
issue? It should
be obvious to you if you did!

No I didn't and don't intend to. I fully understand where the 7 is
coming
from. HOW MANY TIMES DO I HAVE TO SAY THIS, "I WANT TO KNOW HOW TO CODE
SOME
MATHS THAT DOESN'T INTRODUCE THE 7".
****
And how many times do we have to explain to you that this desire cannot
be
realized if you
insist on using finite-precision arithmetic. It isn't going to happen.
It can't happen.
It DOESN'T EVEN MAKE SENSE THAT YOU INSIST THAT IT NOT HAPPEN because to
make this so you
have to introduce a very large error.
****

You really keep missing the point. You confuse precision with textual
representaiton.

NO JOE, I AM THE ONE ASKING THE QUESTION HERE - *YOU* ARE MISSING THE
POINT
AND *STILL* ANSWERING SOME OTHER QUESTION.
****
You are asking a question which makes no sense, because any answer to it
is wrong. See my
other post about inability to ask meaningful questions.

You say "I don't want the 7" at the same time you say "I want more
accuracy". In
finite-precision IEEE-754 floating point arithmetic, these goals are
incompatible. If you
want accuracy, you want the 7, if you don't want the 7, you lose
accuracy.
Please explain
how we can simultaneously satisfy your demands for accuracy and
representation when they
are mutually incompatible? At least if you insist on using 'double' and
printing out all
the digits of precision? YOUR QUESTION IS NOT BEING ANSWERED BECAUSE IT
IS NOT
ANSWERABLE!!!

Since you seem to think that there is a feasible answer to an impossible
question, perhaps
you should consider the nature of mathematics. Consider the Post
Production problem.
Consider the Turing Machine Halting Problem. Consider the Gödel
Incompleteness Theorem.
For years, mathematicians insisted that mathematics could be a closed
system in which all
answers were possible. Then in the 1930s, people like Church, Turing,
Gödel, and Post
came along and demonstrated that there were truly unsolvable problems in
mathematics. You
have one: you want finite-precision arithmetic to work in a domain in
which it cannot
work. You cannot have any floating-point unit in the history of
computing
give you values
that correspond to your notion of reality. It won't happen, it can't
happen, and it isn't
going to happen. So we keep telling you your goal cannot be achieved,
and
you keep
insisting that it MUST be achieved. You are asking for something that
is
impossible, and
all the demanding of an answer is not going to change the fact that it
is
impossible to
get what you want.

We have told you that the only alternative is BIGNUM rational
representations, which still
won't be right, but won't have the limitations of finite-precision
floating point, and you
keep ignoring that advice. (Note that on both input and output,
rational
arithmetic still
fails, but it can do what you want up to certain limits)

You cannot get an answer to a question which does not have the answer
you
want. You once
suggested I go into politics. I think you should consider it as a
career,
since your
philosophy is consistent with politicians "My mind is made up, don't
confuse me with
facts!" The facts are simple: your goal is impossible with double
arithmetic.

Who said anything about having to use double to get to the goal - only you
keep promoting double. I have been talking about mathematics all along and
you insist on going on about IEEE and binary representations and floating
point precision etc etc - all irrelevant to the question!!! And straight
away we are back to you answering a different question from that asked -
hence the suggestic politics route. The question that you keep on
answering
and then defending the answer to was not asked in the first place and is
(as
you point out) impossible to answer! Of course, you then go on to say that
so long as the answers 'double' produces are changed slightly before
displaying them, then it is perfect. Not the kind of maths I want to
calculate thanks - I would rather do some sums and rely on the answer
without having to add a little bit or compare it with 1 part in 1 million!

I have an application which can be reduced down to a user typing some
numbers in decimal into some boxes and pressing a few buttons and sliders,
then seeing a series of results in decimal. Whether the numbers are
internally converted to binary, hex, russian or double dutch, the user
simply doesn't care and frankly, neither do I.
****
It is called "software development cost". You may not care, but SOMEONE
cares, about the
cost. It is called "performance". You may not care if the answer is
produced in a timely
fashion, but SOMEONE cares. So you are saying that in the compromise
between development
cost and performance, a built-in type that is supported in the hardware,
"double", is
wrong, but arbitrary-precision BIGNUM rational arithmetic, expensive to
develop and
massively slow, is acceptable. This is a scary concept: a programmer for
whom development
cost and software performance are both irrelevant!
****
I would like the answers to
be correct without having to manipulate them in any way other than
truncate
to the desired number of decimal places. There should not have to be any
check to see if a number is close to another number, rather than equal to
it!
****
But since this doesn't work, as I have demonstrated to you on several
occasions, in
decimal arithmetic, so why should you expect a computer is going to do any
better?

Have you never made a purchase on which there is a sales tax? If I make a
purchase of
0.99, how is it that I am to pay the $0.0693 tax on it? Hmm... as it
turns out, in all
jurisdictions I;m aware of, truncation is illegal; you must round.

Rounding is mathematically fine, so long as you leave enough decimal places
to make your calculations precise enough, sticking a random digit on the end
of a number is not mathematically sound.


.

Quantcast