R Fateman | 1 Aug 03:06 2011
Picon

Re: Using Lisp complex

On 7/31/2011 9:41 AM, Robert Dodier wrote:
> Yup, that's a good list.
> I've just taken one step -- maybe someone else wants to keep going.
>
> best
>
> Robert Dodier
>
>
I've thought about this some more, and I think it would be too messy to 
introduce CL complex in any central
way in Maxima.
1. The CL notion is of a pair of reals. But Maxima has another real 
type, namely bigfloat, which is
not acceptable as part of a CL complex.  So the CL notion is inadequate 
for even numerical use
in Maxima.
2. The notion of number in Maxima is extended further, to symbols and 
symbolic expressions.
The CL complex notation is not adequate for pairs of arbitrary expressions.
3. It might make sense (or, at least, not much difference) to use 
internally #c(0 1) instead of $%i.
Input and Output would be modified to show %i as before.

note that in a+b*%i  there is no a priori requirement that a and b  be 
real or real-valued. So
extending CL complex to allow symbolic real and imaginary parts would 
not be so great...

realpart(a+b*%i) is not necessarily a  .  etc.
(Continue reading)

Robert Dodier | 1 Aug 07:38 2011
Picon

error processing Texinfo -- Logarithms.es.texi

Hi, I;m trying to build packages for 5.25.0
(I think I have successfully created a tag, branch-5_25-base,
and a branch, branch-5_25) and make dist-gzip gives me this:

make[3]: *** No rule to make target `Logarithms.es.texi', needed by
`distdir'.  Stop.

Can someone fix it?

best

Robert Dodier
Mario Rodriguez | 1 Aug 08:35 2011
Picon

Re: error processing Texinfo -- Logarithms.es.texi

El dom, 31-07-2011 a las 23:38 -0600, Robert Dodier escribió:
> Hi, I;m trying to build packages for 5.25.0
> (I think I have successfully created a tag, branch-5_25-base,
> and a branch, branch-5_25) and make dist-gzip gives me this:
> 
> make[3]: *** No rule to make target `Logarithms.es.texi', needed by
> `distdir'.  Stop.
> 
> Can someone fix it?
> 
> best
> 
> Robert Dodier

Robert,

I think I've fixed it. I forgot to remove Logarithms.es.texi from
Makefile.am.

