Donate to Remove ads

Got a credit card? use our Credit Card & Finance Calculators

Thanks to johnstevens77,Bhoddhisatva,scotia,Anonymous,Cornytiv34, for Donating to support the site

Brick

cinelli
Lemon Slice
Posts: 550
Joined: November 9th, 2016, 11:33 am
Has thanked: 231 times
Been thanked: 160 times

Brick

#139541

Postby cinelli » May 17th, 2018, 11:35 am

A rectangular solid brick has edge lengths a, b and c. The "side diagonals" are d = sqrt(b^2+c^2), e = sqrt(a^2+c^2) and f = sqrt(a^2+b^2). Find the smallest brick for which all of a, b, c, d, e and f are whole numbers. By smallest I mean the lowest volume. Can you find a brick where, in addition, the corner diagonal sqrt(a^2+b^2+c^2), is integral too?

Cinelli

UncleEbenezer
The full Lemon
Posts: 10690
Joined: November 4th, 2016, 8:17 pm
Has thanked: 1459 times
Been thanked: 2965 times

Re: Brick

#139932

Postby UncleEbenezer » May 18th, 2018, 10:30 pm

EPARSE. A rectangle is a two-dimensional shape, but your description implies three dimensions.

Sorry, can't see a better solution than to google. Never had a knack for number theory (at least, anything more modern than Euclid) even when I was a mathematician.

Googling does turn up one little nugget you may not have seen. Your final question has been answered in the negative, as recently as 2015. https://arxiv.org/pdf/1506.02215.pdf

Gengulphus
Lemon Quarter
Posts: 4255
Joined: November 4th, 2016, 1:17 am
Been thanked: 2628 times

Re: Brick

#141477

Postby Gengulphus » May 26th, 2018, 12:40 pm

cinelli wrote:A rectangular solid brick has edge lengths a, b and c. The "side diagonals" are d = sqrt(b^2+c^2), e = sqrt(a^2+c^2) and f = sqrt(a^2+b^2). Find the smallest brick for which all of a, b, c, d, e and f are whole numbers. By smallest I mean the lowest volume. ...

Well, it's a problem that in the past, I've seen, worked on and read up on in the literature, which is why I haven't said anything about it so far: it would be me parroting a solution, not producing one! But in the absence of anyone else saying anything, here are some observations about how one might tackle it:

* There cannot be any whole number n > 1 that divides all three of a, b and c, because if there were, a/n, b/n and c/n would be a smaller solution. In particular, that means that at least one of a, b and c must be odd, as if they were all even, 2 would divide all three of them.

* It's also not possible for two of a, b and c to be odd, because the square of any even number has remainder 0 when divided by 4 and the square of any odd number has remainder 1 when divided by 4. So if for instance a and b were both odd, then f^2 = a^2 + b^2 would have remainder 1+1 = 2 when divided by 4, which is incompatible with f being a whole number.

* So precisely one of a, b and c is odd and the other two are even, and given that reordering the three edge lengths a, b and c makes no difference to whether they form a solution, we can freely choose which one is odd. So we can for instance choose to make a odd and b and c even without risking missing any solutions, provided only that we remember at the end of the process that the full list of solutions includes all reorderings of the solutions we've found.

* One implication of that is that there is at least one whole number n > 1 that divides two of a, b and c, namely n = 2.

* (a,b,f), (a,c,e) and (b,c,d) are all "Pythagorean triplets" - i.e. triplets of whole numbers such that the sum of the squares of the first two is the square of the third, of which (3,4,5) is the smallest and most well-known example.

* Pythagorean triplets have the property that if (x,y,z) is a Pythagorean triplet and a whole number n > 1 divides all three of them. then (x/n,y/n,z/n) is a smaller Pythagorean triplet. Pythagorean triplets for which there is no such whole numbers are known as primitive Pythagorean triplets, so that basically says that any non-primitive Pythagorean triplet is a multiple of a primitive Pythagorean triplet.

