Background:

I gave an exam recently and parts of it involved converting values expressed in hexadecimal to decimal. Seven people did these conversions the same wrong way, which I'll demonstrate by example below:

0x23DF4

2   3   D   F   4
|   |   |   |   |
2   3  13  15   4

4 x 16 = 64
15 x 16 = 240
13 x 16 = 208
3 x 16 = 48
2 x 16 = 32

      64
    240
   208
   48
  32
---------
  391264

(ASIDE: Five others just crammed the individual digit conversions together to get 2313154.)

Puzzle:

While this conversion technique is clearly wrong in general, for small hexadecimal values it results in decimal results that are too large, while for sufficiently large hexadecimal values it results in decimal values that are too small. This raises the question of if there are any hexadecimal values for which this technique, by coincidence, happens to produce the correct hexadecimal values. An obvious, and trivial, case is 0x0, so we will exclude that from further consideration.

Writing a program to search the space is very easy -- though one person that tried that didn't search a large enough space and concluded that there were no nontrivial solutions.

So the challenge of the puzzle is to, by analysis, answer as many of the following questions as possible:

Are there any nontrivial solutions?

And, yes, the comment above reveals the answer to this question, but it's not enough to just say, "Yes," you have to actually prove it.

Assuming that there are non-trivial solutions:

Can you find a nontrivial solution (and, if so, what is it)?
How many nontrivial solutions are there?
What is the largest value that you can prove is a lower bound on nontrivial solutions?
What is the smallest value that you can prove is an upper bound on nontrivial solutions?
What is the smallest non-trivial solution?
What is the largest non-trivial solution?

To avoid spoiling the fun too quickly, don't give actual solutions, but instead supply a simple 'hash' for them as follows:

Sum up the digits in the hex value, each multiplied by i where i = 1 for the least significant digit and increases by one for each digit to it's left.
Sum up the digits in the dec value, each multiplied by i where i = 1 for the least significant digit and increases by two for each digit to it's left.
The hash is the sum of these two sums.

For example, if you claim that the example above, namely 0x23DF4 = 391264, is a solution, you would calculate the hash as follows:

h(0x23DF4) = (2*5) + (3*4) + (13*3) + (15*2) + (4*1) = 95
h(391264) = (3*12) + (9*10) + (1*8) + (2*6) + (6*4) + (6*2) = 182
hash = 95 + 182 = 277

At first, let's apply this same approach for posting your bounding limits. In about a week you can reveal actual values for both solutions and limits, as well as the approach you used.

Remember, the point is to NOT just write a program to do a brute-force search, but to do it with pencil and paper and nothing more than the capabilities of a four-function calculator.

EDIT: Fix typos - Thanks, Ya'akov.

 

Background:

I gave an exam recently and parts of it involved converting values expressed in hexadecimal to decimal. Seven people did these conversions the same wrong way, which I'll demonstrate by example below:

0x23DF4

2   3   D   F   4
|   |   |   |   |
2   3  13  15   4

4 x 16 = 64
15 x 16 = 240
13 x 16 = 208
3 x 16 = 48
2 x 16 = 32

      64
    240
   208
   48
  32
---------
  391264

(ASIDE: Five others just crammed the individual digit conversions together to get 2313154.)

Puzzle:

While this conversion technique is clearly wrong in general, for small hexadecimal values it results in decimal results that are too large, while for sufficiently large hexadecimal values it results in decimal values that are too small. This raises the question of if there are any hexadecimal values for which this technique, by coincidence, happens to produce the correct hexadecimal values. An obvious, and trivial, case is 0x0, so we will exclude that from further consideration.

Writing a program to search the space is very easy -- though one person that tried that didn't search a large enough space and concluded that there were no nontrivial solutions.

So the challenge of the puzzle is to, by analysis, answer as many of the following questions as possible:

Are there any nontrivial solutions?

And, yes, the comment above reveals the answer to this question, but it's not enough to just say, "Yes," you have to actually prove it.

Assuming that there are non-trivial solutions:

Can you find a nontrivial solution (and, if so, what is it)?
How many nontrivial solutions are there?
What is the largest value that you can prove is a lower bound on nontrivial solutions?
What is the smallest value that you can prove is an upper bound on nontrivial solutions?
What is the smallest non-trivial solution?
What is the largest non-trivial solution?

