search

mikeizbicki / subhask

Type safe interface for working in subcategories of Hask
BSD 3-Clause "New" or "Revised" License
418 stars 43 forks source link

What to do about linear algebra #28

Closed tonyday567 closed 8 years ago

tonyday567 commented 8 years ago

I had a stab at #27 and attempted to upgrade to lts-5.9. The main stumbling block seems to be an API change to HMatrix: plus, minus, mult and divide are no longer exported and, instead, the intention is to use standard prelude +,-,* & /. All well and good until you hack deeper into the substrate and get errors such as:

Could not deduce (P.Num (HM.Vector (Scalar (Scalar b))))
  arising from a use of ‘P.-’

At which point I estimate that any personal attempt to fix this will probably do more harm than good, without hassling Mike.

I then turned to the musing in #18 and looked at replacing HMatrix with bed-and-breakfast. Again, all well and good until you reach the type hierarchy and have to decide on things like what the new MatrixField would look like.

So, I came to the conclusion that the best linear algebra support for subhask would be subhask! Using an external library for a matrix representation seems to increase complexity and fragility quite a bit and potentially exposes the library to changes in the underlying memory representation.

A lot of work maybe, but the payoff might be worth it. A tight and stable API across vectors and matrices and a possibility to isolate physical representation choice (aka subhask backends).

Tony

mikeizbicki commented 8 years ago

Thanks for looking into this :)

I'm not too sure what the advantage is of moving to a newer version of the lts.

So, I came to the conclusion that the best linear algebra support for subhask would be subhask! Using an external library for a matrix representation seems to increase complexity and fragility quite a bit and potentially exposes the library to changes in the underlying memory representation.

A lot of work maybe, but the payoff might be worth it. A tight and stable API across vectors and matrices and a possibility to isolate physical representation choice (aka subhask backends).

It would be nice to have a very simple, but slow, generic implementation using subhask types only.

tonyday567 commented 8 years ago

The main reason for moving to the current version of lts is to be able to include subhask in other projects. An example is ihaskell - I would like to be able to include subhask in an ipython notebook but it proved impossible to drop that ecosystem back to lts-3.3 (I tried).

Simple sounds good, and I'm motivated to give it a go. If you have any rough refactoring ideas would love to hear them.

mikeizbicki commented 8 years ago

Okay, that sounds like a good motivation.

With regards to this specific error:


Could not deduce (P.Num (HM.Vector (Scalar (Scalar b))))
  arising from a use of ‘P.-’

I'm guessing the problem is that you need to add Scalar (Scalar b) ~ Scalar b to the constraints. The scalar associated with any scalar value should be itself.

(As an aside, now that GHC 8 supports cyclic class hierarchies, this particular wart of subhask should go away. I'm currently doing a pretty big refactor, and this is one of the things I'm fixing.)

I'll definitely help you get through any other error messages if you post them.

On Fri, Mar 25, 2016 at 4:47 PM, Tony Day notifications@github.com wrote:

The main reason for moving to the current version of lts is to be able to include subhask in other projects. An example is ihaskell - I would like to be able to include subhask in an ipython notebook but it proved impossible to drop that ecosystem back to lts-3.3 (I tried).

Simple sounds good, and I'm motivated to give it a go. If you have any rough refactoring ideas would love to hear them.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/mikeizbicki/subhask/issues/28#issuecomment-201593586

mikeizbicki commented 8 years ago

I'm closing this since I think #30 fixed everything.