Waldek Hebisch <[EMAIL PROTECTED]> writes:
> 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.
OK, then remove them.
> > 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.
Well, I thought that Field is "mathematical", and EXPR INT tries to be 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.
Exactly. And I would have thought that canonicalUnitNormal is such "extra
logic", and since EXPR INT violates it, it shouldn't have it. Do I
misunderstand?
> 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.
Yes, we agree. In fact, even canonical is implemented only very badly, at
least if HyperDoc is correct. I would have thought that, for example, SUP R
should have canonical, if R has.
> 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.
Yes, "zero? is correct" would be a prerequesite for canonicalUnitNormal.
> 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.
Yes, and I hate it. This is (well, was...) "Axiom".
Martin
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
