[Haskell-cafe] New OpenGL package: efficient way to convert datatypes?

[wren ng thornton]

Peter Verswyvelen wrote:
> I don't want to use the GL types directly since the OpenGL renderer is not
> exposes in the rest of the API.
> I was hoping that realToFrac would be a nop in case it would be identical to
> an unsafeCoerce.

This is one of the areas where the H98 spec is broken. Not only is the 
H98 realToFrac slow, it is also incorrect for Double and Float since 
those types contain transfinite values which cannot be represented in 
Rational, but which can be converted successfully when mapping from 
Double to Float and vice versa.

Once you find a suitable function definition, I suggest using the 
RealToFrac class[1]. I don't know the GL types to know what the 
definition should be, but there is a class already out there to help 
deal with this kind of problem both efficiently and correctly.


> I guess one could make rules for that, but this tickets makes me wander if
> that really works:
> http://hackage.haskell.org/trac/ghc/ticket/1434

The RealToFrac class solves Henning's performance complaint as well. 
Because of the correctness issues involved here, I strongly advocate 
*against* the use of rewrite rules for trying to optimize the H98 
definition of realToFrac. The semantics of the program where transfinite 
values are involved should not be contingent on the whims of how the 
compiler feels today. Even though IEEE-754 is fuzzy to begin with, 
altering whether things fall into or out of transfinite states is 
grossly inconsistent.



And in case you're worried about "extraneous dependencies", the logfloat 
package is portable and has negligable dependencies. Moreover it also 
provides a number of other facilities for dealing with IEEE-754 numbers 
correctly. Some examples include:

* correcting the definitions of isInfinite and isNaN used in Hugs,

* defining a class for partial orders (since neither Double nor Float is 
actually a total order due to NaN),

* and a class for types with explicit representations of transfinite 
values, which in turn allows for a modified definition of log which has 
log 0 == negativeInfinity (other Floating methods could be extended 
similarly).



[0]http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logfloat
[1]http://hackage.haskell.org/packages/archive/logfloat/0.12.0.1/doc/html/Data-Number-RealToFrac.html

-- 
Live well,
~wren