All about flooble | fun stuff | Get a free chatterbox | Free JavaScript | Avatars    
perplexus dot info

Home > Numbers
How and When (Posted on 2009-07-29) Difficulty: 2 of 5
Solve this alphametic, where each of the capital letters in bold denotes a different decimal digit from 0 to 9. None of the numbers can contain any leading zero.

3√(HOW)+ 3√(AND) = 3√(WHEN)

See The Solution Submitted by K Sengupta    
Rating: 5.0000 (1 votes)

Comments: ( Back to comment list | You must be logged in to post comments.)
re: two views | Comment 7 of 17 |
(In reply to two views by brianjn)

In the case of the real answer, 192  375  2187, while both j+k and l display as 12.98025, internally they must differ by a small bit in their binary representation.  There can be no direct 1-to-1 correspondence between decimal representations and binary representations of fractions in the floating-point scheme of things.

When you take the string function, you are forcing the conversion to decimal to take place, and both binary values come out to the same decimal value, at Microsoft's choice of how far to go in rounding it.

The fact that the binary representations differ is not an indication that the lhs and rhs are different in reality. They were computed differently and the inevitable rounding error at the end went one way in one of the calculations and the other in the other.

In the way of critiquing your program, I see you left out the DEFDBL A-Z, which would have provided greater accuracy, and in fact eliminated the spurious "solution" of 736  952  6715.

The sum of 9.028714870948001 and 9.837369468917455 (the two cube roots on the left) add up to 18.86608433986546, while the cube root (of 6715) on the rhs is 18.8660945080447. When rounded for single precision decimal, that's apparently close enough, but with double precision it's not.

So no, QB is not more accurate than Excel, and in fact, the single precision is less accurate. Neither is perfectly accurate and rounding error on either side could go either way, and if they don't match, you get a non-match.

The key is to use DEFDBL A-Z, and rather than rely on conversion-to-decimal rounding, code something like:

IF ABS(j+k-l) < 1E-13 THEN

or better yet:

IF ABS((j+k-l)/l) < 1E-15 THEN

as the latter checks the relative error, disregarding the approximately 15th decimal position and beyond.

With the extra precision, I'm confident that the first solution is exact and the second is spurious.


  Posted by Charlie on 2009-07-30 11:50:20
Please log in:
Login:
Password:
Remember me:
Sign up! | Forgot password


Search:
Search body:
Forums (0)
Newest Problems
Random Problem
FAQ | About This Site
Site Statistics
New Comments (3)
Unsolved Problems
Top Rated Problems
This month's top
Most Commented On

Chatterbox:
Copyright © 2002 - 2024 by Animus Pactum Consulting. All rights reserved. Privacy Information