[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jose
Subject: Re: Unequal results when using element-wise and broadcast power operations
Date: Sat, 23 Nov 2013 13:57:12 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

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
for n=1:N
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]