Compiling with hmatrix (>= 0.17)

[kkats]

I was trying to update my work environment to a newer one (stack lts-6.10), when I noticed that hnetcdf-0.3 is unavailable on stack snapshots. I attempted a fix, which is quick and dirty.

The main problem seems to be; to work with hmatrix, CShort, CFloat, and CDouble need to be in Element class, which is now hidden.

My workaround for CFloat and CDouble is messy but works. I have no solution for CShort and naively assumed that CShort and CInt are the same thing! I think the way forward includes

• Request hmatrx to include CFloat etc. in the Element class.
• Drop support for hmatrix
• Totally different implementation in hnetcdf?

Fortunately (?), I do not use hmatrix interface with NetCDF, but I really need hnetcdf so if there is something I could contribute, let me know. Thanks for creating this package.

[ian-ross]

Thanks for the information! At the moment, I don't have any time to work on hnetcdf. I'm happy to add you as a collaborator on the repo if you want to be able to make updates to it. Just let me know.

[kkats]

OK. I'll be busy for next a couple of weeks, but after that let me try to update hnetcdf.

[guaraqe]

CFloat is just a newtype around Float, did you try to use GeneralizedNewtypeDeriving and StandaloneDeriving?

[guaraqe]

For information, the following code snippet works:

{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE StandaloneDeriving #-}

module Test

import Foreign.C.Types
import Numeric.LinearAlgebra

deriving instance Element CFloat

test_matrix :: Matrix CFloat
test_matrix = fromLists [[0,1],[2,3]]

[kkats]

Thank you for the info and sorry for this overdue reply. We still have the problem; once

deriving instance Container Vector CFloat

is added in the above snippet below the deriving instance Element CFloat line (with MultiParamTypeClasses extension), it does not compile

test-deriving.hs:11:1: error:
    • Could not deduce (Integral Float)
        arising from a use of ‘hmatrix-0.17.0.2:Internal.Numeric.cmod'’
      from the context: Integral CFloat
        bound by the type signature for:
                   cmod' :: Integral CFloat =>
                            CFloat -> Vector CFloat -> Vector CFloat
        at test-deriving.hs:11:1-41
    • In the first argument of ‘ghc-prim-0.5.0.0:GHC.Prim.coerce’, namely
        ‘hmatrix-0.17.0.2:Internal.Numeric.cmod' ::
           Float -> Vector Float -> Vector Float’
      In the expression:
          ghc-prim-0.5.0.0:GHC.Prim.coerce
            (hmatrix-0.17.0.2:Internal.Numeric.cmod' ::
               Float -> Vector Float -> Vector Float) ::
            CFloat -> Vector CFloat -> Vector CFloat
      In an equation for ‘cmod'’:
          cmod'
            = ghc-prim-0.5.0.0:GHC.Prim.coerce
                (hmatrix-0.17.0.2:Internal.Numeric.cmod' ::
                   Float -> Vector Float -> Vector Float) ::
                CFloat -> Vector CFloat -> Vector CFloat
      When typechecking the code for ‘hmatrix-0.17.0.2:Internal.Numeric.cmod'’
        in a derived instance for ‘Container Vector CFloat’:
        To see the code I am typechecking, use -ddump-deriv

In hmatrix-0.17.0.2:Internal.Numeric.hs, cmod is undefined. Any idea?

[guaraqe]

This is extremely weird. I just tested the following, and it compiles (strange, but ok...):

class Something a where
  something :: (Integral a) => a

instance Something Float where
  something = undefined

and as soon as I add:

deriving instance Something CFloat

it stops working with the same error. I think that when GHC makes the substitution for cmod', it does not replaces the instance literally, but by using its overloaded name. And since it does not know that it is undefined, it tries to resolve constraints and crashes. This is a strange design choice from hmatrix...

I see no solution besides asking hmatrix to change this, adding a flag for exposing internals maybe or dropping support... Or changing all the types in hnetcdf.

[ian-ross]

Sorry I've not been paying any attention to hnetcdf lately. I've just been looking at this issue, and it looks as though the only option is to drop hmatrix support for the moment. I'm not particularly happy about that (using hmatrix to manipulate data from NetCDF files was my main motivation for writing hnetcdf in the first place), but since the Element type class is now hidden within hmatrix, there's not much that can be done about making the hmatrix container types instances of NcStore. Unless you have any objections or better ideas, I'll make a release of hnetcdf without hmatrix support so that I can "stackify" things and get hnetcdf added to Stackage.

[kkats]

I agree. As I said in another thread, hmatrix-repa can be used to turn Repa output to hmatrix. I like the idea of "stackify"-ing hnetcdf.