Am Samstag, den 01.05.2010, 20:11 -0600 schrieb Robert Dodier:
> On 5/1/10, Dieter Kaiser <drdieterkaiser at web.de> wrote:
>
> > The documentation of scalarp says that an expression is assumed to be
> > scalar if the expression is composed only out of numbers, constants, or
> > variables declared to be scalar. Furthermore, the implementation of
> > scalarp is in a way that functions, which have only scalar arguments are
> > assumed to have a scalar value too.
>
> Well, the current behavior of scalarp, which derives the scalar
> property of a function from its arguments, is really unjustified,
> isn't it? There is no necessary connection between the domain
> and codomain.
Yes, your are right.
> I can't tell if you want to change the behavior of scalarp so that
> it does not derive the scalar-ness of the function from its arguments,
> but I am certainly in favor of that. (I would suggest some mechanism
> to declare the domain and codomain, or to declare that a function
> maps one subset of the domain into a subset of the codomain with
> specified properties, e.g. maps integers to integers, or perhaps more
> more bluntly just declare that a function has a scalar-preservation
> property. But at any rate such properties would affect scalarp only
> for functions with appropriate declarations. Built-in operators would
> have such declarations as appropriate.)
To be more clear. We might call the implementation we have a "wrong"
implementation. This "wrong" implementation does unjustified assumptions
about the scalarness of functions and subscripted symbols.
This "wrong" implementation is present since the initial revision. In
the code of the routine scalarclass we have the following comment:
;; ... If it (the function)
;; isn't explicitly declared, then try to be intelligent by looking at
;; the arguments to the function.
This comment might be more complete, if we add " ... assuming that the
function maps scalars on scalars".
Both bug reports on this topic show that we have an inconsistent "wrong"
implementation. I think these inconsistencies are caused mainly by one
bug in the code and a wired implementation. Furthermore, I think a lot
of results of scalarp are correct by accident. (The main problem is,
that every expression, which can not be deduced to be scalar or
nonscalar is assumed to be scalar by the algorithm.)
My first attempt was to do a consistent "wrong" implementation based on
the assumptions which are already implemented. It might be easier for a
user to have a consistent "wrong" implementation as long as the behavior
is easy to deduce and does not change in some cases.
> > 1.
> > Functions not declared to be nonscalar have a scalar value, if the
> > arguments are scalar.
> >
> > 2.
> > Subscripted symbols not declared to be scalar are assumed to represent a
> > nonscalar expression.
>
> I dunno. These both seem wrong to me.
>
> In (1) in the absence of a declaration which describes the action
> of the function somehow, it doesn't seem justifiable to take the
> arguments into account.
>
> Subscripted symbols seem problematic. With a declaration like
> declare(a, nonscalar), does that imply that a[whatever] is nonscalar?
> Often enough we'd like to attach a subscript to a nonscalar variable
> to indicate a component of the variable. How can we distinguish
> between the nonscalar variable itself and its scalar components?
>
> As a separate issue, we'll probably want to make some default
> assumption about scalar versus nonscalar, but it seems like that
> assumption should be the same for functions as for subscripted
> expressions.
The most clean implementation would be to deduce the scalarness only by
known facts and declarations.
Such an implementation is not to difficult to do. It is even possible to
get the code of Maxima and the share packages again to work.
Furthermore, it is clear that a lot of things in existing user code
might change.
I think we have two different points:
1. Get a consistent "wrong" implementation to close the bug reports.
2. Open a feature request for a new implementation of scalarp and
nonscalarp, which does not use assumptions on functions and symbols,
but uses only known facts.
Dieter Kaiser