Martin Rubey wrote:
>
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> > So, basically you say that we should check number of argument at place
> > of use. I see another possibility: add third argument to isExpt, giving
> > expected number of arguments.
>
> Actually, I now have looked closer at the code and have a rather different
> suggestion. The main point is that we should not check for the name of the
> operator, but rather for identity. Currently we allow to have different
> operators with the same name, although I believe that this feature is unused.
>
> I'm not sure whether we should disable this feature altogether. But I'm
> pretty
> sure that we should require, for example in inroot, that the operator is
> *identical* (in the sense of =$BOP, which is a little bit weaker than EQ$List)
> to operator("nthRoot"::Symbol)$CommonOperators.
>
> Note that the algebra is set up in a way that this works. Below a text I
> wrote
> today morning without internet access, which explains the details.
>
> Dear Waldek,
>
> I looked a little into the isExpt issue and the relations to dealing with
> operators. I found the following surprising:
>
> is?(k, op) and is?(k, sy) (both implemented in Kernel) have *different*
> semantics: the former does not only check the name, but actually identity.
>
> Thus, modifying COMBF as below, also cures the exp^log x problem. However, I
> do not think this is the real fix. I'd prefer to do it as follows:
>
> * remove is? entirely from BasicOperator, Kernel and ExpressionSpace, because
> it's name is misleading.
>
> * remove the two-argument form of isExpt.
>
> * spell out occurrences of isExpt(a, op). I think the following translation
> would be acceptable.
>
>
> I think that testing for equality is correct most of the time...
>
> * replace is?(op, sy) by op.name = sy and is?(op1, op2) by op1 = op2, as
> appropriate. Most of the time it should become the second form, I think.
>
> If this looks good to you, I can post a patch in a few hours.
>
I agree that we should check for identity. Consequently isExpt(x, sy)
should be removed. However, I am not sure if we should remove
isExpt(x, op) and is?. Namely, is? and isExpt (and few related
functions) form a useful abstraction: they are used to implement
"pattern matching" on expressions -- use of is? gives us extra clue
compared to =. Also, I think that we should think twice before
we "spell out the code": when we use aproprate function we have
only single place to read/correct/modify. Once we expand code
we need to search all source for occurences.
One we check for identity my change algfunc and fspace can be reversed.
A bit different story is is?(k, sy) versus is?(k, op): my first
impression is that for example in transsolve we also should check
operator identity. It would be good to sort out this.
One more remark: IIRC operator stuff is on "critical path", that is
its speed visibly affects speed of expression manipulation. I
certainly want to do thing correctly, even if it is slower, but
it would be silly to remove some specific function and re-introduce
them later to gain speed.
--
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
-~----------~----~----~----~------~----~------~--~---
