Floating and Data.Fixed

[davean]

The option you seem to be left unsaid is implementing them correctly.

A lot of the reason for Data.Fixed is you actually require the accuracy
they claim. But these functions aren't magic, they can be calculated to a
given accuracy from their power series approximations, among several other
good methods which are easy to implement and several more methods which are
faster. It would seem, if one were using Data.Fixed, that is what they
should want.

It sounds like you might just want more accurate approximations, like
http://hackage.haskell.org/package/compensated would offer and not actually
fixed point. If that isn't more what you're looking for, I'd be interested
in what your use case is for inaccurate fixed point computations was. (Not
to imply its bad, I can think of a few common scenarios where fairly
inaccurate intermediary results lead to extremely accurate results in the
end)

-davean

On Tue, Apr 14, 2015 at 8:43 PM, Douglas McClean <douglas.mcclean at gmail.com>
wrote:

> Hello libraries list,
>
> (Warning: this whole message may be a waste of time, you may wish to skip
> it.)
>
> 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
> https://ghc.haskell.org/trac/ghc/ticket/10297. Sorry.)
>
> The original idea was along these lines:
>
> 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
>
> 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.
>
> 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.
>
> 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.
>
> Unfortunately I learned this was probably unworthy of this list's
> attention after having already filed the trac ticket.
>
> 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.
>
>
> -Doug McClean
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150414/abb369b5/attachment.html>