How do we plot without scale of xy axis?
eg. plot_2d(sin(x),[x,-2*%pi,2*%pi])
Quoting maxima-request@math.utexas.edu:
> 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. FORTRAN format (Vijayendra Munikoti)
> 2. Re: Various newbie questions (Stavros Macrakis)
> 3. Re: FORTRAN format (Raymond Toy)
> 4. Re: FORTRAN format (Robert Dodier)
> 5. error - system too complex (damiano biagioli)
> 6. Question about declare-top (C Y)
> 7. Re: error - system too complex (Robert Dodier)
> 8. Re: Beginnings of package ideas on wiki (Nikodemus Siivola)
> 9. Re: Beginnings of package ideas on wiki (C Y)
> 10. FORTRAN format (Vijayendra Munikoti)
> 11. LOAD problem (Vijayendra Munikoti)
> 12. compiled code with modedeclare (Barton Willis)
>
> --__--__--
>
> Message: 1
> From: "Vijayendra Munikoti"
> To:
> Date: Tue, 21 Jun 2005 15:03:48 +0200
> Subject: FORTRAN format
>
> Hallo
> I have a huge expression containing numbers, which I intend exporting to
> FORTRAN. Is there a way to change all the numbers in the expression to
> double precision fortran format eg. D0,D1 etc.?
>
> BFLOAT(expression) does this with a difference -- it adds B0, B1 ...
> Is it possible to change this behaviour?
>
> Thanks
> Vijayendra
>
>
>
>
>
> --__--__--
>
> Message: 2
> Date: Tue, 21 Jun 2005 09:55:39 -0400
> From: Stavros Macrakis
> Reply-To: macrakis@alum.mit.edu
> To: Juan Pablo Romero Bernal
> Subject: Re: [Maxima] Various newbie questions
> Cc: maxima@math.utexas.edu
>
> > (%i7) sin(%pi),numer;
> > (%o7) 1.224606353822377E-16
> >
> > Why the result in %o7??. The number in %o7 is very small, but
> > should must be zero??
>
> "numer" means: convert everything to floating point for the
> evaluation. So it first converts %pi to a floating-point number --
> which is inherently an approximation -- then calculates the sine of
> that number numerically. The sine of %pi plus epsilon (a small error)
> is not zero, but -epsilon.
>
> You will see this on any numeric system.
>
> If on the other hand you want the floating-point value of the *exact*
> expression sin(%pi), try float(sin(%pi)). In that case, Maxima will
> first simplify the expression sin(%pi) to zero, and only then evaluate
> that as a floating-point number.
>
> Beware -- floating-point calculations in general are more subtle than
> you might think.
>
> -s
>
>
> --__--__--
>
> Message: 3
> To: "Vijayendra Munikoti"
> Cc:
> Subject: Re: [Maxima] FORTRAN format
> From: Raymond Toy
> Date: Tue, 21 Jun 2005 11:01:48 -0400
>
> >>>>> "Vijayendra" == Vijayendra Munikoti
> writes:
>
> Vijayendra> I have a huge expression containing numbers, which I
> intend exporting to
> Vijayendra> FORTRAN. Is there a way to change all the numbers in the
> expression to
> Vijayendra> double precision fortran format eg. D0,D1 etc.?
>
> Vijayendra> BFLOAT(expression) does this with a difference -- it adds
> B0, B1 ...
> Vijayendra> Is it possible to change this behaviour?
>
> I don't think that's currently possible.
>
> First, fortran eventually calls EXPLODEN to print out numbers. But
> EXPLODEN goes out of it's way to print "small" numbers using ~F format
> instead of ~E. (It should probably use ~G and forget about the
> special cases). But with the ~F format, no exponent is printed. But
> even if it were, I think the exponent marker would be E, not D, which
> isn't what you want.
>
> This issue could be fixed, but EXPLODEN by using ~E for printing, but
> it doesn't know when to use that. It seems, however, that there's a
> variable FORTRANP that could be used to tell EXPLODEN about it.
>
> So, here is a patch that implements this. Now, instead of
> fortran(3.14159*x) producing "3.14159*x", you get "3.14159d+2*x",
> which is what you want, I think.
>
> Ray
>
>
> Index: src/commac.lisp
> ===================================================================
> RCS file: /cvsroot/maxima/maxima/src/commac.lisp,v
> retrieving revision 1.24
> diff -u -r1.24 commac.lisp
> --- src/commac.lisp 9 Mar 2005 16:07:09 -0000 1.24
> +++ src/commac.lisp 21 Jun 2005 15:00:37 -0000
> @@ -472,12 +472,16 @@
> (setq string (print-invert-case symb)))
> ((floatp symb)
> (let ((a (abs symb)))
> + #+nil
> (cond ((or (eql a 0.0)
> (and (>= a .001)
> (<= a 10000000.0)))
> (setq string (format nil "~vf" (+ 1 $fpprec) symb)))
> - (t (setq string (format nil "~ve" (+ 4 $fpprec) symb)))))
> - (setq string (string-left-trim " " string)))
> + (t (setq string (format nil "~ve" (+ 4 $fpprec) symb))))
> + (setq string (if fortranp
> + (format nil "~ve" (+ 4 $fpprec) symb)
> + (format nil "~vg" (+ 4 $fpprec) symb)))
> + (setq string (string-trim " " string))))
> #+(and gcl (not gmp))
> ((bignump symb)
> (let* ((big symb)
> Index: src/fortra.lisp
> ===================================================================
> RCS file: /cvsroot/maxima/maxima/src/fortra.lisp,v
> retrieving revision 1.3
> diff -u -r1.3 fortra.lisp
> --- src/fortra.lisp 25 Nov 2004 02:36:02 -0000 1.3
> +++ src/fortra.lisp 21 Jun 2005 15:00:37 -0000
> @@ -70,8 +70,10 @@
> (defprop mexpt msize-infix grind)
> (defprop mminus 100. lbp)
>
> - (defprop msetq (#\:) strsym)
> - (setq x (mstring x))
> + (defprop msetq (#\:) strsym)
> + (let ((fortranp t)
> + (*read-default-float-format* 'single-float))
> + (setq x (mstring x)))
> ;; Make sure this gets done before exiting this frame.
> (defprop mexpt msz-mexpt grind)
> (remprop 'mminus 'lbp)
>
>
> --__--__--
>
> Message: 4
> Date: Tue, 21 Jun 2005 08:03:49 -0700 (PDT)
> From: Robert Dodier
> Subject: Re: [Maxima] FORTRAN format
> To: Vijayendra Munikoti ,
> maxima@math.utexas.edu
>
> Hello Vijayendra,
>
> > I have a huge expression containing numbers, which I intend exporting
> > to FORTRAN. Is there a way to change all the numbers in the
> > expression to double precision fortran format eg. D0,D1 etc.?
> >
> > BFLOAT(expression) does this with a difference -- it adds B0, B1 ...
> > Is it possible to change this behaviour?
>
> At present it doesn't appear possible to get 1d0 for 1.0 or 1b0.
> That's really too bad since all Maxima floats are
> double precision, if not bigfloat.
>
> Formatting numbers is eventually routed through EXPLODEN,
> which, on inspection, doesn't seem to respect any flags
> for numerical format.
>
> Here's the part of EXPLODEN for formatting floats.
> Maybe someone has some ideas here.
>
> ((floatp symb)
> (let ((a (abs symb)))
> (cond ((or (eql a 0.0)
> (and (>= a .001)
> (<= a 10000000.0)))
> (setq string (format nil "~vf" (+ 1 $fpprec) symb)))
> (t (setq string (format nil "~ve" (+ 4 $fpprec) symb)))))
> (setq string (string-left-trim " " string)))
>
> For what it's worth,
> Robert Dodier
>
>
>
>
>
> ____________________________________________________
> Yahoo! Sports
> Rekindle the Rivalries. Sign up for Fantasy Football
> http://football.fantasysports.yahoo.com
>
>
> --__--__--
>
> Message: 5
> From: damiano biagioli
> To: maxima@math.utexas.edu
> Date: Tue, 21 Jun 2005 17:28:46 +0200
> Subject: error - system too complex
>
> when i typed the following commands on the maxima command line ,
>
> Maxima restarted.
> (%i1) T:matrix([3,45,6,7,8]);
>
> (%o1) [ 3 45 6 7 8 ]
> (%i2) t:matrix([0,3,48,54,61,69]);
> (%o2) [ 0 3 48 54 61 69 ]
> (%i3) algsys([5/N-sum(F*%
> E^(-F*t[1,i])*T[1,i],i,1,5)=0,5/F-sum(t[1,i],i,1,6)-sum(F*n*t[1,i]+%
> E^(-F*t[1,i])*T[1,i],i,1,5)=0],[N,F]);
>
> i got the follwing error :
>
> ALGSYS cannot solve - system too complicated.
> -- an error. Quitting. To debug this try DEBUGMODE(TRUE);
>
> Is there another way to solve this system using maxima ? if this system
> can't be solved using it , what other CAS could I use ?
>
>
> --__--__--
>
> Message: 6
> Date: Tue, 21 Jun 2005 13:48:09 -0700 (PDT)
> From: C Y
> To: Maxima list
> Subject: Question about declare-top
>
> In the mactex file, there exists the following statement:
>
> (declare-top
> (special lop rop ccol $gcprint texport $labels $inchar
> vaxima-main-dir
> )
> (*expr tex-lbp tex-rbp))
>
> What does it mean, from a coding standpoint, to declare these things
> special or "*expr"? I never quite understood this - I was under the
> impression that this was something that appeared on a "per-file" basis,
> but since most everything was in the "MAXIMA" package these statements
> presumably have a global effect? Any insight appreciated.
>
> Cheers, and thanks
> CY
>
>
>
> ____________________________________________________
> Yahoo! Sports
> Rekindle the Rivalries. Sign up for Fantasy Football
> http://football.fantasysports.yahoo.com
>
>
> --__--__--
>
> Message: 7
> Date: Tue, 21 Jun 2005 22:22:15 -0700 (PDT)
> From: Robert Dodier
> Subject: Re: [Maxima] error - system too complex
> To: damiano biagioli , maxima@math.utexas.edu
>
> Hi Damiano,
>
> > (%i1) T:matrix([3,45,6,7,8]);
> >
> > (%o1) [ 3 45 6 7 8 ]
> > (%i2) t:matrix([0,3,48,54,61,69]);
> > (%o2) [ 0 3 48 54 61 69 ]
> > (%i3) algsys([5/N-sum(F*%
> > E^(-F*t[1,i])*T[1,i],i,1,5)=0,5/F-sum(t[1,i],i,1,6)-sum(F*n*t[1,i]+%
> > E^(-F*t[1,i])*T[1,i],i,1,5)=0],[N,F]);
> >
> > i got the follwing error :
> >
> > ALGSYS cannot solve - system too complicated.
>
> Well, I don't know how difficult or easy it should be to solve it.
>
> If you can accept a numerical solution, you can try using
> mnewton (multivariate Newton method). Get mnewton.mac from:
> http://cvs.sf.net/viewcvs.py/maxima/maxima/share/contrib/
>
> Defining F1(N,F) := (left side of one equation),
> F2(N,F) := (left side of other equation), and trying
> some different starting points, I get the following:
>
> (%i28) mnewton([F1(N,F),F2(N,F)],[N,F],[0.001,0.001]);
> (%o28) [[N = 5.601022146947916, F = .0164121839939073]]
>
> and checking the would-be solution --
>
> (%i31) subst([N = 5.601022146947916, F = .0164121839939073], F1(N,F));
> (%o31) - 3.48165940522449E-13
> (%i32) subst([N = 5.601022146947916, F = .0164121839939073], F2(N,F));
> (%o32) - 9.99200722162641E-16
>
> Hope this helps,
> Robert Dodier
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
> --__--__--
>
> Message: 8
> Date: Wed, 22 Jun 2005 08:51:14 +0300 (EEST)
> From: Nikodemus Siivola
> To: C Y
> Cc: Maxima list
> Subject: Re: [Maxima] Beginnings of package ideas on wiki
>
> On Tue, 21 Jun 2005, C Y wrote:
>
> > (defpackage :maxima-declarations
> > (defpackage :maxima-destructuring-let
> > (defpackage :maxima-compatibility-macros1
> > (defpackage :maxima-compatibility-macros
> > (defpackage :maxima-prerequisites
>
> ...ad nauseam..
>
> Commenting purely as a style and sanity issue, this sounds like a rather
> bad idea. Packages aren't C++ or Java classes, which is what this list
> brings to mind. Neither are they build units, which is what these also
> sound like -- I would expect these to be filenames, not packages.
>
> Having multiple packages for a project the size of maxima is most likely
> a
> good idea, but unless those package delimit functional units things make
> no sense.
>
> I would expect more then a dozen or sopackages to be a mistake unless you
> can really justify each and every one of them: if you can write a short
> description of the functionality provided by a package that makes sense
> to
> other people as well _and_ in relation to other packages, then it
> probably
> is a package. If not, then something is off the track.
>
> > (defpackage :maxima-TeX
> > (defpackage :maxima-plotting
>
> To contrast and compare -- these sound perfectly sensible to me. "TeX
> output routines." "Plotting tools."
>
> Cheers,
>
> -- Nikodemus Schemer: "Buddha is small, clean, and
> serious."
> Lispnik: "Buddha is big, has hairy armpits, and
> laughs."
>
>
> --__--__--
>
> Message: 9
> Date: Tue, 21 Jun 2005 23:56:30 -0700 (PDT)
> From: C Y
> Subject: Re: [Maxima] Beginnings of package ideas on wiki
> To: Nikodemus Siivola
> Cc: Maxima list
>
> --- Nikodemus Siivola wrote:
>
> > On Tue, 21 Jun 2005, C Y wrote:
> >
> > > (defpackage :maxima-declarations
> > > (defpackage :maxima-destructuring-let
> > > (defpackage :maxima-compatibility-macros1
> > > (defpackage :maxima-compatibility-macros
> > > (defpackage :maxima-prerequisites
> >
> > ...ad nauseam..
> >
> > Commenting purely as a style and sanity issue, this sounds like a
> > rather bad idea. Packages aren't C++ or Java classes, which is what
> > this list brings to mind. Neither are they build units, which is
> > what these also sound like -- I would expect these to be filenames,
> > not packages.
>
> I suppose in the strict normal use of lisp packages this is not
> standard practice, but that's not my primary reason for doing this. I
> want to compartmentalize as much of the Maxima code base as possible,
> so that the scope of functions is more easily understood. As a result
> it should be much easier to predict the impact of new changes and
> features both inside and outside the package.
>
> I'm not quite sure I'm seeing the problem - from my point of view I
> WANT Maxima broken down into fine pieces, because those are simpler to
> understand and work with. Perhaps some of the categories can be
> improved, but from my point of view having a lot of them is a very
> desirable thing.
>
> > Having multiple packages for a project the size of maxima is most
> > likely a good idea, but unless those package delimit functional
> > units things make no sense.
>
> Well, the basis for those package names comes from the maxima.system
> groupings of modules, which in turn load specific files. Some can
> probably be consolidated, and over time the structure can be shifted to
> more intuitive arrangements. The thing to do at this point is to get
> things, as much as possible, into self contained units with clearly
> mapped dependancies. That is a much stronger position to work from.
>
> > I would expect more then a dozen or so packages to be a mistake
> > unless you can really justify each and every one of them: if you
> > can write a short description of the functionality provided by a
> > package that makes sense to other people as well _and_ in relation
> > to other packages, then it probably is a package. If not, then
> > something is off the track.
>
> OK, fair enough, but my knowledge of Maxima is insufficient to make
> such arguments for lower level functionality. That's one of the goals
> of this project, to make code relationships clear. I'll add another
> criteria to the above test which comes from the other direction - if
> any package cannot be well defined as to its task and methods used to
> impliment that task (being "the" Maxima package won't count), then it
> needs to be compartmentalized until it CAN be well defined. At the end
> of this we want as transparent a code base as can be managed - Maxima
> suffers quite a bit from not being an easy read for new programmers.
> Personally I expect it will take quite a bit more than a dozen packages
> to achieve the latter, given the complexity of the system. We already
> have three or four even with the current monolithic structure. Plus
> packages defined in share will also bump the count.
>
> > > (defpackage :maxima-TeX
> > > (defpackage :maxima-plotting
> >
> > To contrast and compare -- these sound perfectly sensible to me.
> > "TeX output routines." "Plotting tools."
>
> I would argue the following are also clear, or can be broken down
> further to be made clear:
>
> maxima-numerical - numerical routines
> maxima-simplification - simplification code
> maxima-server - server code
> maxima-language-compiler - Maxima language to lisp translation
> maxima-reader - functions to read in code
> maxima-display - functions to display results
> maxima-documentation - describe, other inline documentation
> functionality
> maxima-integration - integration routines
> maxima-trigonometry - sin, cos, tan, etc. etc. etc.
> maxima-matrix-algebra - routines to handle matricies
> maxima-limits - code for handling limits
> maxima-solve - solve routines
> maxima-debugging - special debugging commands and environments
> maxima-sets - code for handling set operations
> maxima-fortran - fortran routines
> maxima-ordinary-differential-equations - ODE code
>
> Others I would need to look at more carefully, but this is already over
> a dozen. I'm not afraid of a large package list - in fact I think it
> is a necessary and natural reflection of the sheer complexity of
> Maxima. But that's just me.
>
> Cheers, and thanks for the input.
>
> CY
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
> --__--__--
>
> Message: 10
> From: "Vijayendra Munikoti"
> To:
> Date: Wed, 22 Jun 2005 11:00:12 +0200
> Subject: FORTRAN format
>
> Hallo
> Thanks to Robert and Raymond for the patches. In "commac.lisp" patch the
> line (setq string (string-trim ... has one extra right bracket. After
> correcting and loading, it worked. It prints however, in E format. I have
> updated f90.lisp also.
> Now f90(expression) produces numbers in E format.
> I want to write all the expressions in a file in f90 format. I am not
> very
> clear how to go about, since the output of f90(exp) or fortran(exp) juts
> prints on the screen and cannot be accessed. Is there a solution?
>
> Thanking you in advance
> Vijayendra
>
>
>
>
> >>Hallo
> >>I have a huge expression containing numbers, which I intend exporting
> to
> FORTRAN.
> >>Is there a way to change all the numbers in the expression to double
> >>>precision fortran format eg. D0,D1 etc.?
>
> >>BFLOAT(expression) does this with a difference -- it adds B0, B1 ...
> >>Is it possible to change this behaviour?
>
> >>Thanks
> >>Vijayendra
>
>
>
> --__--__--
>
> Message: 11
> From: "Vijayendra Munikoti"
> To:
> Date: Wed, 22 Jun 2005 12:01:00 +0200
> Subject: LOAD problem
>
> Hallo
> I am experiencing a strange problem which I am not able to understand:
> Like I said in my previous messages, I am trying to export MAXIMA
> expressions to FORTRAN.
> So, I loaded the following two lisp files:
> LOAD("C:/Programme/Maxima-5.9.1/share/maxima/5.9.1/src/commac.lisp")$
> LOAD("C:/Programme/Maxima-5.9.1/share/maxima/5.9.1/share/contrib/90.lisp")
> I get the following message:
>
> Warning:
> FUNCTIONP is being redefined.
> Warning:
> BREAK is being redefined.
> Warning:
> GCD is being redefined.
>
> After this, my code exits with the message
> "stdin:1500:Incorrect syntax: then is not an infix operator
> := IF (i = j) THEN. "
>
> Although the code is error free. However, when I do not loade
> commac.lisp,
> my code runs but I cannot convert expressions to F90 format. On the other
> hand, if i load the "commac.lisp" at the end of my file, all the
> variables
> are lost !
> Any idea where I am wrong?
> Vijayendra
>
>
> --__--__--
>
> Message: 12
> From: Barton Willis
> To: Maxima list
> Date: Wed, 22 Jun 2005 06:38:33 -0500
> Subject: compiled code with modedeclare
>
>
>
> Compiled functions that use modedeclare(x,float)
> can cause trouble; an example:
>
> The contents of "try.mac" is
>
> ------------
> f(x):=(modedeclare(x,float),x:float(x),x^2);
> myfloat(x) := float(x);
> g(x) := (modedeclare(x,float), x : myfloat(x), x^2);
> ------------
>
> (%i1) load("c:/maxima/try.mac");
> (%o1) c:/maxima/try.mac
> (%i2) f(-1);
> (%o2) 1.0
> (%i3) g(-1);
> (%o3) 1.0
>
> These are OK. Let's translate try.mac.
>
> (%i4) translate_file("c:/maxima/try.mac")$
> (%i5) load("c:/maxima/try.lisp")$
> (%i6) f(-1);
> (%o6) 1
> (%i7) g(-1);
> (%o7) 1.0
>
> These are OK, but I expected (%o6) to be 1.0 instead of 1.
> The translated code for f is
>
> (PROGN
> (DEFPROP |$f| T TRANSLATED)
> (ADD2LNC '|$f| $PROPS)
> (DEFMTRFUN (|$f| $FLOAT MDEFINE NIL NIL) (|$x|)
> (DECLARE (SPECIAL |$x|) (FLONUM |$x|))
> (PROGN NIL (SETQ |$x| |$x|) (EXPT$ |$x| 2))))
>
> What's the story with (setq |$x| |$x|)? I guess the
> modedeclare tells Maxima that x is already a float,
> so x : float(x) isn't needed?
>
> Now, let's compile the code.
>
> (%i8) compile_file("c:/maxima/try.mac")$
> (%i9) load("c:/maxima/try.o")$
> (%i10) f(-1);
> (%o10) 0.0
> (%i11) g(-1);
> (%o11) 1.0
>
> Yikes! Now f misbehaves.
>
> Question: What is the best way to write a function like
> f so that it doesn't misbehave when it's compiled?
>
> Barton
>
>
>
> --__--__--
>
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>
>
> End of Maxima Digest
>