bugGNU Octave - Bugs: bug #37535, Numeric functions don't check for...

 
 

bug #37535: Numeric functions don't check for string inputs

Submitted by:  None
Submitted on:  Wed 10 Oct 2012 01:30:38 PM UTC  
 
Category: InterpreterSeverity: 2 - Minor
Priority: 3 - LowItem Group: None
Status: FixedAssigned to: None
Originator Name: sawattsOriginator Email: -unavailable-
Open/Closed: ClosedRelease: 3.6.2
Operating System: Microsoft Windows

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)

Mon 15 Oct 2012 03:52:22 AM UTC, comment #11:

I changed the expected value in the strplit test suite so that all tests pass again. I'm closing this report.

Rik <rik5>
Project Administrator
Thu 11 Oct 2012 08:19:17 PM UTC, comment #10:

There's one new test failure with 'make check' in strsplit. Try just 'test strsplit' to find it. It seems that splitting with a null string used to return an empty matrix ([]) and now returns an empty string (""). Frankly, this behavior makes more sense so it is probably the expected value in the test suite that should be changed.

Rik <rik5>
Project Administrator
Thu 11 Oct 2012 05:33:46 PM UTC, comment #9:

I'm not sure my suggestion is the best fix.

How about the following change instead? It will at least fix the problem for the numeric mapper functions.

http://hg.savannah.gnu.org/hgweb/octave/rev/814c4b0d5c49

Is that good enough? OK to close this report?

John W. Eaton <jwe>
Project Administrator
Wed 10 Oct 2012 10:05:06 PM UTC, comment #8:

John,

This seems definitely better than the current behavior.
I think str-to-num warning on is warning enough. But
no strong preference.

Good!

Someday, the work of going through mappers.cc and the
others may be somewhat more informative...

Michael Godfrey <godfrey>
Project Member
Wed 10 Oct 2012 09:47:38 PM UTC, comment #7:

Should we just set the default for the Octave:str-to-num warning to be on (or error?) unless using --traditional?

John W. Eaton <jwe>
Project Administrator
Wed 10 Oct 2012 06:50:10 PM UTC, comment #6:

Matlab really does!

I agree that it is minor, but should be done
independently of Matlab behaviour. About
how many functions needing this outside
mappers.cc are there?

Michael Godfrey <godfrey>
Project Member
Wed 10 Oct 2012 06:16:53 PM UTC, comment #5:

If Matlab really behaves this way, it's going to take a huge effort to make Octave error out for all of the numeric functions erroring out on string inputs. It's not just "cos 1", but "exp 1" and "nextpow2 1" and "abs 1" and "sign -1" and so on. A lot of these can be caught as mappers, but the rest of them would have to be checked individually.

Since this doesn't affect working Matlab code, I'm reducing the priority.

Jordi GutiƩrrez Hermoso <jordigh>
Project Administrator
Wed 10 Oct 2012 05:08:44 PM UTC, comment #4:

I would view the current behaviour as undesirable and error prone.

Given three statements:

>> cos (1)
>> cos 1
>> cos "1"


Neither gives an error, but the middle statement in ambiguous - either parenthesis or quotes could have been missed.

The reason for closing this bug has been shown to be incorrect, therefore it should be reopened.

Simon A Watts <sawatts>
Wed 10 Oct 2012 04:09:32 PM UTC, comment #3:

Not true. Matlab says:

>> cos 1

??? Undefined function or method 'cos' for input arguments of type 'char'.

>> cos(1)


ans =

0.5403

>> cos('Hello')

??? Undefined function or method 'cos' for input arguments of type 'char'.

>> version


ans =

7.9.0.529 (R2009b)

>>


=============================
Regardless of Matlab, I think that it would be
more "user friendly" to do an argument check.

Michael Godfrey <godfrey>
Project Member
Wed 10 Oct 2012 03:44:13 PM UTC, comment #2:

Not a bug. This is how Matlab also behaves.

Jordi GutiƩrrez Hermoso <jordigh>
Project Administrator
Wed 10 Oct 2012 01:47:25 PM UTC, comment #1:

This behaviour is true of all the trig functions
in mappers.cc. There is no argument type checking.
cos("1")
and
cos("Hello")
also do not generate errrors.

Michael Godfrey <godfrey>
Project Member
Wed 10 Oct 2012 01:30:38 PM UTC, original submission:

This is odd behaviour which I would not expect from the interpretor:

Missing parentheses after (buildin) function call are not an error:

1> cos (1)
ans = 0.54030
2> cos 1
ans = 0.30059

In line 2, the return is the cosine of the ASCII value of '1', or 49.

I would have expected line 2 to generate an error at least.

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

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 jwe (Posted a comment)
  • -unavailable- added by sawatts (Posted a comment)
  • -unavailable- added by jordigh (Posted a comment)
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by None (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 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 15 Oct 2012 03:52:22 AM UTCrik5StatusConfirmed=>Fixed
      Open/ClosedOpen=>Closed
    Wed 10 Oct 2012 06:16:53 PM UTCjordighSeverity3 - Normal=>2 - Minor
      Priority5 - Normal=>3 - Low
      Summary"cos 1" vs "cos (1)" =>Numeric functions don't check for string inputs
    Wed 10 Oct 2012 06:11:28 PM UTCjordighStatusInvalid=>Confirmed
      Open/ClosedClosed=>Open
    Wed 10 Oct 2012 03:44:13 PM UTCjordighStatusNone=>Invalid
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1