I have a mathematics problem I need the answer to but my skills are not really up to the challenge. I believe it is a relatively simple problem but I may be wrong, there may even be no mathematical answer. The goal is to convert a given number or set of numbers in hex to another specific number or set. The relationships between the numbers are unlikely to be a factor as I sampled them randomly and the sets have no real cohesion. If there is a solution it will probably work for single numbers. Here are some sample input and output. A solution for the reverse, ie. result=start is also acceptable

Start - Result

0x2F3668 - 0x1B1F3B

0x2F3668 - 0x1B1F3B

0x252A4F - 0x15182D

0x252A4F - 0x15182D

0x2F3668 - 0x1B1F3B

0x2F3668 - 0x1B1F3B

0x777777 - 0x444444

0x848484 - 0x4B4B4B

0x6A6A6A - 0x3C3C3C

0x2A2A2A - 0x181818

0x777777 - 0x444444

0x6A6A6A - 0x3C3C3C

Thanks in advance

## A simple puzzle (hopefully)

**Moderators:** gmalivuk, Moderators General, Prelates

### A simple puzzle (hopefully)

***This post is my own opinion and no claim is being made that it is in any way scientific nor intended to be construed as such by any reader***

### Re: A simple puzzle (hopefully)

Why not try it for small numbers, and take them out of hex? It might make it easier to spot a pattern!

### Re: A simple puzzle (hopefully)

Your sample set is really too small to form a conjecture. In particular, because you repeatedly used the same values. Why did you do that?

Nevertheless, I hazard a guess that this is the result of a sequence of logical bit level operations. I immediately spotted that a sequence of 7s was converted to a sequence of 4s. This reminded me of so called Gray coding (often used in telecommunications applications) which amounts to: first shift right one position, and then form the bitwise XOR of the result and the original number. Unfortunately that conjecture fails at your other data points.

I also guess that the function operates on the level of bytes. In other words, pairs of hex-digits. The evidence for this is that a pair of hexits is always mapped in the same way. For example the byte 0x2A seems to always map to 0x18. Irrespective of whether it is the least significant byte, in the middle, or the most significant byte of any 24-bit number. Look at the entries for 0x252A4F and 0x2A2A2A. Their respective images both have 0x18 as the middle byte.

If this is a black box function that you can test further, why don't you try

0x000001

0x000002

....

0x0000FF,

