HP Forum Archive 21

[ Return to Index | Top of Index ]

Log Inconsistency Message #1 Posted by Barry Mead on 23 July 2013, 6:26 a.m. I just noticed a new inconsistency that appears in the 3436 version of the real calculator as well as the emulator. If you put the calculator into any of the "Integer" (base 2, base 8, base10, or base 16) modes doesn't matter, then you enter the following key sequence: [0] [+/-] [blue] [ln] or [0] [blue] [ln] or [0] [+/-] [Enter] [2] [blue] [logx] or [0] [Enter] [2] [blue] [logx] You don't get the "Domain Error" you get a value of zero with the overflow indicator set. but if you enter [0] [+/-] [blue] [lg] or [0] [blue] [lg] or [0] [+/-] [blue] [lb] or [0] [blue] [lb] You do get the "Domain Error" I would think that ln(-0), or logx(0,2) should also return the "Domain Error" if lg(-0) and lb(-0) do. What do you think? Edited: 23 July 2013, 6:44 a.m. after one or more responses were posted

Re: Log Inconsistency Message #2 Posted by Paul Dale on 23 July 2013, 6:41 a.m., in response to message #1 by Barry Mead The difference is LN is computed using the real code, the other two have specific integer implementations. LOGXY also goes via the real code. When using the real code to support an integer function overflow and domain errors are handled consistently but not necessarily the same way as the built in integer mode functions. - Pauli

Re: Log Inconsistency Message #3 Posted by Walter B on 23 July 2013, 7:17 a.m., in response to message #1 by Barry Mead Personally, I think logs make only limited sense in those integer modes. Though the output shall be as consistent as possible. d:-)

Re: Log Inconsistency Message #4 Posted by Paul Dale on 23 July 2013, 7:21 a.m., in response to message #3 by Walter B The only way to make things consistent here would be to disable the use of real functions in integer mode which would impact a lot of other functions. Better might be to document which functions use the real support and how the results are converted. - Pauli

Re: Log Inconsistency Message #5 Posted by Barry Mead on 23 July 2013, 1:03 p.m., in response to message #4 by Paul Dale I disagree with the phrase "Only way". I believe it would be possible to "DETECT" the input conditions that the calculator is in integer mode and X is zero or minus zero before performing the ln or logx funtions. Then when this input condition is detected the "Domain Error" could be triggered. I may be over simplifying things, but isn't this better than disabling real functions entirely in integer modes? Edited: 23 July 2013, 1:35 p.m.

Re: Log Inconsistency Message #6 Posted by Paul Dale on 23 July 2013, 4:06 p.m., in response to message #5 by Barry Mead Flash is full, we don't have enough code space left to check for integer mode in all the real functions we allow in integer mode. - Pauli

Re: Log Inconsistency Message #7 Posted by Barry Mead on 23 July 2013, 5:38 p.m., in response to message #6 by Paul Dale Since the flash is full, you could do one thing that would simplify these issues and reduce code size. (It wouldn't be IDEAL), but it would improve consistency. If you made ALL LOG functions return "Domain Error" for all 0 or -0 input conditions regardless of integer or floating point modes, it would be right for every case except the floating point 0 case. (Which ideally should return minus infinity). It would also make it easier to document how things work.

Re: Log Inconsistency Message #8 Posted by Paul Dale on 23 July 2013, 7:12 p.m., in response to message #7 by Barry Mead Producing an incorrect result from the floating point log function is far worse IMO. In integer mode, these functions aren't all that useful as Walter already pointed out. In floating point mode they are vital and getting a correct result is a priority. One possibility would be to remove these two errant log functions from integer mode -- complete consistency and not a massive loss. Of course, we'd likely have to remove a whole swag of other automatic functions too, some of which people might find useful. A second would be to remove the integer specific log2 and log10 functions and rely on the floating point versions. A huge speed cost (log is very slow in floating point) and again not a good precedent. A third option would be to change how infinite results are converted in integer mode -- produce a domain error instead of an overflow. This is more liveable I feel. However, the best fix I can think of here is to document which functions use the equivalent floating point implementation automatically in integer mode and also document what the behaviour of the automatic conversion is. - Pauli Edited: 23 July 2013, 7:12 p.m.

Re: Log Inconsistency Message #9 Posted by Barry Mead on 24 July 2013, 12:08 p.m., in response to message #8 by Paul Dale I like your third option. If it could be done without adding any (much) code size. The Overflow(0) indication convey's so little information about what just happened (when a ln or logx of zero is taken). Edited: 24 July 2013, 12:09 p.m.

Re: Log Inconsistency Message #10 Posted by Walter B on 23 July 2013, 4:13 p.m., in response to message #5 by Barry Mead In fact, the little amount of flash memory is limiting the WP 34S almost as much as the ... LCD. But such is life. d:-/

Re: Log Inconsistency Message #11 Posted by Paul Dale on 23 July 2013, 7:22 a.m., in response to message #1 by Barry Mead Are you sure you were getting a negative zero here? Only two of the integer modes support -0. The other two don't. - Pauli

Re: Log Inconsistency Message #12 Posted by Barry Mead on 23 July 2013, 12:50 p.m., in response to message #11 by Paul Dale I do know that the behavior for all four integer modes is identical weather -0 or 0 is used as input to the "ln" or "logx" functions. That behavior is to return a zero as the result with the overflow flag set. Whereas with the "lg" or "lb" functions the result is always "Domain Error" weather the input in the x register starts out as -0 or 0. So I don't know if I am actually inputting -0 or 0 because I cannot see any evidence that they behave differently in any of the integer modes. Edited: 23 July 2013, 12:58 p.m.

Re: Log Inconsistency Message #13 Posted by Paul Dale on 23 July 2013, 4:07 p.m., in response to message #12 by Barry Mead In integer mode you can always see a negative zero. In decimal it is -0 whereas in bases 2, 8 and 16 it is the binary representation for negative zero. - Pauli

Re: Log Inconsistency Message #14 Posted by Walter B on 23 July 2013, 4:15 p.m., in response to message #12 by Barry Mead Please see p. 68 of the printed manual. d:-)

Re: Log Inconsistency Message #15 Posted by Barry Mead on 23 July 2013, 4:54 p.m., in response to message #14 by Walter B Even when the calculator is in "1COMPL" mode where the bit pattern for -0 is unique from 0 after pressing [Enter], the "Log Inconsistency" persists. Regardless of the number base, even in 1COMPL mode, all integer modes show a DIFFERENCE in the error reported by (ln logx) vs (lg lb) when attempted on X values of 0 or -0. With X= 0 or -0, the (ln & logx) returns a value of zero with the overflow flag set. (This is not a very meaningful result. It does not inform the user that the returned value was a huge negative number. It only shows a result of zero with the overflow flag set) Whereas with X = 0 or -0 the (lg or lb) returns "Domain Error" Edited: 23 July 2013, 5:04 p.m.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall