Thu 24 Aug 2017 04:00:12 PM UTC, comment #7:
Sorry to be late to this. In reference to comment #5, I believe we have historically demoted rather than promoted to double. For example,
The alternative would be to promote to double and then cast back to single at the end.
But I don't think we do that.
So if possible, this is the desired computation
|
Thu 24 Aug 2017 02:24:56 PM UTC, comment #6:
maybe not news to anyone, but was curious about matlab compatibility. turns out it's a non issue. Matlab errors out on almost all of these:
|
Fri 18 Aug 2017 05:04:22 AM UTC, comment #5:
I made the following change to fix this
Basically, pow(float,octave_int<T>) used to call pow(double,double), and was unintentionally changed at this point to call powf(float,float).
It's not immediately obvious which one of these is "correct", but it is empirically obvious that the new code calling powf is giving a different answer than what Octave normally gives for the scalar operation of single(x)^int32(y).
I think this may have been discussed on another report, but should a mixed operation like single(x)^int32(y) be the same as int32(double(x)^double(int32(y)))? Or should it be the same as int32(single(x)^single(int32(y)))?
|
Fri 18 Aug 2017 04:03:25 AM UTC, comment #4:
This regression was introduced with
https://hg.savannah.gnu.org/hgweb/octave/rev/b488e958d024
Use modf, pow from C++ std library. These functions are guaranteed to be part of C++11 standard library.
Something about this has changed the following two operations, compared to Octave 4.2.1:
This has something to do with the mixed types and the broadcasting expansion. This does not affect the normal elementwise exponentiation when both operands have the same dimension. And calling bsxfun explicitly is also not affected.
This is possibly because the change is now calling std::pow, which is a function template, so different underlying C functions might be called. Before this change, these few spots in the code were calling the C function pow, which always takes its arguments as doubles.
I may try forcing some of these std::pow calls to operate on doubles to see if anything has an effect by trial and error.
Adding Rik in cc.
|
Fri 18 Aug 2017 01:51:49 AM UTC, comment #3:
Oops. Operator problem. I guess one needs to reset randn each time.
Dmitri.
--
|
Fri 18 Aug 2017 01:47:58 AM UTC, comment #2:
I see the problem in reduced example, but not in the one with load randon_state (PASSES 76 out of 76 tests).
Dmitri.
--
|
Fri 18 Aug 2017 12:39:27 AM UTC, comment #1:
Just tested this in Octave 4.2.1 and I see that the same expression does not fail, so recategorizing as a regression on the default branch.
|
Fri 18 Aug 2017 12:37:01 AM UTC, original submission:
I see intermittent test failures in the test scripts in libinterp/corefcn/bsxfun.cc. At least one case that I have captured and reproduced is due to a call to power with a particularly bad set of arguments.
A much reduced minimal example that shows the problem operation first:
This is a reduced and simplified version of the following test case that is actually pulled from the test scripts in bsxfun.cc:
And I pulled this one data set from an actual test run, as can be shown by loading the attached file and running the test suite as follows:
I can easily pick some arbitrary random state to hardcode into the test scripts to ensure that this doesn't happen, but maybe someone wants to look at this further to see if something actually does need fixing, or whether the random vectors can be constrained better.
|