You can easily sidestep problems with errors of calculation (which includes already parsing decimal floats into binary floats, and happens here also with addition) by keeping the error smaller than what you care about: Read in as double precision float and use double for calculation, convert back to single precision before converting to decimal floating point. The error you will do in double precision will be smaller than what you loose converting to single precision. You can use that for SVG path optimization where you will run across 0.1+0.2!=0.3 problems.
If you really want exact measurements, then you would want fractional numbers, so you can also cut lengths in e.g. three precisely.
In a case like that it should "snap-to-grid" on the last decimal place of the number that's being edited, maybe the grid should even be displayed on the screen. That grid might be rotated or skewed because of coordinate transforms, and there ought to be some way to add another digit worth of fineness if not a factor of 2 or 5.
https://www.crockford.com/dec64.html
IMHO it would be nice to see it used in larger-integer-presenting domains: with some limitations, accounting; interpreters where you want 0.1 + 0.2 == 0.3; anywhere there are measurements with units, and factor-of-ten scaling of finite digits is helpful; anywhere you want the simplicity of a single number-type and number-builder; possibly where you want to reserve some exponents for giving language keywords orthogonal number representations.
(Baudrillard would say that anybody using the word "real" is trying to bind you with illusion and like a wolf that craps on a trap to protect the pack he crapped on that word pretty bad!)