Using Nested Logs with differing bases to contract a number

[moyo]

The log to the base 10 of 1000000 is the number 6. this is a much contracted number in terms of length. But the log to the base 10 of 1234567 is 6.0915146640862625...this is an even longer set of digits than the first example , despite the two original numbers both starting with the same length.

This leads to my question.

Could we take nested logs of a number, such that to a certain degree of accuracy, we reduce its length to the smallest possible. where the base of the logs are relatively small integer values. Then decode the number later on using the bases as a key.

so for 1234567 we might have [ (log(base 3) , 5) ];[ ( log (base 23) , 7 ] ; [ ( log (base 9) , 1 ]

as tuple entries in the complete represntation with two sets being (5 , 7 , 1) and the bases ( 3 , 23 , 9 ).

with this information we can contract 1234567 to 571, which is shorter than it is and much shorter than logging it to the base 10.even if we are forced to append the key , we still have a smaller representation than the log one.

Also , because of the way base 10 numbers oscillate in representation as we go through the natural numbers, could there be an optimal key in the sense that , while there may be better keys for particular numbers that are all different, could we have one master key that contracts ALL natural numbers to a size that is the relatively lowest size that will be possible for all of them.

Note this key would probably have to be a progression of some sorts to cater for variable length of numbers.

This would not for encryption purposes, since everyone will know the key. But for example in machine learning algorithms learn to generalize input that is represented in numbers. This is limited in that the numbers cannot go too high because of the storage requirements needed o represent very large numbers. The algorithms also ONLY need to detect a pattern, even if it is placed under transformation. If we can transform the representation using this system , then the ML algorithm will still learn as well as it did before while the computer will be using less , more manageable resources.

 

[jvicens]

I find this idea very interesting and worth exploring. However, I would like to point out a few things to consider.

Firstly, logarithms are mathematical operations that are used to solve equations and represent numbers in a different way. They are not meant to be used as a means of data compression or representation. While they can certainly reduce the length of a number, they do not necessarily make it easier to understand or process.

Secondly, using nested logarithms as a key for decoding a number may not be a practical approach. The number of nested logarithms required to represent a number accurately would depend on the size of the number, and as the number gets larger, the number of nested logarithms required would also increase. This would negate the purpose of using logarithms as a means of compression.

Thirdly, there is no guarantee that using a specific base for the logarithm would always result in a shorter representation. It would depend on the number being represented and the base chosen. So, finding a master key that works for all natural numbers may not be possible.

Finally, as you mentioned, this approach would not be suitable for encryption purposes as the key would be known to everyone. So, it may not have practical applications in machine learning or other areas that require data security.

In conclusion, while using nested logarithms as a means of data compression and representation is an interesting idea, it may not be a practical or efficient approach in most cases. I would suggest exploring other methods of data compression and representation that are specifically designed for those purposes.