Sorry :(
--
Mario

_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima
Stavros Macrakis | 1 Aug 16:54 2011
Picon

Re: Using Lisp complex

It may or may not be a good idea to allow Lisp complexes as part of Maxima expressions.  I tend to think it is not, for many of the reasons Fateman and I have mentioned so far in this thread.  But note that the output, part, and subst cases are actually quite straightforwardly handled by the existing architecture, where format1 (called by subst, part, displa, etc.) does conversions like ((mexpt) x -1) => ((mquotient) 1 x); it could equally well transform #c(1 2) => ((mplus) 1 ((mtimes) 2 $%i)).


But even if they are allowed, this does *not* mean that we can translate Maxima arithmetic directly into native arithmetic.  In fact, we can't even do that for integers and rationals.

For example, the Common Lisp spec (if I'm interpreting it correctly) says that the result of (expt 4 1/2) can be *either* an integer or a float -- GCL in particular returns a float.  That isn't acceptable for Maxima, where it must remain an integer.  Also, I don't believe the CL spec requires that rational powers of integers be calculated exactly; GCL for example is an ULP off for 8^(1/3).

The Common Lisp spec defines (expt 0 0) => 1 and (expt 0.0 0) => 1.0.  Whether we want that to become the Maxima default or not (I know many people have argued for it), we probably want to preserve the *option* of giving an error for it.

True, it is easier to *recognize* a complex if it's in the form #c(1 2) than in the form 1+2*%i, but Maxima will always have to be able to manipulate the latter (including cases where it is not Lisp numbers 1 and 2, but Maxima bfloats or symbolic expressions).

CL floats have advantages for purely numerical calculations; perhaps the better CL implementations even implement them as stack-allocated pairs of floats in compiled code?  How much is that advantage worth to us vs. the complications resulting from allowing complexes within Maxima expressions?

            -s



On Sun, Jul 31, 2011 at 21:06, R Fateman <fateman <at> eecs.berkeley.edu> wrote:
On 7/31/2011 9:41 AM, Robert Dodier wrote:
Yup, that's a good list.
I've just taken one step -- maybe someone else wants to keep going.

best

Robert Dodier


I've thought about this some more, and I think it would be too messy to introduce CL complex in any central
way in Maxima.
1. The CL notion is of a pair of reals. But Maxima has another real type, namely bigfloat, which is
not acceptable as part of a CL complex.  So the CL notion is inadequate for even numerical use
in Maxima.
2. The notion of number in Maxima is extended further, to symbols and symbolic expressions.
The CL complex notation is not adequate for pairs of arbitrary expressions.
3. It might make sense (or, at least, not much difference) to use internally #c(0 1) instead of $%i.
Input and Output would be modified to show %i as before.

note that in a+b*%i  there is no a priori requirement that a and b  be real or real-valued. So
extending CL complex to allow symbolic real and imaginary parts would not be so great...

realpart(a+b*%i) is not necessarily a  .  etc.
4, nothing much is gained.  Maybe saving a little memory occasionally??

If you want to package complex numbers for operations done in Fortran or C, that can be done at
that interface, as appropriate.

After further thought, my view is now:
The list I gave in an earlier message should not be construed as a menu of what to do, but
as a list of reasons that doing it would be so messy as to be a bad idea.  Mathematica has
a Complex number data type and even today it breaks many things to have it around.

RJF



_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima

_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima
R Fateman | 1 Aug 17:28 2011
Picon

Using Lisp rational .. was Re: Using Lisp complex

A better case can be made for using CL  rationals which appear to be 
isomorphic to Maxima structures
of the form , e.g.  ((rat simp)  1 2 ).  numerator and denominator are 
integers etc.

One advantage of our own rat), currently unutilized, is that we COULD in 
Maxima, use ((rat) ...1/0 and -1/0  for pos and neg real infinities, 0/0 
as undefined.  oddly enough, these extension would probably make 
simplification of rational number arithmetic faster.

There plenty of other possible representations. e.g. 2/0, 3/0 ...

RJF
Zbigniew Komarnicki | 1 Aug 17:43 2011
Picon

How to expand matrix multiplications ?

Hello

I have a problem wit matrix multiplication. I could not expand the result, 
below 'res'. How I can do this.

matrix_element_mult: "."$
matrix_element_transpose: transpose$

A: matrix([A1,A2,A3]);
PP: apply(diag_matrix, makelist(P,i,1,3));
res: transpose(A).P.A;

How to expand the last matrix multiplications stored in 'res' ?
expand(res); 

This do not work.

Thank you in advance.

Zbigniew
Zbigniew Komarnicki | 1 Aug 17:50 2011
Picon

Re: How to expand matrix multiplications ?

On Monday 01 of August 2011 17:43:41 you wrote:
[...]
> matrix_element_mult: "."$
> matrix_element_transpose: transpose$
> 
> A: matrix([A1,A2,A3]);
> PP: apply(diag_matrix, makelist(P,i,1,3));
> res: transpose(A).P.A;

I'm sory it should be:
res: transpose(A).P.A - PP;

How to expand the last matrix multiplications stored in 'res' ?
Stavros Macrakis | 1 Aug 17:54 2011
Picon

Re: How to expand matrix multiplications ?

Perhaps you intended


PP: apply(diag_matrix, makelist(P[i],i,1,3));     /* subscript P? */
res: transpose(A).PP.A;            /* PP, not P ? */

?
 
On Mon, Aug 1, 2011 at 11:43, Zbigniew Komarnicki <cblasius <at> gmail.com> wrote:
matrix_element_mult: "."$
matrix_element_transpose: transpose$

A: matrix([A1,A2,A3]);
PP: apply(diag_matrix, makelist(P,i,1,3));
res: transpose(A).P.A;

_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima
Zbigniew Komarnicki | 1 Aug 18:44 2011
Picon

Re: How to expand matrix multiplications ?

On Monday 01 of August 2011 18:35:53 you wrote:
> Still not sure what you have in mind.
> 
> Perhaps you want the 1x1 matrix with the element P?, that is
> 
>      transpose(A).matrix([P]).A - PP;

Yes, it should by 'matrix([P])' . Thank you very much. This is my mistake. 

Now is OK.

Thank you again and very sorry for the mistake.

Zbigniew
Barton Willis | 1 Aug 19:11 2011

Re: proposal for new sign-log

I had suggestions from Stavros & Dan Gildea for improvements to
sign-log--thanks.

This change is checked in--I had some drama getting everything working
on a new computer and new operating system (and new office).

The sign and csign functions are spendy. And the old sign-log was very
slow.

Anytime sign or csign are used in simplifying functions, beware that
sign changes the fact database as it works through an expression.  The
clearsign function removes these facts (I think), but clearsign is
mostly only called at the bottom of the read-eval-print loop.

I noticed that sign sometimes calls factor. For something like
signum(x^2-1), it's sad that sign calls factor (not $factor), but
simp-signum doesn't use the factorization: signum(x^2-1) doesn't
simplify to signum(x-1) signum(x+1).

Maybe somebody would like to speed up sign-mplus & sign-mtimes and
improve them algorithmically...

Again, thanks to all that contributed improvements.

--Barton
_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima

Gmane