On 03/01/2014 06:20 PM, Waldek Hebisch wrote: > AFAICS SimpleAlgebraicExtension in itself should work fine if for > example M is squre, simply resulting ring will have nilpotent > elements.
Yes, would be fine for me, too. I would probably even want such a behaviour in order to create rings with nilpotent elements. > Of course, current definition of 'minimalPolynomial' is wrong if we > allow general M. Hmm, I'm not completely sure that it is wrong. Obviously the designers of that domain intended something with having both minimalPolynomial and definingPolynomial. There is even a characteristicPolynomial. To be honest, their documentation is not really a good to understand their specifications. >> Even worse, S claims to be a field, but it obviously has zero >> divisors. > > Yes, when R is a field SAE claim to be a field which may cause > incorrect results if M is not irreducible. So, when R is a field M > should be irreducible. That would mean I can never create R[x]/<(x^2+5)^2> for R being the integer but not for rational coefficients? I would rather like to not export field if the polynomial given to SAE is not irreducible. Wouldn't it be possible in to say in if R has Field and irreducible?(M) then Field Currently, SAE inherits if R has Field then Field from MonogenicAlgebra(R, UP), and there is no polynomial involved, i.e. MonogenicAlgebra implicitly assumes (or rather it was intended to assume) that there are no zerodivisors in a corresponding domain. I know that adding "irreducible?(M)" would cause a runtime penalty, but wouldn't that only be at creation time and is then cached? How often would a user create a SAE so that one would reasonably argue against adding that test? > I am not sure how to best fix this situation. We have a few similar > places in algebra where declaration assert something which is not > guaranted to be true. In fact, we assert that Complex is a field > and this is exactly the same problem. > One possible solution is to document limitation. Right. For the moment, I would opt for this fix. It is much better if a user knows that something is not handled properly in the code than simply silently returning wrong results. > Slightly better would be to provide two constructors, one which > builds fields, the other giving only rings. In fact, it could be > useful to allow boolean arguments in category tests so user could > supply extra argument saying that domain is a field (or not). > However final responsibility would be on user to give correct > assertions. In fact, I also like this idea. Yes, we would put more responsibility to the user and s/he might give deliberately (or because of lack of knowledge) a wrong argument, but then at least the library code does what it is being told to do and does not return wrong things without wrong input. Actually, the simplest fix would be to always require an irreducible polynomial for SAE and simply document, that one can use SAE also for non-irreducible polynomials, but that certain functionality will return nonsense. So in some sense that means we would have two domains, one that would require irreducibility and another one for the more general case. The latter then would never assert Field even not if the coefficient ring is a Field and M were in fact irreducible. We should refactor the code so that we don't duplicate, but rather inherit. What do you think? (That can be a little student programming project. ;-) ) Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/groups/opt_out.
