ones (1, x) != repmat (1, 1, x)

[John W. Eaton]

On 20-Jul-2009, Jaroslav Hajek wrote:

| On Mon, Jul 20, 2009 at 9:45 AM, Søren Hauberg<soren at hauberg.org> wrote:
| > man, 20 07 2009 kl. 09:39 +0200, skrev Jaroslav Hajek:
| >> currently, this is an invalid assertion - assert(X,Y) requires the
| >> internal class (typeinfo) of X and Y to match, although it's not
| >> documented. I think it really is too strict, given the various
| >> internal classes that may be considered equivalent (try
| >> assert([],zeros(0,0)), but I think any relevant patch here should be
| >> thoroughly discussed, because it will affect many existing tests.
| >
| > I agree that the current requirement of matching internal classes is too
| > strict. That being said, I do see great value in being able to test if
| > two objects are identical, including internal class. Perhaps we should
| > make such tests explicit, i.e. allow for something like
| >
| >  assert (X, Y, "compare_typeinfo")
| >
| > ?
| 
| Possibly. Of course you can also assert the typeinfo explicitly (if
| you know it's expected value), or do something like
| assert ({X, typeinfo (X)}, {Y, typeinfo (Y)})
| 
| Meanwhile, I suggest the attached patch. Any comments?

It was easy to understand that assert required an exact match in type
and value, and that this might be different from just testing with
the "==" operator.  But I can also see that this strict requirement
can make it more difficult to write some tests and can cause some
unexpected behavior given that Octave is now using some special data
types behind the scenes.

If we change the behavior of assert, then precisely what are the
exceptions?  I think they should be documented.  It looks like your
patch requires

  classes agree

  if the values are numeric, then equality requires the check for
  issparse or iscomplex to agree

Is that correct?  I assume that all the current tests pass with this
change, since the requirements are not as strict.  But what about
cases where we care about the result being a diagonal matrix, for
example?  Will we need to add extra conditions for that?  If so, then
why shouldn't we also have to add extra conditions for sparse and
complex values?  Why should those by special?

jwe