To avoid spoiling the fun too quickly, don't give actual solutions, but instead supply a simple 'hash' for them as follows:

Sum up the digits in the hex value, each multiplied by i where i = 1 for the least significant digit and increases by one for each digit to it's left.
Sum up the digits in the dec value, each multiplied by i where i = 1 for the least significant digit and increases by two for each digit to it's left.
The hash is the sum of these two sums.

For example, if you claim that the example above, namely 0x23DF4 = 391264, is a solution, you would calculate the hash as follows:

h(0x23DF4) = (2*5) + (3*4) + (13*3) + (15*2) + (4*1) = 95
h(391264) = (3*12) + (9*10) + (1*8) + (2*6) + (6*4) + (6*2) = 182
hash = 95 + 182 = 277

At first, let's apply this same approach for posting your bounding limits. In about a week you can reveal actual values for both solutions and limits, as well as the approach you used.

Remember, the point is to NOT just write a program to do a brute-force search, but to do it with pencil and paper and nothing more than the capabilities of a four-function calculator.

EDIT: Fix typos - Thanks, Ya'akov.

Hey, I got one right away! It's 0x0 ! (just kidding).

There is another trivial solution very easy to see given that there is no set, required number of digits. I don't want to say anything else just yet but by visual examination it pops right out at ya. In fact, that leads to ...

 

Hey, I got one right away! It's 0x0 ! (just kidding).

There is another trivial solution very easy to see given that there is no set, required number of digits. I don't want to say anything else just yet but by visual examination it pops right out at ya. In fact, that leads to ...

Thanks for posting. I figured there was no interest, so I've been working, off and on, on a post with my approach and solutions. I'll hold off awhile.

I'm curious about this other trivial solution you claim to have found. The only thing I can think of that you might be talking about is infinity, but that doesn't work for a couple of reasons. First, it's not representable as a hexadecimal integer. Second, the error does not go to zero as the hex value grows unbounded, instead if goes to negative infinity (if the error is take as (wrong value - right value) ).

 

Thanks for posting. I figured there was no interest, so I've been working, off and on, on a post with my approach and solutions. I'll hold off awhile.

I'm curious about this other trivial solution you claim to have found. The only thing I can think of that you might be talking about is infinity, but that doesn't work for a couple of reasons. First, it's not representable as a hexadecimal integer. Second, the error does not go to zero as the hex value grows unbounded, instead if goes to negative infinity (if the error is take as (wrong value - right value) ).

Hello again,

Oh I didn't realize we could use negative values too.
I actually didn't look at infinity yet. That might be true.
(PM sent).
What might be even more interesting is the rather unusual answers you were seeing from the tests

 

Hello again,

Oh I didn't realize we could use negative values too.
I actually didn't look at infinity yet. That might be true.
(PM sent).
What might be even more interesting is the rather unusual answers you were seeing from the tests

No negative values -- just normal unsigned integers expressed in hexadecimal. The negative infinity refers to the error between the correct value and the wrong value.

 

No negative values -- just normal unsigned integers expressed in hexadecimal. The negative infinity refers to the error between the correct value and the wrong value.

Hi,

