Closed sikuenstner closed 10 months ago
Thanks for proposing this PR!
I know I suggested this in #267, but thinking about it now, I don't think it is appropriate, for two reasons: (1) According to all the standard bodies (IUPAC, etc,), units are fundamentally case-sensitive - for example, it's 1 Hz and not 1 hz. (2) There are actual ambiguities that could be introduced by being case-insensitive: is mt
a millitesla or a megatesla? Is ev
an electron-volt or an exavolt? Is kg
a kilogram or a kilogauss?
Therefore, I suggest we don't implement case insensitivity. Rather, can you extend the otherwise
branch in the switch
statement to do a case-insensitive comparison to the supported conversions and offer the corrected version if there's a (case-insensitive) match:
You provided 'mhz-mt'. Did you mean 'MHz->mT' ?
If there's no match, an error should be issued of course..
Thanks for your comments. I agree that it makes more sense to keep the case-sensitivity. I completely rewrote the whole function to include error messages depending on the input. Instead of the switch - case structure, I use a cell array with the conversions (like a dictionary) instead. It passes the tests on my machine.
Thanks for this PR!
In issue 267 "Better names for mt2mhz and mhz2mt", Stefan suggested that
unitconvert
should be case insensitive. This is now the case by using the functionlower
to convert the input to lower case. I needed to adapt the statements in the case structure to lowercase.