Teaser 2529: [Cost estimates]
From The Sunday Times, 13th March 2011 [link] [link]
A letter to The Times concerning the inflated costs of projects read:
When I was a financial controller, I found that multiplying original cost estimates by 𝛑 used to give an excellent indication of the final outcome.
Interestingly, I used the same process (using 22/7 as a good approximation for 𝛑). On one occasion, the original estimate was a whole number of pounds (less than £100,000), and this method for the probable final outcome gave a number of pounds consisting of exactly the same digits, but in the reverse order.
What was the original estimate?
When originally published the amount was given as “less than £10,000”, which was raised to “less than £100,000” in the following issue. But even with this change the puzzle is still open to interpretation.
This puzzle was originally published with no title.
[teaser2529]
John Crabtree, 
Hugh Casement, 
Frits, and 1 other are discussing. 
S2T2 
Jim Randell 8:15 am on 16 March 2021 Permalink |
What the puzzle isn’t clear on is what happens to any fractional part of the new estimate. (Which there would always be if you were to multiply by 𝛑).
If we round down (simply ignoring any fractional part) in the result, then we can get a solution to the original puzzle:
And we also get the same result if we round to the nearest pound.
And a different unique solution if we round up:
Raising the limit to £100,000 then we get the following additional solutions:
Rounding to nearest:
Which we also get if we round up, along with:
So the only way we can get a unique solution with the revised upper limit is to assume that, before rounding, the new estimate was a whole number of pounds, and so no rounding was necessary. In this case only the pair £22407 → £70422 remain as a candidate solution, and this was the required answer.
This makes a manual solution easier (and a programmed solution a little faster), as we know the original estimate must be a multiple of 7.
The following Python program lets you play with various rounding methods.
from enigma import (irange, divf, divc, divr, div, nreverse, printf) # the new estimate is the original estimate multiplied by 22/7 # choose an appropriate function from the following # - fn=divf: rounded down # - fn=divc: rounded up # - fn=divr: rounded to nearest integer # - fn=div: exact division estimate = lambda x, fn=div: fn(x * 22, 7) # consider the original estimate x for x in irange(1, 99999): # multiply by 22/7 for new estimate n n = estimate(x) if n is None or n % 10 == 0: continue # new estimate is reverse of the original if nreverse(n) == x: printf("original {x} -> {n}")Solution: The original estimate was: £22,407.
If the estimates had been constrained to be between £100,000 and £1,000,000 then there is a single solution whichever rounding method is chosen:
LikeLike
Frits 1:04 pm on 17 March 2021 Permalink |
# consider original cost abcde w # 22 * abcde = 7 * edcba # 0 < a < 4 as a * 22 / 7 < 10 # a must be also be even as 22 * abcde is even # so a = 2 and 5 < e < 10 # 22 * 2bcde = 7 * edcb2 --> e is 7 or 2 --> e is 7 # equation 22 * 2bcd7 = 7 * 7dcb2 # cost 2-digit number: # -- 27 is not divisible by 7 # cost 3-digit number: 4914 <= 22 * 2b7 <= 5544 so 2 < b < 5 # -- no 2b7 is divisible by 7 for 2 < b < 5 # cost 4-digit number: 49014 <= 22 * 2bc7 <= 55944 so 1 < b < 6 # cost 5-digit number: 490014 <= 22 * 2bcd7 <= 559944 so 1 < b < 6 # ...d7 * 22 ends on 54 + d * 20 --> ends on o4 where o is an odd digit # b = 2 --> ...22 * 7 = ...54, 54 + d * 20 ends on 54 so d = 0 or 5 # b = 3 --> ...32 * 7 = ...24, wrong # b = 4 --> ...42 * 7 = ...94, 54 + d * 20 ends on 94 so d = 2 or 7 # b = 5 --> ...52 * 7 = ...64, wrong # b = 2 --> d = 0 or 5, # b = 4 --> d = 2 or 7 # 4-digit numbers 2207, 2257, 2427 and 2477 are not not divisible by 7 # divisibility by 11 requires that the difference between # the sum of the the digits in odd positions and # the sum of all the digits in even positions is 0 or divisible by 11 # 22x07, sum even positions = 2 --> (9 + x - 2) % 11 = 0 -- > x = 4 # 22407 is divisible by 7 # 22x57, sum even positions = 7 --> (9 + x - 7) % 11 = 0 -- > x = 9 # 22957 is not divisible by 7 # 24x27, sum even positions = 6 --> (9 + x - 6) % 11 = 0 -- > x = 8 # 24827 is not divisible by 7 # 24x77, sum even positions = 11 --> (9 + x - 11) % 11 = 0 -- > x = 2 # 24277 is not divisible by 7 # so 22407 * 22/7 = 70422LikeLike
John Crabtree 1:40 pm on 18 March 2021 Permalink |
X = abcde, Y = edcba where X * 22 = Y * 7
and so 2e = 7a mod 10, and so a = 2 and e = 7
By digital roots, the sum of the digits in X = 0 mod 3. X = Y = 0 mod 3
X = 0 mod 7. Y = 0 mod 11, and so X = 0 mod 11
And so X = 231*M, Y = 726*M, and M = 7 mod 10
Or X = 1617 + 2310*N and Y = 5082 + 7260*N
By inspection X cannot have 2, 3 or 4 digits
70,000 < Y < 80,000 and so N = 9 or 10, which is invalid by inspection.
N = 9 gives X = 22407 and Y = 70422, which is valid.
If X 6 digits, there are only 14 possible values of N, ie 96 to 109, to check.
LikeLike
Frits 12:12 pm on 19 March 2021 Permalink |
@John,
Maybe you used the congruent sign in your analysis and it was replaced by equal signs.
If so you might try the enclosure of text as mentioned in Teaser 2756.
If not the analysis is wrong as 0 mod 11 equals 0.
Please elaborate as I am not an expert in modular arithmetic (I gather X must be a multiple of 3, 7 and 11?).
LikeLike
John Crabtree 4:16 pm on 19 March 2021 Permalink |
@Frits
I do not recall the congruence sign from when I was first introduced to modulo arithmetic nearly 50 years ago. I have always used the equals sign (perhaps incorrectly) followed by mod n.
X = 0 mod 3 means that X is divisible by 3. And so, yes, X is divisible by 3, 7 and 11. As it also ends in 7 the solution space becomes very small. HTH
LikeLike
Hugh Casement 12:25 pm on 19 March 2021 Permalink |
I meant to post this on St Patrick’s day, before most of the other comments appeared.
I’m sure that an integer solution is intended, so no rounding is necessary.
The original estimate must therefore be an integer multiple of 7.
The result is even, so the original estimate (with its digits in reverse order) must start with 2: any larger value would yield a result with more digits.
The result is a multiple of 11, so the original estimate (using the same digits) must be too.
Admittedly, that still means a lot of trial & error if we don’t use a computer.
22/7 is a lousy approximation to pi! Much better is 355/113, but I think that can work only if the original estimate is allowed to have a leading zero.
LikeLike