In response to comment #12, things are actually a bit easier.  There is a distinction between pure math and numerical computation.  And that distinction can be enormously subtle and hard to navigate.  But, round() is a function provided by Matlab and Octave seeks to be compatible with Matlab.  So, we actually have an easy way to answer the question of what "round (0.15, 1)" should return which is that it should return the value that the reference implementation Matlab returns.  In this case, that value is 0.2.  Similarly, Both Octave and Matlab rely on the C++ standard library for some reference functions such as realpow().

10 .^ -5 == 1e-5

returns false in Matlab, but true in Octave on my machine.  So, it does depend on the particular version of C++ libraries and probably compilation options as well since you report that this returned false for you.

Came across this when looking to see if a round(X,N) report had been found. Didn't realize how deep this issue was.

In any case. Just updating with the detail that since the last work on this report MATLAB also made the following tweaks to the function in 2022a:

R2022a: Control tiebreak behavior
Specify how to break ties by using the TieBreaker name-value argument. For example, round(X,TieBreaker="tozero") rounds ties towards zero.

R2022a: round returns consistent results for ties
Starting in R2022a, the round function always rounds ties away from zero to the nearest multiple of 10—N with larger magnitude by default. For example:

X = 1.015:5.015;
N = 2;
Y = round(1.015:5.015,2)
Y =
    1.0200    2.0200    3.0200    4.0200    5.0200
In previous releases, the round function sometimes returned inconsistent results for ties by default. In the previous example, for instance, the second and third elements were rounded towards zero to 2.01 and 3.01, respectively.

I would try to limit the code in the Fround function to just doing argument parsing.  Something like:

{
  int nargin = args.length ();

  if (nargin < 1 || nargin > 3)
    print_usage ();

  if (nargin == 1)
    return ovl (args(0).ceil ());

  int n = args(1).xint_value ("N must be an integer value");

  enum octave::rounding_mode = octave::round_normal;
  if (nargin == 3)
    {
      std::string mode = xstring_value ("MODE must be a string");

      // Case insensitive compare?  Abbreviations?
      if (mode == "significant")
        mode = octave::round_significant;
      else if (mode == "decimals")
        mode = octave::round_decimals;
      else
        error ("round: MODE must be either \"decimals\" or \"significant\"");
    }

  return ovl (args(0).round (n, mode);
}

This change will require the definition of a new octave::rounding_mode enum and new two-argument round functions in octave_base_value and any class that needs them.  Using template functions at that point may help avoid some duplication.

Doing it this way eliminates the explicit checks on data types, which is something I would like to avoid.

Seems like some stuff got truncated.

The function round is in mappers.cc.  I rewrote the first bit to

  if (nargin == 1)
    return ovl (args(0).round ());

which exactly preserves the functionality we have today where the round() function is a method on an octave_value object.

I then tried the following which works, but seems kind of slow because I am not doing an in-place map operation on the object x.

octave_value_list retval (1);

if (args(0).is_double_type ())
  {
    if (args(0).isreal ())
      {
        Matrix x = args(0).matrix_value ();
        x *= pow (10.0, N);
        x = x.map<double> (octave::math::round);
        x /= pow (10.0, N);
        retval(0) = octave_value (x);
verbatim-

I can work around this by writing my own static function in mappers.cc.

+verbatim+
template <typename T>
void
do_map_round (Array<T>& x)
{
  for (octave_idx_type i = 0; i < x.numel (); i++)
    x.xelem (i) = octave::math::round (x.xelem (i));
}

followed by

octave_value_list retval (1);

if (args(0).is_double_type ())
  {
    if (args(0).isreal ())
      {
        NDArray x = args(0).array_value ();
        x *= pow (10.0, N);
        do_map_round (retval);
        x /= pow (10.0, N);
        retval(0) = octave_value (x);

Of course, I will have to write at least 4 if branches (double+real, double+complex, single+real, single+complex) and maybe another two branches for (sparse+real, sparse+complex).  Is there some other, more natural way, to tackle this?

A diff for the changes so far is attached.

Documentation on Matlab's round function is available here (https://www.mathworks.com/help/matlab/ref/round.html).

They seem to implement the scheme suggested by Michael in comment #2.  For example, if you use the two-input form "round (x,n)" they require that x be a floating point class (single or double).  Similarly, they have an example of the possible confusion that can result when a floating point number looks like it should round in one direction, but doesn't because of extra precision.

format short
x = 112.05 - 110
x = 2.05
y = round (x, 1)
%% Expected value from above would be 2.1
y = 2.0
%% Check significant figures
format long
x
x = 2.049999999999997

So this wouldn't be that hard to implement.

We could alse decide whether we want to be nicer than Matlab and work with integer inputs when n != 0.  This would require converting to doubles, rounding, and then converting back to the original type.  Because of saturation, you could get some weird effects though.

round (uint8 (251), -2)
=> 255

My guess is that Matlab went this way so that they could grab users of Excel.  See the documentation for the Excel function round (https://support.office.com/en-us/article/ROUND-function-C018C5D8-40FB-4053-90B1-B3E7F61A213C).  It doesn't make it right, but they were catering to peopele who probably don't know the math behind the round function.

What trivial problems make the guys at Mathworks feel the need to complexify their API... If you only need this to solve a given problem right now, just use

Y=round(X*10^N)/10^N;

But beware that these are then floating-point numbers, that is, if you get let's say 1.3 in this way and 2.7, it is not guaranteed that their sum is equal to a corresponding expression of 4.0 (different from proper rounding, which gives you integer-valued doubles that conform to exact arithmetics as long as you do not exceed bitmax()).