* It can be proved that for any positive whole numbers m and n with m > n that don't have any divisor in common and are not both odd, (m^2-n^2, 2mn, m^2+n^2) is a primitive Pythagorean triplet. For example, choosing m=2 and n=1 (the smallest values that meet the conditions) produces (3,4,5). Furthermore every primitive Pythagorean triplet can be generated in that way, possibly followed by swapping its first two numbers, in precisely one way. I.e. this gives a relatively easy way to produce a list that contains every primitive Pythagorean triplet, precisely once each. (Or to be pedantically accurate, to produce finite initial segments of that list - producing the entire infinite list is rather hard!)

* Note I'm not claiming to have proved any of that last bullet - I've only said that various things can be proved, not actually done so! For proofs, see https://en.wikipedia.org/wiki/Pythagorean_triple.

* While (a,b,f), (a,c,e) and (b,c,d) are all Pythagorean triplets, it's been shown above that at least two of a, b and c have a divisor n > 1 in common, so at least one of them is not a primitive Pythagorean triplet. That means that we apparently need to base any search for solutions on the longer list generated as (k(m^2-n^2), 2kmn, k(m^2+n^2)) for all positive whole numbers k, m, n with m > n and m and n neither being both odd nor having a factor in common.

* However, taking a multiple of a Pythagorean triplet (x,y,z) does not change the ratio y/x. So a list of those ratios for primitive Pythagorean triplets, which is the list of values of (m^2-n^2)/2mn and 2mn/(m^2-n^2) for positive whole numbers m > n with m and n neither being both odd nor having a common factor will include all such ratios for all Pythagorean triplets, not just primitive ones.

* That leads to a reasonable search technique for solutions to the brick problem. Look only for solutions with a < b < c; any solution will be a re-ordering of such a solution (note though that it won't necessarily have a odd and b and c even - that was an example above about how one might choose to order a solution, that is not necessarily the same as how I'm choosing to order solutions here). In that, the three ratios b/a, c/b and c/a will all be > 1 and will satisfy c/a = (b/a) * (c/b). So produce only the list of possible ratios that are > 1 (i.e. for each possible pair (m,n), either put (m^2-n^2)/2mn or 2mn/(m^2-n^2) on to the list, according to whether m^2-n^2 is bigger or smaller than 2mn), and search for pairs of values in the list whose product is also on the list. Any brick solution will produce such a pair, and conversely, any such pair will produce a brick solution (because if ratio1, ratio2 and ratio3 are all on the list and ratio1 * ratio2 = ratio3, then a 1 x ratio1 x ratio3 brick is a solution apart from the fact that all the sides and face diagonals are fractions rather than whole numbers, but you can then multiply that up by the least common multiple of the fraction denominators to create a solution with all of them being whole numbers).

* Do that search with finite initial segments of the list of increasing length, and any given brick solution will eventually turn up, so provided there is a solution (which there is), you will eventually find one. What's a bit trickier and requires more theoretical work is to establish when you've found the smallest solution - to do that, you have to not merely find the smallest solution, but also that no smaller solution will turn up no matter how much further you extend the search.

For further information about the problem, including a spoiler for the actual smallest solution, see https://en.wikipedia.org/wiki/Euler_brick.

cinelli wrote:... Can you find a brick where, in addition, the corner diagonal sqrt(a^2+b^2+c^2), is integral too?

No, I can't. But as far as I know, this is still an unsolved problem: no solution is known, but it also hasn't been established that there is no solution. In particular, while the paper https://arxiv.org/pdf/1506.02215.pdf UncleEbenezer found claims to have answered it in the negative, that answer is at the very least subject to doubt - see https://arxiv.org/abs/1704.00165. I can't say anything more definitive than that, as I haven't properly studied either paper yet - and even if I had, they're both long enough for it to be hard to be certain one hasn't missed an error or an omitted case.

About all I can say for certain is that it is a seriously hard problem!

