<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 11, 2015 at 3:40 PM, Peter Hutterer <span dir="ltr"><<a href="mailto:peter.hutterer@who-t.net" target="_blank">peter.hutterer@who-t.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Jun 11, 2015 at 02:37:38PM -0700, Bill Spitzak wrote:<br>
> Do you actually need 64 bits or are you just trying to get more than 8 bits<br>
> of fraction?<br>
><br>
> If instead other fixed types were provided, such as 1.30 or 7.24, etc could<br>
> that be used? This could be covered by the existing fixed type by just<br>
> defining the argument as being the desired value multiplied by some power<br>
> of 2.<br>
<br>
any 32-bit fixed point will hit the limits in one way our another, so you're<br>
just messing up the space. it's easier to have two data types where one will<br>
definitely be enough.<br></blockquote><div><br></div><div>Well so will 32.32 fixed-point, it is pretty easy to get out of that range as well. The question is if the api actually needs more than 32 bits of *precision*.<br><br></div><div>I think avoiding IEEE floating point in the api is a mistake actually. You are basically adding more types instead of the exponent. And you are going to have to be able to transmit infinity and NaN lossless eventually and will end up inventing your own floating point format.<br><br></div></div></div></div>