Puzzle: When wrong is right.

panic mode

Joined Oct 10, 2011
4,984
i was using brute approach and got the same solution. the hash values i got are different though...

Code:
Public Class Form1
    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        Dim right, wrong As Long
        Dim hh, hd, h As Integer
        Dim hs As String
        Dim i As Integer = 0

        For i6 = 0 To 15
            For i5 = 0 To 15
                For i4 = 0 To 15
                    For i3 = 0 To 15
                        For i2 = 0 To 15
                            For i1 = 0 To 15
                                For i0 = 0 To 15
                                    right = i0 + 16 * (i1 + 16 * (i2 + 16 * (i3 + 16 * (i4 + 16 * (i5 + 16 * i6)))))
                                    wrong = 16 * (i0 + 10 * (i1 + 10 * (i2 + 10 * (i3 + 10 * (i4 + 10 * (i5 + 10 * i6))))))
                                    If right = wrong Then
                                        hh = i0 * 1 + i1 * 2 + i2 * 3 + i3 * 4 + i4 * 5 + i5 * 6 + i6 * 7
                                        hd = i0 * 2 + i1 * 4 + i2 * 6 + i3 * 8 + i4 * 10 + i5 * 12 + i6 * 14
                                        h = hh + hd
                                        hs = Hex(right)
                                        i = i + 1
                                        TextBox1.AppendText(i.ToString + ") 0x" + hs + "," + right.ToString + ", hash=" + h.ToString + vbCrLf)
                                    End If
                                Next
                            Next
                        Next
                    Next
                Next
            Next
        Next
    End Sub
End Class
1) 0x0,0, hash=0
2) 0x1078F40,17272640, hash=381
3) 0x1123080,17969280, hash=153
4) 0x20FB480,34583680, hash=483
5) 0x219BFC0,35241920, hash=534
6) 0x219C740,35243840, hash=426
7) 0x21A4800,35276800, hash=330
8) 0x223DA00,35904000, hash=369
9) 0x32BF7C0,53213120, hash=579
10) 0x32C7880,53246080, hash=483
11) 0x32C8000,53248000, hash=375
12) 0x3368B40,53906240, hash=426
13) 0x3370C00,53939200, hash=330
14) 0x3409E00,54566400, hash=369
15) 0x43EB080,71217280, hash=528
16) 0x43F29C0,71248320, hash=540
17) 0x43F3140,71250240, hash=432
18) 0x448BBC0,71875520, hash=579
19) 0x448C340,71877440, hash=471
20) 0x4493C80,71908480, hash=483
21) 0x4494400,71910400, hash=375
22) 0x452CE80,72535680, hash=522
23) 0x452D600,72537600, hash=414
24) 0x4534F40,72568640, hash=426
25) 0x55AF3C0,89846720, hash=624
26) 0x55B7480,89879680, hash=528
27) 0x5657FC0,90537920, hash=579
28) 0x5658740,90539840, hash=471
29) 0x5660800,90572800, hash=375
30) 0x66E25C0,107881920, hash=585
31) 0x677B7C0,108509120, hash=624
32) 0x6783880,108542080, hash=528
33) 0x6784000,108544000, hash=420
34) 0x681CA80,109169280, hash=567
35) 0x681D200,109171200, hash=459
36) 0x6824B40,109202240, hash=471
37) 0x77FCF40,125816640, hash=801
38) 0x78A7080,126513280, hash=573
39) 0x7947BC0,127171520, hash=624
40) 0x7948340,127173440, hash=516
41) 0x7950400,127206400, hash=420
42) 0x89D21C0,144515520, hash=630
43) 0x8A6B3C0,145142720, hash=669
44) 0x8A73480,145175680, hash=573
45) 0x8B0C680,145802880, hash=612
46) 0x8B13FC0,145833920, hash=624
47) 0x8B14740,145835840, hash=516
48) 0x9AECB40,162450240, hash=846
49) 0x9AF4C00,162483200, hash=750
50) 0x9B8DE00,163110400, hash=789
51) 0x9C377C0,163805120, hash=669
52) 0x9C40000,163840000, hash=465
53) 0xACB8F40,181112640, hash=846
54) 0xAD63080,181809280, hash=618
55) 0xAE03BC0,182467520, hash=669
56) 0xAE04340,182469440, hash=561
57) 0xBDDBFC0,199081920, hash=999
58) 0xBDDC740,199083840, hash=891
59) 0xBDE4800,199116800, hash=795
60) 0xBE7DA00,199744000, hash=834
61) 0xBF273C0,200438720, hash=714
62) 0xCEFF7C0,217053120, hash=1044
63) 0xCFA8B40,217746240, hash=891
64) 0xCFB0C00,217779200, hash=795
 