Yes I found this interesting I sometimes play around with questions like this. They might seem strange to some people but I've always found them interesting to look at if I have the time and I am awake enough.
For example, taking the square root of a number repeatedly, starting with slightly bigger numbers then with numbers very small like 0.001 (that's a simple one though).

I found the results you got back from the tests amusing

 

Amusing -- and utterly pathetic.

 

23DF4 hexa is 146932 dec
Or maybe I don't understand the problem
4+
(F=15) 15*16 = 240 + (16 in hex is equivalent to 10 in decimal)
(D=13) 13*16*16=3 328 +
3*16*16*16= 12 288+
2*16*16*16*16=131 072
------------------------------------
=146932

 

64+
240
------------------
Shifting to the left by one decimal place is the equivalent of multiplying by 10 in decimal.

Another idea to multiply by 10 is X*10=X*8+X*2
X*8 Shift left with 3 positions in binary
X*2 Shift left with 1 positions in binary

2 3 D F 4 hex
0010 0011 1101 1111 0100 bin

0000 0100 + (4hex)

1111 0000 + (F hex shift left by 4= multiplication by 16)
-------------------------------
1111 0100

 

question of if there are any hexadecimal values for which this technique, by coincidence, happens to produce the correct

It is only correct for single-digit numbers in hexadecimal

 

It is only correct for single-digit numbers in hexadecimal

Other than the trivial case of 0x0, it is not correct for single-digit hex numbers.

Counter-example: 0x1

Using the wrong technique:
1*16 = 16

value = 16

Remember, the first step in the wrong algorithm multiplies each individual hex digit, including the one's digit, buy sixteen.

 

23DF4 hexa is 146932 dec
Or maybe I don't understand the problem
4+
(F=15) 15*16 = 240 + (16 in hex is equivalent to 10 in decimal)
(D=13) 13*16*16=3 328 +
3*16*16*16= 12 288+
2*16*16*16*16=131 072
------------------------------------
=146932

Oh It's interesting that someone else became interested in this too.

I think I had calculated that the next collision would only be reached after using 9 hex digits. That means there would be no solution for 1 digit, 2 digits, 3 digits, ... 8 digits, except of course for the 0x00 collision.
See if you can verify this, or refute it.

 

Oh It's interesting that someone else became interested in this too.

I think I had calculated that the next collision would only be reached after using 9 hex digits. That means there would be no solution for 1 digit, 2 digits, 3 digits, ... 8 digits, except of course for the 0x00 collision.
See if you can verify this, or refute it.

You can show pretty quickly that any nontrivial solutions, if they exist, must have exactly seven hex digits.

Post your reasoning behind there not being any with 7 or 8 digits and I will try to find the flaw.

 

You can show pretty quickly that any nontrivial solutions, if they exist, must have exactly seven hex digits.

Post your reasoning behind there not being any with 7 or 8 digits and I will try to find the flaw.

I already PM'd you with the explanation but can't find the PM now. Did that get deleted?
I had shown the equation I used plus the reasoning behind the conclusion.

 

I already PM'd you with the explanation but can't find the PM now. Did that get deleted?
I had shown the equation I used plus the reasoning behind the conclusion.

It didn't get deleted on my end -- and I ground the explanation you were referring to.

For context, here's the equation you were working with:

16777216*g+1048576*f+65536*e+4096*d+256*c+16*b+a
=
16000000*g+1600000*f+160000*e+16000*d+1600*c+160*b+16*a

This is for a hex number of the form 0xgfedcba

One hint that might let you pursue that line of approach is that we can easily establish that 'a' must be zero.

 

It didn't get deleted on my end -- and I ground the explanation you were referring to.

For context, here's the equation you were working with:

16777216*g+1048576*f+65536*e+4096*d+256*c+16*b+a
=
16000000*g+1600000*f+160000*e+16000*d+1600*c+160*b+16*a

This is for a hex number of the form 0xgfedcba

One hint that might let you pursue that line of approach is that we can easily establish that 'a' must be zero.

Oh then maybe it was 7 digits not 9 like I thought.

But why can't I see the PM thread now? It should be under "conversations" right?

 

Oh then maybe it was 7 digits not 9 like I thought.

But why can't I see the PM thread now? It should be under "conversations" right?

That's where it is for me? Have no idea why you aren't seeing it.

When I click on the envelope icon, I then click on the "Show all..." link. But I'm using the Beautiful Blue theme and not the Obnoxious Orange one.

 

That's where it is for me? Have no idea why you aren't seeing it.

When I click on the envelope icon, I then click on the "Show all..." link. But I'm using the Beautiful Blue theme and not the Obnoxious Orange one.

Oh haha, yes, I didn't know you needed to click that to see them all so I found it now, thanks a bunch

I'll quote what I wrote because it's been some time now so other members have had a chance to think about it, and besides there may be a refutation to my conclusion anyway. this quote contains the equations and the logic I used to deduce that the minimum number of hex digits for another collision would have to be 7, not 9 as I thought I remembered.

Be right back with the quote...

START_OF_QUOTE (some grammar corrected):
As to the current problem, I think we can say that we need at least 7 digits before we can show that 'a' can be positive and not negative.
Here is the seven variable equation:
16777216*g+1048576*f+65536*e+4096*d+256*c+16*b+a
=
16000000*g+1600000*f+160000*e+16000*d+1600*c+160*b+16*a

It becomes clear that with each new digit added, the coefficients on the right become 10 times the previous coefficient, and the coefficients on the left become 16 times the previous coefficient. And, because we need at least 'a' to be positive or zero, that means that there is no way we can get that until the highest order coefficient on the left becomes greater than the highest order coefficient on the right. Before that, 'a' always comes out negative.
The only thing is, we can some fractions which may be hard to get them to naturally turn into integers when the terms are summed. The solution for 'a' with 7 digits is:
a=(259072*g-183808*f-31488*e-3968*d-448*c-48*b)/5

and it may be hard to get 'a' to be a whole number now, and also be less than 16. This is a significant constraint I think so it may be possible there is no solution other than zero.
Factoring that solution for 'a' leads to:
a=(16/5)*(16192*g-11488*f-1968*e-248*d-28*c-3*b)
That fraction of 16/5 means we probably can't get 'a' to be a whole number because all the other variables would have to be whole numbers, so the terms would all sum to a single whole number, which means we get stuck with that 16/5 fraction which makes 'a' a non-integer. That could however be the key to solving this (haven't checked anything higher yet though)
END_QUOTE

 

