Fixed point in ZScript

[Accensus]

Why isn't it a thing? I'm running into issues where I'm working with floats but minor rounding errors keep biting me in the ass. Fixed point numbers are exactly what would solve my issue here. Is this a missing feature or is it not possible to achieve in ZScript?

[Rachael]

Have you tried doubles instead of floats? Fixed point numbers would not do much better than that, the data for a double is 64-bit but the data for the highest integer (long) is only 32-bit. (At least, currently, anyway, until int64's are implemented)

That being said, to actually use fixed point it would have to be done by hand, like the original Doom source code did. This should give some idea how to do it: https://stackoverflow.com/questions/502 ... iplication - of course I am sure you already know this stuff can be stuffed into a function and you can use those functions as much as you need to.

I still think doubles would be a better option, though.

[Graf Zahl]

Fixed point is not supported because except for a few isolated parts in the engine they are not used anymore for anything.
Also, what kind of precision errors? When working with floats (and also with fixed point numbers) you have to always be aware that some values are not precisely representable, e.g. 0.1.

[Accensus]

Sorry, I meant doubles. I use floats and doubles interchangeably when speaking in general, but the issue I am running into is machine epsilon, basically, so using doubles (which I already do) isn't going to help me much when I add and subtract. The workaround I use right now is to truncate doubles to four digits past the decimal sign. I'll check out the link, thank you. The lingering 0.00000000001 values mess up the ceil/floor I use and make it seem like the number is bigger or lower than it actually is, which on the HUD is painfully apparent.

Edit: Upon reading the OP again, I guess "rounding" errors isn't exactly the word I should have used. That one's a completely different issue. Derp.

[Rachael]

Wish I could be more help - I found this, too https://stackoverflow.com/questions/140 ... nt-numbers

Adding and subtracting fixed point numbers is easy, you can do that without adjusting them. Multiplying and dividing them can be a bit of a hassle though, and if you want to present them in a user-palatable format you'll have to convert them to floats and divide by their decimal bit anyhow.

[Accensus]

Awesome. Very much appreciated. I only add and subtract so it should be no problem. I guess the other solution is to use large ints directly but that's kinda eh. The use case for this is that I have a battery whose charge is in the range of [0, 100]. If every shot from a weapon drained 1%, cool, could just use an int. But the same battery can be used in different weapons with different drain rates. So if I want to squeeze 200 shots out of a 100 charge battery with an int that isn't represented as a fixed point, I can't. Or rather, I *can*, but the workaround is stinky and creates more problems than it solves due to actual rounding errors.

[Rachael]

Ah, in that case, the decimal bit is just the second bit over then - so you'd internally represent the number as 200 on an int - and do all your math from there - you can safely multiply and divide whole ints (i.e. fixed / int or fixed * int) without adjustment. Obviously fixed + fixed and fixed - fixed will work as-is, and if you need to do fixed + or - non-fixed you'll have to convert it to fixed point by multiplying by the decimal bit number.

fixed * fixed or fixed / fixed is where the fuckery with fixed point comes in - but if you aren't doing that then you don't have to worry about it.

And then when it comes time to present the final battery charge to the end-user, you simply convert it to a double (double)fixed / (float representing the decimal bit) - which in your case will be 2.0. That should represent all the half-charges as .5, which if you want you can simply omit by not converting those to floats and they'll stay as ints.

[Accensus]

Works for me! Many thanks for this. I'll try it out if what I have in mind using doubles doesn't work out. I'd rather not resort to fixed point if I can avoid it, but I appreciate having the option to do so should it become necessary.

[Rachael]

You're welcome.

[Graf Zahl]

Just a quick note on this. When calculating prices, good software will do the calculation in cents, not dollars to avoid rounding issues (our software at work greatly suffers from this because it was done wrong.)

This is essentially the same. I wouldn't recommend true fixed point but instead using a minimum atomic unit of energy where only a multiple of that can be used, i.e. 1/100th or 1/1000th of one percent, but not 1/65536th, because with that you will run into the same rounding issues as with doubles, but probably much earlier, if your atomic unit is not a multiple of it.

[Accensus]

Pricing is a very good example. Duly noted. Thank you, Graf.