
Im fairly confused by this point. However, negative modulo results have existed for decades. If there were an error, I think someone would have noticed before now, seeing as how modulo is very commonly used. See if you can find several matching definations of modulo and compare *that* against the c++ operation, instead of against remainders, and try several compilers as well (you should always get the same result no matter what compiler). Its always possible you have discovered something that has been wrong for 25 or more years, but I just cant imagine a serious bug in so basic a routine has lasted. However, various compilers mess up logical operations on signed numbers as well, and that also surprised me, so odd things do exist in the low level implementations (Mostly by intent for whatever questionable or random reasoning).

Thanks jonnin for reply;
Originally Posted by jonnin
However, negative modulo results have existed for decades.
If we can accept the negative modulo we finally need the positive one , as I told u before if I got a negative in encryption for example I'll not have any sence about what the negative number point to .
Originally Posted by jonnin
If there were an error, I think someone would have noticed before now, seeing as how modulo is very commonly used.
I agree with u it seems there isn't error but what's wrong with "ME" ? , after my small experience I can see that majority of encryption programmers prefere their owen method of modulo in their application , maybe this is because they know the error and ignore it, or because of this they haven't seen the error before !
Originally Posted by jonnin
See if you can find several matching definations of modulo and compare *that* against the c++ operation, instead of against remainders,
I don't agree with u about finding several definition for "Standard" operation in math specially , and the correct defenition as I told u before : mod(n) are the equivalent class from 0 to n1 ; yes I know the equivalent class contains negative numbers in them but why we use mod from begining ... if I have (n+5) I use mod n to get 5 and if I have (3) I use mod n to get n3 , and so on .. so results must be from 0 to n1 .
Originally Posted by jonnin
and try several compilers as well (you should always get the same result no matter what compiler).
I already know , all languages have same problem .
Originally Posted by jonnin
Its always possible you have discovered something that has been wrong for 25 or more years, but I just cant imagine a serious bug in so basic a routine has lasted.
I didn't , it's "Paula" 's :) .. I got confused from this so I'm asking here !
ok thank u anyway I'll look again throw this all maybe I can find something .

You write your own mod for encryption because the standard one cannot handle the large integers used in encryption, right?


thanks for Amady...
first i want to post my thanks and hope to solve that problem but...
why the compiler give us that result??
Is who made the compilers wasn't know the division algorithm and dosen't know that must gives a uniqe (q) and a uniqe(r) ??!!!!!!
i.e. they know or not that :
for all m in Z and n in Z{0} There exist unique integers q and r such that a = qd + r and 0 ≤ r <  d , where  d  denotes the absolute value of d.
If the answer was yes, they were know.
why they did that bug (as I see and sure you with me) ..are they couldn't !!! sure no..
and so the question become why they did that ????
If the answer was No, they weren't know.
now we know that this is a bug ... moreover they weren't know that !!
the question become what we can do to solve that bug???
I as a normal user can't think that the computer give me a rong result ...
and that's our problem and we must solve it But HOW ????


Ohhhhhhhhh :mad: :mad: , relly sorry for that defaul
Originally Posted by Paula
for all m in Z and n in Z{0} There exist unique integers q and r such that a = qd + r and 0 ≤ r <  d , where  d  denotes the absolute value of d.
the correct is :
for all m in Z and n in Z{0} There exist unique integers q and r such that m = qn+ r and 0 ≤ r <  n , where  n  denotes the absolute value of d.

Hey Paula, it's a great honor to see u with us here :WAVE:
Next time make a suitable switch case :
switch(answer)
{
case yes: they know ...
case no : they don't know ...
}
:D
I only want u remember that , of corse they know but the problem why those great computer scientists made compilers on this form ? here we can make the new switch case:
there is a reason for that > what is it ?
there isn't a reason > how to report that bug for all compilers scientists to repair it ? .. I'm series in cryptologie for example it gives us wrong answers ! it's not the true remainder that we expect in our work !
Thanks again Paula for your reply , hope that anybody can give us what's wrong with us or wrong with more than 25 years used language !
Last edited by Amahdy; 12282006 at 07:26 PM.

