Bill Page wrote:
>
> Expression List Integer exports almost no operations. In particular
> it does not export +. The representation of Expression List Integer is
> a constant kernel in Kernel List Integer. The name constant() comes
> from the operator name of this kernel created by constantKernel.
>
> Use
>
> )set message bottomup on
>
> to see that the interpreter resorts to map from
> ExpressionFunctions2(List Integer,Integer) in order to use the + from
> Expression Integer. Referring to the source code:
>
> ExpressionFunctions2(R : Comparable, S : Comparable):
> Exports == Implementation where
> K ==> Kernel R
> F2 ==> FunctionSpaceFunctions2(R, Expression R, S, Expression S)
> E2 ==> ExpressionSpaceFunctions2(Expression R, Expression S)
>
> Exports ==> with
> map : (R -> S, Expression R) -> Expression S
> ++ map(f, e) applies f to all the constants appearing in e.
>
> Implementation == add
> if S has Ring and R has Ring then
> map(f, r) == map(f, r)$F2
> else
> map(f, r) == map(x+->map(f, x), retract r)$E2
>
> it seems that since List Integer is not a Ring, map is called
> recursively on the list obtained by retract. But oddly the 2nd time
> around S = Expression Integer and R = Expression List Integer so map
> is called from FunctionSpaceFunctions2(Expression List Integer,
> Expression Expression List Integer, Expression Integer, Expression
> Expression Integer). Note: This type is not permitted in the
> interpreter but it is OK in SPAD.
Actually 'retract r' produces a kernel. 'map' from E2 extracts
operator and argument list. Then it applies provided mapping
function to argument list. converts operator and applies
converted operator to converted argument list. Constant
kernel has 'constant' as operator and empty argument list,
so the effect is to produce 'constant' operator (with
empty argument list) in 'Expression(Integer)'.
> At this point it seems doubtful to me that this consequence is what
> the author of this part of Expression had in mind. It seems something
> goes wrong on the way to Expression Integer which results in the loss
> of the value part of the constant.
>
> In the absence of any specification of what it is supposed to do in
> the case that R is not even an AbelianSemiGroup, it looks like maybe
> this part of Expression has not been maintained or is obsolete.
AFAICS the 'map' function in such case is bogus: it will drop
value part. More precisely, value of constant kernel is
stored as operator property and 'map' drops properties.
I am affraid that this is case of writing code before thinking
about precise specification. More precisely, 'map' in
'ExpressionSpaceFunctions2' has some restrictions, but alone is
resonable. 'map' in 'ExpressionFunctions2' for non-rings
clearly is deficient, but could work if 'map' in
'ExpressionSpaceFunctions2' worked better.
This is also relevant to disscussion about hashing: interpeter
blindly assumes that if there is a 'map', then it is usable
for coercion. 'map' in 'ExpressionFunctions2' depends on
'map' in 'ExpressionSpaceFunctions2' doing right thing.
But for constant kernels 'map' in 'ExpressionSpaceFunctions2'
misbehaves. One can argue that restriction in
'ExpressionSpaceFunctions2' is reasonable, as it allows
simple implementation of useful function. But in such
case we need to make sure that users of given functionality
obey implicit contract, which is tricky to ensure.
It makes sense to remove implementation of 'map' from
'ExpressionFunctions2' in non-Ring case, as it is likely to
fail or misbehave. Running testsuite shows no change
after removal while Ralf's example complains about missing '+'.
--
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/d/optout.