and then for comparison test the above "conjecture" (a pair of hexits produces identical output irrespective of whether they are (1st and 2nd) or (3rd and 4th) or (5th and 6th).

0x000100

0x000200

0x000300

....

0x00FF00

Also please test the other "conjecture" that the output of a single byte does not depend on the "surrounding bytes".

In other words, whether the images of for example

0x001C00

0x3D1C2F

0xe21C76

all share the same middle byte (=the image of 0x1C).

Of course, it is perfectly possible, even likely, that I'm wrong here. I'm just grasping at straws given the very small sample data set to work with

Are these 24-bit integers supposed to be RGB color codes?

Nevertheless, I hazard a guess that this is the result of a sequence of logical bit level operations. I immediately spotted that a sequence of 7s was converted to a sequence of 4s. This reminded me of so called Gray coding (often used in telecommunications applications) which amounts to: first shift right one position, and then form the bitwise XOR of the result and the original number. Unfortunately that conjecture fails at your other data points.

I also guess that the function operates on the level of bytes. In other words, pairs of hex-digits. The evidence for this is that a pair of hexits is always mapped in the same way. For example the byte 0x2A seems to always map to 0x18. Irrespective of whether it is the least significant byte, in the middle, or the most significant byte of any 24-bit number. Look at the entries for 0x252A4F and 0x2A2A2A. Their respective images both have 0x18 as the middle byte.

If this is a black box function that you can test further, why don't you try

0x000001

0x000002

....

0x0000FF,

and then for comparison test the above "conjecture" (a pair of hexits produces identical output irrespective of whether they are (1st and 2nd) or (3rd and 4th) or (5th and 6th).

0x000100

0x000200

0x000300

....

0x00FF00

Also please test the other "conjecture" that the output of a single byte does not depend on the "surrounding bytes".

In other words, whether the images of for example

0x001C00

0x3D1C2F

0xe21C76

all share the same middle byte (=the image of 0x1C).

Of course, it is perfectly possible, even likely, that I'm wrong here. I'm just grasping at straws given the very small sample data set to work with

Are these 24-bit integers supposed to be RGB color codes?

### Re: A simple puzzle (hopefully)

If you just look at the bytes in hex, you get:

25 - 15

2A - 18

2F - 1B

36 - 1F

4F - 2D

68 - 3B

6A - 3C

77 - 44

84 - 4B

In decimal that is:

37 - 21

42 - 24

47 - 27

54 - 31

79 - 45

104 - 59

106 - 60

119 - 68

132 - 75

The right column is almost exactly 4/7 times the left column, rounded to the nearest integer.

25 - 15

2A - 18

2F - 1B

36 - 1F

4F - 2D

68 - 3B

6A - 3C

77 - 44

84 - 4B

In decimal that is:

37 - 21

42 - 24

47 - 27

54 - 31

79 - 45

104 - 59

106 - 60

119 - 68

132 - 75

The right column is almost exactly 4/7 times the left column, rounded to the nearest integer.

### Re: A simple puzzle (hopefully)

I guess I should have given the details from the start. I thought you guys would enjoy the challenge more if it was a mystery but it seems that it is a pretty arbitrary function so here are the details:

The hex numbers represent pixel colours, I think it is bgr not rgb but I am not sure and it hardly matters. Each 6 data points is a set of 6 pixels taken from a tile in the rougelike Dungeon crawl (the most recent stone tiles version). The function is between a given tile when it is in the players view, and when it is not. Unseen tiles turn slightly darker. I thought something like *4/7 might have been right but when I tested it I didn't get the desired effect.

The following is a downward stairway, first visible and then not.

0x2A2A2A

0x373737

0x515151

0x373737

0x2A2A2A

0x6A6A6A

0x181818

0x1F1F1F

0x2E2E2E

0x1F1F1F

0x181818

0x3C3C3C

this is a suit of leather armour (not all points are necessarily part of the armour and may hit the ground underneath, but I am fairly sure the background tile was the same on both samples)

0x0028A0

0x001860

0x000C30

0x002080

0x002080

0x0028A0

0x00175B

0x000E37

0x00071B

0x001249

0x001249

0x00175B

looking at the game code is cheating

The hex numbers represent pixel colours, I think it is bgr not rgb but I am not sure and it hardly matters. Each 6 data points is a set of 6 pixels taken from a tile in the rougelike Dungeon crawl (the most recent stone tiles version). The function is between a given tile when it is in the players view, and when it is not. Unseen tiles turn slightly darker. I thought something like *4/7 might have been right but when I tested it I didn't get the desired effect.

The following is a downward stairway, first visible and then not.

0x2A2A2A

0x373737

0x515151

0x373737

0x2A2A2A

0x6A6A6A

0x181818

0x1F1F1F

0x2E2E2E

0x1F1F1F

0x181818

0x3C3C3C

this is a suit of leather armour (not all points are necessarily part of the armour and may hit the ground underneath, but I am fairly sure the background tile was the same on both samples)

0x0028A0

0x001860

0x000C30

0x002080

0x002080

0x0028A0

0x00175B

0x000E37

0x00071B

0x001249

0x001249

0x00175B

looking at the game code is cheating

***This post is my own opinion and no claim is being made that it is in any way scientific nor intended to be construed as such by any reader***

### Re: A simple puzzle (hopefully)

For all of the examples given so far this seems to work:

for each byte, b, the new byte, n, is given by the nearest integer to 0.5685*b

or n=round(0.5685*b)

if that helps...

edit:

java code

also, coding from your cell phone is hard.

for each byte, b, the new byte, n, is given by the nearest integer to 0.5685*b

or n=round(0.5685*b)

if that helps...

edit:

java code

Code: Select all

`public static int convert(int in){`

int out=0;

for(int i = 0; in > 0; i++){

out += ((int)Math.round((in & 0xFF)*0.5685)) << (8*i);

in >>= 8;

}

return out;

}

also, coding from your cell phone is hard.

In questions of science, the authority of a thousand is not worth the humble reasoning of a single individual.

Galileo

Galileo

### Re: A simple puzzle (hopefully)

Given the data we have so far, each byte X is multiplied by a constant N, then rounded to the nearest integer to get the new byte Y.

The minimum value of N that will work is 109/192 ≈ 0.567708333, and the minimum value of N that will not work is 121/212 ≈ 0.570754717. If these are indeed pixel color values, then the part you cannot see is just darkened by about 43%.

The minimum value of N that will work is 109/192 ≈ 0.567708333, and the minimum value of N that will not work is 121/212 ≈ 0.570754717. If these are indeed pixel color values, then the part you cannot see is just darkened by about 43%.

wee free kings

### Who is online

Users browsing this forum: No registered users and 10 guests