[Octave-bug-tracker] [bug #38423] [k:l:m] not compatible for m = -0

[Dan Sebald]

Follow-up Comment #7, bug #38423 (project octave):

OK, after looking at the code, I've convinced myself that the same algorithm
is being used in all places (aside from the one you mentioned that you think
is cruft).  That's good.  Probably still some minor quibbles, but fine.

One last thing I'd like you to consider is the min/max results.  Why

191 double retval = 0.0;
192 if (rng_nelem > 0)

?  It is probably meaningless what the initialized return value is because
when I run octave with something like 

octave:1> min(1:-3)
ans = [](1x0)

the result is the empty set, just as with

octave:2> min([])
ans = [](0x0)

Obviously 0.0 is not the minimum displayed so somewhere else the empty set is
overriding the 0.0.  So, one could probably put a more sensible

191 double retval = NAN;
192 if (rng_nelem > 0)

and have it work just as well.

Also notice in the two results above that the size of the empty array are
slightly different.  Why is it that

octave:3> 1:-3
ans = [](1x0)

has a 1x0 as opposed to a 0x0?


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?38423>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/