Waldek Hebisch <[EMAIL PROTECTED]> writes:
> Corectness of coercions in combfunc.spad and uses of is? in efstruct.spad
> depends on design. And since we do not know original design most changes to
> code are likely to conflict with it.
A good testsuite should show this :-) (To make it obvious: I do not think that
we have one)
> > op1 = op2 ==
> > (EQ$Lisp)(op1, op2) => true
> > name(op1) ^= name(op2) => false
> > op1.narg ^= op2.narg => false
> > brace(keys properties op1)^=$Set(Symbol) brace(keys properties op2)
> > => false
> > (func := property(op1, EQUAL?)) case None =>
> > ((func::None) pretend (($, $) -> Boolean)) (op1, op2)
> > true
> >
>
> I must admit that this definition looks very strange, more precisely the
> equality test for properties. Namely, since the same operators appears in
> many places setting property will effectively "change" all places where given
> operator appears. Moreover, if there are any operators which are not EQ to
> given one, but equal by this definintion the property change will suddenly
> break equality. So, it seems that to have sane semantics we need to do one
> of the following:
>
> 1) change property only when creating operators
> 2) keep equal operators EQ
I think that's the current design -- nearly. However, I think that the
original authors wanted different semantics for userland operators.
(1) -> x := operator 'x
(2) -> z := operator 'x
(3) -> (z = x)@Boolean
(3) true
(4) -> w := operator('x, 1)
(5) -> (z = w)@Boolean
(5) false
and so on. I wouldn't mind getting rid of that.
> Now, if 1) is observed, then it should be not hard to also ensure 2). Given
> 2) we could skip rest of checks. Let me remark that in current use typically
> either operators are EQ or names are different -- both tests are fast so
> typically equality testing is fast. But the other tests are really
> expensive...
I agree.
> OTOH if neither 1) not 2) holds I am not sure if I want _this_ operator
> equality -- we may get obscure bugs when previously equal operators suddenly
> turn out to be not equal.
Maybe the safe way is to test the patch also with =$OP defined as EQ$Lisp.
Theoretically, the tests should both succeed. But the problem is, that there
are hardly any tests relying on operators...
> Well, that is really question of design: if operators are kept common, then
> there is no need to fetch operators from specific domains.
I think it's a good idea to have operators with domain specific
properties. I can imagine that at some point we have operators that behave
different in different domains (for example:
(13) -> er := log(x)::EXPR INT
(14) -> ex := log(x)::EXPR COMPLEX INT
(15) -> EQ(operator first kernels ex, operator first kernels er)$Lisp
(15) ()
although I vaguely remember that EXPR COMPLEX INT is not the "right" way...)
-- and I think it's wise to put these properties on the operators, and not as
special checks in the code.
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
-~----------~----~----~----~------~----~------~--~---
