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

 How and When (Posted on 2009-07-29)
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)

 No Solution Yet Submitted by K Sengupta No Rating

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

 Search: Search body:
Forums (1)