gmane.comp.mathematics.maxima.general

Re: limit of floor

Ondrej Certik — 2008-07-25T07:18:39

The way to go imho (at least that's what we do in sympy) is to write a gruntz algorithm, that only requires a series expansion and then fix the series expansion of functions floor (et al.). Ondrej

Re: Problems with ONEARGCHECK and TWOARGCHECK

Billinghurst, David (RTATECH — 2008-07-24T23:47:06

airy.lisp was my first lisp contribution to maxima, and a little learning project. There may be bugs. David Billinghurst NOTICE This e-mail and any attachments are private and confidential and may contain privileged information. If you are not an authorised recipient, the copying or distribution of this e-mail and any attachments is prohibited and you must not read, print or act in reliance on this e-mail or attachments. This notice should not be removed.

Naming of the Exponential Integrals

Dieter Kaiser — 2008-07-24T22:46:29

At first I proposed the following names: expintegral_e (n z) - Exponential Integral En expintegral_e1 (z) - Exponential Integral E1 expintegral_ei (z) - Exponential Integral Ei logintegral_li (z) - Logarithmic Integral Li expintegral_si (z) - Exponential Integral Si expintegral_ci (z) - Exponential Integral Ci expintegral_shi (z) - Exponential Integral Shi expintegral_chi (z) - Exponential Integral Chi These names should emphasize that all this functions are sumerized as Exponential Integrals. But to be consistent we have to use for Li the name expintegral_li and not logintegral_li. I have chosen expintegral_li in my last revision of the code. An alternative to the above functions namens would be the following scheme: expintegral_e (n z) expintegral_ei (z) expintegral_e1 logintegral (z) sinintegral (z) cosintegral (z) sinhintegral (z) coshintegral (z) Both schemes seems to be nice. What should we do? Dieter Kaiser

Exponential Integrals - Complex Bigfloat algorithm

Dieter Kaiser — 2008-07-24T22:33:11

I have implemented Bigfloat arithmetic for the Exponential Integrals and some further test for special values including tests for Bigfloatzero. Furthermore I have extended the test file. The numerical results for Complex Bigfloats are verified for all Exponential Integrals within an accuracy of 62 to 64 digits. Remarks: 1. The Bigfloat routine does not add some extra digits to fpprec. So we lost 1 to 2 digits of precision. This can be further improved. 2. There is no optimization for speed. It was my aim to get an algorithm which will work and calculate correct results. 3. The accuracy of the numerical tests of the test file are optimized for my system (GCL 2.6.8). On other systems a lot of the numerical tests could fail or even produce more accurate results. 4. The examples for testing the symmetry give with one exception exact results (0.0 or 0.0b0). Because we have numerical routines that seems to be by accident. Perhaps other compiler can not verify this results. I have attached the code and a t

Re: limit of floor

Dan Gildea — 2008-07-24T22:24:57

I think adding functions to handle floor/ceiling/round to the limit code wouldn't be too hard to do, and could handle almost all expressions that contain those functions. But right now maxima just gives up when it sees any of these three functions inside a limit.

Problems with ONEARGCHECK and TWOARGCHECK

Dieter Kaiser — 2008-07-24T20:03:00

Today I recognized a strange behaviour of the code of ONEARGCHECK and TWOARGCHECK which test the correct number of arguments of a Maxima function. A correct example for the Gamma function: (%i2) gamma(1,2); Wrong number of arguments to gamma -- an error. To debug this try debugmode(true); (%i3) gamma(); Wrong number of arguments to gamma -- an error. To debug this try debugmode(true); But when I test the Bessel J function I get the following: (%i4) bessel_j(1); (%o4) bessel_j(1, #) (%i5) bessel_j(1,2,3); (%o5) bessel_j(1, 2) One more example for the Airy function: (%i7) airy_ai(); (NIL . |$;|) is a cons with an atomic cdr - `simplifya' -- an error. To debug this try debugmode(true); (%i8) airy_ai(1,2); (%o8) airy_ai(1) Is this only a problem of my system? What is wrong? I use gcl 2.6.8 and the Maxiam CVS code on a Windows XP system. Dieter Kaiser

Re: noninteractive and topoly together

Robert Dodier — 2008-07-24T17:31:05

Unfortunately noninteractive is an experimental package at present. It is not strong enough to handle many asksign problems which occur in practice. I am thinking about ways to make it stronger but from what I can tell it is not going to be easy. best Robert Dodier

thinking about merging ECL branch

Robert Dodier — 2008-07-24T16:51:42

Hello, I am thinking about merging the ECL branch (patches-for-ecl-branch) into the main trunk. The ECL branch mostly has a lot of #+ecl conditionalizations so I think it would have no effect on other Lisps. You can see all changes by making a diff wrt to the branch base. I will work on the merge this weekend unless someone wants to convince me otherwise. Comments? best Robert Dodier

Re: [sympy] Re: [sage-support] Re: limit of floor

Ondrej Certik — 2008-07-24T16:50:09

I am fixing this in sympy right now. The way to go imho is just to make sure floor(x).series(x, 0, 5) is correct. (from the right hand side) and from the left hand side. That's all that the gruntz algorithm needs,then it should work, we'll see. Ondrej

Re: [sage-support] Re: limit of floor

Robert Dodier — 2008-07-24T16:47:13

Well, that's obviously wrong. However in more recent versions limit returns noun expressions for floor and ceiling. That's not incorrect, but also not very helpful. Obviously it is desirable to get correct results for discontinuous functions. I'm not sure what is the best way to go about it. It would be easy to wire in special cases for floor(x) and ceiling(x), and that would help, but I don't know whether Maxima can infer results for more complex cases from that. Dan Gildea has been fixing a lot of bugs in the limit code (thanks very much, Dan). Maybe he can comment on this. FWIW Robert Dodier

Re: [sage-support] Re: limit of floor

Richard Fateman — 2008-07-24T15:11:39

It is not clear what you want from the limit program, in general. For example, you refer to directions like left, right, plus, minus. So you mean that limit should only work for f(x) where x is a REAL valued variable approaching a (presumably) real value [or infinity?] Why not allow x to approach a complex value from some arbitrary path, e.g. a spiral? Why not allow x to be a vector, eg. x->[infinity,infinity] or maybe an interval? Typically "limitands" are composed of real-valued analytic functions, but a program could have other more generous specifications. Vladimir Bondarenko typically makes up such generous specifications and when the CAS "fails" claims it is a bug. For example, one might disallow floor() in a limitand, but that would not necessarily be the case. One might allow arbitrary other expressions available in a computer algebra system, including program fragments, like limit( if(f(x)=0) then 1 else 0, x-> a), which may require that one solve an undecidable predicate, etc. So is this a

Exporting wxMaxima output to ordinary word processors.

Christian Jorgensen — 2008-07-23T19:10:54

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

Re: noninteractive and topoly together

Barton Willis — 2008-07-24T14:08:28

-----maxima-bounces< at >math.utexas.edu wrote: ----- You'll get different dummy variables each time you evaluate %i3. That's a necessary nuisance, I think. Either it means the putative solution is spurious or that there is a bug. Here is an example of a spurious solution: (%i15) eq : sqrt(x) - sqrt(5-x) = -sqrt(2)$ (%i16) to_poly(eq,[x])$ (%i17) elim_allbut(first(%),[x])$ (%i18) sol : solve(first(%),x); (%o18) [x=9/2,x=1/2] (%i19) for si in sol do print([si,radcan(subst(si, eq))]); [x=9/2,2/sqrt(2)=-sqrt(2)] [x=1/2,-2/sqrt(2)=-sqrt(2)] If you allow the square roots in sqrt(x) - sqrt(5-x) = -sqrt(2) to each have different definitions, x = 9/2 is a solution. Sorry--I didn't mean to say that "to_poly_solve finds two solutions." I should have said that the "workaround found..." Barton

Re: noninteractive and topoly together

Dan Hatton — 2008-07-24T13:21:46

Thanks Barton. That solved my specific problem nicely. A couple more things FYI below. On Thu, 24 Jul 2008, Barton Willis wrote: (The dummy variables I get seem to be called %g1 and %g2, but I guess this difference is trivial.) Nice. But I wonder what I should read into it if one of the solutions didn't pass this test. Almost. There are also chains of answers (e.g. -+---+--) for which to_poly_solve finds only one solution, or (e.g. -+-0) for which it finds no solution at all.

Re: noninteractive and topoly together

Barton Willis — 2008-07-24T12:28:56

The function to_poly_solve tries to be careful; try this (eq is your equation) workaround: (%i3) to_poly(eq,[phi2])$ (%i4) elim(first(%),[%g0,%g1])$ (%i5) sol : solve(first(%),phi2); (%o5) [phi2=(((48*Sc-48)*cRhat-72*gamma3*Sc+72*gamma3)*thetaR+((72-72*Sc)*cRhat+72*gamma3*Sc-72*gamma3)*thetaF+ ((24*l+72)*Sc-24*l-72)*cRhat-72*gamma3*Sc+72*gamma3)/(Sc^2*cRhat*thetaR+(24-24*Sc)*cRhat*thetaF+ (-l*Sc^2+(24*l+24)*Sc-24*l-24)*cRhat),phi2=(3*cRhat-3*gamma3)/cRhat,phi2=3] (%i11) for si in sol do print([si,radcan(subst(si, eq))]); (%i12) for si in sol do print([si,ratsimp(subst(si, eq))]); So to_poly_solve finds two solutions; depending on some messy inequality, conditionally there is a third solution. Here's a simple example of how to_poly_solve tries to be careful; since -1 + %i isn't in the range of the square root, the solution set of sqrt(x)=-1 + %i is empty: (%

Re: Can I download the maxima5.9.2?

Alexey Beshenov — 2008-07-24T10:02:48

The 5.9.x packages are available from the SF download page: http://sourceforge.net/project/showfiles.php?group_id=4933&package_id=4960 As for 5.9.2, http://downloads.sourceforge.net/maxima/maxima-5.9.2-2.aurox9.2.i386.rpm http://downloads.sourceforge.net/maxima/maxima-5.9.2-2.i386.rpm http://downloads.sourceforge.net/maxima/maxima-5.9.2-2.src.rpm http://downloads.sourceforge.net/maxima/maxima-5.9.2.exe http://downloads.sourceforge.net/maxima/maxima-5.9.2.tar.gz http://downloads.sourceforge.net/maxima/maxima-5.9.2.zip http://downloads.sourceforge.net/maxima/maxima-exec-gcl-5.9.2-2.aurox9.2.i386.rpm http://downloads.sourceforge.net/maxima/maxima-exec-gcl-5.9.2-2.i386.rpm http://downloads.sourceforge.net/maxima/maxima-xmaxima-5.9.2-2.aurox9.2.i386.rpm http://downloads.sourceforge.net/maxima/maxima-xmaxima-5.9.2-2.i386.rpm

noninteractive and topoly together

Dan Hatton — 2008-07-24T10:28:10

Dear All, I've appended a Maxima script below, which (5.15.0 under SBCL 1.0.17) asks a whole bunch of questions (up to eight of them), then comes up with a set of solutions; I haven't explored every possible permutation of answers to the questions yet, but it looks like the same three solutions keep cropping up again and again. Thinking it would be nice to automate keeping track of this, I added load(noninteractive); on the start of the script (either before or after loading topoly_solver). All I got were two long conditional expressions capped off by "then to_poly_solve(%, phi2)", i.e. the solver wasn't actually run (beyond producing its first question). Any ideas, please? Thanks Dan Hatton load(topoly_solver); (((sqrt(3)*phi2-3*sqrt(3))*Sc-2*sqrt(3)*phi2+6*sqrt(3))*cRhat+3*sqrt(3)*gamma3*Sc-6*sqrt(3)*gamma3)*sqrt(-(((phi2^3-198*phi2^2+1161*phi2-1728)*Sc^2+(336*phi2^2-2016*phi2+3024)*Sc-144*phi2^2+864*phi2-1296)*cRhat^2+((72*gamma3*phi2^2-432*gamma3*phi2+648*gamma3)*Sc-72*gamma3*phi2^2+432*gamma3*ph

Re: invocation history stack overflow

Raymond Toy (RT/EUS — 2008-07-23T13:31:59

[snip] FWIW, I tried this with gcl in a fresh maxima. It computes the eigenvectors just fine. Works fine in cmucl too. Ray

invocation history stack overflow

Tamas K Papp — 2008-07-23T09:59:47

Hi, When calculating the eigenvectors of the following transition rate matrix, I encountered the error mentioned in the subject (using imaxima from Emacs). Running maxima from the command line looks like this: (%i1) Q: matrix([-(lee+leu+len), lee, leu, len], [0,-(leu+len),leu,len], [0,lue,-(lue+lun),lun], [0,lne,lnu,-(lne+lnu)]); [ - leu - len - lee lee leu len ] [ ] [ 0 - leu - len leu len ] (%o1) [ ] [ 0 lue - lun - lue lun ] [ ] [ 0 lne lnu - lnu - lne ] (%i2) eigenvalues(Q); 2 2 (%o2) [[- (sqrt(lun + (2 lue + 2 lnu - 2 lne - 2 leu - 2 len) lun + lue

Re: timedate format

John Ogilvie — 2008-07-23T05:29:14

This ISO format is definitely preferable. Conformity with SI convention and practices is highly commended. J. F. Ogilvie On Wed, 23 Jul 2008, Billinghurst, David (RTATECH) wrote:

Re: timedate format

Billinghurst, David (RTATECH — 2008-07-23T03:33:37

I prefer the ISO 8601 format. NOTICE This e-mail and any attachments are private and confidential and may contain privileged information. If you are not an authorised recipient, the copying or distribution of this e-mail and any attachments is prohibited and you must not read, print or act in reliance on this e-mail or attachments. This notice should not be removed.