Just trying to think through this with you, I get why this method would be a bit shaky, but if you were to instead to multiply and divide, and seperate the two sorts by enough decimals that they would not interact with one another (presuming you don’t have excessively small multiples - I guess your range is really important here), would this work?:
You are right that there actually is a limit to the value precision. I got so fixated about them not being integers that I overlooked that they can be easily turned into integers.
And while your solution would work fine if there are just two variables, there are about 5 variables in my case.
I did some calculations based on my current max ranges for the those variables, and numbers combined in this method would be around 10^39. And this may even increase if the doc gets more complex.
Unfortunately, this is no longer considered a “number”, but a “big num” and coda doesn’t seem to be able to handle those:
If you check back with my document, you’ll see I also made an attempt with LeftPad, which shows some promise, but I ran into some bizarre things there based on the difference of Coda’s sorting methods, take a look at the test sort table as well to see of the strange ways items are interpreted for sorting…
Thanks to @Bobby_Ritter help, I was able to came up with a pretty good solution.
I’m converting the number values from base 10 to base 20000, which allows me to store integers up to 1.6e17, or numbers up to 1.6e13 with 0.0001 precision.
Then I’m converting those numbers into unicode symbols from 20000 to 40000 and into a string.
This way the entries can be sorted by the lexicographical order of the strings.
This solution only relies on turning the numbers into a string, which is just a bunch of mathematical operations so it doesn’t require a lot of computing power.
I also did some actual performance testing, and everything works perfectly and very fast.