Waldek Hebisch <[EMAIL PROTECTED]> writes:
> Martin Rubey wrote:
> >
> > Waldek Hebisch <[EMAIL PROTECTED]> writes:
> >
> > > I wonder why you think that is?(f, sy) is the one to save?
> >
> > actually, just because it's the one that's documented in BOP.
> >
> > > Presonally, this version was a bit misleadig for me (before I got used to
> > > it), not the others. I would say that hasName?(f, sy) would be much
> > > clearer.
> >
> > I think that name f = sy is much clearer. That's why I proposed to
> > eliminate
> > is?.
> >
>
> My problem with "name f = sy" is that such form clearly says that we want to
> check name of operator. However, in algebra we really do not care about
> name, we care about meaning. The is? form is makes clear this aspect.
It does not! The documentation in BOP, KL and ES for is?(f, sy) clearly states
that only the name is checked, and that is?(f, op) is equivalent to
operator f = op (given appropriate definition of operator).
But I believe we are thinking the same, only the communication is tricky.
> Now, implementation of is? is confused, probably some of original authors
> assumed that equal name means equal meaning, but exp^log(x) example shows
> that this is not the case.
Many uses of is?(f, "xxx"::Symbol) actually really want name equality, because
that's the way "operator" is implemented. For example in COMBF:
operator op ==
is?(op, "factorial"::Symbol) => opfact
is?(op, "permutation"::Symbol) => opperm
is?(op, "binomial"::Symbol) => opbinom
is?(op, "summation"::Symbol) => opsum
is?(op, "%defsum"::Symbol) => opdsum
is?(op, "product"::Symbol) => opprod
is?(op, "%defprod"::Symbol) => opdprod
is?(op, POWER) => oppow
error "Not a combinatorial operator"
similar in algfunc and elementry. In these three files, properties are put on
the operators, i.e., they modify them destructively.
I believe that all the other uses of is?(f, "..."::Symbol) (and there are
many), the test only works by coincidence, and it's actually easy to create bug
reports:
(1) -> htrigs exp x
(1) sinh(x) + cosh(x)
Type: Expression(Integer)
(2) -> htrigs exp
>> System error:
Cannot take first of an empty list
(2) -> htrigs x
(2) x
Type: Expression(Integer)
We have
htrigs f ==
(m := mainKernel f) case "failed" => f
op := operator(k := m::K)
arg := [htrigs x for x in argument k]$List(F)
num := univariate(numer f, k)
den := univariate(denom f, k)
is?(op, "exp"::Symbol) =>
g1 := cosh(a := first arg) + sinh(a)
g2 := cosh(a) - sinh(a)
supexp(num,g1,g2,b:= (degree num)::Z quo 2)/supexp(den,g1,g2,b)
sup2htrigs(num, g1:= op arg) / sup2htrigs(den, g1)
Unfortunately, it's not completely intuitive how to change the test. I first
thought it should be
op = operator("exp"::Symbol)$CommonOperators =>
but this is not quite correct, since, in theory, the semantics of exp could
depend on the arguments of TranscendentalManipulations(R, F). So the proper
fix is probably
op = operator("exp"::Symbol)$F =>
which is not really nice. Note that the only domains that implement
ExpressionSpace are EXPR, AN and FortranExpression. AN does not contain
operators, I do not know about FortranExpression. EXPR however implements
operator as follows:
operator op ==
belong?(op)$AF => operator(op)$AF
belong?(op)$EF => operator(op)$EF
belong?(op)$CF => operator(op)$CF
belong?(op)$LF => operator(op)$LF
belong?(op)$FSF => operator(op)$FSF
belong?(op)$FSD => operator(op)$FSD
belong?(op)$ESD => operator(op)$ESD
nullary? op and has?(op, SYMBOL) => operator(kernel(name op)$K)
(n := arity op) case "failed" => operator name op
operator(name op, n::NonNegativeInteger)
so it does the hard work for us...
> I think that we definitly should do the easy part: remove isExpt(x, sy) and
> use only isExpt(x, op) or isExpt(x) (and undo extra checks for number of
> arguments).
OK. I'll provide an appropriate patch.
> Concerning is?(op, sym): I think it would be good to clear current mess. But
> to do that we would need to analyze uses of is?(op, sym) to find out if the
> intent was is?(op, op) or if the code wants some looser equivalence relation
> on operators. It is possible that all uses of is?(op, sym) should be is?(op,
> op), but that this requires a bit more thought.
See above.
> One more remark: there is also question of user code. If users keep names
> distinct, then is?(op, sym) is actually OK. So, the question is if we should
> remove is?(op, sym) entirely, forcing users to choose between "name op = sym"
> (worse IMHO) or "is?(op, operator(sym, arity))" (more effort).
I think that for long term it's better to remove is? (except for pattern
matching, of course).
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
-~----------~----~----~----~------~----~------~--~---