Hi,
While mathematically correct, your assumptions fail to notice two points:
 it is not the compiler that performs the calculations, but the microprocessor. The compiler just translates the code into suitable machine instructions, in this case the instruction that performs the calculation is IDIV, so, 10 % 3 translates into something in the lines of:
Code:
mov eax, 10 ; load dividend value
mov ebx, 3 ; load divisor
idiv ebx ; perform integer signed division
; now eax contains the quotient (3 in this case)
; edx contains the remainder (1 in this case)
So, don't blame your compiler (nor the "great computer scientists" that made that compiler), at least not for this specific "bug".
 Intel, in its Software Developer Manual, clearly states how IDIV works and explicitly indicates that:
 nonintegral results are ALWAYS truncated (chopped) towards 0. Which means IDIV will divide until the absolute value of the reminder is lower than the absolute value of the divisor and no further (which is, in substance, what you ask for, in order to obtain a positive remainder).
 the sign of the reminder is ALWAYS the same as the sign of the dividend (in this case, 1 has the same sign as 10).
Is it a bug? Well, It could be said that mathematically speaking the result is not "what was expected" (at least by you). But certainly it is not incorrect, either (the result does satisfy Dividend = Divisor * Quotient + Reminder).
This has to do with the way division is implemented in the processor's ALU (Arithmetic Logic Unit), and the divider circuit's limitations. You can get an idea of the algorithms used for division in circuits by taking a look here.
IMHO, programming requires one to acknowledge these constraints and, where necessary, devise a way around the limitations the architecture pushes on you. After all, most cyphering programs work correctly, despite this detail...

