[Octave-bug-tracker] [bug #31392] fix for case insensitivity of optimset options

[Olaf Till]

Follow-up Comment #5, bug #31392 (project octave):

It is fixed for the special case of my example, but here is a different
example which does not work:

octave:1> munlock ("__all_opts__")
octave:2> clear __all_opts__ # for reproducibility
octave:3> function  ret = test_options (arg)
> ret = optimset ("a_b", 1, "ab", 2, "c", 3);
> endfunction
octave:4> __all_opts__ ("test_options")
ans =

{
  [1,1] = a_b
  [1,2] = ab
  [1,3] = c
}

octave:5> optimget (struct (), "a_b")
warning: unrecognized option: a_b
ans = [](0x0)
octave:6> 

The reason is that lookup(,, "i") internally converts to uppercase (you have
mistaken this in your last comment), while __all_opts__.m maintains the names
in lowercase sort order. This doesn't matter as long the names consist only of
letters, but underscore, e.g., is in between uppercase and lowercase letters
in ASCII sort order.

If you change "tolower" to "toupper" in __all_opts__.m, it will work. But
only as long as lookup(,, "i") indeed internally converts to uppercase (and
nobody decides to change this to lowercase for some reason).

I understand that it makes sense from the point of efficiency (intended in
the future as you say) to use lookup(,, "i") with an accordingly pre-sorted
table. But if you keep the "i" option of lookup for this reason, you should
IMHO explicitly advertize it to the user as "uppercased lookup", not
"case-insensitive lookup", since the user has to know in which order the table
for lookup has to be provided.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?31392>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/