Changes in STRNCMP

When did STRNCMP change its behaviour?

Matlab 2009a:

    strncmp('asd', 'qwe', 0)   % >> 0

Matlab 2011b:

    strncmp('asd', 'qwe', 0)   % >> 1

And in general: What is an efficient way to determine the release, when a function was changed?

[EDITED] 30-Sep-2011, 06:48 UTC

Matlab 2009a:

strncmp('a', 'a', 2)   % >> 0

Matlab 2011b:

strncmp('a', 'a', 2)   % >> 1

There are good arguments for the one and the other reply. But there are no good arguments for changing the behaviour of such elementary functions. It affects about 40.000 lines of my code, which directly and indirectly depends on the replied values.

I'm trying to migrate from 2009a to 2011b and this first problem stopped the tests after 3 minutes only. And there is no really convenient way to find a description when and why STRNCMP has changed. Even the bug-report is misleading:

 STRNCMP and STRNCMPI return FALSE when comparing cell arrays and
 considering 0 characters (i.e., with the third input set to zero).

No, it does not concern only cell arrays, but CHAR vectors also.

[bym]

as a tangent: in what situation would you use strncmp('asd', 'qwe', 0)?

[Walter Roberson]

longest prefix matching?

[Jan]

@proecsm: I'm using a large software package with >300'000 lines of code (plus comments!). Such packages cannot be controlled manually anymore, such that automatic tests are needed to check the compatibility. To compare the functionality of my function STRNCMPR (compare strings from the right, FEX) I compare it with the builtin STRCMP with flipped inputs. Besides the known answers tests I use a gun-shot-programming technique to check the reaction of the function to wrong and "almost wrong" inputs. In the case of STRNCMPR this means feeding with cells of numerical arrays, multi-dimensional empty cells, cells containing NULL pointers, and N set to Inf, -Inf, NaN, [], -1, uint8(N), NULL pointer, and of course 0.

Now the unit-test fails, because STRNCMP has changed. In consequence all tools, which are using STRNCMP and my STRNCMPR are marked as invalid. "Well, I hope it will run inspite of this, 0 length comparisons are so unlikely" is not a reliable reaction, because the tool is used for clinical decision making, which urgently requires a standardized quality control.

Let me mention, that this let me react more emotionally, than I want to express in this public forum.

Answer 1

[Wayne King]

Hi Jan, This was a bug fixed in R2010b

http://www.mathworks.com/support/bugreports/629110

Hope that helps, Wayne

[Jan]

As mentioned above: This bugreport claims, that the "problem" concerns cell strings, but it appears for CHAR vectors also. In addition it would be nice, if the report contains a short hint, why this behaviour is assumed to be a *bug*. I do not think that "strncmp('a', 'b', 2)==TRUE" is more intuitive than the former behaviour.

[Andreas Goser]

Jan pointed me to this here. I will investigate.

[Andreas Goser]

Result: The change was incorporated into R2010a as a bug fix. As this was not a customer reported bug and also not assessed as a severe bug, no externally visible bug report was created. This also means, that the incompatibilty introduced was not reported in the release notes. I will get in touch with Jan about the details.

[Jan]

TMW might estimate, that the former behaviour was not a severe bug. But changing the behaviour of STRNCMP in two details causes severe bugs in my programs. Therefore I'm convinced, that changing the behaviour of fundamental function must follow these rules:

1. Avoid them, because even "not severe" changes will cause severe bugs in many user-land programs.

If not possible:

2. Document them explicitely in the release notes, help text and list of changes.

3. Document them even more.

4. Test all possible side-effects hysterically.

It seems to me, as the questionable reply of "strncmp('a', 'b', 0)" was changed for some reasons, but this introduced the behaviour "strncmp('a', 'a', 2)==TRUE" as bug, which has not been detected due to weak or missing unit-tests.

Such "actually unimportant" and in consequence undocumented changes discourage users from migrating to a new Matlab release. It is not easy to control the quality of a Matlab program when migrating without knowing the methods and results of the quality control applied to maintain Matlab itself.

[Yair Altman]

@Andreas - most of the respectable software vendors that I know are not ashamed in listing bug fixes when they release new versions, even if the bugs were discovered internally as in this case.

Jan's example is simply one case of many. When I upgrade my clients' software to a new release I depend on the release notes to give me an accurate description of all the changes, so that I could make an informed decision about what to check and possibly fix for the new release. If MathWorks chooses to hide this information from users then I cannot make informed decisions!

I am sorry to say that I am very disappointed with MathWorks for this.

MathWorks reportedly places huge efforts in backward compatibility, and changing things like this, *AND THEN NOT EVEN REPORTING THEM!*, makes a mockery of such efforts.

[Andreas Goser]

I respect and understand your viewpoint and will forward it to the right person. For now, the FAQ for Bug Reports http://www.mathworks.com/support/faq/bugreportsfaq.html mentions: "6.Why aren't all bugs shown? Why isn't the bug I reported showing up? Bugs reported in this system are those that may be of interest to customers, based on general use of our products. Bugs are updated by the development team as more information and releases become available. This includes provisions for any known workarounds or file replacements. Bug report information is available for bugs either exist in or have been fixed in Release 14 SP2 or later. Information is not available for all bugs, known or unknown, including bugs in prior releases. If you feel your bug should appear in this table, contact technical support and ask that your bug be nominated as a bug report."

Answer 2

[Kelly Kearney]

On the topic of history, I've requested this as an enhancement multiple times. When I wrote to the Mathworks to ask whether I could get a complete change history of a particular function (in my case, minor updates to datetick that hadn't made the release notes were affecting my code), I was told that the best way to check this was to look at the Revision line in the m-file itself.

Of course, this is only possible if you actually own all releases. I don't, but the Mathworks of does. Assuming they don't already have a centralized database of change histories for all functions, it seems to me it would be a relatively simple endeavor to write a simple file parser that reads out the revision line from each function in each release. Then users could get a clear idea of when each function was introduced, when others were phased out, and when both major and minor changes were made.

[Jan]

I really agree. I need a database which contain:

1. A list of the names of toolbox functions (to avoid collisions, e.g. if I share a function with another lab, which uses more toolboxes than I do).

2. The time-history of this list, such that I can if the other lab running Matlab RXYZ can use STRREAD, REGEXP('split') or TEXTSCAN.

3. A list of changes in the behaviour.

While 1. and 2. could be solved by a tiny program and the collaboration of 20 or 30 other contributors, point 3. should be created by TMW. It would be a silly idea to create an undocumented documentation.

Digging in the release notes is not efficient or complete enough to be an alternative.

Answer 3

[Walter Roberson]

I don't know when the functionality changed, but I observe that the documentation of strncmp and strncmpi were split as of 2011a. The merged 2010b page vs split 2011a page

The only "efficient" way I have found to identify changes is to request searching an older release, and then edit the URL to move between different versions. :(

I'll be looking through the beta Documentation Center

[Walter Roberson]

Darn. Beta version doesn't give any change history either, and also doesn't have that link near the top to the launchpad for searching specific releases.

[Walter Roberson]

http://www.mathworks.com/help/matlab/ref/strncmp.html

is the beta page.