It's been long enough that I'll post the majority of my solution -- the rest of the stuff is just tweaks and fine points that I find interest, but that aren't necessary. This is so that people that run across it in the future can see what I did.

Originally, I put this in spoiler tags, but the tex stuff doesn't render there.

So go ye no further if see not solution thou want.


First, I noted that the wrong method multiplies every digit by sixteen, including the ones digit. This results in the decimal value being too large. Then they proceeded to convert the number, using digit values that are sixteen times too large, by multiplying each digit by a weight that is base-10 and not base-16, resulting in the decimal value being too small. That opens the door to the possibility that there may be one or more values for which this approach actually yields the correct result.

The approach I took was to look at the error function between the correct value and the "wrong" value for an N-digit hex number.

Correct value:

\(R \; = \; \sum\limits_{i=0}^{N-1} \left( D_i \cdot 16^i \right)\)

Wrong value:

\(
W \; = \; \sum\limits_{i=0}^{N-1} \left( \left(D_i \cdot 16 \right) 10^i \right)
\)

Error function:

\(
\begin{align}
E \; &= \; W \; - \; R \\
&= \; \sum\limits_{i=0}^{N-1} \left( \left(D_i \cdot 16 \right) 10^i \right) \; - \; \sum\limits_{i=0}^{N-1} \left( D_i \cdot 16^i \right) \\
&= \; \sum\limits_{i=0}^{N-1} \left( D_i \cdot 16 \cdot 10^i \; - \; D_i \cdot 16^i \right) \\
&= \; \sum\limits_{i=0}^{N-1} \left( D_i \left( 16 \cdot 10^i \; - \; 16^i \right) \right) \\
&= \; \sum\limits_{i=0}^{N-1} \left( D_i \cdot E_i \right)
\end{align}
\)

where the "error weights" are given by

\(
E_i \; = \; 16 \cdot 10^i \; - \; 16^i
\)

Then I tabulated the first several error weights:

i       Ei
0            15
1           144
2         1,344
3        11,904
4        94,464
5       551,424
6      -777,216
7  -108,435,456

Since we are looking for the error to be zero, we immediately see that any nontrivial solution has to have at least seven hex digits. Since all of the error weights beyond what is in the table just get progressively more negative, it also turns out that any nontrivial solution can't have more than seven hex digits because the contribution of the portion of the number associated with positive weights is capped at fifteen times the sum of the positive weights, which works out to

E_max = 9,889,425

In fact, since 9,889,425 / 777,216 = 12.72..., all solutions are less than 0xC000000.

Furthermore, because all of the weights except E0 are divisible by 16 and E0 is not even divisible by 2 and no digit value (0..15) is divisibly by 16, we know that any solution has zero for its least significant hex digit. Thus our search space is already narrowed to a little over 11.5 million possible solutions.

To find a solution, we can attempt a greedy approach. Since the error weights are not greedy, a greedy algorithm is not guaranteed to find a solution even if one exists. But its simple, so it might find some low hanging fruit.

We start by picking the lowest digit that has a negative error weight:

0x1?????0 (-777,216)

