(06-22-2014 12:38 PM)Gerald H Wrote:  So that's it? An obvious error will be passed over & the operating system remains defect?

(06-22-2014 01:11 PM)Dieter Wrote:  

(06-22-2014 12:38 PM)Gerald H Wrote:  So that's it? An obvious error will be passed over & the operating system remains defect?

I do not think this is an "obvious error" or the 34s firmware is "defect". ..
Dieter

(06-22-2014 01:11 PM)Dieter Wrote:  

(06-22-2014 12:38 PM)Gerald H Wrote:  So that's it? An obvious error will be passed over & the operating system remains defect?

I do not think this is an "obvious error" or the 34s firmware is "defect". This topic and the various reasons for the one or other way an operator like MOD or RMDR should behave with negative operands have been discussed here several times over the years. Take a look at this thread that is more than ten years old now: 33s RMDR bug?. It's even almost exactly the same subject, but here with a question mark since the author was not so sure if the observed behaviour actually was a bug. Which always is a good attitude, I think. ;-)

All essential information is included in that thread. Please especially take a look at message #7. It boils down to the simple insight that there are two different functions that return some kind of division remainder: the one is MOD and the other is RMDR. Some calculators only offer the former, others feature the latter, and both are different in the way they handle negative arguments. The mentioned 41-series as well as their successors 48 and 50 offer MOD and do it their way, the 33s and 35s (and probably others) do it the other way and call their function RMDR. The 34s offers both. It operates exactly as the trusted 16C that offers both flavours as well. They both do not neccessarily match the mathematical definition of the MOD operator, whatever this may be. And the thread above even discusses the ways common math software like MathCAD and Mathlab handle these functions: they do not agree either.

So I think it's all as it is supposed to be. AFAIR the 34s implementations of MOD and RMDR have been discussed in the old forum as well, and this is the result. Today's RMDR even used to be named MOD in early 34s versions. ;-) As always, you just have to know how the tools you use behave.

Dieter

(06-22-2014 01:11 PM)Dieter Wrote:  

(06-22-2014 12:38 PM)Gerald H Wrote:  So that's it? An obvious error will be passed over & the operating system remains defect?

I do not think this is an "obvious error" or the 34s firmware is "defect". This topic and the various reasons for the one or other way an operator like MOD or RMDR should behave with negative operands have been discussed here several times over the years. Take a look at this thread that is more than ten years old now: 33s RMDR bug?. It's even almost exactly the same subject, but here with a question mark since the author was not so sure if the observed behaviour actually was a bug. Which always is a good attitude, I think. ;-)

All essential information is included in that thread. Please especially take a look at message #7. It boils down to the simple insight that there are two different functions that return some kind of division remainder: the one is MOD and the other is RMDR. Some calculators only offer the former, others feature the latter, and both are different in the way they handle negative arguments. The mentioned 41-series as well as their successors 48 and 50 offer MOD and do it their way, the 33s and 35s (and probably others) do it the other way and call their function RMDR. The 34s offers both. It operates exactly as the trusted 16C that offers both flavours as well. They both do not neccessarily match the mathematical definition of the MOD operator, whatever this may be. And the thread above even discusses the ways common math software like MathCAD and Mathlab handle these functions: they do not agree either.

So I think it's all as it is supposed to be. AFAIR the 34s implementations of MOD and RMDR have been discussed in the old forum as well, and this is the result. Today's RMDR even used to be named MOD in early 34s versions. ;-) As always, you just have to know how the tools you use behave.

Dieter

(06-22-2014 01:51 PM)Gerald H Wrote:  Sorry, I forgot, what's the result of the calculation on the HP 16C?

(06-22-2014 02:26 PM)Thomas Klemm Wrote:  Whatever the definition of MOD is, it should be idempotent:

Example in C:

Code:

#include <stdio.h>
int main()
{
    printf("%2d = %2d\n",  4 %  5, (  4 %  5) %  5);
    printf("%2d = %2d\n", -4 %  5, ( -4 %  5) %  5);
    printf("%2d = %2d\n",  4 % -5, (  4 % -5) % -5);
    printf("%2d = %2d\n", -4 % -5, ( -4 % -5) % -5);
}

Result:

Code:

 4 =  4
-4 = -4
 4 =  4
-4 = -4

This is clearly violated with the current implementation of MOD in the WP-34S:
-4 MOD 2 = 2
but
(-4 MOD 2) MOD 2 = 0

Cheers
Thomas

(06-22-2014 01:11 PM)Dieter Wrote:  

