Home
Isn't it weird how exact and perfect integers are? Like, when someone says "my cat weighs 4kg", you don't think "that cat weights exactly 4kg, not a femptogram more or less" you think "that cat weights somewhere inbetween 3,500 and 4,500 grams".
But if someone says they have "12 eggs" they have exactly 12. They don't have 12.001, or 11.999, they have 12. This is, obvious, but also a bit unusual. The real world is chaotic, and messy. It isn't exact, and it shouldn't be. Let's make a terrible numbering system to "fix" this!
Relevant xkcd
There's a lot of ways to do this. My first thought is to make the symbols' values different, like <4> meaning 4.0023, but then I had a better idea. Oh, and by the way I'm using decimal, just to make this simpler for the audience. No point in messing with it being decimal.
But I think pure integers should be representable, so a better idea (in my opinion) is to make the value multipliers different. Base 10.0038 sounds good. So the numbers 0-9 all look the same, but to write 10, it's 9... uh, okay this math is really complicated. For simplicity sake, it's mixed radix*. Decimal after the radix point, and base 10.0038 before it. So 10DEC is 9.9962INEX!
*I only just now realized how funny this is. Using mixed radix to make something simpler. Oh also mixed radix is when different digits of a number use different bases, like how 1:00 on a clock is equivalent to 60 minutes instead of 100.
But here's the thing, this is kind of boring too. It just stacks multiples of 0.0038. To convert 24 to inexactimal, it's just 24 - (0.0038 * 2.0). The next thing I tried was using proper base 10.0038 using wolfram alpha. Wolfram alpha would sometimes accept my inputs, so now I know that 10DEC is 9.996618014299...INEX, but the problem is that every integer is represented as that integer minus one and then that exact string of digits after the radix point. It's the same for every number.
So the first method was too simple, and the second method was too predictable, hmmm...
I think I've been thinking about this all wrong. We don't want there to be a way to represent perfect integers perse (though there probably is a way too) we want all these numbers to be estimations. Like, 776 should still mean roughly 776, but just be ever so slightly off. Let's revisit the very first idea. The base is 10 but each digit has a slightly randomized value.
I think the problem with this is that it will be too deterministic, but let's try it out. I wrote a little program to make this 100 entry table. Also, I decided to keep 0 at 0. I don't know why, it just felt like too much to change it for some reason. Something about large powers of ten. Idk I'm silly.
Alright that's looking pretty good! They're fairly random, whilst being pretty much the number they say they are. It took me 2 tries, but in the end my first instinct was the best. Maybe I could've improved this by using real randomness, but I don't know how to implement that well. My one complaint, if I had to make one, is that they're too simple. 90 is 89.98, after all, it should have like 20 digits. Eh, doesn't matter that much. It should be inexact anyway.
Lastly, they're pronounced like normal decimal numbers, but with "roughly" in front. Since <10> means 10.006, it makes perfect sense to call it "roughly ten". "About", "almost", and "basically" work too.
This webpage was a little shorter than my usual ones. I hope you enjoyed it anyway, though. Maybe I'll update it in the future. I made this on 1.9996/18.006446/2024.59574, thanks for reading!
PS one half is exactly 0.499974, or roughly 0.5.