Section 5 "Perfect cuboid" of the above link https://en.wikipedia.org/wiki/Euler_brick contains more information about the problem.

Gengulphus

cinelli
Lemon Slice
Posts: 550
Joined: November 9th, 2016, 11:33 am
Has thanked: 231 times
Been thanked: 160 times

Re: Brick

#144098

Postby cinelli » June 6th, 2018, 11:17 am

Just to wrap up this puzzle, the dimensions of the brick I was looking for are

a = 44, b = 117, c = 240

which makes the face diagonals

d = 267, e = 244, f = 125

This was discovered in 1719 by Paul Haicke. I often wonder how the evolution of mathematics would have been different if mathematicians from former centuries had had access to computers. In this case the corner to corner diagonal is not an integer, 270.6, and no one has ever found a “perfect brick”. The Wikipedia article, referred to by Gengulphus, is excellent.

Cinelli

GoSeigen
Lemon Quarter
Posts: 4350
Joined: November 8th, 2016, 11:14 pm
Has thanked: 1590 times
Been thanked: 1579 times

Re: Brick

#144114

Postby GoSeigen » June 6th, 2018, 12:49 pm

cinelli wrote:In this case the corner to corner diagonal is not an integer, 270.6, and no one has ever found a “perfect brick”.
Cinelli


Probably should emphasise that the diagonal is 270.6 to 4sf. The actual value is neither an integer, nor rational of course, else finding a perfect brick would be trivial!


GS

UncleEbenezer
The full Lemon
Posts: 10690
Joined: November 4th, 2016, 8:17 pm
Has thanked: 1459 times
Been thanked: 2965 times

Re: Brick

#144120

Postby UncleEbenezer » June 6th, 2018, 1:24 pm

cinelli wrote:Just to wrap up this puzzle, the dimensions of the brick I was looking for are

a = 44, b = 117, c = 240
Cinelli

That of course answers the question you meant to ask, and which I and others read (and which I looked up and Gengulphus already knew).

A much easier answer to the question you actually asked: a = b = c = 0. You didn't say anything about the numbers being positive, and mathematicians are comfortable with zero-sized bricks :lol:

GoSeigen
Lemon Quarter
Posts: 4350
Joined: November 8th, 2016, 11:14 pm
Has thanked: 1590 times
Been thanked: 1579 times

Re: Brick

#144127

Postby GoSeigen » June 6th, 2018, 2:01 pm

GoSeigen wrote:
cinelli wrote:In this case the corner to corner diagonal is not an integer, 270.6, and no one has ever found a “perfect brick”.
Cinelli


Probably should emphasise that the diagonal is 270.6 to 4sf. The actual value is neither an integer, nor rational of course, else finding a perfect brick would be trivial!


GS


Actually my statement is also unsound, because the actual value does not have to be irrational: it could also be unknown whether it is rational or irrational, in which case even if it were rational we clearly would not know its value.

So I suppose I should ask: can anyone prove that the actual value of the diagonal, 5 * sqrt(29*101), is irrational?

[The square roots of both 29 and 101 are irrational, but in general the product of two irrational numbers may be either rational or irrational.]


EDIT: Hmm, just thinking about it IIRC the root of any imperfect square is irrational, so I guess the diagonal must be irrational. QED

GS

Gengulphus
Lemon Quarter
Posts: 4255
Joined: November 4th, 2016, 1:17 am
Been thanked: 2628 times

Re: Brick

#144486

Postby Gengulphus » June 8th, 2018, 12:52 pm

cinelli wrote:Just to wrap up this puzzle, the dimensions of the brick I was looking for are

a = 44, b = 117, c = 240

which makes the face diagonals

d = 267, e = 244, f = 125

This was discovered in 1719 by Paul Haicke. I often wonder how the evolution of mathematics would have been different if mathematicians from former centuries had had access to computers. ...

To give the workings of a solution using the method I outlined above to find solution bricks with a < b < c (which essentially finds all solutions, since any solution can be reordered if necessary to have a <= b <= c, solution bricks with a = b don't exist because that would imply that f = sqrt(2) * a, which is irrational and therefore not an integer, and solution bricks with b = c don't exist similarly):

