I installed qalculate on a Nokia N810 and it is really brilliant.
However I found a strange bug:
When in hexadecimal input mode I typed in sin(1E) to calculate the sine of 30 (0x1E) degrees.
which is interpreted as 0*(30)
and tan(1E) results in 10*(30)
It seems that in hex mode the letters of the function names are interpreted as numerals, e.g in the word 'tan' it interpretes the 'a' as a numeral ten.
I think this ambuiguity can simply be solved by accepting only capital letters as numerals (for radixes above ten) and lowercase for function names, variable names, etc.
Moreover there is no multiplication sign in the input string so from where the multiplication sign ?
In hex mode functions are simply disabled.
I do not think it's a god idea the change the case sensitivity of function just for the hexadecimal input mode and the hexadecimal number would still be in conflict with for example E as in exa.
I suggest that you use 0x1E in decimal input mode instead.
Not disabled as when clicking on 'sin' on the keypad it does calculate it so it is a parsing problem.
And with changing case sensitivity I mean changing the number notation , *not* the functions.
Then I assume you're using RPN mode. When in RPN mode the keypad functions are applied directly to the RPN stack (current expression are first added i present), thus bypasses any parsing.
As I said before if number notation is changed to only use upper-case letters (and functions, which currently are case insesitive, to only use lower-case), it will still conflict with for example units and prefixes which must be case-sensitive (C=coulomb while c=speed of ligtht, h=hour H=henry, mm is not the same as Mm, etc.).
The only possible alternative is to enable only functions and make functions case sensitive in this special case. I think however that it least would make sense to warn the user in some way that functions, units, and variables are disabled.
The multiplication sign comes from implicit multiplication because of number in parentheses.
Log in to post a comment.