bugGNU Octave - Bugs: bug #51779, bsxfun unit tests occasionally...


bug #51779: bsxfun unit tests occasionally fail on certain random inputs

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Fri 18 Aug 2017 12:37:01 AM UTC  
Category: Test SuiteSeverity: 4 - Important
Priority: 5 - NormalItem Group: Regression
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

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

Rik <rik5>
Project Administrator
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:

Nicholas Jankowski <nrjank>
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)))?

Mike Miller <mtmiller>
Project Administrator
Fri 18 Aug 2017 04:03:25 AM UTC, comment #4:

This regression was introduced with


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.

Mike Miller <mtmiller>
Project Administrator
Fri 18 Aug 2017 01:51:49 AM UTC, comment #3:

Oops. Operator problem. I guess one needs to reset randn each time.


Dmitri A. Sergatskov <dasergatskov>
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 A. Sergatskov <dasergatskov>
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.

Mike Miller <mtmiller>
Project Administrator
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.

Mike Miller <mtmiller>
Project Administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #41564:  random_states added by mtmiller (15KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by nrjank (Posted a comment)
  • -unavailable- added by mtmiller
  • -unavailable- added by dasergatskov (Posted a comment)
  • -unavailable- added by mtmiller (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 18 Aug 2017 04:03:25 AM UTCmtmillerStatusNone=>Confirmed
      Carbon-Copy-=>Added rik5
    Fri 18 Aug 2017 12:39:27 AM UTCmtmillerSeverity3 - Normal=>4 - Important
      Item GroupInaccurate Result=>Regression
    Fri 18 Aug 2017 12:37:01 AM UTCmtmillerAttached File-=>Added random_states, #41564

    Back to the top

    Powered by Savane 3.1-cleanup1