Re: [OctDev] [CHANGESET] Re: Genetic algorithms in Octave

[John W. Eaton]

On 17-Mar-2008, David Bateman wrote:

| > What about the attached. Is this is accepted in to the octave-core could
| > you adapt your code to use num2hex and hex2num instead? We should then
| > think about getting the code on to octave-forge.
| 
| Here is another version that adds a couple of tests.

Thanks, I applied this patch.

| +                   num <<= 4;
| +                   if (ch >= 'a')
| +                     num += static_cast<uint64_t> (ch - 'a' + 10);
| +                   else if (ch >= 'A')
| +                     num += static_cast<uint64_t> (ch - 'A' + 10);
| +                   else
| +                     num += static_cast<uint64_t> (ch - '0');

This works for ASCII but would fail for EBCDIC (at least the version
shown here: http://en.wikipedia.org/wiki/EBCDIC) since 'A' has a
character code greater than 'a'.  I realize that this is probably does
not matter for any system that Octave currently runs on, but is there
another good way to do this that does not rely on ASCII ordering other
than

  switch (ch)
    {
    case 'f': case 'F':
      num += 15;
      break;

    case 'e': case 'E':
      num += 14;
      break;

    [...]

    case '0':
      break;

    default:
      error ("hex2num: invalid character found in string");
      break;
    }

?  I'm not quite paranoid enough to change this.  I'm more curious to
know if anyone knows of another (efficient) trick that avoids the
possiblity of trouble due to a strange character encoding.

| +               unsigned char ch = 
| +                 static_cast<char> (num >> ((15 - j) * 4) & 0xF);
| +               if (ch >= 10)
| +                 ch += 'a' - 10;
| +               else
| +                 ch += '0';

I guess this would work as long as 0-9 and a-f are sequential in the
character set.  Even EBCDIC (all versions?) had that, though the full
A-Z and a-z were not sequential.

jwe