Re: modulo solving lacking domain?

*To*: mathgroup at smc.vnet.net*Subject*: [mg126847] Re: modulo solving lacking domain?*From*: Richard Fateman <fateman at eecs.berkeley.edu>*Date*: Wed, 13 Jun 2012 04:55:13 -0400 (EDT)*Delivered-to*: l-mathgroup@mail-archive0.wolfram.com*References*: <201206120659.CAA25892@smc.vnet.net> <C49675CE-DFFB-4759-A1FC-F853D06D2456@mimuw.edu.pl>

On 6/12/2012 7:51 AM, Andrzej Kozlowski wrote: > On 12 Jun 2012, at 07:59, Richard Fateman wrote: > >> Solve[12*n==8,n,Modulus->20] >> >> returns >> {{n->4+5*C[1]}} >> >> It omits C[1] element of Integers. >> I doubt that this is a feature; is it a bug? >> >> C[1] is not necessarily a member of the finite field of >> integers modulo 20. It is obvious not an arbitrary Real. >> > Integers modulo 20 do not form a finite field. Yes, true, it is not a finite field. However, the complaint still holds. > Since 4*5 = 0 modulo 20, so 4 and 5 are zero divisors modulo 20 Integers modulo 20 do are not even an integral domain. > > The constant in the answer is obviously an integer modulo 20. Actually it is not, which is the point of my question. Let C[1]=1000. then n==5004 is a solution. > Probably a mariginally better answer would be > {{n->ConditionalExpression[4+5 C[1],Element[C[1],Integers]}} something like that perhaps. There is also the syntax Element[C[1],Integers] && n==4+5*C[1]] though, confusingly, that might be the result form from Reduce rather than Solve...

**References**:**modulo solving lacking domain?***From:*Richard Fateman <fateman@cs.berkeley.edu>