Recent

Author Topic: Recreational maths: a very funny number  (Read 3011 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 3064
Recreational maths: a very funny number
« on: June 27, 2021, 10:21:08 pm »
I don't know whether this is coincidence, or a quirk of number theory. If it's the latter it's well beyond me, and I'd be interested in any comments.

I've got a test program which is sending binary messages to a graphical output device, the configuration messages can include a palette.

When I was defining palettes in the test program I decided that rather than entering in lots of numbers I'd allow the user to specify either a linear, logarithmic or antilogarithmic (exponential) transfer function.

The palette can be of various sizes: 2^1, 2^2 ... 2^6. The smallest value in the palette should be 0 and the largest 255, so in the case of 2^1 it's (0, 255) and so on.

Of these, the most demanding palette is the exponential palette of size 2^2, since the ideal is to have the smallest value zero and the next non-zero... getting this right took some experimentation. Assuming that entries indexed i = 0..3 are i^z, I get this for various values of z:

Code: Pascal  [Select][+][-]
  1. (* 1.0001       249 251 253 255                                                 *)
  2. (* 1.001        198 215 234 255                                                 *)
  3. (* 1.01          20  47 109 255                                                 *)
  4. (* 1.1            0   0   0 255                                                 *)
  5. (* 1.05           0   0   4 255                                                 *)
  6. (* 1.025          0   4  31 255                                                 *)
  7. (* 1.024          1   5  34 255                                                 *)
  8. (* 1.026          0   3  29 255                                                 *)
  9.  

I'm assuming that the best z for a palette sized 2^2 is also best for larger palettes, and I'm slightly spooked that the digit sequence radix 10 is so familiar.

Is there any rational reason why the best z = (2^10+1)/10^3 or is it a dumb coincidence? :-)

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MathMan

  • Full Member
  • ***
  • Posts: 236
Re: Recreational maths: a very funny number
« Reply #1 on: June 28, 2021, 08:29:35 am »
I don't know whether this is coincidence, or a quirk of number theory. If it's the latter it's well beyond me, and I'd be interested in any comments.

I've got a test program which is sending binary messages to a graphical output device, the configuration messages can include a palette.

When I was defining palettes in the test program I decided that rather than entering in lots of numbers I'd allow the user to specify either a linear, logarithmic or antilogarithmic (exponential) transfer function.

The palette can be of various sizes: 2^1, 2^2 ... 2^6. The smallest value in the palette should be 0 and the largest 255, so in the case of 2^1 it's (0, 255) and so on.

Of these, the most demanding palette is the exponential palette of size 2^2, since the ideal is to have the smallest value zero and the next non-zero... getting this right took some experimentation. Assuming that entries indexed i = 0..3 are i^z, I get this for various values of z:

Code: Pascal  [Select][+][-]
  1. (* 1.0001       249 251 253 255                                                 *)
  2. (* 1.001        198 215 234 255                                                 *)
  3. (* 1.01          20  47 109 255                                                 *)
  4. (* 1.1            0   0   0 255                                                 *)
  5. (* 1.05           0   0   4 255                                                 *)
  6. (* 1.025          0   4  31 255                                                 *)
  7. (* 1.024          1   5  34 255                                                 *)
  8. (* 1.026          0   3  29 255                                                 *)
  9.  

I'm assuming that the best z for a palette sized 2^2 is also best for larger palettes, and I'm slightly spooked that the digit sequence radix 10 is so familiar.

Is there any rational reason why the best z = (2^10+1)/10^3 or is it a dumb coincidence? :-)

MarkMLl

Hello MarkMLI,

I think I can follow the above up to, but not including, the list. Can you pls show how you calculate the linear, logarithmic & eponential transfer.

Depending on how you calculate the exponential transfer it is probably no coincidence that the "best fit" is the one you are seeing. If you are looking for an exponential fit that gives 0 (for i=0) and 255 (for i=2^k-1) then the natural approach would be to map i equidistant on the range 0..1 (in the reals) and calculate 256^(p(i))-1. You seem to have opted for keeping i as is and adapt the exponent z. Depending on the way you calculate it is reasonable that z is correlated to 256 (max range) times 4 (i variants) = 1024.

Cheers,
MathMan
« Last Edit: June 28, 2021, 09:30:52 am by MathMan »

MarkMLl

  • Hero Member
  • *****
  • Posts: 3064
Re: Recreational maths: a very funny number
« Reply #2 on: June 28, 2021, 09:31:52 am »
I think I can follow the above up to, but not including, the list. Can you pls show how you calculate the linear, logarithmic & eponential transfer.

Here's the relevant bits in a test program:

Code: Pascal  [Select][+][-]
  1. program precomputePalettes;
  2.  
  3. uses
  4.   Math;
  5.  
  6. var
  7.   i: integer;
  8.   p2, l2: array[0..3] of double;
  9.  
  10. begin
  11.  
  12. // Working values for linear palettes (or various sizes).
  13.  
  14.   for i := 0 to 3 do
  15.     p2[i] := i * (255 / 3.0);
  16.  
  17. // Working values for alog (exponential) palettes.
  18.  
  19.   for i := 0 to 3 do
  20.     l2[i] := 1.025 ** p2[i];
  21.  
  22. // Round alog palette to integers.
  23.  
  24.   for i := 0 to 3 do
  25.     WriteLn(Round(255.0 * (l2[i] / l2[3])))
  26. end.
  27.  

Quote
Also, looking at the list above, I would have choosen z = 1.025 or z = 1.026 as "best fit" by your explanation. As you have obviously choosen 1.001 I must have misunderstood something - care to explain in more detail?

No, that list was purely in the order I worked through to get the results: the value I chose- and am puzzled over- is 1.025 which gives the sequence (0, 4, 31, 255).

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MathMan

  • Full Member
  • ***
  • Posts: 236
Re: Recreational maths: a very funny number
« Reply #3 on: June 28, 2021, 10:32:09 am »

Quote
Also, looking at the list above, I would have choosen z = 1.025 or z = 1.026 as "best fit" by your explanation. As you have obviously choosen 1.001 I must have misunderstood something - care to explain in more detail?

No, that list was purely in the order I worked through to get the results: the value I chose- and am puzzled over- is 1.025 which gives the sequence (0, 4, 31, 255).

MarkMLl

Thanks for sharing. Must have been a x-post - I misread one statement from your original and modified my response later on.

Now that I saw your calculation I am convinced it is a coincidence that you found z= 1.025 / 1.026 as best fit. The way you are calculating requires a z for which holds z^255 >= 2*255 (to get the lower rounding to 0 correct). If you solve that for z you get 1.0247499.... (for equality). If you had i.e. a LUT maximum of 1,023 (instead of 255) the equivalent calculation would spit out z = 1.007473... As described above (in my edited post) I would have done the exponential fit slightly different.

Cheers,
MathMan

MarkMLl

  • Hero Member
  • *****
  • Posts: 3064
Re: Recreational maths: a very funny number
« Reply #4 on: June 28, 2021, 11:40:32 am »
Now that I saw your calculation I am convinced it is a coincidence that you found z= 1.025 / 1.026 as best fit. The way you are calculating requires a z for which holds z^255 >= 2*255 (to get the lower rounding to 0 correct). If you solve that for z you get 1.0247499.... (for equality). If you had i.e. a LUT maximum of 1,023 (instead of 255) the equivalent calculation would spit out z = 1.007473... As described above (in my edited post) I would have done the exponential fit slightly different.

Yes, I was wondering later what the rounding was contributing. Just dumb luck then :-)

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018