You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
bdezonia
changed the title
The bridge classes are too weak
The algebras are too strict
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.
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.
The text was updated successfully, but these errors were encountered: