octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem with sum (...)


From: Ben Abbott
Subject: Re: problem with sum (...)
Date: Mon, 5 Nov 2007 06:44:00 -0500


On Nov 5, 2007, at 4:18 AM, Søren Hauberg wrote:

Ben Abbott skrev:
On Nov 4, 2007, at 8:50 PM, Ben Abbott wrote:
On Nov 4, 2007, at 1:00 PM, Søren Hauberg wrote:

Ben Abbott skrev:
In any event, you've done quite a bit more work on this than I. I had added some additional tests to my version that produced failures in the original. They pass in yours.
Are these tests part of the current set of tests? If not, then please send them so they can be part of the test suite.

I've managed to break your efforts :-(

The problem is with these lines ...

      a = cellstr(num2str(a))
      S = cellstr(num2str(S))

The support for "rows" only works in the event that num2str() returns the same number of characters for each member of 'a' and 'S'

Søren,
Not a pretty solution, but this code below corrects the error. I'll defer to you on whether it should be included or if more work is needed.
----------------------------
  ## We currently handle the 'rows' argument in a fairly ugly way.
## The numbers are converted to strings and then to a cell array of strings. ## We need this dirty hack because we can only compare cell arrays when
  ## they contain strings (using 'strcmp').
  if (nargin == 3)
if (strcmp (rows_opt, "rows") && ismatrix (a) && ismatrix (S) && columns (a) == columns (S))
#      a = cellstr(num2str(a))
#      S = cellstr(num2str(S))
      rS = rows (S);
      ra = rows (a);
      index = zeros (ra,1);
      for r = 1:ra
        tmp = ones (rS,1) * a(r,:);
        f = find (all (tmp' == S'), 1);
        if ! isempty (f)
          index(r) = f;
        end
      end
      c = logical (index);
      return
    else
error ("ismember: with 'rows' both sets must be matrices with an equal number of columns");
    endif
  endif
----------------------------
Thoughts?
Well, it seems as if I just keep on embarrassing myself :-)
The solution I suggested just doesn't work. It should work for integers but not floating point numbers as they can't be represented by strings without loss of accuracy which we can't accept. So the 'rows' part of my patch is just broken. Is there a way to convert a number to a string (doesn't have to be human readable) without any loss of precision? I C/C++ you can cast a 'double' into 8 'char's. Is something like that possible in Octave? Well, this just show that my evil-and-dirty hack indeed was evil and dirty :-)

Søren

P.S. If we disregard the handling of 'rows' does my patch seem to work as it should?

Yes, with the exception of the rows, I found no problems.

Regarding casting double into 8 chars, there was a time when characters were *hacked* into Matlab and were still stored as double. Very inefficient, but this would make your suggesting reasonably possible ... assuming Octave did the same. Its been years since I've looked into this *feature* so I don't know who character data is presently stored in either.

Perhaps someone with more up to date knowledge will propose a more elegant/proper solution.

In any event, I'll be working on more test scripts in an attempt to be sure all features are tested.

What else needs to be done before the new version of ismember is ready to be submitted to cvs?

Ben




reply via email to

[Prev in Thread] Current Thread [Next in Thread]