Re: [Maxima-discuss] new version of maxmin.lisp + interaction of limit and max

[Stavros M. <mac...@al...>]

I don't think that *simp-max* should perform special-purpose
simplifications on its arguments. There are lots of cases where it might be
beneficial to reduce things to standard/canonical form before further
computation, but that's not the Maxima way.

Special-purpose simplifications within simplifiers lead to two main
problems:

   - That context may perform more simplifications than more general
   contexts. Do we really want  *max(**(x^2-1)/(x-1),x)-1 *to return *x* when
   top-level *(x^2-1)/(x-1)-1 *doesn't?
   - Similarly,* is(...<...)* may become less powerful than *max(...)*,
   which will surely confuse users.
   - The execution time of *simp-max *becomes less predictable and possibly
   much slower. Some users routinely manipulate huge expressions -- we don't
   want to be applying *ratsimp* to them.
   - If the result of *max* is not affected by the *ratsimp*, the work done
   by *ratsimp* will be thrown away, and will potentially be repeated over
   and over.

In any case, I think we need to spend some more time on the fundamentals of
*csign* before making the *users* of *csign *try to work around its
shortcomings. Here are some particularly flagrant cases:

   - *assume(a>b); is(a+1>b) => unknown*
   - *is(a^4<(a^2+1)^2)** => unknown*
   This is especially egregious because deep in the bowels of the code (in
   *signfactor*), it's already used *ratsimp/factor *(expensive functions!)
   to simplify the difference to *2*a^2+1*, which *csign* does know is
   positive. (I have a patch for this which I'm testing.)

             -s

On Thu, Jun 3, 2021 at 2:35 PM Barton Willis via Maxima-discuss <
max...@li...> wrote:

> ​FYI:  For some time, I've been working on revised code for
> simplification of max & min.  As an experiment, I pasted in some code at
> the top level that calls sratsimp on each term (I also experimented with
> trigsimp & trigred).
>
> Should be harmless, right?  Wrong: an example:
>
> (%i29) limit( 27^(log(n)/log(3))/n^3,n,inf);
>
> Since 27^(log(n)/log(3))/n^3 = 1 for positive n, the limit is one.
>
> *Call max on a singleton list:*
>
> 1 Enter simp-max [max(1-(3*log(3))/log(27)),1,true]
>
> *Return the ratsimped value of 1-(3*log(3))/log(27)*
>
> 1 Exit  simp-max (log(27)-3*log(3))/log(27)
>
> *The value returned by limit is rubbish*
>
> (%o29) 0
>
> Of course, I can hide this limit bug by checking for a singleton list and
> immediately returning the singleton member.
>
> I''ll sort this, but it might take some time. In limit.lisp, I see a
> function maxi that might duplicate max, but I have not yet discovered how
> the limit code calls max.
>
> --Barton
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>