Then we reduce this error as much as we can with the next digit:

0x11????0 (-225,792)

Proceeding with successively lower digits, we obtain:

0x112???0 (-36,864)
0x1123??0 (-1,152)
0x11230?0 (-1,152)
0x1123080 (0)

The decimal equivalent of 0x1123080 is 17,969,280

Next, we need to confirm that this is, indeed, a solution:

0*16 =   0
8*16 = 128
0*16 =   0
3*16 =  48
2*16 =  32
1*16 =  16
1*16 =  16

          0
       128-
        0--
      48---
     32----
    16-----
 + 16------
------------
   17969280

So it IS a solution.

Running an exhaustive search of all potential solutions yields that there are 64 of them.

  1)          0 [0x00000000] (sig =   0)
  2)   17272640 [0x01078F40] (sig = 403)
  3)   17969280 [0x01123080] (sig = 449)
  4)   34583680 [0x020FB480] (sig = 497)
  5)   35241920 [0x0219BFC0] (sig = 430)
  6)   35243840 [0x0219C740] (sig = 412)
  7)   35276800 [0x021A4800] (sig = 418)
  8)   35904000 [0x0223DA00] (sig = 381)
  9)   53213120 [0x032BF7C0] (sig = 387)
 10)   53246080 [0x032C7880] (sig = 427)
 11)   53248000 [0x032C8000] (sig = 375)
 12)   53906240 [0x03368B40] (sig = 448)
 13)   53939200 [0x03370C00] (sig = 454)
 14)   54566400 [0x03409E00] (sig = 451)
 15)   71217280 [0x043EB080] (sig = 436)
 16)   71248320 [0x043F29C0] (sig = 460)
 17)   71250240 [0x043F3140] (sig = 372)
 18)   71875520 [0x0448BBC0] (sig = 563)
 19)   71877440 [0x0448C340] (sig = 545)
 20)   71908480 [0x04493C80] (sig = 515)
 21)   71910400 [0x04494400] (sig = 393)
 22)   72535680 [0x0452CE80] (sig = 512)
 23)   72537600 [0x0452D600] (sig = 460)
 24)   72568640 [0x04534F40] (sig = 518)
 25)   89846720 [0x055AF3C0] (sig = 696)
 26)   89879680 [0x055B7480] (sig = 736)
 27)   90537920 [0x05657FC0] (sig = 545)
 28)   90539840 [0x05658740] (sig = 527)
 29)   90572800 [0x05660800] (sig = 463)
 30)  107881920 [0x066E25C0] (sig = 557)
 31)  108509120 [0x0677B7C0] (sig = 484)
 32)  108542080 [0x06783880] (sig = 454)
 33)  108544000 [0x06784000] (sig = 402)
 34)  109169280 [0x0681CA80] (sig = 521)
 35)  109171200 [0x0681D200] (sig = 399)
 36)  109202240 [0x06824B40] (sig = 369)
 37)  125816640 [0x077FCF40] (sig = 593)
 38)  126513280 [0x078A7080] (sig = 463)
 39)  127171520 [0x07947BC0] (sig = 484)
 40)  127173440 [0x07948340] (sig = 466)
 41)  127206400 [0x07950400] (sig = 384)
 42)  144515520 [0x089D21C0] (sig = 496)
 43)  145142720 [0x08A6B3C0] (sig = 493)
 44)  145175680 [0x08A73480] (sig = 533)
 45)  145802880 [0x08B0C680] (sig = 548)
 46)  145833920 [0x08B13FC0] (sig = 572)
 47)  145835840 [0x08B14740] (sig = 554)
 48)  162450240 [0x09AECB40] (sig = 550)
 49)  162483200 [0x09AF4C00] (sig = 556)
 50)  163110400 [0x09B8DE00] (sig = 465)
 51)  163805120 [0x09C377C0] (sig = 529)
 52)  163840000 [0x09C40000] (sig = 447)
 53)  181112640 [0x0ACB8F40] (sig = 532)
 54)  181809280 [0x0AD63080] (sig = 578)
 55)  182467520 [0x0AE03BC0] (sig = 599)
 56)  182469440 [0x0AE04340] (sig = 581)
 57)  199081920 [0x0BDDBFC0] (sig = 771)
 58)  199083840 [0x0BDDC740] (sig = 753)
 59)  199116800 [0x0BDE4800] (sig = 671)
 60)  199744000 [0x0BE7DA00] (sig = 722)
 61)  200438720 [0x0BF273C0] (sig = 466)
 62)  217053120 [0x0CEFF7C0] (sig = 586)
 63)  217746240 [0x0CFA8B40] (sig = 647)
 64)  217779200 [0x0CFB0C00] (sig = 653)