* One works upwards through possible positive values of m, and for each such value, positive values of n < m that are of the opposite parity (i.e. even or odd) and that have no common factor with m. The pairs of m and n that produces are an infinite list that starts (2,1), (3,2), (4,1), (4,3), (5,2), (5,4), (6,1), (6,5), (7,2), (7,4), (7,6), (8,1), (8,3), (8,5), (8,7), (9,2), (9,4), (9,8), (10,1), (10,3), (10,7), (10,9), (11,2), ...

* For each such (m,n) pair, you generate the first two numbers of the corresponding primitive Pythagorean triplet, i.e. m^2-n^2 and 2mn, and sort them to produce num = MAX(m^2-n^2,2mn) and den = MIN(m^2-n^2,2mn). In solution bricks with a < b < c, the rational number num/den is a possible value for any of the ratios b/a, c/b and c/a. Furthermore, since such (m,n) pairs generate all primitive Pythagorean triplets, and the ratio of the first two numbers of any non-primitive Pythagorean triplet is identical to the same ratio for the primitive Pythagorean triplet it is a multiple of, we know that for any given solution brick with a < b < c we will eventually find all three of b/a, c/b and c/a if we go far enough along the list of (m,n) pairs. Since c/a = (b/a) * (c/b), that means that when we get to the last of those three ratios, it will complete a set of three ratios such that one of them is exactly equal to the product of the other two.

