One hack for this in robotics, and I assume it would work here is to change your units through a multiplier and in effect changing the resolution. Lets say you are plotting something on a 100 pt. scale, but converting it to degrees. It could be probable that x% as an integer would equate to y.z float value in degrees X/360. However, if you took x% and multiplied it by 36, then if your input is an integer, so then should your output.
To get even more resolution out of your integers, you could multiply both pieces of the ratio. You could figure out the relationship between the degrees and pixels then multiply your input by 36 then by the ratio between pixels and degrees. We do this with encoders frequently because encoder ticks are float values, but not all encoders have the resolution we want. So, we need to change the resolution to match. Like with the encoder trick, we are not creating data that does not exist. We are just upscaling (or downscaling) it. If your input is a base 10 integer, and your output is a base 360, multiplying the input by 36 and then plotting it is not going to to put an input of 7.6666666666 (or pi for that matter) the perfect place, however, if the input was a float, it should come close. The same is true with robotics (and actually tvs, that is sort of one they convert 1080 to 4k, of course then they also add an algorithm layer to make up for lost data). You cannot make a 4 counts per revolution encoder have the accuracy of one with 4000 CPR, but you can get integers you can work with.
Having said all of this, many times rounding can be just as effective and save some work by both you and the processor. For those situations in which it matters, this could be a workaround.
I hope this makes sense and helps a bit.
P.S. I am making numbers up, so I apologize if my math is wrong. I tend to have to go through a few iterations to find the correct multiplier.
