Martin Rubey wrote:
>
> Martin Rubey <[EMAIL PROTECTED]> writes:
>
> > Waldek Hebisch <[EMAIL PROTECTED]> writes:
> >
> > > I am now cleaning patch changing attributes to categories. AFAICS
> > > the following attributes are essentially unused:
> > >
> > > leftUnitary
> > > rightUnitary
> > > NullSquare
> > > JacobiIdentity
> > > infinite
> > > noetherian
> > > central
> > > unitsKnown
> > > canonicalsClosed
> > > canonical
> > >
> > > By essentially unused I mean that they are only defined and not
> > > used or are used only in its own definition or definition of
> > > another essentially unused attribute.
> > >
> > > Most of then look like mostly unimplemented. Also, most of them
> > > does not look really useful. I am tempted to remove to first 7 of
> > > them. The last 3 look like they may be of some use so ATM it
> > > is not clear what to do with them.
> >
> > I agree.
>
> Oops, sorry, I changed my mind. I thought they would only appear in attreg,
> but they don't: they document an attempt to encode more mathematical knowledge
> in the algebra.
>
> If it's not more work, please leave them in (replacing them with empty
> categories). Possibly one can use them at some point.
>
My impression is that if you want to codify more mathematical knowledge,
then it is better to start from scratch -- simply the information
is _very_ incomplete and ad hoc. For example the only noetherian
rings are Integer and SingleInteger. Also, arguably some attributes
just duplicate what is already implied by categories domain. For
example the attribute JacobiIdentity really does not add information
to LieAlgebra (point is that word JacobiIdentity does not add information,
if we could add corresponding equation in machine usable form then we would
gain).
Anyway, I do not have strong opinion either way, just thoght that
removing them would make algebra a little more tidy.
> I do think, however, that the "canonical" attributes are either badly
> documented or exported by mistake. For example:
>
> canonicalUnitNormal
> ++ \spad{canonicalUnitNormal} is true if we can choose a canonical
> ++ representative for each class of associate elements, that is
> ++ \spad{associates?(a,b)} returns true if and only if
> ++ \spad{unitCanonical(a) = unitCanonical(b)}.
>
>
> and in Field (!) we have:
>
> canonicalUnitNormal ++ either 0 or 1.
> canonicalsClosed ++ since \spad{0*0=0}, \spad{1*1=1}
>
>
> But this seems wrong to me, since EXPR INT is a Field (and I think this is
> correct if we look at expressions as functions), but we cannot decide whether
> something is identically zero.
>
Well, in Field we have:
unitCanonical(x) == if zero? x then x else 1
...
x / y == (zero? y => error "catdef: division by zero"; x * inv(y))
Now, if operations are supposed to return correct answers, than
Expression Integer is not a Field. If operation just make
"best effort" to be correct, but may return wrong result, than
we need some extra logic to state when result is really
supposed to be correct.
Now concering canonical: it has well established meaning in the
literature, namely to each element has unique representation
(in other words mathematical equality implies data structure equality).
So if domain has canonical, then equality must be decidable and
presumably our equality is supposed to give correct result. In
fact I would say that if we allow any incorrect operation in
a domain which has canonical, than canonical would become
meaningless.
One can think of canonicalUnitNormal as variant of canonical,
than we should assert it only when zero testing gives
correct answers. Knowing if zero testing works probably
needs extra attribute.
Coming back to our attributes: canonicalUnitNormal nicely illustates
that most of attributes is ill-defined. Namely, we have mathematical
properties which are true or false regardless of our imperfect
implementation and we have properties of implemention. For example,
building Lie algebra starting from matrices over Expression Integer
will give us JacobiIdentity, but due to division by zero in
actual computation Jacobi identity may be violated.
--
Waldek Hebisch
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
