Robert Dodier | 1 Jul 15:32 2009
Picon

Maxima 5.19 branch scheduled for Aug 1

Hello,

I am planning to make a release branch for Maxima 5.19 on Aug 1.
So, developers, if you want to squeeze something into the release,
now is a good time to do it. I'm planning a 5.20 release for December.

FWIW

Robert Dodier
Robert Dodier | 1 Jul 16:39 2009
Picon

Re: "horner([...],x)/FIX" - ID: 631216.

On 6/30/09, Dieter Kaiser <drdieterkaiser <at> web.de> wrote:

> With this changes $ratnumer and $ratdenom map over lists, matrices and
> equations. The function $horner will map over these bags too.

OK by me.

> I think it is useful to implement the mapping over lists and equations.
> This can be done at more places too.

I'm mostly in agreement, except I think it would be better
(for simplifying functions, anyway) to implement such mapping
via a declaration and a general mechanism in the simplification code,
instead of wedging (IF (MBAGP FOO) ...) into every function.

Specifically I would rather see this:

declare (foo, distributes_over ("["));
declare (foo, distributes_over (matrix));
declare (foo, distributes_over ("="));

and then detect that in the simplifier.

This scheme has 2 advantages: it's not necessary to change each
function, and it is easy to find the functions which map over
aggregates --- just look for the distributes_over property.

That won't work for ratnumer, ratdenom, & friends because they
are not simplifying functions. At the moment, I don't see a way
to handle them.
(Continue reading)

Richard Fateman | 1 Jul 17:34 2009
Picon

[Fwd: Re: "horner([...],x)/FIX" - ID: 631216.]


Robert Dodier wrote:
> ..
> I'm mostly in agreement, except I think it would be better
> (for simplifying functions, anyway) to implement such mapping
> via a declaration and a general mechanism in the simplification code,
> instead of wedging (IF (MBAGP FOO) ...) into every function.
>   
Yes, but if you place it in meval or mapply,  it would work even in the 
case of ratnumer etc.

RJF
Richard Fateman | 1 Jul 21:04 2009
Picon

Mapping over "bags" by declaration; was Re: [Fwd: Re: "horner([...],x)/FIX" - ID: 631216.]

I just checked on the definition of meval1. It is a jungle, checking for 
things that simply do not and cannot exist in Maxima,
like lsubr  (left over from maclisp)

Nevertheless,
I think that it would be easy to call a function  (distributes-over 
operator argument)  at some key point, and map over the argument.
I wrote this for mapply1.  But mapply is not actually called from meval 
in general.  Possibly contributing to the meval mess :)

Note that if you say distribute foo over "[",  then foo( [a,b,c])  
evaluates to  [foo(a),foo(b),foo(c)]    {evaluated...}
But what would you like in case of foo( [a,b,c], d, [e,f,g])  ??

Code for mapply1 available on request.  (from file mlisp.lisp)

Richard Fateman wrote:
> Robert Dodier wrote:
>   
>> ..
>> I'm mostly in agreement, except I think it would be better
>> (for simplifying functions, anyway) to implement such mapping
>> via a declaration and a general mechanism in the simplification code,
>> instead of wedging (IF (MBAGP FOO) ...) into every function.
>>   
>>     
> Yes, but if you place it in meval or mapply,  it would work even in the 
> case of ratnumer etc.
>
> RJF
(Continue reading)

Dieter Kaiser | 3 Jul 00:05 2009
Picon

Simplifications of 3*sqrt(2)/sqrt(3)/sqrt(6)

I had a look at the bug report ID: 1639678 "3*sqrt(2)/sqrt(3)/sqrt(6) !=
1". Because I have done some work on TMS and TIMESIN I have tried to
optimize the algorithm to simplify such expressions.

First my results.

This is the example of the bug report. It simplifies immediately:

(%i1) 3*sqrt(2)/sqrt(3)/sqrt(6);
(%o1) 1

Other examples are:

(%i3) sqrt(6)/sqrt(12);
(%o3) 1/sqrt(2)

(%i4) sqrt(6)/sqrt(10);
(%o4) sqrt(3)/sqrt(5)

Furthermore the following example simplifies nicely:

(%i5) 4^(1/4)*4^(n/2);
(%o5) 2^(n+1/2)

With the CVS code we have the result sqrt(2)*4^(n/2).

This is a result for big numbers we have now;

