bugGNU Octave - Bugs: bug #52787, chop behaves differently from...


bug #52787: chop behaves differently from documentation

Submitted by:  None
Submitted on:  Tue 02 Jan 2018 02:21:02 PM UTC  
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.2.1
Operating 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)

Thu 04 Jan 2018 08:16:24 PM UTC, comment #7:

Doubtless Matlab use to have this, but I really can't find any mention of it any more. I deprecated the function on the development branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/30bcf1723ca8). It will be removed in version 4.8 of Octave.

That's all for this bug report. Marking as fixed and closing.

Rik <rik5>
Project Administrator
Thu 04 Jan 2018 07:45:52 PM UTC, comment #6:

I'm certain that chop was in the original Fortran Matlab and in older versions of Matlab from TMW. I only added it because of that. I don't know when it was removed from Matlab. Or maybe it is still there and undocumented. I'd say we can deprecate and remove it from Octave as well.

John W. Eaton <jwe>
Project Administrator
Thu 04 Jan 2018 07:30:23 PM UTC, comment #5:

I've added jwe to the CC list for this bug. The remaining issue is with chop.m. I'm not sure if the best course of action is to modify how chop behaves, or to document the difference in behavior between 2 and 3 input arguments.

Also, this function was added by jwe back in 2010, but I don't see it used in any of the current m-files in scripts, nor is it a Matlab function. Maybe it should just be deprecated and removed.

Rik <rik5>
Project Administrator
Thu 04 Jan 2018 07:25:50 PM UTC, comment #4:

The problem with cumsum was not the input validation of the arguments, but rather the documentation itself. The cumsum function does not support an "extra" argument as there is no xcumsum() function in liboctave to call. I removed the mention of "extra" in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/59d080a90f17).

Rik <rik5>
Project Administrator
Thu 04 Jan 2018 07:04:41 PM UTC, comment #3:

@Sahil: I checked in your change for primes.m here (http://hg.savannah.gnu.org/hgweb/octave/rev/070e9b036141).

I added a longer commit message. The form of the message that Octave uses is a 1-line summary, followed by two newlines, followed by a list of the files that were modified and what exactly was done in each file.

I tweaked something in the documentation which was unrelated to this changeset, but I did add BIST tests to check the new behavior. In generaly, it is a good idea to use test-driven development and write the tests for a new feature or bug fix before the feature itself so you know whether you got it right.

Rik <rik5>
Project Administrator
Wed 03 Jan 2018 06:10:40 AM UTC, comment #2:

OP has correctly pointed out the change in "primes".

As for the "cumsum", since the documentation has that "extra" and "double" will function the same as far as double precision is concerned, I have merged the cases for extra and double.

For "chop", there were separate conditions for cases when the bases have been provided or not by the user with this note by jwe in the file :

Now since the OP has pointed the differences in the values generated by the two cases, I have removed the comment and the conditions as well.

Now it's upto the maintainers as to how they see the problems, these were just my two cents.

PS: The "primes" changeset is in the 52787_2.diff file and the other two are in 52787.diff file.

(file #42795, file #42796)

Sahil Yadav <batterylow>
Tue 02 Jan 2018 02:28:16 PM UTC, comment #1:

Ah, maybe the "primes" might be fixed as

Tue 02 Jan 2018 02:21:02 PM UTC, original submission:

"cumsum" document mentions parameter "extra",
but doesn't support it:

"chop" document says that
-- chop (X, NDIGITS, BASE)
If BASE is not specified it defaults to 10.
but behaves as

"primes" document says that
The output data class (double, single, uint32, etc.) is the same
as the input class of N.
but the output class is always "double":



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

Attach Files:

Attached Files
file #42795:  52787.diff added by batterylow (2KiB - text/x-patch - primes - 52787_2.diff , cumsum and chop - 52787.diff)
file #42796:  52787_2.diff added by batterylow (589B - text/x-patch - primes - 52787_2.diff , cumsum and chop - 52787.diff)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by batterylow (Updated the item)

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

    Only project members can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-01-04 rik5 StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2018-01-04 rik5 Carbon-Copy- => Added jwe
    2018-01-04 rik5 StatusNone => Confirmed
        SummaryArithmetic functions cumsum,chop,primes behave slight differently from document => chop behaves differently from documentation
    2018-01-03 batterylow Attached File- => Added 52787.diff, #42795
        Attached File- => Added 52787_2.diff, #42796

    Back to the top

    Powered by Savane 3.3