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

The algebras are too strict #31

Open
bdezonia opened this issue Jun 2, 2020 · 1 comment
Open

The algebras are too strict #31

bdezonia opened this issue Jun 2, 2020 · 1 comment

Comments

@bdezonia
Copy link
Owner

bdezonia commented Jun 2, 2020

The algebras of the various types are very strongly typed. The G.DBL algebra deals with specific float implementations. The bridge classes are less strict. They implement MatrixMember. However they can't be passed to these strict algebras as arguments to methods. Maybe we need to relax the constraints on the algebras. On top of which we might also move to a SparseMatrix type that as it stands now could not be passed to an algebra that works on FloatMatrix elements only. One reason to do this is to allow a matrix multiply to check if it has sparse arguments and if so do an optimized multiply. Investigate how hard it is to relax type constraints in the algebras. If we could then we would be open to supporting specialized implementations. This seems like a somewhat crucial need.

@bdezonia bdezonia changed the title The bridge classes are too weak The algebras are too strict Jun 2, 2020
@bdezonia
Copy link
Owner Author

bdezonia commented Jun 2, 2020

Some quick investigation with float16matrix and complexfloat16matrix showed that good progress is not hard. Making strict Float64MatrixMember params into MatrixMember is half the battle. Needed to move a few things around in the algebra hierarchy. Some of the set()/get() matrix methods break because of loss of variable visibility. A couple issues with casting in the equals(obj) method. One trick: sparse matrices would somehow need to support or bypass RawData. We'll need to investigate further but I think all of this is eminently doable.

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

1 participant