Re: Unequal results when using element-wise and broadcast power operations

[Jose]

On 22/11/13 22:12, Jordi Gutiérrez Hermoso wrote:
> On Fri, 2013-11-22 at 18:33 +0200, Jose wrote:
>
> > As the subject says, have a look.
> > ----------
> > clear all
> > r=3;
> > N=100;
> > S=rand(1,N);
> > C=S.^r;
> > C2=bsxfun(@power,S,r);
> > for n=1:N
> >     C3(n)=S(n)^r;
> > endfor
> > assert(C,C2)  %fails
> > assert(C,C3)  %fails
> > assert(C2,C3) %Does not fail
> > ----------
>
> Can you please file a bug report? I have some idea of where the bug
> might be, but this seems like a very low-priority thing. I am  trying
> to spend my time on stabilising the Octave GUI on Mac OS X right now.
>
> We have other issues with exponentials, for example, how e^X and
> expm(X) follow completely different codepaths.

Bug #40683 filed, thanks for your quick response.

Regarding the priority of this issue, I would consider giving it somehow 
high priority, or at least not a low one. Let me explain why.

As you can imagine, in essence this bug makes many tests untrustful, an 
this has further implications.

- The first thing that one usually thinks when assert(A,B) fails in a 
test is that A is not exactly B because one's formulas/theoretical 
considerations and/or implementation might be wrong. After quite a while 
of hair pulling not finding the cause, one starts to consider esoteric 
possible sources of the problem, thinking at the same time that one is 
getting paranoid. And only then one starts to check things like 
different expressions that should give the same result. All this is very 
puzzling, and can turn tests into a nightmare.

- IFF one is aware of this issue, one could in principle try to take it 
into account in the test code. Finding out when this bug might affect a 
particular test can be already quite tricky and tedious. Moreover, 
different cases will in general require different handling. This will 
make the test code dirty and difficult to maintain. Even worse, in some 
cases it will be not possible to differentiate whether an incorrect 
result is due to this bug or to any other reason.

So, in short, I think that this bug has enough bad potential 
consequences related to testing as to not deserve a low priority.

Regards,
J.