Re: errata and comments, chapters 2 and 4

Andreas Strotmann wrote:

> I admit, however, that the easy way out that I suggested (i.e. 
> deprecation) is perhaps a bit too radical for a second edition, 
> besides having the disadvantage of breaking old code and examples. An 
> alternative solution could take the form of specifying an algorithm 
> that is guaranteed to determine, from context, whether an interval 
> element is a qualifier or a constructor. This algorithm would probably 
> require some reasonable restrictions on the use of interval as a 
> qualifier; here is a sample restriction that would make such a 
> decision algorithm easy to specify:

Perhaps the problem is best captured by the example

<apply><plus/>
<interval><ci>0</ci><ci>1</ci></interval>
<interval><ci>1</ci><ci>2</ci></interval>
</apply>

With plus allowed to have a domainofapp, (as happens with a  uniform 
treatment of n-ary perators ... )
 this becomes ambiguous, and I can imagine wanting to add together 
intervals.  The author
could still disambiguate this by specifying a definitionURL for plus, - 
forcing their own
specific interpretation on  how the interval qualifier is handled, but 
perhaps something more is needed.

We'll get back to you on this.

>
> Is it possible to use both a "function" and a "real" type value 
> simultaneously to denote a real function?
>
>> > partialdiff:
>>
>> > Why is the optional degree qualifier available for partialdiff but not
>> > diff? That seems inconsistent to me.
>>
>> The diff operator is explicitly univariate and the degree can
>> always be inferred from the degree of the bound variable. 
>
>
> Not for display it can't: d/dx  d/dy  d/dz f    is usually written   
> d^3 f/dx dy dz, so that you have exactly the same problem as for 
> partialdiff. 


No matter what we do,  when univariate an algorithm for deriving a 
presentation must currently unwrap three nested apps of diff while if it 
becomes multivariate this may introduce confusion with partialdiff.   
Well have to  reflect on this and get back to you.

>
>
>> The partialdiff's degree qualifier enables one to more
>> easily write the total degree  in    d^(m+n)/(dx^m dy^n)
>> or   d^3/(dx dy dz)  without requiring the implementation of
>> software to introduce the algebraic
>> arithmetic necessary to compute the total degree. 
>
>
> I take this answer to mean that this kind of change would not be 
> appropriate for a second edition. That's fine with me. 

Correct.  We are not planning to change this at this time.

>>
>> > 4.2.5.
>>
>> Fixed.
>>
>> > mention that conditions can be used with arbitrary "heads" of their
>> > apply, just like bvars. 
>
>
> Here, I see only one 'fixed' but two suggestions. ?? 

This clarification has hit in several places, but I'll check and get 
back to you.
The basic notion has been incorporated.

>
>
>> > 4.3.2.5 nargs:
>>
>> > add a possible value to specify that the declared operator follows the
>> > model of quantifiers or sum/prod/int/max/min/... 'Binder' is used in
>> > OpenMath, 'quantifier' or 'generalized-quantifier' might be
>> > alternatives, too.
>>
>> The type attribute could be used to specify this, or alternatively
>> a definitionURL, so we have left this as is. 
>
>
> So, did you add this kind of type attribute (along with the new one 
> for 'function' you mentioned earlier)? 

Both the type attribute and definitionURL's can have any string as a 
value so
the hooks are there, but specific attribute values with this meaning are 
not spelled
out.   To properly introduce this we would need to introduce some 
classes of
operators, and some notation to refer to them which was a fairly big change
so we elected to leave it as is.

(personal remark)  I suspect the best way to proceed on something like 
this is to
use the existing hooks to model it, and then when this stabalizes move it in
in some future revision.  

>
>
>> > 4.4.2.15
>>
>> > mention that domainofapplication is a qualifier element. 
>
>
> ?? 

Fixed.

Received on Wednesday, 18 June 2003 11:45:14 UTC