BigNum V2 calculation ofset

I have been working on an incremental game and decided to use the BigNum V2 scirpt but an issue happen. For some reason first calculation is done perfectly but afterwards numbers instead of being 2e20 for example are 1.99999999999e20. Anyone know what the issue is?

1 Like

Floating point numbers has been literally the most innacurate thing in programming (IEEE754)
I have no idea how the hell it came into somebody’s head to use them for that.

You can just allocate multiple numbers in array for that

{
1; -- 0-999
1; -- 0k-999k
1; -- 0M-999M
1; -- 0B-999B;
--...
}

--So basically value will always be from 0 to 999 in each sector
Visualizing that may be problematic tho.
1 Like

i mean, i just made it save like that as in incremental game is isnt a big issue and when displaying it i just round it up, not a big deal but i was curious why

1 Like

If you want to store big numbers then using floating points is the worst thing you could think of to implement that.
Arrays is probably the oldest and the most robust way to do that.

1 Like

Does it matter? Just round it up when you need to show it visually, else if you just need it for calculations keep it as it is. Since your game is an incremental game it means that you don’t need exact precision down to the last digit anyway(since a very small difference wont change anything when numbers are this large). The only scenario where precision matters is an information scenario, where you actually need many specific bytes to store information. Encryption is such a case. But for things such as simulators, incrementals or physics games, it doesn’t matter.

Basically you only need to handle the visuals for when you want to show the numbers on UIs

1 Like

its not a good way since i tried testing now and started from 0 and went +5 every few seconds, i ended up getting ofset of like 10 after 100 ticks, it keeps just completly removing stuff, i tried rounding but it doesnt help since numbers are just being lost

Relativity is what matters in simulators. If for example the numbers grow by the thousands, if the calculations are off by lets say 20, it doesn’t matter, because it contributes almost nothing to the overall change.

I know i dont bother for higher numbers, but now that on start, you earn 5 per collect it means that if you get 1 taken of it every few collections it ramps up alot, i dont mind tbh that much but it seems unfair?

If the number is that small and you see precision errors the error is somewhere else.

My initial reply focused on you comparing 2e20 with 1.99999999999e20 by pointing out the fact those numbers are basically the same when numbers are that large.

I mean i dont understand why before it was so little but now it just substracts whole number of it, i can start with 1k on start sure but its just weird to take that path. Id rather keep it this way and let deal with it since after all, its just a start but then issue is if i make a limited resource it will be a huge issue.

just wanted to say thanks for help, but i found a way to fix this, i will make you on start earn for example 5m instead of 5, and in displays i will make it always display 1M times less so players wont know anythings wrong while in reallity its just a bigger num

the same issue appears, sometimes 1/100th of the final value vanishes

it all works now someone helped me on discord, i just switched up to use eternitynum as it is way more precise.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.