* So for each such (m,n) pair, after generating num and den, we should check whether its rational number num/den and two of the previously-found such numbers form a set in which one of the three (not necessarily the one we've just found) is the product of the other two. That assumes that all three of b/a, c/b and c/a are distinct, and we do in fact know that c/a is distinct from both of the others, since if it were equal to one of them, c/a = (b/a) * (c/b) would imply that the other was equal to 1, contradicting the fact that a < b < c implies that b/a, c/b and c/a are all greater than 1. But it is conceivable that b/a = c/b, making c/a = (b/a)^2, so also check whether the newly-found num/den is the square or square root of one of the previously-found such numbers.

* Those checks could be done by ordinary arithmetic, and that might be the best way to do them by computer: calculate each num/den value as described above, then (a) use a loop to run through the list of previous num/den values, checking whether the larger of that value and the newly-found one is equal to the square of the other; (b) use a double loop to run through pairs of values from that list, checking whether the largest of the newly-found value and the two values in that pair is equal to the product of the other two of those three values. (There is the tedious point that if two numbers are very nearly equal but not quite, computer arithmetic might reckon that they are equal, so that can produce apparent solutions that aren't real, but those will be very rare because of the high precision of computer arithmetic and any that do happen can be eliminated by doing final checks that a generated solution really is a solution.) For hand calculations, though, that sort of method is ridiculously tedious and error-prone because of the large number of long multiplications and divisions it produces.

* A better method for hand calculation is to use the fact that like integers, rational numbers have prime factorisations of the form:

2^e2 * 3^e3 * 5^e5 * 7^e7 * 11^e11 * ...

with the exponents e2, e3, e5, e7, e11, ... all being integers and only a finite number of them being nonzero. The only difference is that for prime factorisations of integers, all of e2, e3, e5, e7, e11, ... must be non-negative, while for prime factorisations of rationals, that restriction is dropped. Prime factorisations still have the properties that they're unique (i.e. if you have two prime factorisations of the same rational number, they must be equal), that multiplication of two rational numbers corresponds to adding the exponents of each prime factor, and that division of two rational numbers corresponds to subtracting the exponents of each prime factor. The proofs of all of those are quite easy, but in the best mathematical tradition, I'll leave them as exercises for the reader... ;-)

Those give us a fairly simple way to determine the prime factorisation of a rational number num/den: produce the (integer) prime factorisations of num and den, then e2 is the number of 2s in the factorisation of num minus the number of 2s in the factorisation of den, and correspondingly for each other prime. This gives us the following initial workings for the search for a solution brick, where the first num and den columns give their numeric values, the second such columns give their integer factorisations, and all unshown exponent values are zero:


Now for the solution search. We want to find:

(a) pairs of rows such that each exponent on one row is twice the corresponding exponent of the other row;

(b) triplets of rows such that each exponent on one row is the sum of the corresponding exponents of the other two rows.

For hand calculation, the arithmetic involved is much simpler and less error-prone than using ordinary arithmetic: additions and doublings of small integers, not long divisions and multiplications, and we also have no issue with limited-precision rounding errors creating false solutions. There's still the apparent issue of the number of pairs and triplets of rows to be checked: doing hundreds, thousands or even more of them is no problem for a computer, but a distinct issue for hand calculations!

The number of pairs to be checked is no real issue: two rows can only be as described in (a) if at least one of them contains only even exponents. So we can scan through the table for such rows, and if we find any, then for each such row, do another scan for a row with half its exponents. For the above table, just one scan is enough: every row contains at least one odd exponent. I'm not certain whether any row containing only even exponents ever appears as we extend the search further and further (I suspect not), but it's clear that if such rows do appear, they only occur very rarely. So we can check for case (a) just by looking at each row once, or maybe a much smaller number of times than the number of rows in the table, which will be far fewer checks in total than the number of pairs of rows from the table, and so a lot more amenable to hand calculation.

The number of triples to be checked is more of an issue, as there is no check as simple as that scan for even-only exponents. However, a look at the above table shows it has some properties that prove useful for divide-and-conquer purposes. First, the e2 column doesn't contain any 0s, 1s or -1s, and it also doesn't contain any entries above 4 or below -4. The first of those is actually provable: every (m,n) pair contains one even number and one odd, so m^2-n^2 must be odd and 2mn must be a multiple of 4. So the factorisation of one of num and den must contain no 2s and that of the other at least 2, and since e2 is the difference between the two counts of 2s, that means that it must be >= 2 or <= -2. The second of them is only true so far: the non-zero count of 2s comes from 2mn, and the number of 2s in its factorisation comes from 2mn and is therefore 1 plus the number of 2s in the factorisation of whichever of m and n is even. So values of 5 and -5 will start to appear when (m,n) contains a multiple of 16, which will start to happen when m reaches 16; values of 6 and -6 will similarly start to appear when m reaches 32; values of 7 and -7 will similarly start to appear when m reaches 64; and so on.

That starts the divide-and-conquering because it's easy to work out that the only ways to make two numbers in {-4,-3,-2,2,3,4} add up to a number also in that set are (-2)+(-2) = -4, (-4)+2 = -2, (-2)+4 = 2 and 2+2 = 4. The first of those can only happen if exponents of two rows in the first section of the following table add up to the exponents of a row in the second section:


The only way the e13 addition can work in that is 0+0 = 0, so we can eliminate rows F and G. Then the only ways that the e11 addition can work are 0+0 = 0 and 0+1 = 1. 0+0 = 0 means we're adding two of rows A-C to produce row H, but the e7 addition cannot work for that. 0+1 = 1 means we're adding one of rows A-C and one of rows D-E to produce row I, but then the e3 addition says that it can only be row A plus row D, and the e7 addition says that's not possible. So (-2)+(-2) = -4 is not a possible e2 addition.

Next, the 2+2 = 4 possibility for the e2 addition, which says that exponents must add up in a similar way in the following table:


The e11 and e19 additions must be 0+0 = 0, so we can eliminate rows C and F. After that, the only possible e3 values to be added are -1 and 1, so their sum must be -2, 0 or 2, so we can eliminate rows G and H. Row I is then the only 'sum' row and tells us that the e3 addition must be 1+1 = 2, and since row C has been eliminated, the two rows being added must be rows B and D, but the e5 addition (for instance) tells us that that doesn't work. So 2+2 = 4 is also not a possible e2 addition.

On to the (-4)+2 = -2 possibility for the e2 addition. Now we get a three-section table, with the exponent sums all needing to work for a row in the first section and a row in the second section producing a row in the third section:


It is easy to see that the e13, e17 and e19 additions can all only be 0+0 = 0, so we can eliminate rows F, G, H, N and O. That means that the e3 addition must be one of {-1,2} plus one of {-1,1} to produce one of {-2,-1,1,2}, and the only ways that works out are (-1)+(-1) = -2 and 2+(-1) = 1. So the row from the second section must have e3 = -1, and as row G has been eliminated, it must be row C. So if the e3 addition is (-1)+(-1) = -2, it must be of row B and row C to produce row L, and if it is 2+(-1) = 1, it must be of row A and row C to produce row I. But it is easy to check that the e5 addition (for instance) doesn't work for either of those, so (-4)+2 = -2 is also not a possible e2 addition.

The remaining possibility for the e2 addition is (-2)+4 = 2. Now we need the exponent sums in the same way as for the (-4)+2 = -2 possibility, but in the following three-section table:


The e3 addition requires one of (-2,-1,1,2) to be added to one of -1 and 2 to produce one of -1, 1 and 2: the possibilities that work are 2+(-1) = 1 and (-1)+2 = 1.

Looking at just the ways that the e3 addition can be (-1)+2 = 1 reduces the table to:


in which the e17 addition cannot possibly work. So the e3 addition must be 2+(-1) = 1, which reduces the table to:


In that, row N being the 'sum' row requires that the e7 addition produces 1 and the e13 addition produces -1. But the e7 addition can only produce 1 if the row from the second section is row I, and the e13 addition can only produce -1 if it is row H. It can't be both, so we can eliminate row N. But then the e5 addition must be of the form x+(odd) = (odd), which implies that x is even and the row from the first section must be row G. Then the e11 addition implies that the row from the third section must be row M, followed by the e7 addition implying that the row from the second section must be row H.

So the addition must be of rows G and H to produce row M, and we can double-check that the exponent sums do all work:


To complete the solution, that implies that there are solutions with b/a = 117/44 and c/a = 60/11, i.e. a solution which is some number times the triplet (1,117/44,60/11). For the first component of the solution to be a positive integer, the number we multiply by must be a positive integer; for the second component to also be a positive integer, it must be a positive multiple of 44; for the third component to also be a positive integer, it must also be a positive multiple of 11. So for all three components to be positive integers, we must multiply by a positive multiple of the least common multiple of 44 and 11, i.e. by a positive multiple of 44. Multiplying the least such multiple, i.e. by 44 itself, produces (a,b,c) = (44,117,240) as the smallest solution with b/a = 117/44 and c/a = 60/11.

My point in saying all that is to demonstrate a method of finding the (44,117,240) solution by hand calculations - long hand calculations, but doable without using more than a day or two of careful work. I.e. a method of finding that solution by brainpower alone, without computer aid, which makes it a proper puzzle IMHO, albeit a pretty hard one!

The problem of establishing that it's the smallest solution by volume is harder: there's no guarantee that a smaller solution wouldn't emerge if one checked for solutions similarly in a longer list of (m,n) pairs and the rows they generate. If one took the list far enough, one would get such a guarantee - a very crude argument to show that is:

* The first two numbers of the primitive Pythagorean triplet generated by (m,n) are m^2-n^2 and 2mn. For a fixed value of m, m^2-n^2 decreases and 2mn increases as we move upwards through possible values of n. So m^2-n^2 is at least its value when n = m-1, which is m^2 - (m-1)^2 = 2m-1, and 2mn is at least its value when n = 1, which is 2m. So the first two numbers in primitive Pythagorean triplets generated for a particular value of m are all >= 2m-1.

* That shows that if one extended the list up to and including the primitive Pythagorean triplets generated by (m,n) pairs with m = 617760, any further extension of the list would only produce primitive Pythagorean triplets that only contained numbers >= 2*617761 - 1 = 1235521. So any solution using those triplets would have to have volume >= 1235521, and so would be larger than the (44,117,240) solution with volume 44*117*240 = 1235520.

So we're guaranteed that if we don't find a smaller solution than (44,117,240) by the time we've extended the list to include all the primitive Pythagorean triplets with m = 617760, we won't ever get a smaller solution. That's only an existence proof that the method will eventually produce such a guarantee, of course, not a practical suggestion: extending the list up to m = 617760 is ridiculously impractical for hand computations, and would be challenging even by computer.

It's not hard to bring that upper limit of 617760 down considerably - a first step is to observe that in any primitive Pythagorean triplet, m is at least 2, so m^2-n^2 is at least 2*2-1 = 3 and 2mn is at least 2*2 = 4. So in any Pythagorean triplet (x,y,z) with x < y < z, x >= 3 and y >= 4, and since a and b in a solution are x and y in such a triplet, a >= 3 and b >= 4. So if c > 1235520/12 = 102960 in a solution, we know that it has a greater volume than the (44,117,240) solution, and so we know that if we extend the list up to and including the primitive Pythagorean triplets with m = 51480, without finding a solution smaller than (44,117,240), extending it further won't do so either.

A second step is: the above says that the smallest number in all primitive Pythagorean triplets with m >= 7 is at least 13. So a complete list of primitive Pythagorean triplets that contain a number <= 12 can be obtained by picking out the ones that do so from those for m <= 6: from the first table above, it is (3,4,5), (5,12,13), (8,15,17), (7,24,25), (9,40,41), (12,35,37) and (11,60,61). Multiples of those that contain a number <= 12 are (6,8,10), (9,12,15), (12,16,20) and (10,24,26), so combining those two lists produces the complete list of Pythagorean triplets containing numbers <= 12. In a solution (a,b,c) with a < b < c, a is the smallest element of two Pythagorean triplets: inspection of the lists shows that the smallest number for which that is possible is 9, so a >= 9. And b is the middle element of one Pythagorean triplet, the smallest element of another, and > a: similar inspection shows that the smallest number for which those can all be true is 12, so b >= 12. Compared with the use of a >= 3 and b >= 4 above, that takes a further factor of 9 out of the upper limit on m, so going up to m = 5720 without finding smaller solutions would be sufficient to establish that there weren't any.

It's possible to go a lot further with increasingly intricate arguments, but I haven't found a way of getting down far enough to bring it within the range of sensible hand calculations. So I'm not claiming to have found a complete hand-calculated solution to the puzzle in the OP, just a hand-calculated solution to it with the 'smallest volume' requirement removed. I'm also not claiming to have found the best way of hand-calculating solutions - there may well be better ways I haven't found - nor to have discovered Paul Haicke's method, merely to have shown how he could have found it without a totally prohibitive amount of work.

Finally, I have of course 'cheated' a bit in the above, by choosing to take the table up to and including the (m,n) = (11,2) row, which is the one that makes the (44,117,240) solution possible, before starting the divide-and-conquering. Had I completely genuinely been searching for solutions, I would have added one row at a time, refining the divide-and-conquering each time. For example, up to the (8,1) row, all e2 values would have been in {-3,-2,2,3} and it would have been impossible to make the e2 addition work. Then the (8,1) row would have added -4 to the possible e2 values and made it necessary to check the possible (-2)+(-2) = -4 and (-4)+2 = -2 e2 additions. Two rows further, the 4 value would be added, making the other two e2 additions possible. And each of those possible e2 additions would probably have needed only a very simple analysis initially, which would gradually get more complex as further rows were added. It would have been somewhat more work than what I've actually done for this post, but not prohibitively so; it would however have resulted in a considerably longer post than this one!

Gengulphus


Return to “Games, Puzzles and Riddles”

Who is online

Users browsing this forum: No registered users and 5 guests