Ralf Hemmecke wrote:
>
> 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.
definingPolynomial gives you minimal polynomial of the generator
of the extension. minimalPolynomial works for arbitrary elements.
characteristicPolynomial is charcteristic polynomial of regular
representation. So they are related, but different objects.
> >> 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?
ATM Spad compiler does not allow such tests. More precisely, in
implementation part one can use arbitrary tests. But export list
uses limited form of tests. Concerning cost of the test: when
we integrate algebraic functions at least one (and possibly more)
SAE is created. Worse, the base field is Fraction(SUP(Expression(Integer)))
Formally we need absolute factorization here (since EXPR is
algebraically closed). In actual use we work over a
subfield, so what we use may be a field even if correctly
implemented 'irreducible?' would return 'false'.
Integrator is supposed to perform apropriate factorization if
needed so the tests would be redundant. In fact, in this
context integrator knows more about factorization than
general factorizer...
> > 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. ;-) )
It is not good candidate for student project: important part are
design decisions involving interactions between various
parts. Large part of coding is to test alternatives and
scrap the bad ones. If we decide to go with Boolean
parameter, then adding support in compiler and adjusting
algebra could be a project. But I am affraid that we
can decide if we want this only _after_ we have implementation.
So there is risk of "wasted" effort, not nice...
ATM Boolean parameter for me looks most reasonable (should
be easiest to get needed functionality without duplication).
But without implementation I am not sure...
--
Waldek Hebisch
[email protected]
--
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.
