Waldek,
Thank you for your comments.
> Bill Page wrote:
>> I think that 'CoercibleTo' should be eliminated. all domains A
>> in which the category CoercibleTo(B) occurs, it should be removed
>> and RetractableTo(A) added to the domain B (if not already present).
>> All occurrences of
>>
>> if A has CoercibleTo(B) then ...
>>
>> should be replaced with
>>
>> if B has RetractableTo(A) then ...
>>
>> In a few cases this might mean providing code for missing
>> retractions.
>>
On Wed, Dec 3, 2008 at 9:39 PM, Waldek Hebisch wrote:
> Canonical use of CoercibleTo is CoercibleTo(OutputForm).
One definition of the word "canonical" is "reduced to the simplest and
most significant form possible without loss of generality"
(wikipedia). Almost all domains inherit 'CoercibleTo(OutputForm)'
occurs in 'SetCategory' therefore a very large number of domains
inherit 'coerce:%->OutputForm' in this manner. But in spite of this I
am not sure that we should consider this a "canonical use" in the
above sense. 'SetCategory' could just as easily exported
'coerce:%->OutputForm' directly.
I think a more "canonical" example of 'coerce' is probably
coerce:Integer->Float
which is provided to Float by 'RetractableTo(%)' in 'RealNumberSystem'.
> Do you think that we should have retraction from OutputForm back
> to given domain?
>
Obviously not. So my prescription: "In all domains A in which the
category CoercibleTo(B) occurs, it should be removed and
RetractableTo(A) added to the domain B (if not already present)." is
certainly wrong in this case.
I would claim that what we are lacking is a proper definition of the
meaning of 'coerce'. When should some operation be called a "coercion"
and when should it more properly be called a "conversion"
('ConvertibleTo')?
> If you look at coercions another interesting case are Void, None
> and Any -- if you believe that coercions can be composed you
> can construct some absurd mapping using those domains.
>
'coerce' operations, as mappings A->B and B->C, can certainly be
composed in a meaningful way. But I am less certain about whether we
really want to consider
A:CoercibleTo(B) and B:CoercibleTo(C)
to be composible.
> More generally CoercibleTo means _one way_ transformation,
> without a canonical way back. RetractableTo is closer to
> embedding.
By _one way_ I guess that you mean that information is lost. I am not
sure what you mean by "canonical" here. Perhaps another way of saying
this might be that the mapping 'coerce' is not one-to-one (monic). I
agree that this seems to be the intended meaning of 'coerce' in the
context of 'RetractableTo'. What you propose is that 'coerce' has a
different meaning in the context of 'CoercibleTo'. In contrast I
specifically wanted to *define* coercion as a mapping that is
necessarily one-to-one (because it is the pullback of an injection). I
am not sure that giving 'coerce' more than one meaning is a good idea.
Perhaps examining more examples of the use of 'CoercibleTo' will help.
Besides 'CoercibleTo(OutputForm)' other uses of 'CoercibleTo' in the
FriCAS library include:
array1.spad.pamphlet:
Tuple(S:Type): CoercibleTo(PrimitiveArray S)
[bijection]
equation2.spad.pamphlet:
Equation(S: Type): public == private where
if S has SetCategory then
SetCategory
CoercibleTo Boolean
[many-to-one]
float.spad.pamphlet:
Float():
Join(FloatingPointSystem, DifferentialRing, ConvertibleTo String, OpenMath,_
CoercibleTo DoubleFloat, TranscendentalFunctionCategory,_
ConvertibleTo InputForm, arbitraryPrecision, arbitraryExponent)
[many-to-one]
kl.spad.pamphlet:
MakeCachableSet(S:SetCategory): Exports == Implementation where
Exports ==> Join(CachableSet, CoercibleTo S)
[bijection]
lie.spad.pamphlet:
AssociatedLieAlgebra(R:CommutativeRing,A:NonAssociativeAlgebra R):
public == private where
public ==> Join (NonAssociativeAlgebra R, CoercibleTo A)
[one-to-one]
AssociatedJordanAlgebra(R:CommutativeRing,A:NonAssociativeAlgebra R):
public == private where
public ==> Join (NonAssociativeAlgebra R, CoercibleTo A)
[one-to-one]
LieSquareMatrix(n,R): Exports == Implementation where
Exports ==> Join(SquareMatrixCategory(n,R,Row,Col), CoercibleTo Matrix R,_
FramedNonAssociativeAlgebra R)
[one-to-one]
matrix.spad.pamphlet:
RectangularMatrix(m,n,R): Exports == Implementation where
Exports ==> Join(RectangularMatrixCategory(m,n,R,Row,Col),_
CoercibleTo Matrix R)
[one-to-one]
SquareMatrix(ndim,R): Exports == Implementation where
Exports ==> Join(SquareMatrixCategory(ndim,R,Row,Col),_
CoercibleTo Matrix R)
[one-to-one]
newpoly.spad.pamphlet:
NewSparseUnivariatePolynomial(R): Exports == Implementation where
Exports == Join(UnivariatePolynomialCategory(R),
CoercibleTo(SUPR),RetractableTo(SUPR))
[bijection]
RecursivePolynomialCategory(R:Ring, E:OrderedAbelianMonoidSup,
V:OrderedSet): Category ==
PolynomialCategory(R, E, V) with
...
if (V has ConvertibleTo(Symbol))
then
CoercibleTo(Polynomial R)
ConvertibleTo(Polynomial R)
[bijection]
NewSparseMultivariatePolynomial(R,VarSet) : Exports == Implementation where
Exports == Join(RecursivePolynomialCategory(R,IndexedExponents
VarSet, VarSet),
CoercibleTo(SMPR),RetractableTo(SMPR))
[bijection]
polset.spad.pamphlet:
PolynomialSetCategory(R:Ring, E:OrderedAbelianMonoidSup,_
VarSet:OrderedSet, P:RecursivePolynomialCategory(R,E,VarSet)): Category ==
Join(SetCategory,Collection(P),CoercibleTo(List(P)), finiteAggregate)
[bijection]
variable.spad.pamphlet:Variable(sym:Symbol): Join(SetCategory,
CoercibleTo Symbol)
[one-to-one]
vector.spad.pamphlet:
DirectProductCategory(dim:NonNegativeInteger, R:Type): Category ==
Join(IndexedAggregate(Integer, R), CoercibleTo Vector R, _
finiteAggregate)
[one-to-one]
In these examples it seems that only 'Equation' uses
'CoercibleTo(Boolean)' and 'Float' uses 'CoercibleTo(DoubleFloat)' in
a sense similar to 'CoercibleTo(OutputForm)', i.e. where there is no
possible way to return. In the cases I have marked [one-to-one]
above, I think defining 'coerce' in terms of a retraction probably
makes sense. The cases marked [bijection] seem to involve kind of
isomorphism.
I think that (re-)defining these different types of conversions,
retractions and coercions in a more consistent manner would be a good
thing.
Regards,
Bill Page.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
