Threaded Mode | Linear Mode

Dieter · (This post was last modified: 06-22-2014 01:15 PM by Dieter.)

(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

pito · 06-22-2014, 01:26 PM

(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

This topic Gerald has started is not about wrong defs of MOD or RMDR, it seems the MOD works ok for positive/negative numbers.
The only issue we see is the special case where Y = k * X. Then the result shall be 0.
That needs to be fixed, it seems.

Gerald H · 06-22-2014, 01:49 PM

(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

I can't see that the HP 16C has an explicit MOD command.

There may be many versions of the MOD function, returning values with eg least norm or least magnitude or even greatest negative magnitude, but, as Pito points out, k*m mod m is returned as zero.

Gerald H · 06-22-2014, 01:51 PM

(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

Sorry, I forgot, what's the result of the calculation on the HP 16C?

Thomas Klemm · 06-22-2014, 02:05 PM

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

0

Thomas Klemm · 06-22-2014, 02:26 PM

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

Gerald H · 06-22-2014, 02:43 PM

(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

Yes, idempotency is required.

You seem to be willing to accept that remainder producing zero does not imply mod giving the same result?

Gerald H · 06-22-2014, 02:45 PM

(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

I omitted the question mark in the heading as I was sure the result was incorrect.

pito · (This post was last modified: 06-22-2014 04:47 PM by pito.)

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

..be careful with mod with negative numbers in C - usually not defined behavior, I burned my fingers few times already Smile

PS: also % in C must not be exactly what mod does in wp34s ..

PS1: the density plot Y MOD X, with 2 examples: -4 mod -2 and -4 mod 2
(the white lines are ~zeros)

walter b · 06-22-2014, 07:29 PM

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:-)

walter b · 06-22-2014, 07:39 PM

Just for the record: we had those discussions about MOD and RMDR almost exactly 3 years ago. Seems some functions are used more frequently than others. Wink

Joe Horn · 06-22-2014, 08:41 PM

Also for the record: The <voice at awe-struck whisper>HP-71</voice> has THREE different modulo/remainder-type functions:

MOD(x,y) = x-y*INT(x/y) = "x reduced modulo y"
RMD(x,y) = x-y*IP(x/y) = "remainder of x/y"
RED(x,y) = "reduction of x by y, that is x-y*n, where n is the nearest integer to x/y"

MOD(-4,2) --> 0
RMD(-4,2) --> -0
RED(-4,2) --> -0

None return 2.

Gerald H · 06-23-2014, 05:42 AM

(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:-)

Could you please find an argument to convince Dieter, as he, unlike you, seems to find the matter much more complex.

walter b · 06-23-2014, 07:31 AM

(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:-)

Gerald H · 06-23-2014, 08:34 AM

(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:-)

Thanks for the answer.

No, I shan't try to persuade him, I have already given cogent arguments, & to anyone numerate post #1 is sufficient.

Paul Dale · 06-23-2014, 08:40 AM

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

Actually, no it isn't. The later discussion is sufficient but not the first post.

The history of this command is that it was added for compatibility with the 41 series devices. At the very least, a sufficient post must include a result from a 41C that differs from the 34S output for the same arguments.

In addition some extra explanation would have been beneficial.

- Pauli

Gerald H · (This post was last modified: 06-23-2014 08:59 AM by Gerald H.)

(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

Clear it is that I don't have the authority to clarify post #1 to you.

That remainder gives zero & modulo doesn't is, however, or at least to me, surprising?

Perhaps Walter B shouldn't attempt to fix this so-called bug?

Paul Dale · (This post was last modified: 06-23-2014 09:21 AM by Paul Dale.)

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

Gerald H · 06-23-2014, 09:25 AM

(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

I greatly appreciate the work & effort that have gone into this project & congratulate the collaborators.

It pleases me to think I can contribute to this calculator project.

walter b · 06-23-2014, 10:23 AM

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

Just continue thinking ... Wink