|
From: | Carlo de Falco |
Subject: | stable branch release policy [was Re: Possible bug in intersect] |
Date: | Sun, 12 Apr 2009 10:06:20 +0200 |
On 11 Apr 2009, at 22:54, Carlo de Falco wrote:
On 11 Apr 2009, at 19:03, address@hidden wrote:Message: 3 Date: Sat, 11 Apr 2009 17:38:51 +0200 From: Thomas Weber <address@hidden> Subject: Re: Possible bug in intersect To: Jaroslav Hajek <address@hidden> Cc: Massimiliano Culpo <address@hidden>, address@hidden Message-ID: <address@hidden> Content-Type: text/plain; charset="us-ascii" On Sat, Apr 11, 2009 at 02:11:25PM +0200, Jaroslav Hajek wrote:On Sat, Apr 11, 2009 at 12:26 PM, Massimiliano Culpo <address@hidden> wrote:Please find attached a possible bug occurring in octave-3.0.4. The same behavior is very likely to be found also in octave-3.0.5. Massimiliano CulpoI fixed this in the development sources.Test for this bug attached. Thomas -------------- next part -------------- # HG changeset patch # User Thomas Weber <address@hidden> # Date 1239464264 -7200 # Node ID 68036841138c9ef0365ff0f188f3edfee8eb8460 # Parent 22ae6b3411a769d62f66f196473336440194404a Add test for bugfix b2459d21a207 diff --git a/scripts/set/intersect.m b/scripts/set/intersect.m --- a/scripts/set/intersect.m +++ b/scripts/set/intersect.m @@ -104,3 +104,8 @@ %! assert(ib,[3;1]); %! assert(a(ia,:),c); %! assert(b(ib,:),c); +%!test +%! a = [1 1 1 2 2 2]; +%! b = [1 2 3; 4 5 6]; +%! c = intersect(a,b); +%! assert(c, [1,2]); ------------------------------This behaviour is not compatible: --------- >> a = [1 1 1 2 2 2] a = 1 1 1 2 2 2 >> b = [1 2 3; 3 2 1] b = 1 2 3 3 2 1 >> intersect(a,b) ??? Error using ==> intersect at 51 A and B must be vectors, or 'rows' must be specified. >> intersect(a,b,'rows') ??? Error using ==> intersect at 198 A and B must have the same number of columns. >> version ans = 7.5.0.338 (R2007b) >> --------- I would suggest to change the test to --------- c = intersect(a,b(:)); assert(c, [1,2]); ---------so that it won't fail if intersect gets changed to be strictly compatible.c.
Hi,It seems this bug was introduced inbetween releases 3.0.3 and 3.0.4 by the following changeset:
hg log -r 7920 changeset: 7920:e56bb65186f6 user: Jaroslav Hajek <address@hidden> date: Wed Jun 25 22:11:07 2008 +0200 summary: improve set functions for Matlab compatibilityso the question I have is, is there a "bug-fixes only, no new features" policy for the "stable" branch?
Now, this particular bug is probably to be considered minor as compared to the one in "load -ascii" so I'm not sure whether it is worth a 3.0.6 release, but, as it is found in an m-file, maybe a warning about the bug and a link to the 3.0.3 version of the set scripts on the web page would suffice?
As an other alternative to new releases in the stable branch, to fix bugs in m-files and DLD functions maybe a "bugfix" package in Octave- Forge could be used?
Sorry if my suggestions sound stupid, I was just trying to think of a way to keep the number of bugs in the stable branch a monotone non- increasing function of the release number while requiring as little effort on developers like Jaroslav whos precious time is better spent on improving the development version.
c.
[Prev in Thread] | Current Thread | [Next in Thread] |