64 values that work with a cumulative signature of 32151
MAX ERROR at   16777215 [0x00FFFFFF] is 9889425

 

It's been long enough that I'll post the majority of my solution -- the rest of the stuff is just tweaks and fine points that I find interest, but that aren't necessary. This is so that people that run across it in the future can see what I did.

Originally, I put this in spoiler tags, but the tex stuff doesn't render there.

So go ye no further if see not solution thou want.


First, I noted that the wrong method multiplies every digit by sixteen, including the ones digit. This results in the decimal value being too large. Then they proceeded to convert the number, using digit values that are sixteen times too large, by multiplying each digit by a weight that is base-10 and not base-16, resulting in the decimal value being too small. That opens the door to the possibility that there may be one or more values for which this approach actually yields the correct result.

The approach I took was to look at the error function between the correct value and the "wrong" value for an N-digit hex number.

Correct value:

\(R \; = \; \sum\limits_{i=0}^{N-1} \left( D_i \cdot 16^i \right)\)

Wrong value:

\(
W \; = \; \sum\limits_{i=0}^{N-1} \left( \left(D_i \cdot 16 \right) 10^i \right)
\)

Error function:

\(
\begin{align}
E \; &= \; W \; - \; R \\
&= \; \sum\limits_{i=0}^{N-1} \left( \left(D_i \cdot 16 \right) 10^i \right) \; - \; \sum\limits_{i=0}^{N-1} \left( D_i \cdot 16^i \right) \\
&= \; \sum\limits_{i=0}^{N-1} \left( D_i \cdot 16 \cdot 10^i \; - \; D_i \cdot 16^i \right) \\
&= \; \sum\limits_{i=0}^{N-1} \left( D_i \left( 16 \cdot 10^i \; - \; 16^i \right) \right) \\
&= \; \sum\limits_{i=0}^{N-1} \left( D_i \cdot E_i \right)
\end{align}
\)

where the "error weights" are given by

\(
E_i \; = \; 16 \cdot 10^i \; - \; 16^i
\)

Then I tabulated the first several error weights:

i       Ei
0            15
1           144
2         1,344
3        11,904
4        94,464
5       551,424
6      -777,216
7  -108,435,456

Since we are looking for the error to be zero, we immediately see that any nontrivial solution has to have at least seven hex digits. Since all of the error weights beyond what is in the table just get progressively more negative, it also turns out that any nontrivial solution can't have more than seven hex digits because the contribution of the portion of the number associated with positive weights is capped at fifteen times the sum of the positive weights, which works out to

E_max = 9,889,425

In fact, since 9,889,425 / 777,216 = 12.72..., all solutions are less than 0xC000000.

Furthermore, because all of the weights except E0 are divisible by 16 and E0 is not even divisible by 2 and no digit value (0..15) is divisibly by 16, we know that any solution has zero for its least significant hex digit. Thus our search space is already narrowed to a little over 11.5 million possible solutions.

To find a solution, we can attempt a greedy approach. Since the error weights are not greedy, a greedy algorithm is not guaranteed to find a solution even if one exists. But its simple, so it might find some low hanging fruit.

We start by picking the lowest digit that has a negative error weight:

0x1?????0 (-777,216)

Then we reduce this error as much as we can with the next digit:

0x11????0 (-225,792)

Proceeding with successively lower digits, we obtain:

0x112???0 (-36,864)
0x1123??0 (-1,152)
0x11230?0 (-1,152)
0x1123080 (0)

The decimal equivalent of 0x1123080 is 17,969,280

Next, we need to confirm that this is, indeed, a solution:

0*16 =   0
8*16 = 128
0*16 =   0
3*16 =  48
2*16 =  32
1*16 =  16
1*16 =  16

          0
       128-
        0--
      48---
     32----
    16-----
+ 16------
------------
   17969280

So it IS a solution.