(%i7) sqrt(101!)/sqrt(100!);
(%o7) sqrt(31450696910808591132148340194) /
(Continue reading)

Raymond Toy | 3 Jul 02:35 2009
Picon

Re: Simplifications of 3*sqrt(2)/sqrt(3)/sqrt(6)

Dieter Kaiser wrote:

[nice examples snipped]
> The idea is to factor an integer which is the base of a mexpt-expression
> and multiply the factored form into the list of products. I do not know
> if this method is the fastest way to get the factors of an integer. But
> the code is only called a few times within the testsuite and
> share_testsuite and therefore the much better simplified results might
> overweight the effort to get the factors.
>
> One change of the behavior of Maxima is, that we always get more
> factored results, e.g.
>
> (%i6) sqrt(6);
> (%o6) sqrt(2)*sqrt(3)
>
> (%i14) sqrt(10);
> (%o14) sqrt(2)*sqrt(5)
>
> and no longer sqrt(6) or sqrt(10).
>
> Any comments?
Not sure.  The other examples you presented are probably what I would
like.  But I'm not so sure that I would want sqrt(6) to be factored into
sqrt(2)*sqrt(3).  But I would like sqrt(6)/sqrt(3) to be simplified to
sqrt(2).  Perhaps these are conflicting desires on my part.

And I think always calling factor for these cases may not be such a good
idea.  What if the number is the product of two fairly large primes or
even a prime?  Maxima will spend a lot of time trying to find the factors.
(Continue reading)

reyssat | 3 Jul 08:24 2009
Picon

Re: Is %i an integer? - Adding more facts to the database

Robert Dodier a écrit :
> On 6/28/09, Dieter Kaiser <drdieterkaiser <at> web.de> wrote:
>
>   
>> I have added the following facts to the database:
>>
>>    (kind $%i $imaginary)
>>    (kind $%pi $real)
>>    (kind $%gamma $real)
>>    (kind $%phi $real)
>>     
>
> OK by me. But in addition perhaps %pi, %gamma, and %phi
> should be declared irrational. (Or maybe transcendental for
> %pi and %gamma, but I don't remember if featurep and kindp
> handle that correctly.)
>
>   
I don't think it is a good idea to declare %gamma irrational in maxima 
since it is not proved to be irrational (although everybody suspects it 
even to be transcendental).

Eric Reyssat
Richard Fateman | 3 Jul 17:15 2009
Picon

Re: Is %i an integer? - Adding more facts to the database

I doubt that much can be done automatically with information that a 
constant is irrational or transcendental, so I think such information 
could be left out.

The last I heard, it was unknown whether e+pi was irrational.

Though  either e+pi or e-pi is irrational.
(If they were both rational, then their sum would be rational, and 2e is 
not rational.)

RJF
Robert Dodier | 3 Jul 17:24 2009
Picon

Re: Is %i an integer? - Adding more facts to the database

On 7/3/09, reyssat <eric.reyssat <at> math.unicaen.fr> wrote:

> I don't think it is a good idea to declare %gamma irrational in maxima
> since it is not proved to be irrational (although everybody suspects it
> even to be transcendental).

Agreed. Thanks for pointing it out.

Robert Dodier
reyssat | 3 Jul 17:28 2009
Picon

Re: Is %i an integer? - Adding more facts to the database

Richard Fateman a écrit :
> I doubt that much can be done automatically with information that a 
> constant is irrational or transcendental, so I think such information 
> could be left out.
Maybe you're right, but who knows how this information could be used ? 
For instance one could imagine a different treatment of continued 
fractions if one knows a priori that it doesn't stop in theory 
(irrational numbers), or use a greater precision if some value, known to 
be transcendental, is found to be almost zero.
But one needs at least to implement some rules, like
rational + irrational -> irrational
non zero rational * irrational -> irrational
non zero rational (or algebraic) polynomial applied to transcendental -> 
transcendental
sqrt(rational)-> algebraic irrational
sqrt(transcendental) -> transcendental

>
> The last I heard, it was unknown whether e+pi was irrational.
>
> Though  either e+pi or e-pi is irrational.
> (If they were both rational, then their sum would be rational, and 2e 
> is not rational.)
yes and even e*pi or e+pi  is irrational, and even transcendental  
(otherwise e and pi would be algebraic)

Eric
>
> RJF
>
(Continue reading)


Gmane