Log Inconsistency  Printable Version + HP Forums (https://archived.hpcalc.org/museumforum) + Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum1.html) + Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum2.html) + Thread: Log Inconsistency (/thread246897.html) 
Log Inconsistency  Barry Mead  07232013 I just noticed a new inconsistency that appears in the 3436 version 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 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 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  Paul Dale  07232013 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.
Re: Log Inconsistency  Walter B  07232013 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  Paul Dale  07232013 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.
Re: Log Inconsistency  Paul Dale  07232013 Are you sure you were getting a negative zero here? Only two of the integer modes support 0. The other two don't.
Re: Log Inconsistency  Barry Mead  07232013 I do know that the behavior for all four integer modes is identical 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  Barry Mead  07232013 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  Paul Dale  07232013 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  Paul Dale  07232013 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.
Re: Log Inconsistency  Walter B  07232013 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  Walter B  07232013 Please see p. 68 of the printed manual.
d:)
Re: Log Inconsistency  Barry Mead  07232013 Even when the calculator is in "1COMPL" mode where the bit pattern
Regardless of the number base, even in 1COMPL mode, all integer 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)
Edited: 23 July 2013, 5:04 p.m.
Re: Log Inconsistency  Barry Mead  07232013 Since the flash is full, you could do one thing that would simplify Re: Log Inconsistency  Paul Dale  07232013 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 log_{2} and log_{10} 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  Barry Mead  07242013 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.