First thank u very much mikkus for this great post ;
Now, after looking again I found that u r right about my mistake in saying "compiler" problem , I didn't know before that there is an "idiv" only "div" and I thinked that the compiler generate a simple loop doing that . actually this solve more than the half of the problem ; because in this case as u said it's not a problem for all compilers scientists , only a processor issue, or specially Intel architecture [I don't know what sun and mac do] ..
about the manual , I have only pentium 1 manual so please tell me where is it exactly , It's only to read the complete article I'm interisted in this .
"the sign of the reminder is ALWAYS the same as the sign of the dividend "
this where I want to stop coz as explained in my earlier posts it's not what we expect , bref: it's not the correct answer that we want .
"programming requires one to acknowledge these constraints "
I'm sorry but I think u exagere here , not all programmers must know all things ,it's usually good to know lot of things about this but not be an assembler and it's not very nessesary .
"After all, most cyphering programs work correctly, "
maybe u haven't read all the topic , I mentioned that and I said that they use their owen function to make the mod function , and I have provided solutions for the main algorithm so why we must respect the "limitations the architecture pushes on you" , why not report to the architecturers to repair it ,, this what I mentioned too u think that it'm my problem only and I confirm it's a problem in cryptologie but I think programmers ignore it [or so what?] .
"the result does satisfy ..." we don't want satisfying only, we need the uniquness ,
a + b = 2 , a could be 1 and b = 1 but maybe I [the sender] mean a = 0 and b = 2
so as I said before this digital algorithm can be simply solved I think using my provided solutions made by my great prof : drAmer .
Thank u again for your great reply.
Last edited by Amahdy; 12292006 at 03:44 PM.

Hi, Amahdy,
First off, the manual I'm referring to is located here. This is the first part of the instruction set, volume 2A. Just search for the IDIV instruction in the index. The rest of the volumes can be downloaded here along with some optimization guides. You can find similar info in AMD's website, for their respective processors.
With regards to the fact that this is a bug, I'll just refer to Wikipedia (entire article here) which states:
The way remainder was defined, in addition to the equality a= qd+ r an inequality was also imposed, which was either 0≤ r <  d or  d < r ≤ 0. Such an inequality is necessary in order for the remainder to be unique — that is, for it to be welldefined. The choice of such an inequality is somewhat arbitrary. Any condition of the form x < r ≤ x+ d (or x ≤ r < x+ d), where x is a constant, is enough to guarantee the uniqueness of the remainder.
With two choices for the inequality, there are two possible choices for the remainder, one is negative and the other is positive. This means that there are also two possible choices for the quotient. Usually, in number theory, we always choose the positive remainder. But programming languages do not. C99 and Pascal choose the remainder with the same sign as a. (Before C99, the C language allowed either choice.) Perl and Python choose the remainder with the same sign as d.
In the excerpt, a is the dividend, d is the divisor, q is the quotient and r is the remainder. As you see, there have been different ways of approaching this and neither is inherently wrong.
Of course, when I said programmers had to know these details I was just generalizing, saying that a programmer should be prepared to circumvent a problem when it comes up, instead of "blaming it to the hardware". After all, hardware is known to have limits.

How can I miss that ! I'm was talking about my hardcopy and I have missed that it must be somewhere on the internet an eCopy , thank u for the link !
**I haven't found exactly what u mentioned but generally the idiv results table explain it .
look the operation "or" make more than one answer, if each answer is true then the or make one or both of them true , as u said they expect in math the positive one and in programming depends [they mustn't say programming lang. but proccessor arch. ] however as every body know that (math implies computer) without math we couldn't make any updates in computer science , usualy we make theorems and we apply it in computer using many algorithms ,, like divison theorem , and like any encryption algorithm .
Okey tell me where we need this remainder ? and in my post number 15 here after the small if condition , can't we repair this digitally or programatically to have the normal needed remainder ? I think it's easy digitally , and this hardware limit could be corrected to solve what we all usually need .

You posted a solution for the problem already, checking if the reminder is negative and adjusting the results seems to be the correct, and only, way to go.
This could come as news to you, but actually computers are terrible mathematicians... they are too limited in the way they represent numbers, to begin with. In computers, most advanced (and not so advanced) math is either simulated or approximated. For example, a computer does not natively understand negative numbers, or real numbers, it just simulates them, but at the cost of precision.

"This could come as news to you, but actually computers are terrible mathematicians" :o
I don't know why u r talking about this limit as if it's huge problem .. I mentioned before too the used algorithm and the solution .. I haven't read too much in the computer phisics but finally to implimint the "idiv" for example they make a similar to a loop and it stops at the first number which is sometimes negative .. this loop couldn't be ameliored , or such an if condition couldn't be implimented with this bid processor technologie ?
otherwise in the article they mentioned :
"... But programming languages do not. C99 and Pascal choose the remainder with the same sign as a ..." are they true by saying programming langs ?
And u tell me some computer architecture basis , I'm not expert or a big savant but do u think if I'm talking about this topic I don't know that "a computer does not natively understand negative numbers" or "they are too limited in the way they represent numbers" ?
Thanks very much mikkus for your great replies and I hope really find a final response in this topic or I'm wrong in somewhere or we should tell *** to upgrate this .
Thank u.
Similar Threads

By Matrix.net in forum ASP.NET
Replies: 5
Last Post: 10242006, 10:49 AM

By Jeff Johnson in forum .NET
Replies: 2
Last Post: 07252002, 01:57 PM

Replies: 2
Last Post: 05212002, 02:01 PM

Replies: 9
Last Post: 03312002, 11:14 AM

By John Knoop in forum .NET
Replies: 5
Last Post: 10282000, 04:38 PM
Posting Permissions
 You may not post new threads
 You may not post replies
 You may not post attachments
 You may not edit your posts

Forum Rules

Development Centers
 Android Development Center
 Cloud Development Project Center
 HTML5 Development Center
 Windows Mobile Development Center
