[Date Index]
[Thread Index]
[Author Index]
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...
Prev by Date:
**Re: for control systems stateSpaceModel?**
Next by Date:
**Re: modulo solving lacking domain?**
Previous by thread:
**Re: modulo solving lacking domain?**
Next by thread:
**Re: modulo solving lacking domain?**
| |