#2099: Storable instance for Complex
----------------------------+-----------------------------------------------
Reporter: jedbrown | Owner:
Type: proposal | Status: new
Priority: normal | Milestone: Not GHC
Component: libraries/base | Version: 6.8.2
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Multiple
Os: Multiple |
----------------------------+-----------------------------------------------
Comment (by jedbrown):
Care to write a RealFloat instance for Int64?
It is true that what you describe would be sufficient for my needs, but I
don't think the general instance is too general. All this instance
prescribes is the ordering of real and imaginary components which is quite
standard. With regard to Haskell versus C types, how likely is it that
Double /= CDouble at some point? I'm curious what the best practice is
for high performance numerics libraries where marshaling arrays in and out
of each foreign call is not acceptable. This appears to mean that C types
must extend arbitrarily deeply into the Haskell world which seems to
defeat the point of having separate types. The libraries that I'm
familiar with (hmatrix and fft) assume that Double == CDouble so they are
broken if this doesn't hold.
Note: There is now 'storable-vector' on Hackage which defines this
instance. fft-0.1.1 depends on it and Alberto tells me that hmatrix will
soon.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2099#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
