Martin Rubey wrote:
>
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> > Currenly have no clear idea which design is better. There are few
> > possibilities:
> >
> > 1) each "functional" domain has its own oparators
> > 2) common oparators but domain specific properties
> > 3) common oparators including properties
> >
>
> I would suggest to leave the design as it is for the moment, since it's a
> rather straightforward change to correct the problem with name capture for the
> moment.
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.
> I checked this weekend the usage of is?:
>
> the only place where we really want that is? tests name equality is in the
> "operator" functions in COMBF, EF, etc.
>
> In all the other places we want that the operators to be equal.
>
> (Note that equality of user defined operators is usually the same as name
> equality, since users typically do not put domain specific properties on their
> operators...)
>
> You find a small sample of my patch below. I think it's not very pretty, but
> at least it's correct. Well, untested... It should not have a big effect on
> speed, here is the definition of equality of operators:
>
> 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
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...
OTOH is 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.
> Of course, it means a little more time is spent in instantiation of domains,
> but I think it will be negligible.
>
> I do not think that we can do much better: we need to fetch the actual
> operator
> from the domain F we are working in.
>
Well, that is really question of design: if operators are kept common,
then there is no need to fetch operators from specific domains. OTOH
keeping pre-computed operators in variables means that we use more
space (rather small increase, which should not be bad), potentially
pay higher const for equality (if there are equal, but not EQ
operators) and save time spent coercing strings to symbols. The
last factor probably have most impact on run time.
> If you say go ahead, I'll finish the patch (it is a lot of work, albeit stupid
> work...) and test it, and then post it for revision.
>
Well, if you fell so go ahead. As I wrote your change may uncover
subtle bugs in code/design but we should be able to handle this.
> However, I think that a lot of testing would be wise. Unfortunately, it seems
> that operators are very little tested (also when I look at Tim's tests).
>
First I would try to find out if something similar to issue 16 can
happen in integration routines (whether one can sneak in user
operator with the same name as a predefined one).
--
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
-~----------~----~----~----~------~----~------~--~---
