Scope, assumptions, asksign, context. Was Re: Bug in Maxima 5.30.0

I agree ... there is a lot to be done in this area.  The work splits up
logically into three parts:

* Scope of identifiers
* Scope of assumptions
 * Core mathematical inference

Maxima could use improvement in all of these areas:

For identifier scope, I think the biggest challenge is designing a
semantics we're happy with.  It needs to work well both for program
variables and symbolic variables, and not be surprising or difficult for
ordinary users.

For assumption scope, the core semantics seem OK, though I don't like the
interface too much. Depending on the implementation, this may be fairly
closely dependent on the identifier scope and inference components.

For inference, the core partial-order system (written by Genesereth) seems
OK, but we do pretty weak inferencing on top of it.  For example, given a>b
and c>d, sign(a+c-b-d) => pnz.  This area could be worked on pretty much
independently of the others.  The system already has some good algorithms
(e.g. Fourier-Motzkin implemented by Barton), but they're not integrated
into "sign", "is", etc. Then there's the question of whether we want
potentially very slow algorithms being called every time a program calls
"sign".  Should we have a powerful, fast version and a simple, slow version
as we do in simplification?  (e.g. default simplification doesn't calculate
GCDs, let alone canonicalize radicals)

                    -s

On Fri, Aug 30, 2013 at 2:17 PM, Richard Fateman <fateman at gmail.com> wrote:

>  It might not be a bad idea for some ambitious person to re-examine the
> whole
> assume / database / deduction/ context ball of wax.  The original author
> (Michael Genesereth)
> is at Stanford.  Probably not interested in hearing about problems with
> it..
>
> Scope in Maxima has several nasty aspects.  For example, scope of bindings
> during pattern
> matching vs scope of bindings in function calls vs. simplifcation rules
> vs. global bindings; also
> bindings of properties.  e.g.
> assume(x>0)  block([x],assume(x<0), is (x>0))  returns true.
>
>
> Integration isn't the only place where local knowledge is requested and/or
> generated.  If
> we can fix it there, it may pay to look at  (for example)  simplification
> of sums, solve,
> and who knows where else.
>
> RJF
>
>
> On 8/30/2013 10:50 AM, Stavros Macrakis wrote:
>
>  It is clearly wrong to have $sign call clearsign -- sign/asksign results
> are supposed to be persistent across a single user interaction (%i/%o --
> see suprv1/meval*).  This makes sense because the user has no way of
> knowing what internal/local scope they might be in.
>
>  If a more local scope is wanted for a sign/asksign result, it should be
> handled using the context mechanism.  I suppose you could try to do it also
> using unwind-protect etc., but that is tricky to get right.  For example, I
> see that compar/asksign-p-or-n has a bug where if it is previously assumed
> that not equal(x,0), then (asksign-p-or-n x) will *remove* that
> preexisting assumption.
>
>  I suppose there may be cases where the caller really knows that the
> result should not be persistent, and could call sign-plus-cleanup, but that
> seems like a really bad idea in general.
>
>             -s
>
>
>
> On Fri, Aug 30, 2013 at 12:52 PM, Robert Dodier <robert.dodier at gmail.com>wrote:
>
>> On 2013-08-30, Raymond Toy <toy.raymond at gmail.com> wrote:
>>
>> >     3137b946bed77dc4311e4266ed338cd2d46d299f is the first bad commit
>> >     commit 3137b946bed77dc4311e4266ed338cd2d46d299f
>> >     Author: robert_dodier <robert_dodier at users.sourceforge.net>
>> >     Date:   Thu Mar 21 16:03:43 2013 -0700
>> >
>> >         Call CLEARSIGN from $SIGN to clean up facts introduced by sign
>> functions.
>> >
>> > All versions before this commit are fine; you only have to answer one
>> > question and the integral is evaluated correctly.  All versions after
>> this
>> > version are bad; you have to answer several questions and the integral
>> > is not evaluated.
>>
>>  Hrm. That change was made to counteract some other strange behavior --
>> 'sign' left some facts floating around after it was called. Without
>> looking at the integration code, my guess is that it is assuming the
>> sign fact persists for the duration of the integration. Should there be
>> separate sign-plus-cleanup and sign-with-no-cleanup functions? It hurts
>> my head a little bit but maybe so ....
>>
>> Thanks for looking into it --
>>
>> Robert Dodier
>>
>> _______________________________________________
>> Maxima mailing list
>> Maxima at math.utexas.edu
>> http://www.math.utexas.edu/mailman/listinfo/maxima
>>
>
>
>
> _______________________________________________
> Maxima mailing listMaxima at math.utexas.eduhttp://www.math.utexas.edu/mailman/listinfo/maxima
>
>
>