[sage-devel] Re: Project
On Apr 20, 5:55 pm, mabshoff <[EMAIL PROTECTED] dortmund.de> wrote: > I forgot one important argument here: With ecls you can embed the lisp > interpreter into an external library, hence we would be able to use > Maxima as a library instead of using the inefficient pexpect > interface. I am not sure how much work this would be, but if I were a > Maxima coder I would certainly look into that possibility since it > opens a whole lot of possibilities for Maxima IMHO - totally > independent of Maxima's role in Sage. Aside from just getting stuff linked together (plenty of trouble to start with), the more difficult problem is that Maxima is written with a pervasive assumption that there is someone at the console, e.g you ask for an integral or a limit and Maxima comes back with a question about some parameter. That make interaction with another program very difficult (as I think you know already). I have attempted to resolve this by converting questions into conditional expressions e.g. "Is x positive, negative, or zero?" => if x > 0 then ... elseif x < 0 then ... else It sort of works but there are difficulties. If anyone wants to work on it with me, I'd be glad to have the help. Robert Dodier Maxima developer --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Project
mabshoff wrote: > Well, since the Maxima folks now have told us that they will support > ecls soon the decision has been made on our end to switch to Maxima > +ecls. Michael, I don't mean to rain on the parade, but: I personally am willing to try to resolve the problems compiling Maxima with ECLS, but I can't promise that anyone else is going to be interested. > There is no point in beating the dead horse that is gcl. It has been proposed more than once on the Maxima mailing list to drop GCL. The main issue is that GCL runs on Windows and some other Lisps of interest (SBCL, CMUCL) do not. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage, Maxima, Lisp
On Apr 23, 1:08 pm, "Bill Page" <[EMAIL PROTECTED]> wrote: > Perhaps you have other ideas about how to achieve this kind of > interoperability? I could imagine for example linking Python directly > into the Aldor C run-time system or maybe linking the Python into the > lisp image that runs Axiom? There is an implementation of Python in Lisp called CLPython. There was a message from its developer a day or two ago that he's thinking about porting CLPython to SBCL (it runs on Allegro CL and Lispworks at present). If CLPython could run on SBCL, it could be compiled into the same image as Maxima and then Python could (I guess) be used as the user language for Maxima. I would be interested to see what that's like. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] compiling Maxima by ECL
Hello, I have gotten Maxima (current CVS head + ECL-specific changes) compiled by ECL (current CVS head, release 0.9j won't work). I committed the ECL-specific stuff on the branch patches-for-ecl-branch in Maxima CVS. I merged in a patch posted by Michael Goffioul in 2005 and some stuff I did a few months ago. Many thanks to Michael G for his contribution. I couldn't get the autoconf/automake stuff to work, but I was able to get Maxima compiled by following the instructions in maxima/INSTALL.lisp. The resulting maxima.fas sort of works but the testsuite shows a lot of errors. I haven't looked into it in detail, but it appears that the assume stuff (inferences about sign of expressions) isn't working, and my first guess about that is that all the EVAL-WHEN stuff is dorked up. Incidentally run_testsuite() itself barfs out an error, that the name of a file that needs to be loaded (namely testsuite.lisp) is not a stream. I worked around it by loading testsuite.lisp separately first. I have a couple of motivations for attempting Maxima + ECL. (1) ECL is a potential replacement for GCL on Windows. (2) It appears that the Sage project is interested only in Maxima + ECL. If Maxima continues to be usable through Sage, we might get some bug reports and, who knows, even bug fixes from Sage. I'll look into this some more & let you know if I can resolve anything. I would like to take this opportunity to invite interested parties of any/all projects to try this also, maybe your luck is better. FWIW & HTH. Robert Dodier Maxima developer --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Maxima + ECL status
Hello, I've updated my copy of ECL to current CVS version and Maxima seems to be more broken than it was before. I'll try to figure out what is going on; maybe I am just doing something differently. But I'm curious to know whether anyone else is trying Maxima + ECL. At this point it looks like it is going to be a long haul, and I'm not sure I want to do it by myself. Of course, no one is obligated to help. So: is anyone working on Maxima + ECL ? Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Maxima + ECL status
Carl Witty wrote: > I'd like to give it a try. (I can't commit for a "long haul" myself, > but I could spend some time on it in the near future.) Super -- any time you can invest is greatly appreciated. > Could you explain what the current status is, and how I could > replicate your current setup? Maybe we could set up a wiki page > somewhere? (We could put it on wiki.sagemath.org, if you don't have a > better place.) Well, there's not much to say. The ECL-specific stuff is on the branch patches-for-ecl-branch in Maxima CVS. I think this incantation or something like it should fetch the branch: cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/maxima get -rpatches-for-ecl-branch maxima You'll need to build ECL from current CVS (the 0.9j release won't work). The --enable-smallcons flag for configure is recommended (by the ECL maintainer) and --enable-unicode is discouraged. Following the instructions in INSTALL.lisp (in the top-level maxima directory) up to and including step 4. Then cd src, launch ECL, and try to build Maxima via defsystem (further steps in INSTALL.lisp) or asdf. Sorry if this is too vague; I haven't yet figured out what works. The resulting Maxima program (launched by (cl-user::run)) can do a lot of stuff, but it has nontrivial strangeness. It gets part way through the Maxima test suite (run_testsuite()) before halting with an error. Dunno what's going on there. I think Maxima + ECL works better if the code is interpreted instead of compiled. Perhaps you can verify this. I've cc'd this message to the Maxima and ECL mailing lists. Follow-ups should probably be directed to the ECL list. I'll copy this message, such as it is, to the Maxima wiki for reference. http://maxima.sourceforge.net/wiki Thanks for your interest, & let us know how it turns out. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] progress on Maxima + ECL
Hello, I have committed some more patches for ECL on the Maxima CVS branch patches-for-ecl-branch. With the stuff currently at the end of the branch, I find that (require 'asdf) (asdf:operate 'asdf:load-source-op :maxima) (run) run_testsuite(); runs happily and reports no unexpected errors. The help system works as expected and plotting works OK with plot_format either gnuplot or openmath, but not gnuplot_pipes. So that's all good. (asdf:operate 'asdf:load-op :maxima) compiles all the files without error and (run) launches Maxima, and some things work, but run_testsuite reports many errors. In particular, it appears that factor is completely messed up (returns 0 in many cases) and the assume stuff is completely messed up; between the two of them, those bugs are enough to break a lot of stuff. Dunno what else might be wrong. If someone can verify the stuff above, that would be very helpful. If someone can fix the compilation problems, that would be even better. Please direct followups to the ECL mailing list. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: progress on Maxima + ECL
mabshoff wrote: > Out of curiosity: Did you take today's CVS since the anon ecl CVS > trees were corrupted until about two, three hours ago? I am working with ECL built from anonymous CVS from around May 14. I haven't been able to update from CVS since then; apparently the anonymous CVS server was/is out of date. best Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Maxima license "GPL v.3 or later"?
Disclaimer: I am not a lawyer. Jaap Spies wrote: > See at the end of: > > http://www.math.utexas.edu/pipermail/maxima/2008/011842.html I don't know what is at stake here from the perspective of Sage, but so far as I know the current developers of Maxima are not in a position to change the license by their own agreement. The code base from which the current developers are working was released by Bill Schelter under terms of the GNU GPL v2. (To the best of my knowledge, Schelter never referred to later versions of the license.) Unfortunately Schelter died in 2001. To change the license to anything else, it seems necessary to get approval from Schelter's heirs. If someone wants to contact them, I certainly can't stop them, but I'm not interested in doing it myself. In the absence of such approval, I don't see how any relicensing can go forward. If someone wants to pomote a legal theory under which relicensing is possible, I'd like to hear about it. But from what I can tell, a decision amongst the current developers isn't enough. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Maxima license "GPL v.3 or later"?
William Stein wrote: > In fact looking through the actual source code, it mostly says > "Copyright William F. Schelter" or "See the GNU General Public > License for more details. You should have received a copy of > the GNU General Public License." The top level of the maxima > distribution contains the standard GPLv2 license file, which > is "GPLv2+", since it contains the phrase "If the Program does > not specify a version number of this License, you may choose > any version ever published by the Free Software Foundation." On considering this, I believe you are correct. Although the license Schelter included in his distribution was GPL v2, Schelter never specified the revision number to the best of my knowledge. Therefore (according to the license itself) licensees can choose any version (not just v2+). I don't think that allows present-day contributors to change the license to v2+ or v3+ (i.e. to exclude certain versions). But since v3 is among "any version ever published" it seems like the use of Maxima in Sage is OK. Yes/no/maybe ? best Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Maxima] [sage-devel] Re: Maxima license "GPL v.3 or later"?
On 6/1/08, Andrej Vodopivec <[EMAIL PROTECTED]> wrote: > As I have mentioned in some other thread, even if most of the code is > GPLv2+, there are files which are GPLv2 only: Yeah -- some of those are files which I created. I am willing to change those from GPL v2 to GPL nonspecific. About the others, I guess we will have to identify them and negotiate with each author. I've been meaning for a long time to do a license review sweep through all of the share stuff --- maybe now is as good a time as any. best Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Maxima] [sage-devel] Re: Maxima license "GPL v.3 or later"?
On 6/3/08, Jaime Villate <[EMAIL PROTECTED]> wrote: > so we can continue to develop Maxima as his original author intended > to? I will point out that current developers are on much firmer ground if they consider what Bill Schelter did, as opposed to what he was thinking. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] presentation about Maxima at Sage developer days
Hello, I was invited to the on-going Sage developer days workshop. http://sagemath.org http://wiki.sagemath.org/dev1 I gave a little presentation about Maxima. http://maxima.sourceforge.net/misc/maxima-opinions.pdf Sage is a really exciting project in many ways. I think merging different computational systems is a very useful goal. In Maxima there is a similar trend although less extensive since at present it is required that stuff be translated to Lisp. The new computational stuff for exact linear algebra, modular forms, and other topics is very interesting and a great contribution. Maybe in some form some of that would someday be ported to Maxima. I'm somewhat less excited by the subproject to write new symbolic manipulation code for Sage. Sorry to say it, but it seems like a reinvention of the wheel. Maybe that's unavoidable; and maybe you'll do a better job of it than Maxima! Sage is a great project and it was terrific to meet William Stein and everyone else. Many thanks to William for the invitation. I look forward to further collaboration. best Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] test suites, was: presentation about Maxima at Sage developer days
root wrote: > Are there any other major test suite collections available? At present Maxima includes a copy of Michael Wester's test suite which was the basis for his published review of computer algebra systems from about 10 years ago. We haven't done anything with it but I asked for and received permission from him to release it under terms of GPL and it is now in Maxima CVS. Wester has test scripts for several programs; Maxima CVS only contains the Macsyma test scripts. best Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: working on Sage
William Stein wrote:
> It would likely be possible -- though difficult (maybe not too difficult) --
> to have Sage automatically give all possible answers to Maxima and
> construct a conditional integral expression that gives each possible
> answer for given conditions.
My preference for handling this on Maxima's side is to catch
questions and turn the result into a conditional expression.
Conceptually it is not very complicated but carrying out the program
has various difficulties. I've made an attempt to do it
("noninteractive" package in Maxima) but it's not enough.
I would very much appreciate any help on it.
Also part of the problem is that the assume system in Maxima
is not very strong, and it has bugs. We could use some help on
that too.
I think I;ve made this appeal before --- I'm just trying to take
advantage of the momentary attention to this problem.
best
Robert Dodier
Maxima developer
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: how to handle assumptions
William Stein wrote: > If you answer could you summarize what Maple/Mathematica do > (if you care), and if so why you think whatever you propose is > better than them. Not sure if I am the "you" in question here, but fwiw I don't know what Maple or Mathematica do when there are multiple solutions. best Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: how to handle assumptions
root wrote: > <http://axiom.axiom-developer.org/axiom-website/CATS/> > view the pdf file for "Schaums 14.120-14.124" (schaum5.input.pdf) > See the result on page 3 of the pdf. > > The first integral result returned by Axiom is a list of answers. Hmm. I don't see any indication of the domain in which each result is applicable. Did I miss something? It appears that the ascii art display shows something different from the TeX display. Maybe they're equivalent, I can't tell. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Gap closing or widening to Mathematica?
Harald Schilly wrote: > On Jul 13, 10:50�pm, saucerful <[EMAIL PROTECTED]> wrote: > > I was interested in seeing the performance differences between MATLAB > > and some open source offerings so I googled and came across this: > > http://www.sciviews.org/benchmark/index.html > I have seen this benchmark, it's outdated and i think totally wrong. Aside from being out of date, what's wrong with it? curiously Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] units, was: Suggestion components to add onto SAGE
William Stein wrote: > The justification for ConvertAll would be exactly the justification for us to > *not* use it in Sage, i.e., for Sage unit conversion we would surely want > something that works well in the context of sage itself, e.g., the coercion > model, symbolic calculus, etc. FWIW I've been working on a units package for Maxima (ezunits) which exploits its symbolic functions to make working with units convenient, extensive, and flexible. I claim to have gotten some useful & interesting code at this point. A dimensional quantity like 10 meters is represented as 10 ` m, i.e. a Maxima expression with the operator ` and arguments 10 and m. As usual (for the most part) Maxima carries along such expressions when they appear in algebraic operations, which leaves the door open for us to define results appropriate for dimensional quantities. E.g. product of dimensional quantities => product of nondimensional parts times product of units. Unit conversions are indicated by the `` operator, e.g. 10 ` m `` ft => 12500/381 ` ft. Units are converted by constructing and solving a system of linear equations (after taking logarithms). So far the package as it stands in CVS doesn't have anything beyond algebra, but I was just trying some calculus operations and it looks like integrals and derivatives should work OK. E.g. stuff like diff(x(t) ` m, t ` s) => dx(t)/dt ` m/s, integrate(v(t) ` m/s, t`s, a`s, b`s) => integrate(v(t), t, a, b) ` m. I haven't worked out the details yet. Ezunits also has some functions for dimensional analysis which were adapted from an existing Maxima package, and also a collection of physical constants (CODATA 2006) from NIST. Ezunits exists in previous versions of Maxima but there will be a substantial revision in the 5.16 release which will appear next month. Anyway maybe this is some use or interest. Comments on the CVS version are much appreciated. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: units, was: Suggestion components to add onto SAGE
William Stein wrote: > Since you've clearly been thinking of this from a developer's perspective, > and maybe even spending a lot of time writing code, is there any > chance you could just dump some of your design thoughts in an > email here? I'll try to come up with some coherent description & post it here. >(1) Are the list of all units one uses pretty standard? Is there > a table, say in Wikipedia, with pretty much all of them? Or do > people make up new units in the course of their work or research? Well, from what I can tell in any given field most work is done with a relatively small set of units which are conventional for the field. The union of all units in all fields is fairly extensive though. Any computerized units system would have to include the SI units. Beyond that, there are so-called customary units (feet, pounds, etc) which are still widely used in the US; I am not aware of other non-SI systems in extensive use. I think it's fairly common to see semi-SI units such as MJ/day or mg/kg. I think it's common enough to invent to invent new units like those for convenience. The implication, to me, is that any units system has to be easily extensible, since it's likely that random users would want units that escaped our notice. >(2) Are there *any* difficult algorithms that involve units or is this > mostly a notational and representation problem plus some algebra > and simplification? There's isn't really anything too complicated -- probably the most complex operation in the ezunits package is to solve a system of linear equations. Most of the fun seems to be in the notation and representation. Maybe there would be some interesting algebra problems if only I had more imagination. >(3) Does Maxima, Maple, Mathematica, Matlab or Axiom do anything > particularly cool, surprising or clever involving units? I have looked around to see what Maple and Mathematica have in the way of units, but from what I have seen, there is nothing very exciting. Which is OK --- something boring which just works right would be very useful. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: units, was: Suggestion components to add onto SAGE
Tim Lahey wrote: > I've used the Maple units package and it works fairly well for most > of the calculations I've done with it. It's an add-on package but is > still useful enough to handle most things I've thrown at it. The biggest > problem I've had is the appropriation of symbols for use in units when > I've wanted to use them for something else. The best example is > the use of A for amps when I wanted to use A to represent an area. Yeah, I've thought about that ... I think it would be possible in Maxima at least to prevent evaluation of units (so you could assign something to A and still have A appear as a symbol in units), but that would also prevent stuff like ev(12 ` goats + 5 ` sheep, goats = sheep/2), i.e. evaluate w/ some conversion indicated by binding goats to a value. Maybe that kind of assignment is less important than preventing unintended evaluation of units symbols. Undecided at this point. best Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Why lim goes wrong
On Aug 21, 9:09 am, "William Stein" <[EMAIL PROTECTED]> wrote: > Use the assume command, as illustrated below. You'll eventually get log(2): Looks like this is fixed in more recent versions of Maxima. With current 5.16.2: limit (log (2 + sqrt (atan (x) * sin (1/x))), x, 0); => log(2) (No questions asked.) We can probably thank Dan Gildea for this, as he has done a lot of extremely valuable bug-fixing work on Maxima. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: axiom
On Aug 21, 9:08 am, "Bill Page" <[EMAIL PROTECTED]> wrote: > Perhaps Sage can implement some form of pattern matching and > subsitution such is done by Axiom's rewrite rules? I think that in > many respects these provide a functionality similar to Mathematica. > > There is also a similar re-writing system in Maple (applyrule). Dunno if it matters but there is also pattern matching, substitution, and expression-hacking machinery in Maxima. It's probably well within the realm of possibility to strengthen Maxima's pattern matching by importing an existing Lisp library for that purpose. I haven't looked into the details. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
On Aug 20, 11:18 pm, Tim Lahey <[EMAIL PROTECTED]> wrote: > 1. Commands to parse expressions. Maxima has various expression-hacking functions. Most objects are expressions. > 2. Like M. Hampton, I miss implicit variables. Maxima makes default assumptions about variables, and doesn't require them to be declared before use. This is part of Maxima's general sloppiness but it does make for ease of use. > 3. Somewhat related to #1, is the ability to make new variables/ > function names from old ones. Maxima function concat. > To illustrate this, my Maple code for this is: I glanced at the code and it looks like it should be translateable to Maxima. Maybe I'll try it this weekend. I'm pushing Maxima here for two reasons; one is that the solution for the problems stated here might be close at hand after all. More selfishly, I'd like to get more people using and (I hope) developing Maxima rather than reinventing its wheels. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
William Stein wrote:
> That said, I could certainly see a place in sage for something
> like this:
>
> sage: data = [-1, 2, 3]
> sage: data = ma_eval('data /. x_?(# < 0 &) -> 0')
> sage: data
> [0, 2, 3]
>
> where ma_eval is a function that evaluates a mathematica-style
> expression in the scope of the current Sage
> session, and returns the result as a Python object.
The Mma operators /. #& -> etc are just doing things that might
just as well be represented as ordinary functions.
Wouldn't it be much clearer, and much less hackish, to just make
them functions and stay entirely within Python?
What's the benefit of parsing a string? Aside from the w00t-factor.
Incidentally Maxima has mostly the same set of expression-
mogrification
operators, expressed as function calls.
FWIW
Robert Dodier
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
Tim Lahey wrote:
> 3. Somewhat related to #1, is the ability to make new variables/
> function names from old ones. For example, when in the Calculus of
> Variations, I'll create the variation function with a name based on
> the function to be varied (e.g., v(x,y,z,t) to \delta v(x,y,z,t)).
> I also need this to carry out my EulerLagrange calculation. To
> illustrate this, my Maple code for this is:
Dunno if it really matters, but I couldn't resist the opportunity to
translate the function in question to Maxima ...
euler_lagrange (Lagrangian, variables) := block
([num_list, qv_name, vel_var, qv_subs, qv_unsubs, Lagrange_subs1,
Lagrange_subs2, dL_dqv1, dL_dqv2, dL_dqv, dL_dqvt, dL_dq, dL_dq1,
dL_dq2, dL_dq3, q_name, q_subs, q_unsubs],
/* guessing here that nops = length */
num_list : makelist (i, i, 1, length (variables)),
qv_name : map (concat, qv, num_list),
q_name : map (concat, q, num_list),
vel_var : map (lambda ([x], 'diff (x, t)), variables),
/* guessing here that
* zip(f, a, b) = [f(a[1], b[1]), ..., f(a[n], b[n])
*/
qv_subs : map ("=", vel_var, qv_var),
qv_unsubs : map ("=", qv_var, vel_var),
q_subs : map ("=", variables, q_name),
q_unsubs : map ("=", q_name, variables),
/* guessing here that subs = subst */
Lagrange_subs1 : subst (qv_subs, Lagrangian),
Lagrange_subs2 : subst (q_subs, Lagrange_subs1),
dL_dqv1 : map (lambda ([x], diff (Lagrange_subs2, x)), qv_name),
dL_dq1 : map (lambda ([x], diff (Lagrange_subs2, x)), q_name),
/* not sure why original has map2(subs(...)) here;
* why not just subs ? stagger ahead anyway
*/
dL_dq2 : subst (qv_unsubs, dL_dq1),
dL_dqv2 : subst (qv_unsubs, dL_dqv1),
dL_dqv : subst (q_unsubs, dL_dqv2),
dL_dq : subst (q_unsubs, dL_dq2),
dL_dqvt : map (lambda ([u], diff (u, t)), dL_dqv),
[dL_dqvt, dL_dq]);
The above is untested. As you can see from the comments
I'm not sure what some (maybe most) of the Maple functions do.
What does this prove? Maybe not much, except that in this case
it's possible to do some useful expression hacking without
writing new code for Sage.
FWIW
Robert Dodier
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
Jason Merrill wrote:
> pbe = r^2 p''[r] + 2 r p'[r] == r^2 k^2 Sinh[p[r]]
> diffEqOrder[eqn_, y_, x_] :=
> Max[Cases[pbe, Derivative[o_][y][x] -> o, Infinity]]
> firstOrderForm[eqn_, y_, x_] :=
> Module[{rep, order = diffEqOrder[eqn, y, x]},
> rep = Solve[
> eqn /. {Derivative[o_][y][x] -> y[o][x], y[x] -> y[0][x]},
> y[order][x]];
> Join[Table[y'[o][x] == y[o + 1][x], {o, 0, order - 2}],
>y'[order - 1][x] == y[order][x] /. rep]
> ]
OK --- here is some more or less equivalent Maxima code.
Maxima's pattern construction functions are more verbose.
There isn't any built-in function to get a list of subexpressions
but it's easy to create one.
matchdeclare ([aa, bb], symbolp, ii, integerp);
defrule (r1, 'diff (aa, bb, ii), ii);
defrule (r2, 'diff (aa, bb, ii), aa[ii]);
subexprs (e) := if mapatom(e) then e else [e, map (subexprs, args
(e))];
first_order_form (e, y, x) := block ([n],
n : apply (max, subst (false=minf, map (r1, flatten (subexprs
(e),
ev (subst (y=y[0], apply1 (e, r2)), opsubst=false),
solve (%%, y[n]),
append
(makelist ('diff (y[i], x) = y[i + 1], i, 0, n - 2),
['diff (y[n - 1], x) = rhs (%%[1])]));
> firstOrderForm[pbe, p, r]
>
> {p'[0][r] == p[1][r], p'[1][r] == (k^2 r Sinh[p[0][r]] - 2 p[1][r])/r}
pbe : r^2 * 'diff (p, r, 2) + 2 * r * 'diff (p, r) = r^2 * k^2 * sinh
(p);
first_order_form (pbe, p, r);
=> ['diff(p[0],r,1) = p[1],
'diff(p[1],r,1) = (sinh(p[0])*k^2*r-2*p[1])/r]
> It's just a short shot from here to providing the input in a form that
> would be accepted by the gsl solver, or scipy.
Yes. I believe a combination of symbolic and numerical problem
solving is very powerful.
FWIW
Robert Dodier
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
Tim Lahey wrote: > I presume that Sage can't take a derivative with respect to a function > (Maple can't which is why this code is written this way). By the way, what do you mean by that? What is the operation that you would like to do, but fails? Thanks for the info. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
Tim Lahey wrote:
> \frac{d}{d t}\left(\frac{\partial L}{\partial \dot{q_i}}\right)
> = \left(\frac{\partial L}{\partial q_i}\right)
>
> where i=1,...,n and L(q_i,\dot{q_i},t). Note that q_i
> is a function of at least t. This is the Euler-Lagrange
> equation. It's the basis for most advanced dynamics.
>
> So, I want to differentiate L with respect to \dot{q_i) and
> q_i as if they were just x and t in a normal derivative.
> This is why my code replaces the functions with symbols and
> then takes the derivative with respect to these placeholder
> symbols and then reverses it.
FWIW Maxima likes to see dy/dx in formulations of
differential equations instead of dy(x)/dx so I think maybe
this problem of whether y is a variable or a function doesn't
really come into play; Maxima can always handle y as a
variable. You could ask on the Maxima mailing list to see
if anyone has worked with Lagrangian mechanics in Maxima.
Robert Dodier
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: limit evaluation bug
Dan Drake wrote: > sage: f = sqrt(1-x^2) > sage: g = diff(f, x); g > -x/sqrt(1 - x^2) > sage: limit(g, x=1, dir='below') > +Infinity > > It's a semicircle, so the derivative should go to negative infinity on > the right side. Hmm. Did you mean the left side? I'm probably missing something. There are 2 things going on here. (1) Maxima (current cvs version) has trouble with this problem. (2) Maxima returns the symbol infinity for this limit (and others) which represents complex infinity, as opposed to real positive or negative infinity, which are inf and minf, respectively. About (1), (1a) limit (-x/sqrt(1 - x^2), x, 1); => limit(...) (just rephrased) (1b) limit (-x/sqrt(1 - x^2), x, 1, minus); => infinity (1c) limit (-x/sqrt(1 - x^2), x, 1, plus); => limit(...) (just rephrased) (1a) seems OK although in similar situations sometimes limit returns und (undefined). I guess (1b) isn't incorrect but it could be more precise (namely minf). As for (1c) I would expect infinity. I hope someone from the Maxima project can weigh in on the correct results to be expected from 1a, 1b, and 1c. About (2), if Sage's Maxima interface doesn't distinguish infinity from inf, probably it should. Maybe it does already. If someone can post a bug report to the Maxima bug tracker for this problem, that would be great. HTH Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Why Sage needs var(...) commands unlike Mathematica?
Justin C. Walker wrote: > On Nov 2, 2008, at 00:01 , [EMAIL PROTECTED] wrote: > > Is it possible to avoid need to declare variables with var commands? Sage has adopted Python's evaluation policy, in which it is an error to evaluate an undefined variable. Mathematica adopted Macsyma's policy, in which it is not an error; an unbound symbol evaluates to itself. I don't know where Macsyma got that; in Lisp, at present, it's an error to evaluate an unbound variable, but maybe it was different in ancient times (1970's). Python is an interesting and useful language, but in some ways it isn't well-suited to symbolic processing. Too bad about that. > People coming from a Mathematica background should not assume that > they know all there is to know about how to use a Computer Algebra > System, and instead, read the documentation. This is so obnoxiously wrong, I just don't know where to start. (0) O.p. didn't give any indication of sweeping assumptions. (1) Few people read the documentation before using a program for the first time. It's not a problem, & developers ought to plan for it. (2) If you want people to use Sage, you might attempt to accomodate them, rather than immediately switching into the you're-a-moron mode. (3) The answer to the o.p.'s question isn't in the tutorial or reference manual. Yes, I looked. Did you? I didn't think so. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Why Sage needs var(...) commands unlike Mathematica?
William Stein wrote: > I personally Python well suited to mathematical computation, No problem with any computation involving literal objects. It's the symbolic stuff that's lacking. > and at least the approach in Python regarding undefined variables > is consistent with every other general purpose programming > language I've ever used. Well, this is an opportunity for Sage to do something usefully different, then. > But it is definitely different than Mathematica. Apparently Maple also does not require variables to be declared (to judge by their quick start guide). Neither does Maxima/Macsyma nor MuPAD nor PARI/GP ftr. > What is wrong? That statement Justin made or that he made it at all? It's a classic strawman. There's no evidence whatsoever in the original message that the o.p. (Seberino) has assumed that he knows "all there is to know about how to use a Computer Algebra System". > The first line of section 2 of the tutorial (about calculus) is > "The solve function solves equations. To use it, first specify some variables; > ..." and gives an example of using var. > > I guess this suggests that one needs to use var. This would > be a good place in the tutorial to insert a sentence that if you > don't use var then you will get a NameError, and that this > behavior is different than in Mathematica, and there is no > mode to change this, since it's a basic feature of how the Python > language works. Well, that would be an improvement. The need to declare variables is different from various other packages, not just Mathematica. Some explanation should go in the documentation for var itself as well. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Why Sage needs var(...) commands unlike Mathematica?
William Stein wrote: > Incidentally, if we did allow automatic creation of symbolic > variables, and default calling of symbolic expressions, then > doing something like this would happen > all the time and confuse the crap out of people: > > sage: function_name_with_slight_typo(10) > 10 Well, that's weird, but it's not weird because of automatically creating a variable for function_name_with_slight_typo. Calling symbolic expressions -- that's weird. > I think it would be interesting to have at least the capability > of a mode where variable names are made symbolic if > not previously used, at least if the calling behavior were redefined > as above. This would have be done by somehow parsing the > input, finding all undefined variables, defining them, etc > It's techincaly possible. Maybe Fernando Perez and I can > try to make a demo of something like this at Sage Days 11. I would be inclined to plug in a custom top-level interpreter loop which just catches NameError and instantiates suitable variables and reevaluates the input when that happens. Is there a way to get Python to parse the input without evaluating it? (Isn't there an AST package or s.t.l.t. which could do that?) Then you could (I guess) detect undefined variables without causing side-effects from any part of the input. Just a guess -- I'm no expert on Python. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: yet another talk on Sage
On Nov 5, 10:23 am, "David Joyner" <[EMAIL PROTECTED]> wrote: > I am personally happy with the GFDL 1.3, but some might find it > a bit of overkill. FWIW for Maxima I have pressed for new documents to be licensed under GPL. Having the same license for documents and code means stuff can be freely copied back and forth. Also, from what I can tell GPL covers all the bases for documents; it doesn't help, in my opinion, to bring the extra baggage of GFDL into play. Other licenses might work instead, but, none of them are any better than GPL, from what I can tell. I think even for trivial documents, just as for trivial programs, it is a good idea to state the license terms. You never know what's going to happen to the stuff you create. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] calling symbolic expressions, was: Why Sage needs var(...) commands unlike Mathematica?
William Stein wrote: > Would you consider this weird if you read it in a paper, or > would you know how to interpret it? > > "Let $f = x^3 + x + 1$ and consider $f(10)$." I'm not so sure I know what to do with that. I'm pretty sure I want (x^3 + x + 1)(10) to be (x^3)(10) + x(10) + 1(10). (If the last term were y instead of 1, I'd probably want y(10).) About x(10), I might want that to be x, 10, 10*x, or let it remain x(10). About (x^3)(10), I might want that to be x(x(x(10))) or (x(10))^3. I might want 1(10) to be 1. I probably want x(10) to yield the same as 1(10) if I substitute 1 for x. These considerations lead to different interpretations, most of which differ from the way Sage implements callable expressions, if I'm not mistaken. I don't see a need for Sage to preempt useful and interesting interpretations. Under the circumstances, the right thing to do is to postpone function evaluation until additional context is supplied. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: calling symbolic expressions, was: Why Sage needs var(...) commands unlike Mathematica?
On Nov 5, 10:10 pm, Nick Alexander <[EMAIL PROTECTED]> wrote: > I find this bizarre. I am absolutely certain that I want to view $f$ > as a polynomial in one variable and evaluate it at 10. That's nice. I wouldn't want to stand in your way. What is worrisome here is that you are all too ready to rule out alternatives, which, as pointed out elsewhere in this thread, are not nearly as bizarre as you say. It's rather unmathematical, frankly, to insist that you know the one true interpretation of an ambiguous expression. > I can think of lots of alternate ideas (evaluate everything to > bottom!) but I believe none of them are common. All of the alternatives I suggested are pedestrian. I'm too ignorant to suggest anything exotic. The larger issue is that callable symbolic expressions are a convenience hack; since they are starting fresh, Sage developers can and should steer away from them. I say this after encountering various convenience hacks in Maxima, which, lo, these many decades on, are very hard to banish. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: calling symbolic expressions, was: Why Sage needs var(...) commands unlike Mathematica?
On Nov 6, 1:02 pm, Peter <[EMAIL PROTECTED]> wrote: > "Let $f:R\to R$ be defined by $f = x^3+x+1$." > > I would consider this a (fairly harmless) typo, since the author > surely meant "...defined by $f(x) = x^3+x+1$." What if the author really did mean just what he wrote? How could he express it so that his readers wouldn't mistakenly try to clean it up? I don't think he should bother trying. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Wolfram Alpha and Google (Trendalyzer)
mark mcclure wrote: > There's a lovely little article in the February 2009 issue > of the monthly on using integrals to approximate pi. The > author "discovers" some nice rational approximations of pi > by systmeatically searching through integrals of the > form > > integrate( > (x^m * (1 - x)^n * (a + b*x + c*x^2))/(1 + x^2), > x, 0, 1) > > with Maple. Unfortunately, Maxima (and therefore Sage) > cannot do these integrals. Maybe a different example is needed; Maxima can now compute such integrals. (The code was in CVS at the time and now it's been released.) Maxima's symbolic integration has been greatly strengthened by recent work of Dieter Kaiser and Raymond Toy. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Clarification of Sage and GPL
On May 5, 8:05 pm, Brian Granger wrote: > > A sage worksheet is no more a derived work of Sage than a jpeg would > > be a derived work of Photoshop/GIMP or a .doc file would be a derived > > work of MS Office or OpenOffice. > > I disagree. A jpeg or .doc file is not source code in any sense of > the word, thus the GPL is completely irrelevant (I think we agree on > that). That simply isn't so. To quote the GPL: "This License applies to any program or other work ..." "The "Program", below, refers to any such program or work, ..." FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Clarification of Sage and GPL
Brian Granger wrote: > Are you arguing that jpeg's produced by GIMP are all GPL'd? No. > I agree that it is definitely possible to release "non-programs", such > as JPEGs, under the GPL. OK, I misunderstood. I thought you were claiming just the opposite. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Clarification of Sage and GPL
Gonzalo Tornaria wrote: > Auch... then, if I take GIMP source code, and carefully translate it > 100% into, say... lisp, then the resulting work is not a C++ program, > and therefore not a derived work. Careful. I'm pretty sure a translation (be it from natural language or computer language) is a derived work. IANAL, Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: statistics in sage
dagss wrote:
> Basically I can see Sage being a great place to merge symbolic
> calculations in statistics and data analysis.
Yup.
> sage: a, b = var('a,b')
> sage: sigmasq = Gamma(a, b); sigmasq
> Gamma distribution with parameters a, b
> sage: y = Normal(0, var=sigmasq); y
> Normal distribution with gamma distributed variance
> sage: y.mle(data) # generic maximum likelikehood on arbitrary
> distributions
> {"a":2.32, "b": 12}
> sage: y.draw(10) # draw 10 random samples through e.g. automatic MCMC
> through symbolics
> ...
> sage: z = given(y, [sigmasq, 2]); z
> Normal distribution with variance 2
>
> Or perhaps some syntax candy
> sage: y | sigmasq=2
> Normal distribution with variance 2
Maxima can already do some of this; see the distrib package
(also stats and descriptive). Maybe that could be some inspiration
for Sage.
> I don't know whether something like this could be made powerful enough
> to be useful above a teaching level, but it would definitely be useful
> there. At least it would allow natural operations on what I learnt in
> my Bayesian statistics coure :-)
Agreed 100%. As it happens, symbolic + numerical computation,
specifically for Bayesian inference, is one of my pet projects.
The overall strategy is to pose the problem in symbolic form,
try to push the analysis symbolically as far as possible, then
resort to numerical approximation. I have a paper about that if
you're interested.
FWIW
Robert Dodier
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Wolfram Alpha and Google (Trendalyzer)
mark mcclure wrote: > I did see on the Maxima discussion list back on February 20 > that CVS Maxima could do these integrals. However, I checked > Maxima 5.18.1 on my Mac laptop and the following returns > unevaluated: > integrate((x^m * (1 - x)^n * (a + b*x + c*x^2))/(1 + x^2), x,0,1); Sorry for the late reply. The problem which came up in February was to compute the integrals for specific values of m and n. However Maxima still cannot solve the general problem. Hope this clarifies the situation. best Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Maxima Errors
On Jun 25, 9:58 am, Brendan Rooney > In trying to extend my computations I have run into > a number of Maxima errors that I am at a loss to explain. > These errors occur only after several thousand consecutive > calculations, and fail to repeat themselves when the > offending calculation is immediately repeated. It seems possible that Maxima is running out of memory. In the interest of pushing the resolution forward I'd like to ask you to post an example which triggers the problem. Especially this: > This error arose while trying to calculate the matchings > polynomial for all graphs on 9 vertices. It occured even > after storing the input strings in small files, and > processing them individually. Can you show us one of these small files? You mention that you're working with polynomials. What operations are you doing? There may be different algorithms (selected by global flags) which can run to completion. It may be possible to adjust the memory allocation parameters for Maxima, but that will depend on the Lisp implementation. For what it's worth, GCL seems to use memory less efficiently than other Lisp implementations; I have observed GCL running out of memory on problems which other implementations can run to completion. So maybe switching the Lisp implementation can help, but, I'll guess, not GCL. HTH Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Implementation of Zeilberger and similar algorthms?
Jason Grout wrote: > You can use Maxima to invoke Zeilberger's algorithm, Gosper's algorithm, > etc., using code like in the example in the above mailing list post. The simplify_sum share package calls the Gosper and Zeilberger algorithms, and applies some other methods as well. (The linked-to articles refer only to the simpsum flag, which handles relatively simple cases.) FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Implementation of Zeilberger and similar algorthms?
On Jul 6, 6:16 am, Burcin Erocal wrote:
> I'm reluctant to expose this functionality by default in Sage, since
> Maxima returns wrong results for certain input:
>
> http://trac.sagemath.org/sage_trac/ticket/3587#comment:9
Looks like the problems mentioned there have been fixed in CVS.
(%i5) simplify_sum ('sum (binomial (n, k), k, 0, n));
(%o5) 2^n
(%i6) simplify_sum ('sum (binomial (n, k), k, 1, n));
(%o6) 2^n-1
(%i7) simplify_sum ('sum (binomial (n, k), k, 2, n));
(%o7) 2^n-n-1
(%i8) simplify_sum ('sum (binomial (n, k), k, 2, n - 2));
(%o8) 2^n-2*n-2
Or is that wishful thinking on my part?
FYI the Maxima 5.19 branch is scheduled for Aug 1
with an official release later in the month.
Robert Dodier
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Sage organizational structure, AWOL people
On Jul 30, 10:47 am, William Stein wrote: > Anyway, I would appreciate people sharing their thoughts about how to make > the Sage project more organized with respect to key people vanishing -- > either temporarily or permantly -- from the project. Well, I'm inclined to think you need less organization, not more. The current situation in the Maxima project is that we have multiple administrators, multiple mailing list moderators, and no assigned project roles. (Well, not many. We have a webmaster.) We don't have a formal code review process. Or a project goal statement, for that matter. The advantage of this kind of disorganization is that the presence or absence of any one person doesn't matter so much. I'm the only active project administrator but if I disappeared the others can take over, or if they don't want to, they're already empowered to make someone else an administrator. Incidentally, project administrators are just bureaucrats; they don't set policy or make decisions or stuff like that. Decisions are made informally by discussion on the mailing list. We don't have any formal policies. I find this kind of disorganization quite comfortable; I don't have any trouble figuring out what to do, and, I guess, neither do the other participants. We get a lot of work done. It's a great project. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Patches for building Maxima with ECL
Juan Jose Garcia-Ripoll wrote: > 2) There is a serious bug in src/db.lisp, passing an integer as an > argument to CAR. ECL's new type propagation code has detected it. I > have provided a reasonable fix. I stand in awe. src/db.lisp is probably the most obscure of all the obscure code in Maxima. Well done! I'll try the patch & if all goes well I'll commit it. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: What do we do about the Maxima / ecl / Solaris issues?
William Stein wrote: > +1 Make packages so that everything works, but don't include them in > sage-4.1.1. When will the next Maxima come out? Maybe that's for > sage-4.2 or sage-4.1.2? I'm on the verge of making the Maxima 5.19 release branch (today or tomorrow). I'll try the patches from Juanjo Garcia and commit them before the branch if they work. FWIW the current schedule is 3 releases per year, April, August, & December. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Maxima] Patches for building Maxima with ECL
On 8/3/09, Juan Jose Garcia-Ripoll wrote: > Using these patches, Maxima builds and installs just fine using the > unstable (git/CVS) sources of ECL, which will conform the upcoming > 9.8.1 release. Please take them into consideration. I'll try these patches and if they work OK then I'll commit them for Maxima 5.19. Or if anyone would like to commit the patches then please go ahead. 8^) best Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: What do we do about the Maxima / ecl / Solaris issues?
On Aug 3, 8:56 am, "Dr. David Kirkby" wrote: > So we can expect 5.19 sometime in August, is that correct? Any rough > idea when it might be - first half/second half of the month? I'll start turning out releases on the 5.19 branch -- 5.19.0, 5.19.1, etc. Usually the branch stabilizes after 2 or 3 releases, which takes 2 or 3 weeks. Probably by the end of August we'll have a stable release. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: What do we do about the Maxima / ecl / Solaris issues?
rjf wrote: > The idea that one should "patch" the code in Maxima without knowing > what that code does (or should do) or that someone involved in the > Maxima project should make a substantive program content fix from one > version to another to make the ECL compiler happy --- when no other > compiler is affected is pretty much backward. I don't see any problem here. The patch is harmless and may even do some good so far as I can tell. I've applied it. I don't know what the big deal is. The code was an archaism (probably worked OK in the 70s) and should have been updated like the rest. If anyone was paying attention they could have fixed it long ago. Who cares how the bug was found, at least it's fixed now. We can be grateful that anybody outside the project is still paying attention to Maxima. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New ECL is released - a few issues to consider.
Burcin Erocal wrote: > An spkg with the latest Maxima CVS would make it very easy to test what > possible issues we'll face with the new release. A script to pull the > code from the CVS, build it and install it into Sage would be even > better. :) If someone is going to pull from Maxima CVS, my advice is to pull RELEASE-5_19-BRANCH since upcoming releases (RSN) will, I hope, differ only minimally from whatever you get. Some of the bugs mentioned might have been fixed already, I haven't checked. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New ECL is released - a few issues to consider.
Dr. David Kirkby wrote: > I'm not a great user of CVS. Can you give me the command for getting > that branch? cvs -d :pserver:anonym...@maxima.cvs.sourceforge.net:/cvsroot/maxima get -r RELEASE-5_19-BRANCH maxima grabs the branch version of the CVS module named maxima (incidentally creating a new directory named maxima in the current working directory). I'm planning to tag Maxima 5.19.0 and create tar.gz and rpms so maybe that obviates the need for CVS. Be advised it's likely there will be a few more 5.19.xx releases. HTH Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New ECL is released - a few issues to consider.
I have tagged version-5_19_0 in CVS and created tar.gz and rpms and uploaded them to SF. See: http://sourceforge.net/projects/maxima/files/ Likely there will be 5.19.1 and maybe .2 later this month. HTH Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Maxima] Possible problem with elliptic_eu in Maxima 5.19.0
On 8/9/09, Dr. David Kirkby wrote: > sage: elliptic_eu (0.5, 0.1) > Expected: > 0.496054551287 > Got: > 0.495848403419 Current CVS Maxima + Clisp + Linux yields .4960545512865969. Last week CVS + ECL + Linux yields .4960545512865966. As with the other elliptic_e problem, my first guess is that ECL calls C libraries which yield different results. The above was generated on Solaris, right? Maybe someone can try it on other systems. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
Re: [Maxima] [sage-devel] Doctest failure solving an equation solve(Q*sqrt(Q^2 + 2) - 1, Q)
On 8/9/09, Dr. David Kirkby wrote: > Maxima 5.19.0 http://maxima.sourceforge.net > (%i1) load(topoly_solver); domain:complex; Well, this is part of the problem. The script to load is to_poly_solver, not topoly_solver. At present there is both to_poly_solver.mac and topoly_solver.mac. I don't know what the difference is, or whether both are needed. If topoly_solver isn't needed, we should axe it. If it's needed, we should rename it. Barton? best Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
Re: [Maxima] [sage-devel] Doctest failure solving an equation solve(Q*sqrt(Q^2 + 2) - 1, Q)
On 8/9/09, Barton Willis wrote:
> $ ./maxima-local
> Maxima 5.18post http://maxima.sourceforge.net
>
> (%i2) load("to_poly_solver.mac")$
> (%i3) display2d : false$
>
> (%i4) to_poly_solve(q*sqrt(q^2+2)-1,q);
> (%o4) %union([q = -1/sqrt(1-sqrt(2))],[q = 1/sqrt(1-sqrt(2))],[q = 1/sqrt
> (sqrt(2)+1)])
Unfortunately this isn't right either. The first solution is spurious, isn't it?
float(subst(q = -1/sqrt(1-sqrt(2)), q*sqrt(q^2+2)-1)) => - 1.999
Thanks for your help
Robert Dodier
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: [Ecls-list] How might this elliptic_e issue on SPARC hardware with ECL be debugged?
On Mon, Aug 10, 2009 at 2:22 AM, Juan Jose Garcia-Ripoll wrote: > The way to determine whether it is the compiled code that is > responsible is to execute the same function interpreted and compiled. > But of course, for that we need the particular expression that Maxima > is using. The code in question is function ELLIPTIC-E in maxima/src/ellipt.lisp. (Note that there are several similarly-named functions in there, so be careful.) Thanks for your help, Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: How might this elliptic_e issue on SPARC hardware with ECL be debugged?
On Aug 10, 11:29 am, David Kirkby wrote: > Is there a test-suite of some sort for Maxima (outside that in Sage of > course)? run_testsuite(); runs Maxima's collection of tests. run_testsuite(tests = [rtest1, rtest2, ...]); runs a subset of the tests. ? run_testsuite says more about options. HTH Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Test failures with sage-4.1.1.rc0 with Maxima 5.19.0
Dr. David Kirkby wrote: > sage: A.eigenvectors() > Expected: > [[[2,11],[1,2]],[0,0,1],[0,1,1/3]] > Got: > [[[2,11],[1,2]],[[[0,0,1]],[[0,1,1/3 eigenvectors now tries to present more detail in its return value. ? eigenvectors describes the return value. See the Maxima mailing list archive for the story --- search for "eigenvector patch" or something like that. HTH Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: units
On Aug 11, 4:29 pm, William Stein wrote: > I just wanted to let people know that David Ackerman -- a UW student who > took my course on Sage last quarter -- is working (funded by NSF) on > creating a "units package" for Sage right _now_. If anybody has any > pseudo-sage code that involves units that they wished work, please post it > to this thread. What do you want units to *do*? I'm assuming you mean physical units, not something algebraic. I'm rather fond of the ezunits package in Maxima. (Disclaimer: I wrote it.) I tried to exploit symbolic computation in useful ways; I'll let you be the judge of it. * a quantity and its units comprise an expression which can be mangled in the usual ways * clear, terse notation for units and unit conversion * quantities can be anything (symbol, list, matrix, etc) * units are ordinary symbols, need not be declared before use * usual lazy evaluation of arithmetic on quantity + units * unit conversion = solving equations * favor exact quantities (not automatically floatified) * symbols can be declared to have units * includes dimensional analysis * includes a list of physical quantities represented as symbols with units and other properties * derivative and integral of quantity + units via pattern matching (still working on this one) ?? ezunits and ?? physical_quantities finds the documentation. demo(ezunits) shows some examples. Maybe a Sage units package could do something similar. FWIW Robert Dodier --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel?hl=en -~--~~~~--~~--~--~---
[sage-devel] Re: units
William Stein wrote:
> Maple example is:
>
> convert(4.532, 'units', 'N'/'m'^2, 'lb''ft'/('s'^2'ft'^2))
> In Mathematica it would be basically:
>
> Convert[4.532*Newton/Meter^2, Pound * Feet/(Second^2 * Feet^2)]
>
> and in Sage it will be
>
> sage: from units import newton, meter, pound, feet, second
> sage: a = 4.532*newton/meter^2
> sage: a.convert(pound*feet/(second^2*feet^2))
Well, while we're doing the Rosetta stone here ...
load (ezunits);
4.532 ` N/m^2 `` lbm*foot/(s^2*foot^2);
=> 3.045884688 ` lbm/(foot*s^2)
Differences:
(1) separate units from quantities
(right & left sides of backtick)
(2) concise notation
(3) conventional abbreviations
(4) conventional capitalization
Robert Dodier
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: units
William Stein wrote: > suggested doing almost precisely what Robert Dodier keeps telling us > to do, which is make the different units just be symbolic variables, Well, in addition to implementing units as symbols, it greatly simplifies the whole business to keep the units separate from the quantities, instead of smashing them into the same multiplicative expression. Otherwise you have trouble distinguishing units from other terms. (You're going to allow symbolic quantities, not just numbers, right?) > * a very big list of different standard units (e.g., Foot, > Mile, Meter Second, etc.), which are all literally just symbolic > variables. I think it's fairly important to keep the names of things close to what people would scribble on a piece of paper. Unconventional capitalization and having to write out every name is going to make it clumsy to use. > sage: from units import mega, kilo, byte, second, giga, minute > sage: n = 94959 * kilo*byte > sage: n.convert(mega*byte) I recommend against mega, kilo, etc. Just append Mb, kb, etc to your list of conversions w/ Mb = 10^6*b, kb = 10^3*b, etc. Otherwise you get megas and kilos floating around in the units -- depending on the canonicalization of multiplicative expressions you'll get foo*mega where foo is some unit. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: units
William Stein wrote: > We will just do whatever Mathematica does, unless somebody can come up > with a good argument while the Mathematica design is nonoptimal. Hmm. I wonder what it would take to talk you out of it. I claim that you're better off copying ezunits instead. Try demo(ezunits); in a recent Maxima release (5.19 if you have it) and tell me if you still prefer Mathematica. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: units
William Stein wrote: > Mathematica's design spells out the units instead of using the > conventional abbreviations. I think that makes a lot more sense for > Sage as well, since it's much more explicit, and it is very easy to > confuse say "N" (for Newton's) with say "N" for numerical_approx. Agreed. That's a good argument for separating units from quantities in an expression. Then you can tell without ambiguity which symbols are supposed to be units. best Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Serious bug in integral using Maxima?
William Stein wrote: > Unless you can give a explanation of what you want integrating wrt x^2 > to mean, I think we should also raise an error in Sage. That would be unfortunate. Faced with some unrecognized construct, the mathematical thing to do is to just leave it be. Whether it's meaningful is for the user to decide. You don't know what integrate(f(x), g(x)) means. Why not let someone else come up with an interpretation? Why must you close that door? Incidentally, integrate(f(x), g(x)) = integrate(f(g^(-1)(y)), y), when g^(-1) is well defined, seems plausible. I'm not saying Sage should apply such an identity, only that Sage should not prevent the user from applying it. I agree that Maxima's result for integrate(f(x), x^2) is spurious. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
Nils Bruin wrote: > 7. The main drive for using ecl-as-a-library in sage is to get a > faster interface with Maxima. If all options above turn out to involve > a lot of work or are expensive to maintain, perhaps we need to find > another way of speeding up the interface. As a side effect, we already > have maxima-as-a-library in ecl now. Processes can communicate > efficiently in various ways. Shared memory? Send data info through a > pipe? With a little programming on both the sage and the ecl side, we > could make a binary communication protocol. Definitely not as > satisfying a solution as a library interface, but perhaps good enough. Thanks for your work on this topic, I know it isn't easy. Best of luck to you. There are a few things to bear in mind. (1) Maxima was originally written with a general assumption that someone is sitting at the console. This is the origin of the asksign stuff. Interactive features (mostly asksign, also printing error messages (instead of throwing something), are the major items in Maxima) make it difficult to write programmatic interfaces. Even if you solve the communication problem, you'll still need to somehow handle the interactive stuff. I've made an attempt to work around the interactive stuff but it doesn't always work as intended. Btw I wouldn't mind getting some help on it. (2) There are probably some substantial chunks of Maxima which you'd be better off omitting. E.g. if you can somehow talk to Maxima directly, you can omit the parser. I'm trying to make some tentative steps toward organizing Maxima to be more easily decomposable. I wouldn't mind some help with that too. (3) For the most part, Maxima has a very simple internal format for expressions. A general expression foo(a, b, c) is represented pretty much as ((FOO) A B C) in Lisp. Infix and postfix operators in Maxima are represented as prefix operators in Lisp, e.g. a + b => ((MPLUS) A B) . If you call Maxima directly from outside presumably you'll get some C object which stores the Lisp expression. Seems like it should be easy to traverse those in C code. However, there are some objects, notably a special representation for polynomials, which are not so simple. Probably the easiest way to deal with those is to convert them to their so-called display representation, which is the simple ((FOO) A B C) scheme above. (1) is the most important, (3) not so much, and you can ignore (2). I mention here that I'd like help on (1) and (2) because it's of interest mostly to outsiders; within Maxima it doesn't make much difference. Hope this helps in some way. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
On 8/23/09, William Stein wrote: > In fact, I am mildly surprised that the above two timings between ecl > and maxima are so different. I wonder why it is an order of magnitude > faster to compute "(+ 1 2)" than to compute "(MEVAL #$ 1 + 2$)". > Perhaps in the second case the Maxima parser has to parse "1+2"? Well, the Maxima parser is slow, but also (MEVAL '((MPLUS) 1 2)) goes through the simplifier, which eventually calls (+ 1 2) as a special case. The simplifier attempts to apply various identities, so it's really much more complex than just adding two integers. I suppose that adding numbers is an important enough special case that some effort could be spent trying to speed it up. But most of the fun is in symbolic stuff, so that's probably why it hasn't been done yet. Not sure in this case whether the parser or simplifier dominates. > Robert Dodier -- do you have any crazy ideas why Maxima might get > slower to do the same thing over time? Is it caching all output > somewhere? What other caching might be going on? This kind of stuff drives me nuts ... It appears the problem is that Maxima is keeping a list of all input streams that have ever been opened, and traversing the list every time an input line is parsed. I'm guessing that Sage creates a little input file each time it calls Maxima or something like that which creates a new input stream every time. (In that case a work-around is to avoid creating so many new input streams. Maybe open a socket and send stuff through that?) That is in the code which annotates input with debugging info. Try this: either edit maxima/src/nparse.lisp and clobber the existing definition of ADD-LINEINFO with: (defun add-lineinfo (x) x) or, somehow define ADD-LINEINFO in a running Maxima session. I would try this: :lisp (defun add-lineinfo (x) x) but istr you had trouble with that, so how about ?add\-lineinfo (x) := x; translate (?add\-lineinfo); That's a long shot -- define a Maxima function by the same name first, then tell Maxima to translate it to Lisp. Worth a try. FWIW & HTH Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
> On Sun, Aug 23, 2009 at 11:38 PM, Nils Bruin wrote: >> The slowing down has nothing to do with the sage interface, but >> probably with the macro #$...$ The #$ macro constructs a string input stream and eventually calls ADD-LINEINFO so it suffers from the bug I mentioned in a previous message. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
On 8/24/09, William Stein wrote:
> I wonder -- if Maxima's basic arithmetic -- e.g., simplifying 1+2 --
> is super slow for some abstract reason, I wonder if it is taking
> longer and longer to compute the next prompt number. That would be
> pretty funny. Is there any way to turn off the prompt numbers?
Hmm, my guess is that since Maxima by default maintains a list of
all previous inputs and outputs, it might take longer and longer to
append to that list ... Within Maxima, try nolabels:true; (constructs
and displays labels but doesn't construct the list).
Or: put print(elapsed_real_time()); in your script and load("myscript.mac");
(parses and evaluates all the stuff in the script but doesn't create
labels).
HTH
Robert Dodier
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
On Aug 24, 2:11 pm, Nils Bruin wrote: > On Aug 24, 7:55 am, Robert Dodier wrote: > > > The #$ macro constructs a string input stream and eventually > > calls ADD-LINEINFO so it suffers from the bug I mentioned in > > a previous message. > > The $NOLABELS variable seems to live in local scope somewhere, and > hence setting it does not affect the detoriation in the #$...$ macro: Well, there are two separate problems. #$ tickles the bug in ADD-LINEINFO, clobbering ADD-LINEINFO should fix it. Entering a lot of lines of input tickles the labels bug, nolabels:true should fix it. Either one or both could have come into play in the various examples that have been posted. best Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Dangerous mixing of different domains for symbolic variables
FYI the Maxima functions conjugate, realpart/imagpart, & cabs/carg have been revised recently. Maybe you can try it with the most recent version (5.19.2). For the purposes of debugging I think it's best if you use Maxima directly instead of going through Sage. On Sep 2, 5:49 am, Golam Mortuza Hossain wrote: > This seems to be happening because maxima(via simplify) > treats variables as real whereas pynac treats as complex. FWIW in order for conjugate & friends to recognize variables as complex, probably it is necessary to declare them as such (i.e. declare(foo, complex)). I think domain:complex won't have the same effect. Maybe Sage is already calling declare. HTH Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Prototype library interface with Maxima/ECL
Nils Bruin wrote: > WARNING: ecl is written to provide only one instance of its workspace. > So whatever code is run will have to play nice with other components. > In particular, it is not possible to have two maxima instances running > in the same processes. I don't know how much global state maxima > relies on. Probably by carefully encoding symbols, this problem can be > minimized. Maxima has a lot of unorganized global state -- just a lot of so- called special variables. So there isn't any way at present to have multiple independent instances in the same ECL process. At present all Maxima symbols are in the package (i.e. namespace) named MAXIMA. It seems theoretically possible to create a new package when Maxima is launched and define all symbols in that new package. Then separate instances would have separate namespaces. The easiest way to get independent instances is via fork/exec. I think ECL has those and other POSIX-ish functions. Dunno if they work on Windows, if they exist. Thanks for your work on the Maxima/ECL/Sage combo. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Statistics in Sage
Carlo Hamalainen wrote:
> So what do you think about this patch?
> http://trac.sagemath.org/sage_trac/ticket/6827
Some random comments on
http://trac.sagemath.org/sage_trac/attachment/ticket/6827/probability_distribution.patch
Feel free to ignore this ranting.
757 def cum_distribution_function(self, x):
If anything is spelled out, seems like it should be "cumulative".
That said, in English "cdf" or "CDF" is a widely-understood
abbreviation for cumulative distribution function.
758 """
759 Evaluate the cumulative distribution function of
760 the probability distribution at ``x``.
I guess x must be a number. If I were using this code I would
really like for x to be a symbol too.
761
762 EXAMPLE::
763
764 sage: T = RealDistribution('uniform', [0, 2])
Selecting the type by a string seems clumsy. Why not make
Python work for you? e.g. T = distributions.uniform([0, 2]) .
I guess you have RealDistribution here to indicate that the
support of the density function is a subset of the reals.
You can't exploit that programmatically: what subset is it,
exactly? All of R, an interval, zero to infinity, what?
Better to just indicate the support separately. e.g.
uniform.support => interval or product of intervals,
gaussian.support => all of R (however that's indicated),
discrete.support => explicit enumeration (or implicit if you
are clever), etc.
(The reason I'm getting worked up over support is that it can
be exploited to formulate an integral of foo(x)*pdf(x) where
foo is a loss function and pdf(x) is a density. This is a computation
of central importance in decision theory. You want people to use
Sage for decision theory, right? There are various other integrals
of interest, for which you'd need to know the support. Bayesian
inference is all about the integrals. You want people to use Sage
for Bayesian inference, right?)
765 sage: T.cum_distribution_function(1)
766 0.5
767 """
768 if self.distribution_type == uniform:
769 return sage.rings.real_double.RDF(gsl_cdf_flat_P(x,
self.parameters[0], self.parameters[1]))
770 elif self.distribution_type == gaussian:
771 return sage.rings.real_double.RDF(gsl_cdf_gaussian_P
(x, self.parameters[0]))
772 elif ...
This if--elif--elif-- ... seems clumsy. Once the type is selected,
shouldn't you try to avoid branching to find the right function to
call?
Also, the purpose of each parameter is obscured here.
If uniform, gaussian, etc were classes in a package of distributions,
each one could have named parameters according to what's
appropriate for them (a, b, mu, sigma, whatever).
I've probably misunderstood what's going on here, if so, feel
free to flame me as needed.
FWIW
Robert Dodier
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Statistics in Sage
William Stein wrote: > so if you could say more about what you might > want such a "nice module" to do, it would be very useful! Well, in order to have some functionality above and beyond what R or other numerical systems offer, I think you should emphasize symbolic computation. Wrapping numerical functions is nice but doesn't offer anything fundamentally different. Making it possible to do statistical stuff with symbolic or mixed symbolic-numerical computations would be very exciting and useful. Maybe you're already working on that, I can't tell. If so sorry for the bother. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Behavior of solve
On Oct 1, 9:33 am, Stan Schymanski wrote: > Would it be hard to write a routine, which answers all of maxima's > questions with all possible answers and creates a new solution branch > for each answer? I attempted, some time ago, to automate the question-answer business; the result is the "noninteractive" add-on package. It sort of works, but it's easy to find cases for which it fails. Some successful cases and some failures are stated in the comment header of noninteractive.mac (in the Maxima distribution). The general strategy was to intercept questions and generate the alternatives and re-evaluate under each alternative. That way it's not necessary to change the code at all of the places at which questions are generated. I considered that also and decided against it. If anyone is interested, I would very much appreciate your help. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: finding arclength around a circle hangs maxima
On Oct 16, 2:23 pm, Jason Grout wrote: > I'm not on their list. I hope Robert Dodier or someone else sees this. Probably it's best to submit Maxima bugs to the bug tracker. http://sourceforge.net/tracker/?func=browse&group_id=4933&atid=104933 FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Can Sage solve inequalities?
ma...@mendelu.cz wrote: > does Sage solve inequlitites? According to Maxima mail list ( > http://thread.gmane.org/gmane.comp.mathematics.maxima.general/28497/focus=28530 > ) Maxima can do at elast someting in this area. I was not able to find > out, wheather Sage can somehow solve ineqaulities - via maxima or via > another way. Can it? Maybe the Maxima share package fourier_elim is useful to you. There is no documentation, but there are some examples in rtest_fourier_elim.mac. Also look in the mailing list archive for some mention of it. I'm sure the author (Barton Willis) would be happy to answer questions posted to the mailing list. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Building Maxima (on ECL) on Itanium
On 10/24/09, William Stein wrote: > I can't get Maxima--5.19.1 to build on Itanium on top of ECL. The > build fails with: > > ... > ;;; Emitting code for DO-MERGE-SYMM. > ;;; Emitting code for DO-MERGE-ASYM. > ;;; Internal error: # > ; - Loading binary file "binary-ecl/clmacs.fas" An error occurred > during initialization: clmacs.lisp has a lot of floating point stuff in it, to calculate extreme values and what-not. Do you have a working build from an earlier version of Maxima? If so, try :lisp (load "path/to/clmacs.lisp") in Maxima. That should fail with a more informative message. If you don't have a working version, try reverting clmacs.lisp. I don't know how far back you'll have to go. Sorry I can't be more helpful, Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: maxima: too many contexts
> kk = 1.0
> ll = 10.0
> npi = N(pi)
> var('z, zd, zl, zg, zz')
>
> dz = 1.0
> zs = pylab.arange(0.0, ll+0.5*dz, dz)
>
> f1 = lambda z: z*(ll-z)
>
> ghomo = lambda zl, zg: 2/ll*sin(kk*zl)*sin(kk*(ll-zg))/(kk*sin(kk*ll))
> gfourn = lambda z, zd, n: sin(npi*n*z/ll)*sin(npi*n*zd/ll)/((npi*n/ll)^2 -
> kk^2)
>
> def uhomo(z):
> return N(integrate(ghomo(zl,z)*f1(zl),zl,0,z) +
> integrate(ghomo(z,zg)*f1(zg),zg,z,ll))
> def ufourn(z,n):
> return [N(integrate(f1(zd)*gfourn(z,zd,nn),zd,0,ll)) for nn in range(1,n)]
>
> print ufourn(2.3, 8)
Dunno what's going on here, but when I try this in Maxima 5.19.2
it works OK (I get a list of values from ufourn).
I can post a session log later if there is interest.
Robert Dodier
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: maxima: too many contexts
OK, here's the input I tried: kk:1; ll:10; dz:1; ghomo(zl,zg):= 2/ll*sin(kk*zl)*sin(kk*(ll-zg))/(kk*sin(kk*ll)) ; gfourn(z,zd,n):=sin(npi*n*z/ll)*sin(npi*n*zd/ll)/((npi*n/ll)^2 - kk^2) ; uhomo(z):=integrate(ghomo(zl,z)*f1(zl),zl,0,z)+integrate(ghomo(z,zg)*f1 (zg),zg,z,ll); ufourn(z,n):=makelist(integrate(f1(zd)*gfourn(z,zd,nn),zd,0,ll),nn, 1,n); f1(z):=z*(ll-z); npi:%pi; and with this I get: (in Maxima built from CVS recently) ufourn(23/10,8); => [4000*sin(23*%pi/100)/(%pi^3*(%pi^2/100-1)),0, 4000*sin(69*%pi/100)/(27*%pi^3*(9*%pi^2/100-1)),0, 32*sin(23*%pi/20)/(%pi^3*(%pi^2/4-1)),0, 4000*sin(161*%pi/100)/(343*%pi^3*(49*%pi^2/100-1)),0] float (%); => [-94.65540344672326,0.0,-35.36737678051993,0.0, -.3192995340015049,0.0,-0.0922486943844007,0.0] Note that I put off the numerical stuff to the very end. Maxima is more comfortable with rational numbers. On Dec 3, 1:24 pm, kcrisman wrote: > >The call to trigreduce is the key point here. It modifies the > >integrand so as to avoid triggering the MONSTERTRIG bug. > > Did this bug ever get fixed (I ask out of ignorance)? Could this be > related, assuming it did get fixed? Yes, I think it was fixed. Yes, it could be related. > PS, not necessarily relevant: On the Maxima lists, it seems this is > set at 50 at compile time. Can one do the following suggestion (taken > from the list) later? It may not help, of course, if there really is > a horrible loop. I don't think that would help. "Too many contexts" has been an indication of some kind of bug every time I've seen it. best Robert Dodier -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: [Maxima] Maxima stats huge numbers of files at startup?
On 12/10/09, William Stein wrote: > 1. "maxima opens the root directory / and stats each file found there. > Then it does the same thing for the /u (home) directory. The sys > admin believes the bottleneck is the slow response of doing a stat on > each NFS home directory, especially slowed down by the home > directories that are remotely NFS mounted from across the country." My first guess is that the Maxima build was misconfigured and Maxima doesn't have the right value of *MAXIMA-SHAREDIR*. What does "maxima --directories" report? Maxima tries to construct the list of share directories at run time. I'm guessing it's looking at / in the mistaken belief that it's the top of the share directory. > 2. The user reports that "maxima reads the file > local/lib/ecl-9.10.2/sysfun.lsp one character at a time doing 72K > read() calls of one character each. The sys admin doubts that is anywhere > near the > problem of the NFS stat calls, but it does seem inefficient." Well, when I try it, I see sysfun.lsp being read in blocks of 8 K. Dunno why it would try to read it one byte at a time. Maybe ECL tried to determine a suitable block size and failed? Just a guess. FWIW Robert Dodier -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] ECL reads sysfun.lsp one byte at a time, was: Maxima stats huge numbers of files at startup?
On 12/10/09, William Stein wrote: > 2. The user reports that "maxima reads the file > local/lib/ecl-9.10.2/sysfun.lsp one character at a time doing 72K > read() calls of one > character each. The sys admin doubts that is anywhere near the > problem of the NFS stat calls, but it does seem inefficient." OK, I've confirmed this w/ a recent version of ECL (9.12.2). It didn't happen with an older version (I don't remember which version). I am working on Linux with an ordinary file system (not NFS). Other calls to read have block size = 512 or 1024 or 8096. Dunno what's going on. Not really so much of a problem, but it is a curiosity. FWIW Robert Dodier -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: [Maxima] Maxima stats huge numbers of files at startup?
On Tue, Dec 15, 2009 at 11:37 AM, William Stein wrote: > (%i1) :lisp *maxima-sharedir* > > /home/wstein/build/sage/local/share/maxima/5.19.1/share > (%i1) :lisp (directory (pathname (concatenate 'string *maxima-sharedir* "/"))) > > (/scratch/wstein/build/sage/local/share/maxima/5.19.1/share/) So far so good > (%i1) :lisp (share-subdir-list) > > Maxima encountered a Lisp error: > > The function SHARE-SUBDIR-LIST is undefined. Oops, it should be (share-subdirs-list) . Robert Dodier -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: [Maxima] Maxima stats huge numbers of files at startup?
On Tue, Dec 15, 2009 at 11:42 AM, William Stein wrote: > (affine algebra algebra/charsets algebra/solver calculus colnew colnew/lisp : : : > orthopoly physics simplification sym tensor trigonometry utils vector) Well, that looks right. I don't see any indication that Maxima was searching all of / . Do you see Maxima looking in all of / in the calls to stat? If not, what do you get for the above steps if you run it on a system in which Maxima searches all of / ?? FWIW Robert Dodier -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] announcement: Maxima 5.20
Please distribute this message as you see fit. Announcing Maxima 5.20 Maxima is a GPL'd branch of Macsyma, the venerable symbolic computation system. Maxima 5.20 is a bug fix and feature enhancement release. The current version is 5.20.1. Maxima has functions to work with polynomials, matrices, finite sets, integrals, derivatives and differential equations, linear algebra, plotting, floating point and arbitrary-precision arithmetic, etc. Maxima can run on MS Windows and various flavors of Unix, including MacOS X. There is a precompiled executable installer for Windows, RPM's for Linux, and source code tar.gz. Maxima is implemented in Common Lisp; several Lisps can compile and run Maxima, including CMUCL, SBCL, Clisp, GCL, and ECL. The Maxima project welcomes new participants. You can contribute in several ways: reporting bugs, fixing bugs, writing new add-on packages, revising core functions, user interfaces, documentation, Why not see what's happening on the mailing list and consider how you might contribute to the project. Thanks to everyone who contributed to the 5.20 release. Special thanks to Dieter Kaiser for his extensive, excellent contributions on a variety of topics. Regards, Robert Dodier Maxima developer and 5.20 release manager Project page: http://sourceforge.net/projects/maxima Documentation: http://maxima.sourceforge.net/documentation.html Bug reports. Please create a Sourceforge login before filing a bug report. http://sourceforge.net/tracker/?group_id=4933&atid=104933 Mailing list. Please sign up before posting a message. http://maxima.sourceforge.net/maximalist.html Download page: http://sourceforge.net/project/showfiles.php?group_id=4933 Ports page: http://apps.sourceforge.net/mediawiki/maxima/index.php?title=Maxima_ports Project home page: http://maxima.sourceforge.net Change log: http://maxima.cvs.sourceforge.net/*checkout*/maxima/maxima/ChangeLog-5.20 -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Vote for ecl/boehmgc and removal of clisp
mabshoff wrote: > this has been discussed a bunch of time, but now finally the first > official move: I would like to remove clisp and switch over to ecl as > the base for Maxima as well as the optional FriCAS spkgs. ecl is > faster, builds and works on way more platforms including 32 and 64 bit > MSVC and has been supported by Maxima since the 5.16.x release. Michael, can you summarize the status of Maxima + ECL ? Compilation / installation issues, test suite, known strangeness ... ? By the way, which versions of Maxima and ECL are you using? In particular ECL is a rather quickly moving target. For the record, there will be the now-usual December release of Maxima next month, to be followed by another April, etc. Thanks a lot for your work on Maxima + ECL. I know that's only a tiny fraction of all the work you do. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: A simpler SAGE?
Jeff Pickhardt wrote: > I'm thinking I'll probably just continue my own back end (which I've > started rewriting in Python) but leverage some hand-picked advanced > functionalities like integration. The advantage of this is that I can > make it secure and easy to use; the disadvantage is that it'll be more > work. It absolutely has to be easy and secure, though. It sounds like you don't need all the capabilities that are in Sage, maybe just Maxima is enough. There have been various attempts to create limited-functionality interfaces for Maxima; see: http://maxima.sourceforge.net/relatedprojects.html Even if you end up using Sage, you might get some ideas there. Hope this helps Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Expected value of probability space
On Dec 1, 1:48 am, "William Stein" <[EMAIL PROTECTED]> wrote: > [Another response in this thread from David Kohel (who maybe should be > posting on list)] > Actually, I correct myself -- the average should be over the values > of the function, weighted by the probabilities. The domain of the > function (the keys) can be in any set (e.g. "A","B","C"), so the > current behavior is correct. David, I have to say the current behavior seems anomalous at best. >From what I can tell, since a probability space is just a normalized measure space, the underlying set on which the measure is defined need not be something for which linear combinations like A P(A) + B P(B) + C P(C) + ... is defined. If such linear combinations are not defined, then DiscreteProbabilitySpace.expectation should throw an exception. Maybe the expectation function should be moved out of the probability space base class (I don't know what that is in Sage) and into some subclass which can guarantee the operation succeeds. Just a thought. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Maxima] slowness is repeated Maxima evaluations?
On 12/6/08, David Joyner <[EMAIL PROTECTED]> wrote:
> (1) Sage calls Maxima and asks it to do lots of definite integrals
> (about 30 in this case, each involving a sine or cosine) - these are the
> Fourier coefficients,
> (2) Sage multiplies each of these coefficients by a sine or cosine function
> and adds them up - call this finite sum f(x),
> (3) Sage calls Maxima to evaluate f(x) at lots of points to plot the graph
> (maybe 100 point-wise evaluations of f(x)),
> (4) calls matplotlib to create the plot of f.
OK, I hope the following script (see PS) follows these steps.
> This was repeated (for timing purposes) 10 times. In an example involving
> about 30 terms, the first took about 10-11 seconds, and repeated
> evaluations took longer and longer, with the 10th taking about 30-35 seconds.
With the script as shown in the PS, I don't see an increase of
run time over 100 iterations. It takes about 16 seconds (varies
between 15.something to 17.something) with Maxima 5.17.0 + Clisp 2.46
on CentOS Linux, 3.4 GHz Intel x86.
Incidentally some integrals cause messages to be printed;
these originate in the Taylor series code, which is called from
integration.
Hope I've understood the question & haven't messed up something.
Robert Dodier
PS.
$ maxima --batch sage_fourier_helper.mac 1> 1.out 2> 2.out
$ tail 1.out
$ cat sage_fourier.mac
fc_all(n):=fc_ab(-1,n,-%pi,(-%pi)/2)+fc_ab(2,n,-%pi/2,0)
+fc_ab(-1,n,0,%pi/2)+fc_ab(2,n,%pi/2,%pi)$
fc_ab(e,n,a,b):=if n = 0 then [integrate(e,x,a,b)/(2*%pi),0]
else fc1_ab(e,n,a,b)$
fc1_ab(e,n,a,b):=[integrate(e*cos(n*x),x,a,b)/%pi,
integrate(e*sin(n*x),x,a,b)/%pi]$
coefs : map (fc_all, makelist (i, i, 0, 15));
fsum : sum (coefs[1 + n][1] * cos (n*x) + coefs[1 + n][2] * sin (n*x), n, 0, 15)
;
xx : makelist ((i - 1) * 2 * %pi / 100 - %pi, i, 1, 101), numer;
fsum_xx : makelist (''fsum, x, xx), numer;
$ cat sage_fourier_helper.mac
load ("./sage_fourier.mac");
load ("./sage_fourier.mac");
... (lots more to make 100 in all) ...
load ("./sage_fourier.mac");
load ("./sage_fourier.mac");
map (time, labels (%o));
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Cosine Integral and Sine Integral?
Tim Lahey wrote: > I mentioned this before in the context of the Sine Integral, Si(x), > but it appears that neither Sage nor Maxima have support for the > Sine Integral, Si(x) or the Cosine Integral, Ci(x). Dieter, are the Si and Ci functions on your radar? Context -- Dieter has been doing a tremendous amount of work on integration and special functions in Maxima. best Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] build recipe for Maxima in Sage?
Hello, Can someone tell me where to find the build scripts or whatever for building Maxima + ECL for Sage? I poked around in the Mercurial repository but came up empty-handed. I am having some trouble building Maxima + ECL so I was hoping to find a successful recipe. Thanks for any information. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: build recipe for Maxima in Sage?
mabshoff wrote: > There is no such thing in Sage, all the experiments were done without > Sage, i.e. build ecl and then Maxima. OK. Btw, what mechanism did you use to build Maxima? ASDF or defsystem or ?? best Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: reduce
mabshoff wrote: > Yes, but you can run Maxima on top of ecl, but the issue with asksign > for example does not go away. I asked Robert Dodier about it at Dev1 > and he seemed reluctant about this possibility. Hmm, what is "this possibility" ? I don't understand. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Maxima, ECL, asksign; was: Re: reduce
mabshoff wrote: > On Jan 3, 11:27�am, Robert Dodier wrote: > > Hmm, what is "this possibility" ? I don't understand. > I meant embedding Maxima into a library extensions via ecl. You stated > to the best of my recollection that this would be troublesome due to > asksign since there would be the need on occasion by the user to > interact with the integration/limit calculation - unless I > misunderstood you :) OK, I don't remember what I might have said, probably not too important. Instead let me spell out my current thoughts about the situation. Maxima + ECL seems to work OK at this point so I guess you could indeed link in Maxima via CFFI or some other C interface. (Although there are two layers of glue here, right? Lisp -> C and C -> Python; seems like it could be messy.) asksign would presumably still interfere, but it wouldn't be any more of problem than it is now. About disabling asksign, I made an attempt to do that in a non- intrusive way, by having asksign throw an exception back to a high-level handler which could construct a conditional expression. (The code is in share/contrib/noninteractive/.) That sort of works, except that it clogs up the assume system (which eventually stops working). Also, the scheme inherits assume's weakness. So at this point I think it would be necessary to revise every call to asksign to construct a conditional expression when asksign is disabled. That would be tedious --- there are something like 100 calls to asksign or similar functions throughout the core code --- but it seems straightforward. I might try to work on that in 2009. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: fricas release 1.0.5 package for sage
On Jan 27, 12:25 am, William Stein wrote: > I'm using gmail and the fonts are proportionally spaced, so ASCII is > mangled (of course, I'm being lazy -- I could paste it somewhere). FWIW if you choose "Show original" from the options, the message is displayed using a fixed width font, from what I can tell. HTH Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Integration syntax
On Feb 2, 9:16 pm, kcrisman wrote:
> sage: integrate(sin(x),[x],[var('y')]) # double integral, x first
> sage: integrate(sin(x),[x,0,pi],[y]) # one definite, one indefinite
> sage: integrate(sin(x),(x,),(x,)) # double integral, using tuples
> instead of lists if you like parentheses
> sage: integrate(sin(x),(x,),(var('y'),),(var('z'),)) # or more
> integrals
Since the Sage project does not have the burden of history
(relatively speaking) I think you guys should go nuts and try
to do it "right".
I'll leave it to you to decide what's right but to me it means
trying to directly represent general integrals, so the syntax is:
integrate(F, R) or integrate(F, R, mu) where F is a function,
R is a region, and mu is an optional measure.
Leaving aside mu for the moment, F is specifically a function
(named or unnamed, and not a general expression) and R is an
interval or product of intervals or some more general set.
1-d integrals would be like integrate(lambda([x], sin(x)), [0, pi])
(sorry, I don't know the python lambda notation)
or integrate(sin, [0, pi]). 2-d like
integrate(lambda([x, y], x*y), [0, 1] cross [0, 1]),
more general region like integrate(lambda([u, v], exp(u - v)),
set((u, v) s.t. u - v < 0)).
I've imagined some notations such as cartesian product
and so-called "set builder" which may not yet exist in Sage.
The existing notation integrate(a, b, c, d) could be preserved
as a convenience function equivalent to integrate(lambda([b], a), [c,
d]).
I've left out many details but the general point is that I think
you guys (= Sage project) should aim high.
FWIW
Robert Dodier
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: tab completion and function aliases cluttering the namespace
On Feb 9, 8:44 am, Jason Grout wrote: > What do people think? I think this would finally answer the tension > between the people that want useful tab completion and the people who > want the function names to look "right". FWIW I 'm pretty sure aliases are a disaster; whether you can get most people to agree on a big-endian (_) or little-endian (_) naming scheme, you shouldn't try to accomodate the other via aliases. Maybe it's too late to do away with existing aliases, but at least new ones can be discouraged Incidentally I'm in favor of a big-endian naming scheme: names nearby in a sorted list are more likely related. (The tab-completion effect is a helpful side-effect.) About narrow and extensive searches, for Maxima we've adopted ? foo to indicate an exact search while ?? foo indicates a search for foo as a substring. (Since regex characters could be arithmetic operators, allowing any kind of regex syntax seems problematic.) Maybe Sage likewise could adopt a distinction between different kinds of search. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: A laugh
On Feb 13, 9:09 am, William Stein wrote: > In case nobody noticed, I'm not exactly a big fan of the Ma*'s. But > for whatever reason -- perhaps their purely selfish desire to make > money -- they do often try to listen to users and solve problems, > instead of making excuses like some posters in this thread. For my part I am willing to consider modifying asksign (the Maxima function which originates the "Is foo positive or ...?" questions) to apply some simplifications in an effort to avoid some questions. Maybe it's as simple as wedging a call to trigsimp into asksign. I haven't looked at it and I'm distracted by other things so it's unlikely that I'll do it. But if someone wants to look into it and make a report and/or proposal to the Maxima mailing list, then more power to you. A larger issue is that asksign is generally obnoxious. I've worked on ways to construct a conditional expression instead of requiring user input. I'll be happy to collaborate with interested parties on a solution. Believe it or not, Maxima is not stuck in a time warp; progress is actually possible, when we stop carping and focus on solving problems instead. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