Running an exhaustive search of all potential solutions yields that there are 64 of them.

  1)          0 [0x00000000] (sig =   0)
  2)   17272640 [0x01078F40] (sig = 403)
  3)   17969280 [0x01123080] (sig = 449)
  4)   34583680 [0x020FB480] (sig = 497)
  5)   35241920 [0x0219BFC0] (sig = 430)
  6)   35243840 [0x0219C740] (sig = 412)
  7)   35276800 [0x021A4800] (sig = 418)
  8)   35904000 [0x0223DA00] (sig = 381)
  9)   53213120 [0x032BF7C0] (sig = 387)
10)   53246080 [0x032C7880] (sig = 427)
11)   53248000 [0x032C8000] (sig = 375)
12)   53906240 [0x03368B40] (sig = 448)
13)   53939200 [0x03370C00] (sig = 454)
14)   54566400 [0x03409E00] (sig = 451)
15)   71217280 [0x043EB080] (sig = 436)
16)   71248320 [0x043F29C0] (sig = 460)
17)   71250240 [0x043F3140] (sig = 372)
18)   71875520 [0x0448BBC0] (sig = 563)
19)   71877440 [0x0448C340] (sig = 545)
20)   71908480 [0x04493C80] (sig = 515)
21)   71910400 [0x04494400] (sig = 393)
22)   72535680 [0x0452CE80] (sig = 512)
23)   72537600 [0x0452D600] (sig = 460)
24)   72568640 [0x04534F40] (sig = 518)
25)   89846720 [0x055AF3C0] (sig = 696)
26)   89879680 [0x055B7480] (sig = 736)
27)   90537920 [0x05657FC0] (sig = 545)
28)   90539840 [0x05658740] (sig = 527)
29)   90572800 [0x05660800] (sig = 463)
30)  107881920 [0x066E25C0] (sig = 557)
31)  108509120 [0x0677B7C0] (sig = 484)
32)  108542080 [0x06783880] (sig = 454)
33)  108544000 [0x06784000] (sig = 402)
34)  109169280 [0x0681CA80] (sig = 521)
35)  109171200 [0x0681D200] (sig = 399)
36)  109202240 [0x06824B40] (sig = 369)
37)  125816640 [0x077FCF40] (sig = 593)
38)  126513280 [0x078A7080] (sig = 463)
39)  127171520 [0x07947BC0] (sig = 484)
40)  127173440 [0x07948340] (sig = 466)
41)  127206400 [0x07950400] (sig = 384)
42)  144515520 [0x089D21C0] (sig = 496)
43)  145142720 [0x08A6B3C0] (sig = 493)
44)  145175680 [0x08A73480] (sig = 533)
45)  145802880 [0x08B0C680] (sig = 548)
46)  145833920 [0x08B13FC0] (sig = 572)
47)  145835840 [0x08B14740] (sig = 554)
48)  162450240 [0x09AECB40] (sig = 550)
49)  162483200 [0x09AF4C00] (sig = 556)
50)  163110400 [0x09B8DE00] (sig = 465)
51)  163805120 [0x09C377C0] (sig = 529)
52)  163840000 [0x09C40000] (sig = 447)
53)  181112640 [0x0ACB8F40] (sig = 532)
54)  181809280 [0x0AD63080] (sig = 578)
55)  182467520 [0x0AE03BC0] (sig = 599)
56)  182469440 [0x0AE04340] (sig = 581)
57)  199081920 [0x0BDDBFC0] (sig = 771)
58)  199083840 [0x0BDDC740] (sig = 753)
59)  199116800 [0x0BDE4800] (sig = 671)
60)  199744000 [0x0BE7DA00] (sig = 722)
61)  200438720 [0x0BF273C0] (sig = 466)
62)  217053120 [0x0CEFF7C0] (sig = 586)
63)  217746240 [0x0CFA8B40] (sig = 647)
64)  217779200 [0x0CFB0C00] (sig = 653)
64 values that work with a cumulative signature of 32151
MAX ERROR at   16777215 [0x00FFFFFF] is 9889425

Yes that looks interesting. I was't sure what you meant by "using summation" in our previous chat, but I can see what you mean now.
Next, I wonder if there is a practical use for this, or at least the general method. Sometimes great things come out of looking at unusual problems.