Art Vandelay

Joined Nov 1, 2024
140
This turned out to be a neat problem. I had trouble working out the algebra so I wrote a program to brute the answer.

In lieu of the formal proof, my graphs show there are indeed a number of valid solutions. The correct formula is linear while the wrong produces a sawtooth. It's really interesting to see how the solutions intersect before diverging towards infinity when the sharp edge drops off.

eq.png

Figure_1.png
Figure_2.png
Figure_3.png

I'm giving myself half marks on this one for the visual proof.

:)
Python:
import matplotlib.pyplot as plt

def transform_hex_to_custom_decimal(hex_number):
    # Use a single pass to calculate the total sum
    total_sum = 0
    length = len(hex_number)

    # Precompute powers of 10 for efficiency
    power_of_10 = [10 ** i for i in range(length)]
   
    # Loop through each digit in the hexadecimal number
    for index, digit in enumerate(hex_number):
        # Convert hex digit to decimal
        decimal_value = int(digit, 16)  # Base 16 conversion
       
        # Calculate transformed value using precomputed multiplier
        transformed_value = decimal_value * (16 * power_of_10[length - index - 1])
       
        # Add to total sum
        total_sum += transformed_value
   
    return total_sum

def convert_hex_to_decimal(hex_number):
    # Use built-in int function for direct conversion
    return int(hex_number, 16)

def main():
    hex_values = []
    custom_results = []
    standard_results = []
   
    print(f"{'Hex':<5} | {'Custom Result':<20} | {'Standard Result':<20} | Match")
    print("-" * 60)
   
    # Define the range for decimal values (0 to 1000) and increment variable
    start = 1
    end = 1000
    increment = 1  # Change this value to set the increment step
   
    for i in range(start, end + 1, increment):  # Loop from start to end (inclusive) with a step of increment
        hex_input = f"{i:X}"  # Convert to hexadecimal string without leading '0x'
       
        # Call both functions with current hex input
        custom_decimal_result = transform_hex_to_custom_decimal(hex_input)
        standard_decimal_result = convert_hex_to_decimal(hex_input)
       
        # Store values for plotting
        hex_values.append(i)  # Store the decimal value for x-axis
        custom_results.append(custom_decimal_result)
        standard_results.append(standard_decimal_result)
       
        # Determine if results match
        match_status = "Match" if custom_decimal_result == standard_decimal_result else "No Match"
       
        # Print results side by side
        print(f"{hex_input:<5} | {custom_decimal_result:<20} | {standard_decimal_result:<20} | {match_status}")

    # Plotting results
    plt.figure(figsize=(12, 6))
    plt.plot(hex_values, custom_results, label='Custom Decimal Result', color='blue', alpha=0.7)
    plt.plot(hex_values, standard_results, label='Standard Decimal Result', color='orange', alpha=0.7)
   
    plt.title('Comparison of Custom and Standard Decimal Conversion with Increment = ' + str(increment))
    plt.xlabel('Decimal Value')
    plt.ylabel('Converted Value')
    plt.legend()
    plt.grid()
   
    plt.show()

if __name__ == "__main__":
    main()
 

MrAl

Joined Jun 17, 2014
13,704
Interesting replies, you all beat me to the brute force search I was going to do also at some point.
The waveforms idea was also interesting that gives a visual display.

My proof was based on the fractional part of any solution for any digit. If we can prove that any digit would have to have a fractional part in order to satisfy the equation, then it can't be right because Hex digits can not have a fractional part.
For example, if after computing the error we got a fractional part in one digit like 17.1, then the choice for the solution must be wrong. I could illustrate this using the 7 digit equation.

There could be practical applications for these ideas and solutions in the future we may come across one.

