Log Inconsistency



#2

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


#3

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

#4

Personally, I think logs make only limited sense in those integer modes. Though the output shall be as consistent as possible.

d:-)


#5

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


#6

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.


#7

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


#8

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.


#9

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.


#10

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.

#11

In fact, the little amount of flash memory is limiting the WP 34S almost as much as the ... LCD. But such is life.

d:-/

#12

Are you sure you were getting a negative zero here? Only two of the integer modes support -0. The other two don't.


- Pauli


#13

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.


#14

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

#15

Please see p. 68 of the printed manual.

d:-)


#16

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.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime : inconsistency with implicit multiplication in CAS Olivier Lecluse 6 321 10-27-2013, 03:30 AM
Last Post: parisse
  Wrong answer when evaluating log(10^-12) Daniel Greenidge 4 197 01-26-2012, 05:54 PM
Last Post: Daniel Greenidge
  HP20b Log error Jeffrey Herrington 8 287 03-19-2009, 02:26 PM
Last Post: Gene Wright
  HP-41C LOG PAC Muhammad Ahmad 10 334 09-04-2008, 11:27 PM
Last Post: Muhammad Ahmad
  LOG function or ln CaribbeanHP12c 21 635 04-09-2008, 05:47 PM
Last Post: CaribbeanHP12c
  Log Base 2 on HP15C John 5 216 08-09-2005, 03:19 PM
Last Post: John
  HP12c Plat and trig/log/etc WigglePig 0 85 05-28-2003, 05:47 PM
Last Post: WigglePig

Forum Jump: