Commons Math
  1. Commons Math
  2. MATH-870

Deprecate interfaces and implementations of sparse vectors and matrices

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 4.0
    • Fix Version/s: None
    • Labels:
      None

      Description

      Recently, many problems have been found out with class
      OpenMapRealVector (see MATH-803 and MATH-821), to the point that the complete removal of this class in upcoming versions (as of 4.0) has been agreed markmail.

      Since it now becomes useless, SparseRealVector will also be removed. For the sake of consistency, SparseFieldVector will also be removed.

      Furthermore, it is expected that the same kind of bugs will occur with sparse implementations of real/field matrices, which will also be removed.

      In version 3.1, the following classes and interfaces will be deprecated

      • SparseRealVector
      • OpenMapRealVector
      • SparseFieldVector
      • SparseRealMatrix
      • OpenMapRealMatrix
      • SparseFieldMatrix

      They will be completely removed in version 4.0.

        Issue Links

          Activity

          Hide
          Sébastien Brisard added a comment -

          In r1390684, deprecated SparseRealVector and OpenMapRealVector.

          Show
          Sébastien Brisard added a comment - In r1390684 , deprecated SparseRealVector and OpenMapRealVector .
          Hide
          Sébastien Brisard added a comment -

          In r1390829, deprecated SparseFieldVector.

          Show
          Sébastien Brisard added a comment - In r1390829 , deprecated SparseFieldVector .
          Hide
          Sébastien Brisard added a comment -

          In r1390831, deprecated SparseRealMatrix and OpenMapRealMatrix.

          Show
          Sébastien Brisard added a comment - In r1390831 , deprecated SparseRealMatrix and OpenMapRealMatrix .
          Hide
          Sébastien Brisard added a comment -

          In r1390832, deprecated SparseFieldMatrix.

          Show
          Sébastien Brisard added a comment - In r1390832 , deprecated SparseFieldMatrix .
          Hide
          Sébastien Brisard added a comment -

          This improvement no longer affects version 3.1. As of version 4.0, all above mentioned classes must be removed.

          Show
          Sébastien Brisard added a comment - This improvement no longer affects version 3.1. As of version 4.0, all above mentioned classes must be removed.
          Hide
          Michael O. Church added a comment -

          Out of curiosity, is there a plan to replace these deprecated versions with a new sparse vector/matrix implementation?

          Show
          Michael O. Church added a comment - Out of curiosity, is there a plan to replace these deprecated versions with a new sparse vector/matrix implementation?
          Hide
          Gilles added a comment -

          Currently, no. But contributors are very much welcome to do so.
          And users are welcome to indicate whether they successfully use the current code, even with the identified shortcomings.
          There have been recurrent discussions on this on the "dev" ML.

          Show
          Gilles added a comment - Currently, no. But contributors are very much welcome to do so. And users are welcome to indicate whether they successfully use the current code, even with the identified shortcomings. There have been recurrent discussions on this on the "dev" ML.
          Hide
          ejoliet added a comment -

          Why should be removed??? We use it heavily and need the class as it gives what we need (handling the input of course!)
          I understand the problem of an incorrect/improper handling of NaN/Infinity conditions but can't justify to remove the classes completely? Isn't it??

          Show
          ejoliet added a comment - Why should be removed??? We use it heavily and need the class as it gives what we need (handling the input of course!) I understand the problem of an incorrect/improper handling of NaN/Infinity conditions but can't justify to remove the classes completely? Isn't it??
          Hide
          Luc Maisonobe added a comment -

          The classes have been un-deprecated as per r1569825, after a decision on the developers mailing list.

          We basically consider that we should not try to find a perfect theoretical answer here but simply do as most other linear algebra libraries do: ignore the problems of NaNs and infinities in sparse matrices and vectors. This behavior seems to be well accepted in all current libraries.

          Show
          Luc Maisonobe added a comment - The classes have been un-deprecated as per r1569825, after a decision on the developers mailing list. We basically consider that we should not try to find a perfect theoretical answer here but simply do as most other linear algebra libraries do: ignore the problems of NaNs and infinities in sparse matrices and vectors. This behavior seems to be well accepted in all current libraries.
          Hide
          Gilles added a comment -

          Strictly speaking, there hasn't been a decision (unless I missed
          answers
          to the message I posted on "dev" to that effect):
          http://markmail.org/message/4boqba7amzvt235s

          Regards,
          Gilles

          Show
          Gilles added a comment - Strictly speaking, there hasn't been a decision (unless I missed answers to the message I posted on "dev" to that effect): http://markmail.org/message/4boqba7amzvt235s Regards, Gilles
          Hide
          Luc Maisonobe added a comment -

          Considering point 1 in your message, the text you proposed has been added on the classes (not only OpenMapRealMatrix and OpenMapRealVector), but also on the interfaces and on the "Field" classes too.

          Considering point 2, I don't understand what you want us to demonstrate. Do you want us to set up a matrix multiplication with a NaN that get not propagated or something like that? What would this test bring?

          Considering point 3, I have not seen any special handling in OpenMapRealMatrix. Dis you write about the ebeDivide and ebeMultiply methods in OpenMapRealVector?

          Point 4 has been addressed.

          Show
          Luc Maisonobe added a comment - Considering point 1 in your message, the text you proposed has been added on the classes (not only OpenMapRealMatrix and OpenMapRealVector), but also on the interfaces and on the "Field" classes too. Considering point 2, I don't understand what you want us to demonstrate. Do you want us to set up a matrix multiplication with a NaN that get not propagated or something like that? What would this test bring? Considering point 3, I have not seen any special handling in OpenMapRealMatrix. Dis you write about the ebeDivide and ebeMultiply methods in OpenMapRealVector? Point 4 has been addressed.
          Hide
          Gilles added a comment -

          [...] matrix multiplication with a NaN that get not propagated or something like that? What would this test bring?

          It would keep track of known limitations; that it has been discussed and accepted.
          So that no user will open a bug report about NaNs being swallowed...

          [...] methods in OpenMapRealVector?

          Yes. Line 376.
          MATH-803 should thus be resolved differently from previously decided, as a consequence of the decision to keep the implementation as is. Maybe other similar issues initially delayed to 4.0 can be resolved now.
          The partial workarounds should be removed since they don't bring any value, knowing that nothing good can be expected once negative zero or NaN enter the picture.

          Show
          Gilles added a comment - [...] matrix multiplication with a NaN that get not propagated or something like that? What would this test bring? It would keep track of known limitations; that it has been discussed and accepted. So that no user will open a bug report about NaNs being swallowed... [...] methods in OpenMapRealVector? Yes. Line 376. MATH-803 should thus be resolved differently from previously decided, as a consequence of the decision to keep the implementation as is. Maybe other similar issues initially delayed to 4.0 can be resolved now. The partial workarounds should be removed since they don't bring any value, knowing that nothing good can be expected once negative zero or NaN enter the picture.
          Hide
          Luc Maisonobe added a comment -

          A tes has been added, and the methods and tests for ebeMultiply and ebeDivide adapted.
          I have therefore also resolved MATH-803

          Show
          Luc Maisonobe added a comment - A tes has been added, and the methods and tests for ebeMultiply and ebeDivide adapted. I have therefore also resolved MATH-803

            People

            • Assignee:
              Unassigned
              Reporter:
              Sébastien Brisard
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development