This reminds me of a Transformers movie trivia, a goof in the logic in a statement made by one of the "experts" in computer science and I think major in cryptology. When trying to decrypt a message from a robot of some kind, the 'expert' said this:
"Even a brute force algorithm would take years to decipher that message" (paraphrased but equivalent).
I'm like, "Yahh, no kidding Sherlock".
She made it sound like that was the fastest way to do it when really it is the slowest method. Thought that was funny. They call this kind of thing a movie "goof" and that's where something that is not reasonable comes into the movie, and it's usually very illogical.
 

Thread Starter

WBahn

Joined Mar 31, 2012
32,840
This turned out to be a neat problem. I had trouble working out the algebra so I wrote a program to brute the answer.

In lieu of the formal proof, my graphs show there are indeed a number of valid solutions. The correct formula is linear while the wrong produces a sawtooth. It's really interesting to see how the solutions intersect before diverging towards infinity when the sharp edge drops off.

View attachment 339880

View attachment 339881
View attachment 339882
View attachment 339883

I'm giving myself half marks on this one for the visual proof.

:)
Python:
import matplotlib.pyplot as plt

def transform_hex_to_custom_decimal(hex_number):
    # Use a single pass to calculate the total sum
    total_sum = 0
    length = len(hex_number)

    # Precompute powers of 10 for efficiency
    power_of_10 = [10 ** i for i in range(length)]
  
    # Loop through each digit in the hexadecimal number
    for index, digit in enumerate(hex_number):
        # Convert hex digit to decimal
        decimal_value = int(digit, 16)  # Base 16 conversion
      
        # Calculate transformed value using precomputed multiplier
        transformed_value = decimal_value * (16 * power_of_10[length - index - 1])
      
        # Add to total sum
        total_sum += transformed_value
  
    return total_sum

def convert_hex_to_decimal(hex_number):
    # Use built-in int function for direct conversion
    return int(hex_number, 16)

def main():
    hex_values = []
    custom_results = []
    standard_results = []
  
    print(f"{'Hex':<5} | {'Custom Result':<20} | {'Standard Result':<20} | Match")
    print("-" * 60)
  
    # Define the range for decimal values (0 to 1000) and increment variable
    start = 1
    end = 1000
    increment = 1  # Change this value to set the increment step
  
    for i in range(start, end + 1, increment):  # Loop from start to end (inclusive) with a step of increment
        hex_input = f"{i:X}"  # Convert to hexadecimal string without leading '0x'
      
        # Call both functions with current hex input
        custom_decimal_result = transform_hex_to_custom_decimal(hex_input)
        standard_decimal_result = convert_hex_to_decimal(hex_input)
      
        # Store values for plotting
        hex_values.append(i)  # Store the decimal value for x-axis
        custom_results.append(custom_decimal_result)
        standard_results.append(standard_decimal_result)
      
        # Determine if results match
        match_status = "Match" if custom_decimal_result == standard_decimal_result else "No Match"
      
        # Print results side by side
        print(f"{hex_input:<5} | {custom_decimal_result:<20} | {standard_decimal_result:<20} | {match_status}")

    # Plotting results
    plt.figure(figsize=(12, 6))
    plt.plot(hex_values, custom_results, label='Custom Decimal Result', color='blue', alpha=0.7)
    plt.plot(hex_values, standard_results, label='Standard Decimal Result', color='orange', alpha=0.7)
  
    plt.title('Comparison of Custom and Standard Decimal Conversion with Increment = ' + str(increment))
    plt.xlabel('Decimal Value')
    plt.ylabel('Converted Value')
    plt.legend()
    plt.grid()
  
    plt.show()

if __name__ == "__main__":
    main()
A friend of mine took the exact same approach -- but ended up concluding that there were no nontrivial solutions because he stopped his program at 0x1000000, just barely before the first nontrivial solution.
 

Thread Starter

WBahn

Joined Mar 31, 2012
32,840
This reminds me of a Transformers movie trivia, a goof in the logic in a statement made by one of the "experts" in computer science and I think major in cryptology. When trying to decrypt a message from a robot of some kind, the 'expert' said this:
"Even a brute force algorithm would take years to decipher that message" (paraphrased but equivalent).
I'm like, "Yahh, no kidding Sherlock".
She made it sound like that was the fastest way to do it when really it is the slowest method. Thought that was funny. They call this kind of thing a movie "goof" and that's where something that is not reasonable comes into the movie, and it's usually very illogical.
With damn few exceptions, neither the screenwriters nor the producers, nor anyone else involved care one bit about getting anything right in a movie. Their idea of "technical accuracy" is throwing out a mix of trendy buzzwords that the audience may have heard elsewhere on occasion, because that's all audiences generally need to conclude that these people really did their homework.

I sat next to an independent film producer on a long flight one time and I asked her why so many movies still make the same classic mistakes that are so frequent and so obvious that they have become cliche, such as someone standing there, with the camera on them the entire time, and firing ten or twelve shots out of a six-shot revolver. She said that it's because the effort to get it right is more than it's worth because the overwhelming majority of audiences don't even notice, and don't care about it if they do. She also said that many things, such as ridiculous capabilities of image enhancement, have so solidly crept into audiences expectations that if you portray them realistically, audiences will notice, but will claim that that is unrealistic and is a sign of how poorly the screenwriters did their research. She made a very good point and that is that the job of a movie maker (of most movies) is to make a movie that audiences will enjoy and that that requires, among other things, that you focus on things that will pull them out of a state of willing suspension of disbelief. So they need to know what will and won't do that -- and sometimes being accurate is the worst thing you can do. It goes without saying that they can't do this for every member of an audience and they know/accept that a lot of what they do to appease the majority of their audience will be the very things that royally piss of a small minority.
 

MrAl

Joined Jun 17, 2014
13,704
With damn few exceptions, neither the screenwriters nor the producers, nor anyone else involved care one bit about getting anything right in a movie. Their idea of "technical accuracy" is throwing out a mix of trendy buzzwords that the audience may have heard elsewhere on occasion, because that's all audiences generally need to conclude that these people really did their homework.

I sat next to an independent film producer on a long flight one time and I asked her why so many movies still make the same classic mistakes that are so frequent and so obvious that they have become cliche, such as someone standing there, with the camera on them the entire time, and firing ten or twelve shots out of a six-shot revolver. She said that it's because the effort to get it right is more than it's worth because the overwhelming majority of audiences don't even notice, and don't care about it if they do. She also said that many things, such as ridiculous capabilities of image enhancement, have so solidly crept into audiences expectations that if you portray them realistically, audiences will notice, but will claim that that is unrealistic and is a sign of how poorly the screenwriters did their research. She made a very good point and that is that the job of a movie maker (of most movies) is to make a movie that audiences will enjoy and that that requires, among other things, that you focus on things that will pull them out of a state of willing suspension of disbelief. So they need to know what will and won't do that -- and sometimes being accurate is the worst thing you can do. It goes without saying that they can't do this for every member of an audience and they know/accept that a lot of what they do to appease the majority of their audience will be the very things that royally piss of a small minority.
Hi,

That makes a h*** of a lot of sense. That also explains why I have trouble watching a lot of movies because they are so darn stupid with the technical and situational accuracies.

I happen to know a Hollywood director still working I'll have to ask him if he feels the same way.
 

crutschow

Joined Mar 14, 2008
38,508
It's curious to me that so many could not correctly convert hex to decimal.
So apparently they did not really understand how a number base other than 10 works.
How much course work did they get covering number bases?
 

Thread Starter

WBahn

Joined Mar 31, 2012
32,840
It's curious to me that so many could not correctly convert hex to decimal.
So apparently they did not really understand how a number base other than 10 works.
How much course work did they get covering number bases?
That's the really sad part -- I covered number bases from square one and in detail. I developed, in class and in supplementary reading material I put together, both brute force and efficient ways to convert from decimal to an arbitrary number base and from an arbitrary number base to decimal. I even showed them an example of how either method could be used to convert directly from an arbitrary number base to another arbitrary number base, except that with one method you have to do the arithmetic in the number base you are converting from and in the other you do it in the number base you are converting to.

But it is increasingly common that many students will go to any lengths they have to in order to avoid any risk of actually learning anything.
 

crutschow

Joined Mar 14, 2008
38,508
But it is increasingly common that many students will go to any lengths they have to in order to avoid any risk of actually learning anything.
Yes, that is sad.
Apparently they had no real interest or curiosity about the subject.
Was this a mandatory course or elective?
 
Top