(06-22-2014 12:38 PM)Gerald H Wrote:  So that's it? An obvious error will be passed over & the operating system remains defect?

I do not think this is an "obvious error" or the 34s firmware is "defect". This topic and the various reasons for the one or other way an operator like MOD or RMDR should behave with negative operands have been discussed here several times over the years. Take a look at this thread that is more than ten years old now: 33s RMDR bug?. It's even almost exactly the same subject, but here with a question mark since the author was not so sure if the observed behaviour actually was a bug. Which always is a good attitude, I think. ;-)

All essential information is included in that thread. Please especially take a look at message #7. It boils down to the simple insight that there are two different functions that return some kind of division remainder: the one is MOD and the other is RMDR. Some calculators only offer the former, others feature the latter, and both are different in the way they handle negative arguments. The mentioned 41-series as well as their successors 48 and 50 offer MOD and do it their way, the 33s and 35s (and probably others) do it the other way and call their function RMDR. The 34s offers both. It operates exactly as the trusted 16C that offers both flavours as well. They both do not neccessarily match the mathematical definition of the MOD operator, whatever this may be. And the thread above even discusses the ways common math software like MathCAD and Mathlab handle these functions: they do not agree either.

So I think it's all as it is supposed to be. AFAIR the 34s implementations of MOD and RMDR have been discussed in the old forum as well, and this is the result. Today's RMDR even used to be named MOD in early 34s versions. ;-) As always, you just have to know how the tools you use behave.

Dieter

(06-22-2014 02:26 PM)Thomas Klemm Wrote:  Whatever the definition of MOD is, it should be idempotent:
Example in C:

(06-22-2014 07:29 PM)walter b Wrote:  Just returned from a long day off internet. And I'm a bit astonished about the amount of ... excitement showing up in this thread. When I quickly answered the OP this morning, I admit I looked to the sign of the result only since I remembered it took me some time to follow the signs when checking MOD and RMDR many months ago. I didn't look at the digit of the result at all. Too simple. My fault. And I had no chance to correct that fault during the day.

So the real message is that -4 ENTER 2 MOD returns 2 while 4 ENTER 2 MOD returns 0 which is obviously inconsistent. Yes, that's a bug. The formula printed on said page of the manual states clearly and correctly:

a-b∙floor(a/b)=:mod(a;b).

Here: mod(-4;2) = -4 - 2∙floor(-4/2) = -4 - 2∙floor(-2) = -4 - 2∙(-2) = 0 in contradiction to the result the WP 34S returns so far.

I'm sure we get that corrected. Thanks for starting the thought process with post #1.

d:-)

(06-23-2014 05:42 AM)Gerald H Wrote:  Could you please find an argument to convince Dieter, as he, unlike you, seems to find the matter much more complex.

(06-23-2014 07:31 AM)walter b Wrote:  

(06-23-2014 05:42 AM)Gerald H Wrote:  Could you please find an argument to convince Dieter, as he, unlike you, seems to find the matter much more complex.

I don't see that. If you think there's a need to convince him, feel free to do it yourself.

d:-)

(06-23-2014 08:34 AM)Gerald H Wrote:  & to anyone numerate post #1 is sufficient.

(06-22-2014 10:56 AM)Paul Dale Wrote:  Are you sure you shouldn't be using the RMDR operation? -4 2 RMDR gives 0.

MOD and RMDR differ in their processing of negative values. The former being added late for compatibility with the 41 series devices.


- Pauli

(06-23-2014 09:19 AM)Paul Dale Wrote:  I already fixed this bug -- circa twelve hours ago now. Walter doesn't touch the code. That's for me and Marcus. As for the numeric code, it is almost exclusively me.

Put bluntly, the first post was not a good bug report. It didn't say what answer was expected. It didn't include results from other calculators. It certainly didn't mention remainder. I might write a report that claims \(SIN(\frac{\pi}{12})\) should be \(\frac{\sqrt{3}-1}{\sqrt{2}^3}\) but I'm getting 0.2588, please fix. Should I begin recoding immediately?

Subsequent posts filled in all these details and then I acted. I don't jump to fix things instantly, I need to know that there really is a problem and what the proper fix should be. These functions are often subtle and the obvious fix won't work. If I'd had a 41C to hand, I might have acted faster, but I didn't.

Still, I'd say that a twenty four or so hour response time from the initial report to a committed fix is far better than you'll ever get from a commercially supported product. Remember that we're making no money from this firmware, it is a labour of love.


- Pauli

(06-23-2014 09:25 AM)Gerald H Wrote:  It pleases me to think I can contribute to this calculator project.