Community Tip - You can subscribe to a forum, label or individual post and receive email notifications when someone posts a new topic or reply. Learn more! X
My dilemma has arisen from a debate with my 9.5 years old daughter about her school teacher taught her during classes.
So my daughter told me that by convention (if someone has to) he/she may approximate 15 by 20 (two tens), 9.5 (b t w ! ) to 10, and so on.
Personally I didn't care much for long time of such kind of approximation, but I answered her that it seemed to me quite strange.
Then we turned to Mathcad and we got the results in the attached sample.
All seems in line with my daughter's teacher, excepting the last (fifth) example, where unlike the first four cases, round estimate is made by diminution ...,
that is 987654325 is rounded to 9.8765432*10^8.
So, why the different behiavour in the last case ? Exception is determined by the conversion of the number into binary (or hexadecimal) numbers made internally by computer in this particular case .... ?
(Actually, by accident the first example I gave to my daughter was the exception of the fifth number).
In the first four examples, is really a matter of accepted convention for making up the round approximate ?
(As shown, same result in older version of Mathcad like Mcd2001).
Best regards, Liv.
An obscure bug, affecting only 2nd, 7th, and 11th decimal places:
TTFN
Interestingly, Studyworks does not have the same problem with the 2nd decimal place, but does have the 7th and 11th decimal place error:
TTFN
Same in M15.
If the 5 is changed to a 6 it then works??????
Mike
It looks to be a complex bug. 9.005 rounds correctly, as does 9.025, 9.125, 9.225, and 9.425
Likewise, the 7th decimal place rounding is in error only for ...325
BUT, the 11th decimal place rounding is in error regardless of the digit leading the ....25, BUT the 11th decimal place rounding is in error if the digit leading the 5 is an even number.
Sounds almost like someone planted a complex Easter Egg...
TTFN
Sounds almost like someone planted a complex Easter Egg...
Not too bad then because I like Easter Eggs
Mike
So, why the different behiavour in the last case ? Exception is determined by the conversion of the number into binary (or hexadecimal) numbers made internally by computer in this particular case .... ?
Yes, I think so. I'm not sure if I would even classify this as a bug. It's just a reality of numerical computing. The symbolic processor can do arbitrary precision arithmetic, and therefore doesn't show the problem
Yes, I think so. I'm not sure if I would even classify this as a bug. It's just a reality of numerical computing. The symbolic processor can do arbitrary precision arithmetic, and therefore doesn't show the problem
I would violently disagree. The algorithm does not require extreme precision, since it's quite capable of converting from the IEEE binary format to decimal and displaying the result. Based on the displayed result, there is absolutely no ambiguity about how it should round. The fact that it can correctly round 99.999999% of the time shows that it's not at all random, and is in fact, quite deterministic. Excel doesn't have this problem with its rounding function; I can't accept that the SW guys at MS are that much better at this than the Radzow and guys at Mathsoft.
TTFN
I tend to agree with Mei ....
Using keyword "float" (symbolic calculation), one may get some others examples of unusual ('unconventional') results
(I wonder how many... see attached).
In other software, it seems to appear similar unusual display, but there it is less important since underlying number is kept as in the original format.
However, it thus becomes more captivating to assist my daughter for her homeworks.
I must do it more often.
And, if I have the choice, I'll try to negotiate my next bank loan for a 9.825 % interest (thanks to Mei, too).
Best regards,
Liv.
I agree with you, Richard, but for a humble user it's quite tricky ...
Best, Liv.
Oh, I forget ...
Some part of my dilemma is still there.
So I was curious if it's matter of general accepted convention for computers to round up numbers with 5 last digit ..., or, if not,
is there some other special reason for rounding up ?
(It's true that some of the first computing machines were made for banking to calculate debts interests ...
Many thanks, Liv.
What is learned in school, around 5th grade or so, is to round up on 5.
However, there is a school of thought that 5 is exactly halfway and shouldn't be arbittrarily rounded up, as that would introduce a statistical bias, so one approach is to round up if the preceeding digit is odd, and round down if the preceeding digit is even.
For a more detailed and laborious discussion, see:
http://en.wikipedia.org/wiki/Rounding
and:
http://en.wikipedia.org/wiki/Round-off_error
TTFN
Specific to the question about computers, they tend to truncate or round up, depending on how the hardware is implemented. On a fixed-precision calculation, the result would most likely be truncated. But if the calculation is done at a higher precision, and displayed or transferred at a lower precision, then the implementers may elect to round up.
In general, the question would be pretty much moot, since most computers implement the equivalent of about 16 digits of decimal precision, and the rounding only occurs in the last digit, and only obscure, or badly formed, calculations would exercise the last digit to the point of significance.
TTFN
Yes, in general ...
But there are some more exceptions, and far from 10^-16 !
And where it is shown that Mcd2001 was doing a little better than 14.
Best, Liv.
A bit [ ] better than Mcd14 with the symbolic processor ...
Same, Liv.
II'm not necessarily surprised. The expectation would be that the "float,n" command would use the same code as the round(x,n-1).
The only possible surprise is why no one at PTC has responded with either a note that the bug has already been logged or whether no one else has ever run across it.
TTFN
And it's worse in MC14 than in an older version like MC2001... Progress has its price .
But who cares (beside users) ?
Best, Liv.
I have been thinking about this, and what I can't figure out is how Excel (or any other program that "always gets it right") handles certain numbers. Take a number uv.wxyz5. It doesn't matter what the number is, only that the last digit in decimal is 5, and that when converted to binary the number is irrational (such numbers surely must exist). That means it cannot be represented exactly in binary, no matter how many digits of precision there are. If the sequence of digits is simply truncated then the number is slightly less than uvwxyz5, call it uv.wxyz5-, and there is no longer any record of the fact that the number that is supposed to be represented is anything other than uv.wxyz5-. So rounding it would correctly give uv.wxyz. Once it has been stored as binary, there is no basis for rounding it up.
That implies (to me, anyway) that the only thing you could do is add one bit at the time the number is stored, any time the last digit is 5 and the binary representation of that number is irrational (because there are plenty of numbers ending in 5 that can be represented exactly in binary, such as 0.5, 0.25), so that the stored number is slightly larger than the true number. But then if you want to choose a different rounding scheme........
If the sequence of digits is simply truncated then the number is slightly less than uvwxyz5, call it uv.wxyz5-, and there is no longer any record of the fact that the number that is supposed to be represented is anything other than uv.wxyz5-. So rounding it would correctly give uv.wxyz. Once it has been stored as binary, there is no basis for rounding it up.
Actually, I guess there is a basis for rounding it up. Suppose we take a decimal number D with N digits of precision and convert it to a binary number B with n bits of precision. If the decimal number cannot be represented exactly using the n bits, then I think it must be true to say that if the binary number B is convert back to decimal it cannot be represented exactly using N digits. So it must be rounded either slightly up or slightly down. In the example above, assuming the binary number was obtained by simply truncating the sequence of bits, it would be rounded slightly up, and the result would be uv.wxyz5. If we round uv.wxyz5 the rounding operation is of course done in binary, but knowing that we need to round up slightly to display the number in decimal, we would add 1 bit to the binary representation first, then round it. I think that would always give the correct answer.
So the rounding operation needs to take into account the radix of the displayed number. Rounding a number displayed in decimal and then displaying it in hex may not give the same result as rounding a number displayed in hex and then displaying it in decimal! My guess is that Mathcad is failing to take into account the display radix.
It's not a new problem..
This is extracted from some maths notes from an MSc module (sorry about the poor formatting from the cut and paste)
1.2 Roundo error and the Patriot missile
Article [5] by Robert Skeel, professor of computer science at the University of Illinois at Urbana-Champaign, in SIAM News, 1992.
\The March 13 issue of Science carried an article claiming, on the basis of a report from
the General Accounting O ce (GAO), that a `minute mathematical error ... allowed an
Iraqi Scud missile to slip through Patriot missile defenses a year ago and hit U.S. Army
barracks in Dhahran, Saudi Arabia, killing 28 servicemen.' The article continues with a
readable account of what happened.
\The article says that the computer doing the tracking calculations had an internal
clock whose values were slightly truncated when converted to floating-point arithmetic.
The errors were proportional to the time on the clock: 0.0275 seconds after eight hours and
0.3433 seconds after 100 hours. A calculation shows each of these relative errors to be both
very nearly 2^(-20), which is approximately 0.0001%.
\The GAO report contains some additional information. The internal clock kept time
as an integer value in units of tenths of a second, and the computer's registers were only
24 bits long. This and the consistency in the time lags suggested that the error was
caused by a fi xed-point 24-bit representation of 0.1 in base 2. The base 2 representation
of 0.1 is nonterminating; for the fi rst 23 binary digits after the binary point, the value is
0.1 x (1 - 2^(-20)). The use of 0.1 x (1 - 2^(-20)) in obtaining a floating-point value of time in
seconds would cause all times to be reduced by 0.0001%.
\This does not really explain the tracking errors, however, because the tracking of a
missile should depend not on the absolute clock-time but rather on the time that elapsed
between two di erent radar pulses. And because of the consistency of the errors, this time
di erence should be in error by only 0.0001%, a truly insigni cant amount.
\Further inquiries cleared up the mystery. It turns out that the hypothesis concerning
the truncated binary representation of 0.1 was essentially correct. A 24-bit representation
of 0.1 was used to multiply the clock-time, yielding a result in a pair of 24-bit registers.
This was transformed into a 48-bit floating-point number. The software used had been
written in assembly language 20 years ago. When Patriot systems were brought into the
Gulf conflict, the software was modi ed (several times) to cope with the high speed of
ballistic missiles, for which the system was not originally designed.
\At least one of these software modi cations was the introduction of a subroutine for
converting clock-time more accurately into floating-point. This calculation was needed in
about half a dozen places in the program, but the call to the subroutine was not inserted
at every point where it was needed. Hence, with a less accurate truncated time of one
radar pulse being subtracted from a more accurate time of another radar pulse, the error
no longer cancelled.
\In the case of the Dhahran Scud, the clock had run up a time of 100 hours, so the
calculated elapsed time was too long by 2^(-20) x 100 hours = 0.3433 seconds, during which
time a Scud would be expected to travel more than half a kilometer.
\The roundoff error, of course, is not the only problem that has been identi ed: serious
doubts have been expressed about the ability of Patriot missiles to hit Scuds."
End of article by Robert Skeel.
Philip
Starting from your observation, Richard, i. e. numbers ending in 5 with irrational binary, one can find all numbers between 0 and let's say 10^6
for which I bet MCD (14) rounding is failing or contradictory (see also attached).
And I agree with you that "a bit better" may be the way to remedy...
As a 'fan' of Mathcad, looking for a better product, I've already mentioned, Mei, the rounding bug under Discussion
"What new features [...] in MCD Prime?"
Best, Liv.
All very interesting, but somewhat irrelevant, since Excel does not have this problem. This problem is unique to Mathcad.
Since the underlying math hardware is the same, the difference is how the hardware is used.
Now, it may be possible that Excel has other bugs, but at least in this case, it does not have the problem that Mathcad has.
TTFN