bugGNU Octave - Bugs: bug #54183, Cache NaN/Inf status of matrix for...

 
 

bug #54183: Cache NaN/Inf status of matrix for performance?

Submitter:  Rik <rik5>
Submitted:  Mon 25 Jun 2018 06:11:33 PM UTC
 
Category:  Performance Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

Mon 25 Jun 2018 07:16:03 PM UTC, comment #1: 

Could we combine both?

In some cases, I think we already check the matrix type for things like symmetry.  So if we are doing that anyway, we could also check for Inf or NaN values.

In other cases, we might only want to check the matrix type if it is already set (rather than computing anything prior to a BLAS operation) and then try the BLAS operation.  If it fails, then try to determine why, or possibly do the more expensive checks for matrix type and NaN or Inf elements.  At that point, we can set the return value appropriately and also modify the matrix type info of the original matrix.

I should also note that one thing I don't like about the current matrix type calculation and caching is that it relies on mutable data and that can cause unpredictable behavior if the compiler optimizes based on assumptions of constness.  So we may need to be careful about how these checks are handled.

John W. Eaton <jwe>
Project Administrator
Mon 25 Jun 2018 06:11:33 PM UTC, original submission:  

Low-level Octave code in liboctave often calculates the 1-norm of a matrix before calling BLAS/LAPACK routines.  This was originally done to prevent segfaults and other unhandled exceptions in the external library code.

However, this is obviously a lot of work, even for the 1-norm.  Now that bug #39000 has been resolved for Windows (XERBLA handler override for external BLAS libraries) there is no longer a pressing need to inspect the matrix so thoroughly before handing it over to the library.

Architecturally, it would be useful to consider the locations in liboctave where we calculate the 1-norm and determine if they could be removed, and instead catch any error from the external library and modify the return value as necessary.  In pseudocode

[retval, info] = BLAS_fcn (A, ...);
if (info)
  if (any (isnan (A(:))))
    retval = NaN (size (A));
  elseif (any (isinf (A(:))))
    retval = Inf (size (A));  # this wouldn't get the sign right, but its close
  endif
endif

This has the advantage of only bothering to inspect the matrix if there is a problem with the calculation.

Alternatively, there is already a caching system in place for Octave matrices that records any special properties abouth them (diagonal, banded, symmetric, etc.).  This caching system could be extended so that any NaN or Inf status of a matrix was calculated only once.

The first solution is preferrable, since most of the time there is no reason to check a matrix as most will be valid.  But at least the second solution would restrict the calculation to once per matrix.

Rik <rik5>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  • -email is unavailable- added by rik5
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.

     

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-06-25 rik5 Carbon-Copy- Added jwe

    Back to the top


    Powered by Savane 3.9