Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dimensions ops #38

Closed
o1lo01ol1o opened this issue May 4, 2018 · 8 comments
Closed

Dimensions ops #38

o1lo01ol1o opened this issue May 4, 2018 · 8 comments

Comments

@o1lo01ol1o
Copy link
Contributor

I've been working on an AD DSL based on the numhask hierarchy and array api and now that I'm filling out the numeric instances for numhask-array I'm finding that many type-level dimensions operations (transpose, tensor-product, etc) will need to be duplicated between the two packages. I propose we talk to @achirkin about making a common package of [Nat] based operations going forward.

@achirkin
Copy link

achirkin commented May 4, 2018

I am happy to help if I can :)

@o1lo01ol1o
Copy link
Contributor Author

I think the way forward would be to move the numhask-array operations to a new project

@tonyday567 What do you think if @achirkin initializes a dimensions-ops repo or similar?

@achirkin
Copy link

achirkin commented May 4, 2018

Hmm, I see this project uses singletons package a lot, so it might be costly to adapt it todimensions. Even though singletons is a great and comprehensive package, I do not use it in dimensions to minimize dependencies (especially to avoid TH). As a result, it is not compatible at all.
On the good side, I think there is no need in a separate dimensions-ops, since most of functions from the module you mentioned is in dimensions already.

@o1lo01ol1o
Copy link
Contributor Author

o1lo01ol1o commented May 4, 2018

That's easier, then, we can just convert these to native dimension operations. @achirkin Does it make sense to you to maintain a separate package of idiomatic linear-algebra operations on [Nat] and [XNat]? If not, we can just factor it to a numhask specific subrepo.

@tonyday567
Copy link
Owner

I'm keen to remove the singletons dependency from here for the same reasons - just got stuck in how to best go about this. So, yes, NumHask.Array.Constraints needs to be switched to dimensions in its entirety.

numhask-array is in this repo because the base library is undergoing a lot of dev, so it's easier to make changes across libraries. I'm finding that the subrepo thing works well, and happy to make a new one, or we can rip it out and make a new repo if that's easier for development purposes.

@achirkin
Copy link

achirkin commented May 5, 2018

Then I would suggest you to try using dimensions in place of singletons and then I will implement missing functionality based on your emerging requirements :)
@o1lo01ol1o I implement some linear algebra ops like products and other ops on multidimensional frames together with other matrix and quaternion operations useful for graphics applications in easytensor package, but that one might be not suitable for your needs. The most important part of it is dealing with sub-frames, so you may want to adapt the type signatures of SubSpace operations to your array implementations.

Note, I am working on branch crazy lately, which is a major rework of the whole project. Will merge it into master this or next week and update it on hackage.

@o1lo01ol1o
Copy link
Contributor Author

unblocks: o1lo01ol1o/diffhask#8

@tonyday567
Copy link
Owner

Closing,, see https://github.com/tonyday567/numhask-array

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants