bugGNU Octave - Bugs: bug #63293, assert skips some type comparisons...

 
 

bug #63293: assert skips some type comparisons if a tolerance is specified

Submitter:  Nicholas Jankowski <nrjank>
Submitted:  Sun 30 Oct 2022 11:47:10 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Missed Error or Warning
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 31 Oct 2022 01:06:36 AM UTC, comment #5: 

looking at the calling forms for Matlab's and Octave's assert, I think Octave currently is a superset of what Matlab's does.


 -- assert (COND)
 -- assert (COND, ERRMSG)
 -- assert (COND, ERRMSG, ...)
 -- assert (COND, MSG_ID, ERRMSG, ...)
 -- assert (OBSERVED, EXPECTED)
 -- assert (OBSERVED, EXPECTED, TOL)


the matlab version uses the first four calling forms.  the last two are what we regularly use in BISTs, and are NOT supported by matlab's assert.

the matlab & 1st set of octave forms just check for COND to return true.  so


>> assert(true)

>> assert(false)
error: assert (false) failed
error: called from
    assert at line 107 column 11


OT: how ours differentiates the different forms is a bit odd. 

>> a = 2;  assert(a,"a string?")
error: ASSERT errors for:  assert (a,"a string?")

  Location  |  Observed  |  Expected  |  Reason
     .            2        a string?     Expected string, but observed number

>> a = true;  assert(a,"a string?")

>> a = false;  assert(a,"a string?")
error: a string?
error: called from
    assert at line 109 column 11



All that said, as Markus said this bug report is really just limited to the Octave unique calling form. So no need to worry about mathworks.

I realize the issue can be avoided by specifically doing an assert(issparse(a),issparse(b)) test rather than relying on setting off assert(a,b) if their sparseness is different. I thought it odd that we ran those tests, though, only if no tolerance was specified.

I didn't know if the issue had to do with the complexity of performing the subtraction and eps comparison for the different types.  (perhaps related to the need to do implicit expansion with eps and bug #63281)

Nicholas Jankowski <nrjank>
Group Member
Sun 30 Oct 2022 07:40:00 PM UTC, comment #4: 

Yes, that Matlab doc says it was added to Matlab in 2007 but Octave has had an assert function for much longer than that.

Should we care about compatibility for this function?  Is there any reasonable way to make that happen?

John W. Eaton <jwe>
Group administrator
Sun 30 Oct 2022 07:25:40 PM UTC, comment #3: 

Matlab's `assert` is different from Octave's implementation:
https://www.mathworks.com/help/matlab/ref/assert.html

I don't think this was for compatibility reasons.

Markus Mützel <mmuetzel>
Group administrator
Sun 30 Oct 2022 03:40:58 PM UTC, comment #2: 

Can you check whether this is Matlab compatible?  I think that may have been the reason this was done.

Rik <rik5>
Group administrator
Sun 30 Oct 2022 11:54:31 AM UTC, comment #1: 

looking at this more closely, it seems that only the assert codepath without tol performs the sparseness check (around line 247), just after a comment: ## Without explicit tolerance, be more strict."
other conditions get ignored as well:


>> assert([1 2 3],complex([1 2 3]))
error: ASSERT errors for:  assert ([1, 2, 3],complex ([1, 2, 3]))

  Location  |  Observed  |  Expected  |  Reason
     ()           O            E         real != complex

>> assert([1 2 3],complex([1 2 3]),eps)



>> assert([1 2 3],single([1 2 3]))
error: ASSERT errors for:  assert ([1, 2, 3],single ([1, 2, 3]))

  Location  |  Observed  |  Expected  |  Reason
     ()           O            E         Class double != single
>> assert([1 2 3],single([1 2 3]),eps)



>> assert([1 0 1],logical([1 0 1]))
error: ASSERT errors for:  assert ([1, 0, 1],logical ([1, 0, 1]))

  Location  |  Observed  |  Expected  |  Reason
     ()           O            E         Class double != logical
>> assert([1 0 1],logical([1 0 1]),eps)


so, this is by design? is it really problematic to have these cases do type checking when a numerical tolerance is given?

Nicholas Jankowski <nrjank>
Group Member
Sun 30 Oct 2022 11:47:10 AM UTC, original submission:  

see below:


>> assert([1 2 3],[1 2 3])

>> assert([1 2 3],[1 2 3],eps)

>> assert(sparse([1 2 3]),[1 2 3])
error: ASSERT errors for:  assert (sparse ([1, 2, 3]),[1, 2, 3])

  Location  |  Observed  |  Expected  |  Reason
     ()           O            E         sparse != non-sparse

>> assert([1 2 3],sparse([1 2 3]))
error: ASSERT errors for:  assert ([1, 2, 3],sparse ([1, 2, 3]))

  Location  |  Observed  |  Expected  |  Reason
     ()           O            E         non-sparse != sparse

>> assert(sparse([1 2 3]),sparse([1 2 3]))

>> assert(sparse([1 2 3]),[1 2 3],eps)

>> assert([1 2 3],sparse([1 2 3]),eps)


I would expect the last two tests to fail as well.

Nicholas Jankowski <nrjank>
Group Member

 

(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 mmuetzel (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by nrjank (Submitted the item)
  •  

    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 group members can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-30 nrjank Summaryassert skips sparseness comparison if a tolerance is specified assert skips some type comparisons if a tolerance is specified

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code