Re: Maxima digest, Vol 1 #158 - 15 msgs



Since I have received no response from
anyone on item no. 7 posted by me
in Vol. 1 #158, I thought that it best that I should
download GNU-Linux and GCLisp to
roll k_delta function myself.

But the installation procedures for
GNU-linux and GCLisp look
so daunting that I thought it best if I
used AutoLisp from AutoCAD under
Window OS.  This I could get working
easily and I have heard that this Lisp
is based on Common Lisp.  Has anyone
any experience in using AutoLisp for
this purpose?

HuenYK
www.cahresearch.com


----- Original Message -----
From: <maxima-request at www>
To: <maxima@www.ma.utexas.edu>
Sent: Friday, December 14, 2001 1:30 AM
Subject: Maxima digest, Vol 1 #158 - 15 msgs


> Send Maxima mailing list submissions to
> maxima@www.math.utexas.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.math.utexas.edu/mailman/listinfo/maxima
> or, via email, send a message with subject or body 'help' to
> maxima-request@www.math.utexas.edu
>
> You can reach the person managing the list at
> maxima-admin@www.math.utexas.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Maxima digest..."
>
>
> Today's Topics:
>
>    1. Re: Maybe some work to make Maxima display much better (Andrey G.
Grozin)
>    2. Re: why GCL,  what about Allegro (Ole Rohne)
>    3. Why do we need gcl at all? (U-E59264-Osman F Buyukisik)
>    4. why GCL,  what about Allegro (Liam Healy)
>    5. Re: why GCL,  what about Allegro (Raymond Toy)
>    6. Re: why GCL,  what about Allegro (James Amundson)
>    7. How to use k_delta function (Webbooks)
>    8. Re: New files in cvs in preparation for 5.9.0 (Vadim V. Zhytnikov)
>    9. Re: Why do we need gcl at all? (Vadim V. Zhytnikov)
>   10. Re: why GCL,  what about Allegro (Vadim V. Zhytnikov)
>   11. Re: Maybe some work to make Maxima display much better (C Y)
>   12. Re: why GCL,  what about Allegro (Liam Healy)
>   13. Re: why GCL,  what about Allegro (C Y)
>   14. simplify programs, poisson...forwarded message from Richard Fateman
>        (fwd) (alexandre@emc.ufsc.br)
>
> --__--__--
>
> Message: 1
> Date: Thu, 13 Dec 2001 12:04:46 +0600
> From: "Andrey G. Grozin" <A.G.Grozin at inp>
> To: Richard Fateman <fateman@cs.berkeley.edu>
> cc: maxima <maxima@www.ma.utexas.edu>
> Subject: Re: [Maxima] Maybe some work to make Maxima display much better
>
> Hello *,
>
> On Wed, 12 Dec 2001, Richard Fateman wrote:
> > I quite disagree.  In fact, the semantics or the syntactic appearance
> > for typeset mathematics in MathML is, so far as I can tell,  not
> > formally specified, and for LaTeX there is deliberately no semantics
> > associated with the appearance so that $AB$  could be A*B  or matrix
> > multiply AB or a symbol AB.   and $A^(4)$ could mean the 4th derivative.
> > Or something else.   For Maxima, the meaning of any utterance is what it
> > means to Maxima, which is operationally defined, and is entirely formal
> > in the sense of computation. You might not like that computation, but it
> > is formally expressed in the program.  MathML is expressed in some
> > slipperly natural language. On top of that it is about 20 times more
> > verbose.
> I quite disagree. Maxima language has a well-defined *mathematical*
> semantics, but no *typesetting* semantics. LaTeX has a well-defined
> typesetting semantics, and no mathematical semantics. MathML has
> typesetting semantics, and a little bit of mathematical semantics.
>
> If somebody would like to use Maxima as a typesetting language, it will
> have to be enhanced by a lot of markup stuff. Why create a new LaTeX, when
> LaTeX works so wonderfully?
>
> > In the interests of not building towers, I would still prefer taking
> > whatever is written (say in Python!) and writing it it lisp so that
> > we have Maxima  (in lisp)  generating a picture-language that is
> > nothing more than a glyph/position collection  (and maybe even plotting,
> > too?)  talking to a very simple and OS/machine independent display.
> > Maybe even a postscript interpreter.
> The answer is: Display GhostScript. GhostScript is an excellent PostScript
> interpreter; Display GhostScript incorporates Display enhancements, which
> were designed by NeXT in order to make PostScript viable as a means of
> communication between applications and display.
>
> Andrey
>
>
> --__--__--
>
> Message: 2
> To: Richard Fateman <fateman@cs.berkeley.edu>
> Cc: maxima@www.ma.utexas.edu
> Subject: Re: [Maxima] why GCL,  what about Allegro
> From: Ole Rohne <ole.rohne at cern>
> Date: 13 Dec 2001 10:40:05 +0100
>
> Richard Fateman <fateman@cs.berkeley.edu> writes:
>
> > 3. It's just another Lisp, along with GCL etc to support.
> > Do it if you want to.
>
> If anybody with a real Allegro license compiles maxima to produce a
> Windows image, I'm sure somebody else with an interest in maxima on
> that platform will download the free version from Franz and find out
> what happens when he hits the 18 MB heap limit:-) Given that heap
> limit and the 60-day license renewal, I wouldn't consider ACL Trial
> Edition an attractive platform for maxima.
>
>
> Has anybody tried to compile maxima with Corman Lisp -
> <http://www.corman.net/>;? The conditions on the free version seems
> quite generous. IIUC, they would allow re-distributing a maxima binary
> (for non-commercial purposes).
>
> Ole
>
>
> --__--__--
>
> Message: 3
> From: U-E59264-Osman F Buyukisik <absd00t at c1186>
> Date: Thu, 13 Dec 2001 08:29:02 -0500 (EST)
> To: maxima@www.ma.utexas.edu
> Subject: Why do we need gcl at all?
> Reply-To: osman.buyukisik@ae.ge.com
>
> dan.stanger@ieee.org writes:
>  > In a previous message to the list, I saw a bench mark that indicated
>  > that clisp was only about 30% slower then gcl.  Wouldnt our time
>  > be better served by building the stuff in clisp that gcl has,
>  > which I thought was tk support, and then putting our time into cmucl
>  > and making it work on more platforms?  clisp is a gpl'd product also,
>  > works on many more platforms than gcl.  Plus, it implements CLOS,
>  > and many more features then gcl.
>  > Dan Stanger
>
> Well, running lie symmetry calculations(SYMMGRP), clisp is slower by at
least a
> factor of 10!
>
> Osman
>
> --__--__--
>
> Message: 4
> From: Liam Healy <Liam.Healy at nrl>
> Date: Thu, 13 Dec 2001 08:53:46 -0500 (EST)
> To: Richard Fateman <fateman@cs.berkeley.edu>
> Cc: maxima@www.ma.utexas.edu
> Subject: why GCL,  what about Allegro
> Reply-To: Liam Healy <Liam.Healy@nrl.navy.mil>
>
> Three years ago, I hacked up Maxima to run on ACL.  It is not the
> current version (I think it was 5.4).  The basics work, and I use it
> from time to time for small computations.
>
> A couple months ago I passed these changes on to James Amundson, and I
> got the impression they are in place in the current version.  Does it
> still not work?  What remains to be done?
>
> Liam Healy
>
> --__--__--
>
> Message: 5
> To: dan.stanger@ieee.org
> Cc: maxima@www.ma.utexas.edu
> Subject: Re: [Maxima] why GCL,  what about Allegro
> From: Raymond Toy <toy at rtp>
> Date: 13 Dec 2001 09:12:22 -0500
>
> >>>>> "Dan" == Dan Stanger <dan.stanger@ieee.org> writes:
>
>     Dan> However, I am leaning toward steelbank, which is a offshoot
>     Dan> of cmucl, as its goal is maintainability.
>
> SBCL only runs on Linux/x86 and Alpha.  CMUCL runs on Linux/BSD x86
> and Solaris/Sparc.  Older versions run on HPUX and SGI.
> Unfortunately, the main developers don't have access to other
> machines, so they've lagged behind.  I also understand that a
> potential commercial version of CMUCL runs on Linux, sparc, and HP-UX,
> with real OS thread support.
>
> I think maintainability of the underlying lisp is irrelevant to maxima
> unless you plan on maintaining the underlying lisp. :-)
>
> Ray
>
> --__--__--
>
> Message: 6
> Subject: Re: [Maxima] why GCL,  what about Allegro
> From: James Amundson <amundson at fnal>
> To: Maxima List <maxima@www.ma.utexas.edu>
> Cc: Maxima List <maxima@www.ma.utexas.edu>
> Date: 13 Dec 2001 08:26:17 -0600
>
> (I'm writing a short message now, as opposed to a long one later. Later
> keeps turning into never...)
>
> On Wed, 2001-12-12 at 18:18, Richard Fateman wrote:
> > I have explored with Franz Inc the possibility of
> > their providing a base of Allegro CL for Maxima
> > development.
>
> <snip>
>
> > I don't know how people here feel about this.
> > Possible reactions
> >
> > 1. Yes, let's do it. It makes our lives simpler.
> >     (We still need to understand what restrictions we
> >      can live with.)
> >
> > 2. No, only open-source GPL code allowed here.
> >
> > 3. It's just another Lisp, along with GCL etc to support.
> > Do it if you want to.
> >
> > 4. Something else.
>
> My initial reaction is 3. In fact, I was more-or-less planning on it. I
> even had the ACL free edition's restriction on dumping images in the
> back of my mind when I designed the binary install structure.
>
> I actually have the free edition on my disk, but I haven't tried Maxima
> with it.
>
> On Thu, 2001-12-13 at 07:53, Liam Healy wrote:
> > Three years ago, I hacked up Maxima to run on ACL.  It is not the
> > current version (I think it was 5.4).  The basics work, and I use it
> > from time to time for small computations.
> >
> > A couple months ago I passed these changes on to James Amundson, and I
> > got the impression they are in place in the current version.  Does it
> > still not work?  What remains to be done?
>
> I used Liam's code to help with general ANSI issues, but I didn't put in
> changes en masse. The current CVS version of Maxima should be close to
> working with ACL, but I expect there would still be some issues.
>
> --Jim
>
> --__--__--
>
> Message: 7
> From: "Webbooks" <webbooks at singnet>
> To: <maxima@www.ma.utexas.edu>
> Date: Thu, 13 Dec 2001 21:51:18 +0800
> Subject: How to use k_delta function
>
> Hello:
> I have been using Macsyma 2.2 for nearly three years.
> There is a k_delta function which I used extensively
> in my programming but I found that it does not
> work in Maxima.  k_delta or kronecker delta
> worked in Macsyma as follows:
>
> k_delta(1,1); 1
> k_delta(1,0); 0
>
> There is a kdelta in the Maxima documentation, but I could
> not get it to work.  Is there anyone who knows to
> to get this function working?
>
> HuenYeongKong
> www.cahresearch.com
>
>
>
> --__--__--
>
> Message: 8
> Date: Thu, 13 Dec 2001 19:24:57 +0300
> From: "Vadim V. Zhytnikov" <vvzhy at mail>
> To: Maxima List <maxima@www.ma.utexas.edu>
> Subject: Re: [Maxima] New files in cvs in preparation for 5.9.0
>
>
>
> C Y wrote:
>
> > One thing we are going to have to fix before 5.9 - when I ran
> > under
> > cmucl, quit(); does not exit cleanly.  Anyone know what's up
> > with that?
> >  It worked fine under Clisp.  Here's what happens:
> >
> > CMU Common Lisp 18c, running on shemp.physics.smu.edu
> > Send questions and bug reports to your local CMU CL maintainer,
> >
> > or to cmucl-help@cons.org. and cmucl-imp@cons.org.
> > respectively.
> > Loaded subsystems:
> >     Python 1.0, target Intel x86
> >     CLOS based on PCL version:  September 16 92 PCL (f)
> > Maxima 5.6 Tue Jul 10 15:41:45 CDT 2001 (with enhancements by
> > W.
> > Schelter).
> > Licensed under the GNU Public License (see file COPYING)
> > (C1) quit();
> >
> > Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER:  the function
> > QUIT is
> > undefined
> > .
> >
> > Debug  (type H for help)
> >
> > (KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER "<error finding name>"
> >                                         #.(SYSTEM:INT-SAP
> > #x3FFFEA5C)
> >                                         #<Alien (*
> >                                                  (ALIEN:STRUCT
> > NIL # #
> > #
> >                                                   ...)) at
> > #x3FFFE6E0>
> >                                         (14))
> > Source: Error finding source:
> > Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file
> > no
> > longer exists:
> >   target:code/interr.lisp.
> > 0]
> >
> >
>
> This problem is already fixed in cvs.
>
> Vadim
>
> --
>
> [ Vadim V. Zhytnikov  <vvzhy@mail.ru>  <vvzhy@td.lpi.ac.ru> ]
>
>
>
>
>
> --__--__--
>
> Message: 9
> Date: Thu, 13 Dec 2001 19:25:31 +0300
> From: "Vadim V. Zhytnikov" <vvzhy at mail>
> To: Maxima List <maxima@www.ma.utexas.edu>
> Subject: Re: [Maxima] Why do we need gcl at all?
>
>
>
> dan.stanger@ieee.org wrote:
>
> > In a previous message to the list, I saw a bench mark that indicated
> > that clisp was only about 30% slower then gcl.  Wouldnt our time
> > be better served by building the stuff in clisp that gcl has,
> > which I thought was tk support, and then putting our time into cmucl
> > and making it work on more platforms?  clisp is a gpl'd product also,
> > works on many more platforms than gcl.  Plus, it implements CLOS,
> > and many more features then gcl.
> > Dan Stanger
> > _______________________________________________
> > Maxima mailing list
> > Maxima@www.math.utexas.edu
> > http://www.math.utexas.edu/mailman/listinfo/maxima
>
> I do not think that damping GCL support is really good idea.
> First of
> all we do not have so many Lisps readily available as base Lisps
> to
> Maxima and I'm not sure what will happen to any of them in
> future.
> Having just three viable (some of them barely viable at present)
> alternatives is really minimal number to fill safe.
>
> As for performance. I have Maxima running on gcl 2.3.8, gcl
> 2.4.0, clisp
> 2.27,
> cmucl 2.4.17, cmucl 18c on one Linux machine with 384Mb RAM and
> Pentium III 733MHz CPU.
>
> In all my tests clisp is 2-3 times (not 30% !!!) slower than gcl
> and
> cmucl.
> The performance of gcl and cmucl is approximately the same but
> fastest is gcl 2.4.0 with gmp support. Note that with gcl I pre
> allocate
> large chunk of ram at start since without this gcl slows down
> substantially.
>
> Vadim
>
> --
>
> [ Vadim V. Zhytnikov  <vvzhy@mail.ru>  <vvzhy@td.lpi.ac.ru> ]
>
>
>
> --__--__--
>
> Message: 10
> Date: Thu, 13 Dec 2001 19:25:54 +0300
> From: "Vadim V. Zhytnikov" <vvzhy at mail>
> To: Maxima List <maxima@www.ma.utexas.edu>
> Subject: Re: [Maxima] why GCL,  what about Allegro
>
>
>
> Richard Fateman wrote:
>
> > I think that Schelter contributed some code
> > that runs only in GCL or is linked to GCL through
> > foreign function interface that makes some procedures
> > run far faster than expected. If you are not using
> > these procedures, the difference would not be visible.
> > I do not know where these are used but I suspect
> > polynomial factorization.
> >
> > I have explored with Franz Inc the possibility of
> > their providing a base of Allegro CL for Maxima
> > development.
> >
> > Advantage:  supported ANSI CL on Windows, Mac OS-X, many
> > different UNIX and linux systems, many extras like
> > graphics, web support, etc.  (see franz.com).
> >
> > Disadvantage:  it does not come with source code.
> > Disadvantage:  there will be presumably SOME restriction
> > on this so that they are not giving away their main
> > source of revenue free.  Yet this may not be much of
> > a restriction since Franz already gives away a rather complete
> > lisp free (minus some compiler features and maybe a
> > maximum memory limit, plus.. one must re-register periodically...).
> > The free "student" version does not
> > include (I think) the full compiler (just compiles in-core,
> > not producing files), and I think does not support
> > new foreign function linkages.  I think that both
> > these restrictions would have to be lifted to be
> > viable.
> >
> > My guess is that it will be something like
> >
> > the free lisp + enough extra resources to include all
> > of maxima code + enough free space to continue to make it
> > interesting.
> >
> > I don't know how people here feel about this.
> > Possible reactions
> >
> > 1. Yes, let's do it. It makes our lives simpler.
> >     (We still need to understand what restrictions we
> >      can live with.)
> >
> > 2. No, only open-source GPL code allowed here.
> >
> > 3. It's just another Lisp, along with GCL etc to support.
> > Do it if you want to.
> >
> > 4. Something else.
> >
> > If you are inclined towards reaction 1, we still
> > need to make our list of "non-negotiable demands".
> > They must be such that Franz Inc's business is
> > placed in jeopardy.  If we use this code it is
> > in our best interests that the company remain profitable.
> >
> > RJF
> >
>
> Sorry, I don't quite grasp your idea. In particular difference
> between 1 and 3. Do you suggest to make Allegro CL
> the primary Lisp for Maxima? If so then I would rather
> support options 3. Any extra Lisps are welcomed and
> I honestly believe that Allegro Common Lisp is better
> than non commercial Lisps we have. But I don't like
> to rely on any closed source binaries. Imagine the
> company which provided them ceased to operate
> (like Macsyma Inc. does) where do I get new ones?
> Maxima is attractive to me due to availability of
> complete source code (including Lisp) which doesn't
> depend on any vendor.
>
> Vadim
>
>
> --
>
> [ Vadim V. Zhytnikov  <vvzhy@mail.ru>  <vvzhy@td.lpi.ac.ru> ]
>
>
> --__--__--
>
> Message: 11
> Date: Thu, 13 Dec 2001 08:49:43 -0800 (PST)
> From: C Y <smustudent1 at yahoo>
> Subject: Re: [Maxima] Maybe some work to make Maxima display much better
> To: "Andrey G. Grozin" <A.G.Grozin@inp.nsk.su>,
>    Richard Fateman <fateman@cs.berkeley.edu>
> Cc: maxima <maxima@www.ma.utexas.edu>
>
>
> --- "Andrey G. Grozin" <A.G.Grozin@inp.nsk.su> wrote:
> > Hello *,
> >
> > I quite disagree. Maxima language has a well-defined *mathematical*
> > semantics, but no *typesetting* semantics. LaTeX has a well-defined
> > typesetting semantics, and no mathematical semantics. MathML has
> > typesetting semantics, and a little bit of mathematical semantics.
> > If somebody would like to use Maxima as a typesetting language, it
> > will have to be enhanced by a lot of markup stuff. Why create a new
> > LaTeX, when LaTeX works so wonderfully?
>
> I'm confused.  What are we arguing about here?  Maxima already has the
> ability to export to LaTeX syntax, and presumably that ability could be
> extended to other formats.  Whatever display we use, can't we just do
> internally whatever is most convenient for display purposes, depending
> on the interface?
>
> > > Maybe even a postscript interpreter.
> > The answer is: Display GhostScript. GhostScript is an excellent
> > PostScript interpreter; Display GhostScript incorporates Display
> > enhancements, which were designed by NeXT in order to make PostScript
>
> > viable as a means of communication between applications and display.
>
> I'm not really familiar with this solution - how would that work on
> various platforms?  The only Display Ghostscript I am aware of is
> http://www.gyve.org/dgs/ which has not been developed, apparently,
> since 2000, is not finished yet and is part of the GNUStep project. Can
> this provide an interactive interface?  What would be a good place to
> start learning about this?
>
> While were at it, Richard, I noticed in "A Review of Macsyma" you
> mentioned some sort of interface that had been developed at Berkeley
> provided  "a menu-based command structure on top of
> typset-display-based local version of Macsyma", and MIT had somehow
> prevented the sharing of the code among users.  Is that interface still
> around?  Would it be of any use in the current problem?
>
> CY
>
> __________________________________________________
> Do You Yahoo!?
> Check out Yahoo! Shopping and Yahoo! Auctions for all of
> your unique holiday gifts! Buy at http://shopping.yahoo.com
> or bid at http://auctions.yahoo.com
>
> --__--__--
>
> Message: 12
> From: Liam Healy <Liam.Healy at nrl>
> Date: Thu, 13 Dec 2001 12:06:36 -0500 (EST)
> To: James Amundson <amundson@fnal.gov>
> Cc: Maxima List <maxima@www.ma.utexas.edu>
> Subject: Re: [Maxima] why GCL,  what about Allegro
> Reply-To: Liam Healy <Liam.Healy@nrl.navy.mil>
>
> >>>>> "Jim" == James Amundson <amundson@fnal.gov> writes:
>
>     Jim> On Thu, 2001-12-13 at 07:53, Liam Healy wrote:
>     >> Three years ago, I hacked up Maxima to run on ACL.  It is not the
>     >> current version (I think it was 5.4).  The basics work, and I use
it
>     >> from time to time for small computations.
>     >>
>     >> A couple months ago I passed these changes on to James Amundson,
and I
>     >> got the impression they are in place in the current version.  Does
it
>     >> still not work?  What remains to be done?
>
>     Jim> I used Liam's code to help with general ANSI issues, but I didn't
put in
>     Jim> changes en masse. The current CVS version of Maxima should be
close to
>     Jim> working with ACL, but I expect there would still be some issues.
>
> Since I have an ACL Enterprise license, I can volunteer (as time
> permits) to test the code, if this is the piece that's missing.  Is
> there a regression test that is used to test Maxima?
>
> On a related thread, it seems there is an idea among some people that
> there is/ought to be one "official" CL to be used with Maxima that is
> supported and everything else is secondary.  Completely unrelated to
> Maxima, I write my CL code to ANSI specs whereever possible, to be
> used with multiple compilers, and carefully isolate (with #+ #-)
> whatever cannot be written to ANSI-CL.  Is this not an achievable goal
> for Maxima as well?  I know it's hard given the long history of
> Maxima, but it should be possible.
>
> In summary, why does an ACL (or for that matter LispWorks, Corman,
> etc.) port preclude CLISP, CMUCL, etc.?  Free vs. nonfree CLs seems a
> non-issue.
>
> Liam
>
>
> --__--__--
>
> Message: 13
> Date: Thu, 13 Dec 2001 09:09:02 -0800 (PST)
> From: C Y <smustudent1 at yahoo>
> Subject: Re: [Maxima] why GCL,  what about Allegro
> To: Maxima List <maxima@www.ma.utexas.edu>
>
>
> --- "Vadim V. Zhytnikov" <vvzhy@mail.ru> wrote:
> >
> > Sorry, I don't quite grasp your idea. In particular difference
> > between 1 and 3. Do you suggest to make Allegro CL
> > the primary Lisp for Maxima? If so then I would rather
> > support options 3. Any extra Lisps are welcomed and
> > I honestly believe that Allegro Common Lisp is better
> > than non commercial Lisps we have. But I don't like
> > to rely on any closed source binaries. Imagine the
> > company which provided them ceased to operate
> > (like Macsyma Inc. does) where do I get new ones?
> > Maxima is attractive to me due to availability of
> > complete source code (including Lisp) which doesn't
> > depend on any vendor.
>
> I agree completely.  ACL should be explored as another lisp on which to
> run, but not THE lisp on which to run.
>
> CY
>
> __________________________________________________
> Do You Yahoo!?
> Check out Yahoo! Shopping and Yahoo! Auctions for all of
> your unique holiday gifts! Buy at http://shopping.yahoo.com
> or bid at http://auctions.yahoo.com
>
> --__--__--
>
> Message: 14
> From: alexandre at emc
> Date: Thu, 13 Dec 2001 14:30:50 -0200 (BRST)
> To: <maxima@www.ma.utexas.edu>
> cc: <dmartins@lcmi.ufsc.br>
> Subject: simplify programs, poisson...forwarded message from
Richard Fateman
>  (fwd)
>
>   This message is in MIME format.  The first part should be readable text,
>   while the remaining parts are likely unreadable without MIME-aware
tools.
>   Send mail to mime@docserver.cac.washington.edu for more info.
>
> ---1567227548-632899460-1008259893=:7465
> Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
> Content-ID: <Pine.LNX.4.33.0112131412171.7465@emc-gw>
>
>
> Where can I find information about:
> 1) "...programs or some rules to transforms...", reduce or simplify
> expresions, when "...the manipulation may not fall into the
> category of just using one of the built-in commands..."
>
> 2)"... a canonical form is better for the computer, and
> even if the expression looks bad in intermediate form it
> might be better to use poisson forms..."
>
> I did not find this topics in the Maxima Manual. I have problems to get
> the feeling to put a trigonometric polynomial in the simplest form, after
> several multiplications, I'd like to use the poisson forms...but I cannot
> find information...
>
> alex
>
> RJF wrote:
>
> If you really need this form as opposed to something
> that is more efficient for the computer (like poisson series),
> then it seems to me you need to write a program or some
> rules that will transform
>
>  sin(z -b) + sin(z +b)  to   2*cos(b)*sin(z)  for z=tD+tC.
> This can probably be done by substituting z for tD+tC, doing
> trigexpand or trigreduce or ....   I am sorry but
> this kind of manipulation may not fall into the category
> of just using one of the built-in commands.
>
> Usually a canonical form is better for the computer, and
> even if the expression looks bad in intermediate form it
> might be better to use poisson forms.
> RJF
>
> Daniel Martins wrote:
>
> Daniel Martins wrote:
> >
> > I have the same problem. It is quite common when we try to multiply
> > homogeneneous matrices. I sincerely tried several combinations of
> > trigreduce, trigsimplify, ratexpand, etc...
> >
> > I cannot catch the ppoint with trigonometrical functions at all.
> >
> >     Dan> Have you tried
> >     Dan>
>
fullmapl(lambda([u],trigreduce(factorout(ratexpand(trigexpand(u)),sin,cos)))
,a)?
> >     Dan> It returned
> >
> >             [       SIN(tD + tC + tB)   SIN(tD + tC - tB)      ]
> >             [       ----------------- + -----------------
> ]
> > (D20)   [          2                       2       ]
> >             [ r SIN(tB) COS(tD + 2 tC) - dA SIN(tB) SIN(tD + tC) ]
>
> > This is the point : This result is not good enough as
> >
> > matrix([cos(tB)*sin(tD + tC)],
> >        [r*sin(tB)*cos(tD+2*tC) - dA*sin(tB)*sin(tD+tC)]);
> >
> > is the desired solution. For this simple matrix this can be a matter
> > of taste but when we multiply in cascade a series of homogeneneous
> > matrices we cannot control the results in a short time.
> >
> > Where is my (our?) fault
> >
> > Daniel
>
>
> ---1567227548-632899460-1008259893=:7465
> Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII
> Content-ID: <Pine.LNX.4.33.0112131411201.7465@emc-gw>
> Content-Description: forwarded message
>
> Return-Path: fateman@cs.berkeley.edu
> Received: from relay.EECS.Berkeley.EDU (relay.EECS.Berkeley.EDU
[169.229.34.228])
> by vangogh.lcmi.ufsc.br (8.9.3/8.9.3) with ESMTP id SAA13329
> for <dmartins@lcmi.ufsc.br>; Mon, 19 Nov 2001 18:01:39 -0300 (EST)
> Received: from cs.berkeley.edu (windsome.CS.Berkeley.EDU [128.32.131.134])
> by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id MAA17617
> for <dmartins@lcmi.ufsc.br>; Mon, 19 Nov 2001 12:00:16 -0800 (PST)
> Message-ID: <3BF964D0.1992DB8A@cs.berkeley.edu>
> Organization: University of California, Berkeley
> X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
> X-Accept-Language: en
> MIME-Version: 1.0
> References: <Pine.LNX.4.33.0111191528240.16101-100000@emc-gw>
> <3BF953EB.5C87F9AC@ieee.org>
<15353.24974.270236.447627@angola.grante.ufsc.br>
> Content-Type: text/plain; charset=us-ascii
> X-UIDL: a5af5e300d7d960352615b02fa6cbbc1
> From: Richard Fateman <fateman at cs>
> To: Daniel Martins <dmartins@lcmi.ufsc.br>
> Subject: Re: [Maxima] reduce a complete vector
> Date: Mon, 19 Nov 2001 12:00:16 -0800
>
> If you really need this form as opposed to something
> that is more efficient for the computer (like poisson series),
> then it seems to me you need to write a program or some
> rules that will transform
>
>  sin(z -b) + sin(z +b)  to   2*cos(b)*sin(z)  for z=tD+tC.
> This can probably be done by substituting z for tD+tC, doing
> trigexpand or trigreduce or ....   I am sorry but
> this kind of manipulation may not fall into the category
> of just using one of the built-in commands.
>
> Usually a canonical form is better for the computer, and
> even if the expression looks bad in intermediate form it
> might be better to use poisson forms.
> RJF
>
> Daniel Martins wrote:
> >
> > I have the same problem. It is quite common when we try to multiply
> > homogeneneous matrices. I sincerely tried several combinations of
> > trigreduce, trigsimplify, ratexpand, etc...
> >
> > I cannot catch the ppoint with trigonometrical functions at all.
> >
> >     Dan> Have you tried
> >     Dan>
fullmapl(lambda([u],trigreduce(factorout(ratexpand(trigexpand(u)),sin,cos)))
,a)?
> >
> >     Dan> It returned
> >
> >             [       SIN(tD + tC + tB)   SIN(tD + tC - tB)      ]
> >             [       -----------------
----                ]
> > (D20)   [          2                       2       ]
> >             [ r SIN(tB) COS(tD + 2 tC) - dA SIN(tB) SIN(tD + tC) ]
> >
> > This is the point : This result is not good enough as
> >
> > matrix([cos(tB)*sin(tD + tC)],
> >        [r*sin(tB)*cos(tD+2*tC) - dA*sin(tB)*sin(tD+tC)]);
> >
> > is the desired solution. For this simple matrix this can be a matter
> > of taste but when we multiply in cascade a series of homogeneneous
> > matrices we cannot control the results in a short time.
> >
> > Where is my (our?) fault
> >
> > Daniel
> > _______________________________________________
> > Maxima mailing list
> > Maxima@www.math.utexas.edu
> > http://www.math.utexas.edu/mailman/listinfo/maxima
>
> ---1567227548-632899460-1008259893=:7465--
>
>
> --__--__--
>
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>
>
> End of Maxima Digest