<div dir="ltr"><div><div><div>Hello libraries list,<br><br></div><div>(Warning: this whole message may be a waste of time, you may wish to skip it.)<br></div><div><br></div>I'd like to inquire about the possibility of a Floating instance for Data.Fixed. (Unfortunately, not knowing of the existence of this list or the appropriate procedure, I created a trac ticket to ask about this, because that was the only forum I knew of. It's <a href="https://ghc.haskell.org/trac/ghc/ticket/10297">https://ghc.haskell.org/trac/ghc/ticket/10297</a>. Sorry.)<br><br></div>The original idea was along these lines:<br><pre class="">lift :: (HasResolution a) => (Double -> Double) -> Fixed a -> Fixed a
lift f = realToFrac . f . realToFrac

instance (HasResolution a) => Floating (Fixed a) where
  pi = realToFrac pi
  sin = lift sin
  -- etc, similar lift2 function for (**), logBase</pre>This allows the use of transcendental functions on Fixed values. Conceptually, transcendental functions on fixed point values aren't problematic, and are actually pretty widely used in certain gaming/simulation/signal processing applications.<br><br></div>I've since learned that this may not be a good idea. A commenter (Scott Turner) on the haskell-cafe mailing list astutely raised the issue that because Data.Fixed uses the arbitrary-size Integer type, it's impossible to correctly compute these functions for all possible Fixed values without an arbitrary precision implementation, simply converting through Double like this won't always work.<br><div><div><div><div><div><br></div><div>Sometimes it can be unclear where to draw the line and "stop worrying" about such issues. However, in this case I think it is a good objection, and that a better solution may be to work on advancing Data.Fixed.Binary or a similar library as a home for this functionality, where the size of the values is statically bounded. This has the advantage of also being outside the scope of the base libraries, and thus easier to modify due to the reduced impact.<br><br></div><div>Unfortunately I learned this was probably unworthy of this list's attention after having already filed the trac ticket.<br><br>Unless anyone disagrees and thinks this would be worthwhile, I will close that ticket tomorrow with a note saying where I'm redirecting the effort.<br clear="all"></div><div><div><br><br></div><div>-Doug McClean<br></div></div></div></div></div></div></div>