Mailman 3 February 2009 - SciPy-Dev

Re: [SciPy-dev] Matrix exponential
by jason-sage＠creativetrax.com 28 Feb '09

28 Feb '09

(It appears that this postscript from John (at the top of the message below) didn't make it to the scipy-dev list, probably because he's not subscribed, so I'm forwarding the message to the scipy-dev list.) -Jason John Cremona wrote: > PS An interesting quote from one of Higham's talks: > > The availability of expm(A) in > early versions of MATLAB > quite possibly contributed to > the system’s technical and commercial success.” > — Cleve Moler (2003) > > I get the impression that this is used a lot, though they only seem to > want double precision (as opposed to multi) which is both fast and has > predictably bounded error. The method is a variant of a standard one > (Pade approximations) with some nice tricks as some once-and-for all > parameter tuning (for which he said they used Maple!) > > John Cremona > > 2009/2/27 <jason-sage(a)creativetrax.com>: > >> John Cremona posted the following message to the sage development list about >> matrix exponentials. I'm copying it to here since it asks about the scipy >> matrix exponential method (we say numpy below, but we really mean scipy...) >> >> John Cremona wrote: >> >> >>>>> I have just been to a colloquium talk by numerical analyst Nick Higham >>>>> (Manchester) called "How to compute and not to compute a matrix >>>>> exponential". He has new methods which are now in mathematica, matlab >>>>> and NAG but (apparantly) nowhere else. He only seemed interested in >>>>> getting good speed & precision to 16 decimals but (when I asked) >>>>> confirmed that the methods should apply to give arbitrary precision. >>>>> >>>>> I just checked and see that Sage's matrix exp() uses something stupid >>>>> except over RDF/CDF where it uses a pade approximation method via >>>>> numpy. The method of the talk was a variant of that, the main trick >>>>> being to use exactly the right order of Pade approx. so maximise >>>>> precision and speed. >>>>> >>>>> I would like to know how good the numpy method is, and whether it can >>>>> be improved to this "state of the art" version at least for RDF. Then >>>>> it could be another selling point for Sage. >>>>> >>> Could you CC the numpy devlist as well on this? It sounds exciting! >>> >> I will if you give me the address (or you can perhaps?). It might be >> worth including Higham's URL: >> http://www.maths.manchester.ac.uk/~higham/ as he has lots of his >> talks up there including some which are similar to the one I heard. >> >> >> >> >> > >

1 0

Implementation of a parallel cKDTree
by Sturla Molden 27 Feb '09

27 Feb '09

I have fiddled a bit with scipy.spatial.cKDTree for better performance on multicore CPUs. I have used threading.Thread instead of OpenMP, so no special compilation or compiler is required. The number of threads defaults to the number of processors if it can be determined. The performance is not much different from what I get with OpenMP. It is faster than using cKDTree with multiprocessing and shared memory. Memory handling is also improved. There are checks for NULL pointers returned by malloc or realloc. setjmp/longjmp is used for error handling if malloc or realloc fail. A memory pool is used to make sure all complex data structures are cleaned up properly. I have assumed that crt functions malloc, realloc and free are thread safe. This is usually the case. If they are not, they must be wrapped with calls to PyGILState_Ensure and PyGILState_Release. I have not done this as it could impair scalability. Regards, Sturla Molden

1 0

unsubscibe
by Stefan Waller 27 Feb '09

27 Feb '09

-----Ursprungligt meddelande----- Från: scipy-dev-bounces(a)scipy.org [mailto:scipy-dev-bounces@scipy.org] För scipy-dev-request(a)scipy.org Skickat: den 27 februari 2009 10:19 Till: scipy-dev(a)scipy.org Ämne: Scipy-dev Digest, Vol 64, Issue 66 Send Scipy-dev mailing list submissions to scipy-dev(a)scipy.org To subscribe or unsubscribe via the World Wide Web, visit http://projects.scipy.org/mailman/listinfo/scipy-dev or, via email, send a message with subject or body 'help' to scipy-dev-request(a)scipy.org You can reach the person managing the list at scipy-dev-owner(a)scipy.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Scipy-dev digest..." Today's Topics: 1. Re: Scipy workflow (and not tools). (David Cournapeau) 2. Re: Scipy workflow (and not tools). (Ondrej Certik) 3. Re: The future of SciPy and its development infrastructure (St?fan van der Walt) 4. Re: RFR 503, 849: more robust implementation of real Bessel I_v (St?fan van der Walt) 5. Re: The future of SciPy and its development infrastructure (Prabhu Ramachandran) 6. Re: The future of SciPy and its development infrastructure (Travis E. Oliphant) 7. Re: The future of SciPy and its development infrastructure (David Cournapeau) 8. Improving the bug tracking workflow: starting document (David Cournapeau) 9. Re: The future of SciPy and its development infrastructure (Pauli Virtanen) ---------------------------------------------------------------------- Message: 1 Date: Fri, 27 Feb 2009 13:23:30 +0900 From: David Cournapeau <cournape(a)gmail.com> Subject: Re: [SciPy-dev] Scipy workflow (and not tools). To: SciPy Developers List <scipy-dev(a)scipy.org> Message-ID: <5b8d13220902262023i675a4bc4ra8bf981267fb2156(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Fri, Feb 27, 2009 at 9:08 AM, Pauli Virtanen <pav(a)iki.fi> wrote: > Fri, 27 Feb 2009 00:48:00 +0200, St?fan van der Walt wrote: > >> 2009/2/27 Pauli Virtanen <pav(a)iki.fi>: >>> If you want to discuss Git, you can probably steal from here: >>> >>> ? ? ? ?http://scipy.org/scipy/numpy/wiki/GitMirror >> >> Ah, yes, good reminder! >> >> Could you give me a quick rundown of why you used --mirror earlier on >> when adding the remote? > > The --mirror option adds > > ? ? ? ?fetch = +refs/*:refs/* > ? ? ? ?mirror = yes > > to [remote "origin"]. So one wouldn't need to edit .git/config manually. > > However, the --mirror has another effect which I missed earlier: it > makes the remote consider all heads its own, so that "git remote prune origin" > would drop all branches, including local ones. Similar issue with "git > fetch". So I think it's not the correct solution. > > ? ?*** > > But all of that is moot now. I finally figured out that I must push to > the mirror with > > ? ? ? ?git push git@github.com:pv/numpy-svn.git \ ? ? ? ? ? ? ? > ?+refs/remotes/*:refs/heads/* +master > > Then it can be cloned simply with > > ? ? ? ?git clone --origin svn git://github.com/pv/scipy-svn.git > > And "--origin svn" only because we want svn/trunk instead of origin/trunk. > Also git-svn can be activated: > > ? ? ? ?git svn init -s --prefix=svn/ http://svn.scipy.org/svn/scipy ? > ? ? ?git svn rebase -l > > And as a bonus, the SVN branches are visible on Github! Ah, nice, I did not find a way to do this - I used a dirty script to get local branches and update them instead. One thing which is still annoying is that tags are considered as branches - but I guess there is no way around it, since svn does not have any tag concept. David ------------------------------ Message: 2 Date: Thu, 26 Feb 2009 20:54:21 -0800 From: Ondrej Certik <ondrej(a)certik.cz> Subject: Re: [SciPy-dev] Scipy workflow (and not tools). To: SciPy Developers List <scipy-dev(a)scipy.org> Message-ID: <85b5c3130902262054i27fca37fq7e2d58c6cf06626a(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Thu, Feb 26, 2009 at 8:23 PM, David Cournapeau <cournape(a)gmail.com> wrote: > On Fri, Feb 27, 2009 at 9:08 AM, Pauli Virtanen <pav(a)iki.fi> wrote: >> Fri, 27 Feb 2009 00:48:00 +0200, St?fan van der Walt wrote: >> >>> 2009/2/27 Pauli Virtanen <pav(a)iki.fi>: >>>> If you want to discuss Git, you can probably steal from here: >>>> >>>> ? ? ? ?http://scipy.org/scipy/numpy/wiki/GitMirror >>> >>> Ah, yes, good reminder! >>> >>> Could you give me a quick rundown of why you used --mirror earlier >>> on when adding the remote? >> >> The --mirror option adds >> >> ? ? ? ?fetch = +refs/*:refs/* >> ? ? ? ?mirror = yes >> >> to [remote "origin"]. So one wouldn't need to edit .git/config manually. >> >> However, the --mirror has another effect which I missed earlier: it >> makes the remote consider all heads its own, so that "git remote prune origin" >> would drop all branches, including local ones. Similar issue with >> "git fetch". So I think it's not the correct solution. >> >> ? ?*** >> >> But all of that is moot now. I finally figured out that I must push >> to the mirror with >> >> ? ? ? ?git push git@github.com:pv/numpy-svn.git \ ? ? ? ? ? ? ? >> ?+refs/remotes/*:refs/heads/* +master >> >> Then it can be cloned simply with >> >> ? ? ? ?git clone --origin svn git://github.com/pv/scipy-svn.git >> >> And "--origin svn" only because we want svn/trunk instead of origin/trunk. >> Also git-svn can be activated: >> >> ? ? ? ?git svn init -s --prefix=svn/ http://svn.scipy.org/svn/scipy ? >> ? ? ?git svn rebase -l >> >> And as a bonus, the SVN branches are visible on Github! > > Ah, nice, I did not find a way to do this - I used a dirty script to > get local branches and update them instead. One thing which is still > annoying is that tags are considered as branches - but I guess there > is no way around it, since svn does not have any tag concept. Btw, I guess you already know it, but if you need to clone the git repository (for example David's) and then you would like to update it using git-svn with the latest svn from scipy, here is the howto: http://subtlegradient.com/articles/2008/04/22/cloning-a-git-svn-clone E.g. basically: git svn init http://macromates.com/svn/Bundles/trunk/Bundles/Ruby.tmbundle -R svn cp .git/refs/remotes/origin/master .git/refs/remotes/git-svn git svn fetch Ondrej ------------------------------ Message: 3 Date: Fri, 27 Feb 2009 07:37:46 +0200 From: St?fan van der Walt <stefan(a)sun.ac.za> Subject: Re: [SciPy-dev] The future of SciPy and its development infrastructure To: SciPy Developers List <scipy-dev(a)scipy.org> Message-ID: <9457e7c80902262137j69478ba9h910dcfac3949af26(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi Travis 2009/2/27 Travis E. Oliphant <oliphant(a)enthought.com>: > My biggest concern is having a bunch of code sitting in a queue and > not reviewed, nor committed --- or the review processes become too > onerous and code not making it through because of what I would > consider to be "ticky-tacky technicalities." That's a very valid concern. David and I are experimenting with different issue trackers and plugins for trac, to see how best to generate a "review pool". I.e., what I'd like to see is that, if you only have 5 minutes to work on SciPy in the evening, you can a) Go to trac and click on "tickets for review" b) Review a couple of tickets or a) Go to trac and click on "reviewed tickets" b) Apply those patches or a) Go to trac and click on "unresolved issues" b) Fix the bug c) Upload the patch for review Technically, (c) is a bit challenging. I note your concern that it would become difficult to check in, so what I would like is to have a script such as scipy-submit -t 212 -m "Do not deallocate memory after object disposal." which then uploads the patch to the codereview site, and adds a link to ticket 212 with the commit message and review URL. All of this can be done via the web, but I'd prefer to have a CLI available. Do you have any suggestions or further concerns? Thanks St?fan ------------------------------ Message: 4 Date: Fri, 27 Feb 2009 07:42:52 +0200 From: St?fan van der Walt <stefan(a)sun.ac.za> Subject: Re: [SciPy-dev] RFR 503, 849: more robust implementation of real Bessel I_v To: SciPy Developers List <scipy-dev(a)scipy.org> Message-ID: <9457e7c80902262142w333024a4nd1a2e0afb8082231(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 2009/2/27 Pauli Virtanen <pav(a)iki.fi>: > Urgh, the codereview app does not add any distinguishing headers to > the mails it sends for each comment. I'll ask on the rietveld list. Cheers St?fan ------------------------------ Message: 5 Date: Fri, 27 Feb 2009 11:22:55 +0530 From: Prabhu Ramachandran <prabhu(a)aero.iitb.ac.in> Subject: Re: [SciPy-dev] The future of SciPy and its development infrastructure To: SciPy Developers List <scipy-dev(a)scipy.org> Message-ID: <49A77FB7.7010406(a)aero.iitb.ac.in> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 02/27/09 11:07, St?fan van der Walt wrote: > scipy-submit -t 212 -m "Do not deallocate memory after object disposal." > > which then uploads the patch to the codereview site, and adds a link > to ticket 212 with the commit message and review URL. All of this can > be done via the web, but I'd prefer to have a CLI available. > > Do you have any suggestions or further concerns? I've not contributed anything in years to scipy but I have a practical problem that might be worth addressing eventually (others might be in a similar position) -- my entire network is firewalled and I can only access the web behind an authenticated http proxy. The firewall does allow ssh connections out though but that seems useless to access a git repository hosted on github say. The git user guide does not mention the word proxy (google wasn't too much help either) and it would be nice if all the tools allowed people to use the workflow from behind a firewall without too much pain. This may or may not be possible right away and may be low priority but is worth keeping in mind. Thanks. prabhu ------------------------------ Message: 6 Date: Fri, 27 Feb 2009 00:00:49 -0600 From: "Travis E. Oliphant" <oliphant(a)enthought.com> Subject: Re: [SciPy-dev] The future of SciPy and its development infrastructure To: SciPy Developers List <scipy-dev(a)scipy.org> Message-ID: <49A78191.20902(a)enthought.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed St?fan van der Walt wrote: > Hi Travis > > 2009/2/27 Travis E. Oliphant <oliphant(a)enthought.com>: > >> My biggest concern is having a bunch of code sitting in a queue and >> not reviewed, nor committed --- or the review processes become too >> onerous and code not making it through because of what I would >> consider to be "ticky-tacky technicalities." >> > > That's a very valid concern. David and I are experimenting with > different issue trackers and plugins for trac, to see how best to > generate a "review pool". I.e., what I'd like to see is that, if you > only have 5 minutes to work on SciPy in the evening, you can > > a) Go to trac and click on "tickets for review" > b) Review a couple of tickets > > or > > a) Go to trac and click on "reviewed tickets" > b) Apply those patches > > or > > a) Go to trac and click on "unresolved issues" > b) Fix the bug > c) Upload the patch for review > > Technically, (c) is a bit challenging. I note your concern that it > would become difficult to check in, so what I would like is to have a > script such as > > scipy-submit -t 212 -m "Do not deallocate memory after object disposal." > Something like that would be nice! Thanks for the continued effort at improving workflow. -Travis ------------------------------ Message: 7 Date: Fri, 27 Feb 2009 14:48:01 +0900 From: David Cournapeau <david(a)ar.media.kyoto-u.ac.jp> Subject: Re: [SciPy-dev] The future of SciPy and its development infrastructure To: SciPy Developers List <scipy-dev(a)scipy.org> Message-ID: <49A77E91.4010101(a)ar.media.kyoto-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1 Prabhu Ramachandran wrote: > On 02/27/09 11:07, St?fan van der Walt wrote: > >> scipy-submit -t 212 -m "Do not deallocate memory after object disposal." >> >> which then uploads the patch to the codereview site, and adds a link >> to ticket 212 with the commit message and review URL. All of this >> can be done via the web, but I'd prefer to have a CLI available. >> >> Do you have any suggestions or further concerns? >> > > I've not contributed anything in years to scipy but I have a practical > problem that might be worth addressing eventually (others might be in > a similar position) -- my entire network is firewalled and I can only > access the web behind an authenticated http proxy. I have similar issues, and I agree those are valid concerns. Those can be very painful to handle. In my case, there is no DNS server, the names are resolved by the proxy; my workstation can only resolve the proxy name. This breaks most applications out there. ssh is not easy, because ssh cannot resolve names - for git, I managed to get things worked out for github using corkscrew. This is the kind of things which I managed to do once and hope never have to do again, so I can't tell you exactly how to do it: http://en.wikipedia.org/wiki/Corkscrew_(program) My .ssh/config looks like this for github Host gitproxy User git HostName ssh.github.com Port 443 ProxyCommand /usr/bin/corkscrew www 3128 %h %p IdentityFile /home/david/.ssh/id_rsa.pub Where www is the name of my proxy and 3128 the port. FWIW, svn has similar problems. I could never commit anything from a former internship location because of some proxy limitations - it is one of the reasons which pushed me into git for scipy development, actually. If you can't access either ssh or proxy, my experience is that you are more or less screwed with any tool out there - but with DVCS, you can at least put your changes aside and commit them later from an easier connection. cheers, David ------------------------------ Message: 8 Date: Fri, 27 Feb 2009 17:28:53 +0900 From: David Cournapeau <david(a)ar.media.kyoto-u.ac.jp> Subject: [SciPy-dev] Improving the bug tracking workflow: starting document To: SciPy Developers List <scipy-dev(a)scipy.org> Message-ID: <49A7A445.4010800(a)ar.media.kyoto-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1 Hi, Following the discussions, I have started to write a small document highlighting my current gripes with trac. I focus on some common scenario, and pin-point trac limitations. I mention possible new tools at the end, but that's not the main point: everybody who is also disatisfied with trac, and maybe even more importantly people who are currently satisfied and think their scenario is not covered should feel free to comment/modify it: http://scipy.org/scipy/numpy/wiki/ImprovingIssueWorkflow I put the initial version in svn as well: http://projects.scipy.org/scipy/numpy/browser/trunk/doc/neps/newbugtracker.r st. cheers, David ------------------------------ Message: 9 Date: Fri, 27 Feb 2009 09:18:22 +0000 (UTC) From: Pauli Virtanen <pav(a)iki.fi> Subject: Re: [SciPy-dev] The future of SciPy and its development infrastructure To: scipy-dev(a)scipy.org Message-ID: <go8b4u$jpb$1(a)ger.gmane.org> Content-Type: text/plain; charset=UTF-8 Fri, 27 Feb 2009 11:22:55 +0530, Prabhu Ramachandran wrote: [clip] > I've not contributed anything in years to scipy but I have a practical > problem that might be worth addressing eventually (others might be in > a similar position) -- my entire network is firewalled and I can only > access the web behind an authenticated http proxy. The firewall does > allow ssh connections out though but that seems useless to access a > git repository hosted on github say. Git can clone over HTTP, just change git:// to http:// and it seems to work. I can also clone through a proxy with export http_proxy=http://username:password@proxy:port/ git clone http://whatever Pushing over HTTP is another question... It's probably not possible to push to Github over HTTPS, but maybe there are places that you can push to with only HTTP authentication. -- Pauli Virtanen ------------------------------ _______________________________________________ Scipy-dev mailing list Scipy-dev(a)scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev End of Scipy-dev Digest, Vol 64, Issue 66 *****************************************

1 0

RFR 503, 849: more robust implementation of real Bessel I_v
by Pauli Virtanen 26 Feb '09

26 Feb '09

(For trying out the code review tool...) Scipy bugs #503 and #849 are due to a non-robust implementation of Bessel I function in Cephes. The following changes address this, by using an implementation from the Boost library, converted to C: http://codereview.appspot.com/20078 A git branch is here: http://github.com/pv/scipy-work/tree/ticket-503-special-iv-fix I'm thinking that this code would be ready to be committed in. I'm not aware of bugs in it. -- Pauli Virtanen

3 5

Updating and improving the statistical capabilities in Scipy
by Bruce Southey 26 Feb '09

26 Feb '09

Hi, I apologize in advance if this is the wrong approach. All this talk has inspired me to do something about developing the statistics of Scipy. We need to develop a strategy to improve the statistical functions within Scipy. A central requirement is a sort of code review to ensure that the existing functions have adequately documentation (see also the Scipy documentation Marathon http://www.scipy.org/Developer_Zone/DocMarathon2008) and have appropriate tests for functionality and accuracy. Basically I strongly believe that we must carefully use a slow divide-and-conqueror approach to succeed simply due to the scope involved. I would be extremely interested in what people would like to see so that we can develop specific goals and action plans to update and improve them. I consider at the least the following major areas currently present in Scipy that I am aware of: 1) Statistical distributions: Josef has vastly improved this. 2) Uni- and multi-variate kernel density estimation - currently Gaussian only available. 3) Basic statistical functions - available for standard and masked arrays but it is inconsistent. 4) Model fitting aspects that integrates different code within Scipy (including Jonathan Taylor's model class - which is really impressive and the Cookbook ols) to provide important functionality including general linear models, generalized linear models, and generalized additive models. I would suggest that we develop some type of PEP structure as starting point for discussion as well as using different threads to address different areas as well as future directions. Therefore I have put together something to address the basic statistical functions in a separate thread. Thanks Bruce

2 1

Re: [SciPy-dev] Scipy workflow (and not tools).
by Elston, Gareth R 26 Feb '09

26 Feb '09

> -----Original Message----- > From: scipy-dev-bounces(a)scipy.org [mailto:scipy-dev-bounces@scipy.org] On Behalf Of scipy-dev-request(a)scipy.org > Sent: 26 February 2009 10:36 > To: scipy-dev(a)scipy.org > Subject: Scipy-dev Digest, Vol 64, Issue 56 > > Message: 1 > Date: Wed, 25 Feb 2009 23:21:40 -0800 > From: Brian Granger <ellisonbg.net(a)gmail.com> > Subject: Re: [SciPy-dev] Scipy workflow (and not tools). > To: SciPy Developers List <scipy-dev(a)scipy.org> > Message-ID: > <6ce0ac130902252321j6139238by634364acd2bd07b2(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Neil, > > Thanks for speaking up! I think there are *many* people in your > situation, including myself - I too am mostly a silent watcher of > SciPy and I would be much more likely to contribute if the things you > list were a part of the Scipy development culture: > > * Tests > * Code review > * Documentation > * Good tools and workflow. > > I think it is an unproven myth that these things are "barriers" for > people who want to write code. In most cases that I have seen, these > things *encourage* new people to contribute to a project and greatly > improve the quality of the code being written by newbies and veteran's > alike. > > Cheers, > > Brian I'm another long-time lurker who's been thinking about contributing for a while but who's been a bit uncertain about where to start. These discussions, plus the git branches Pauli has created, are encouraging me greatly to roll up my sleeves and delve in. Cheers, Gareth. ------------------------------------------------------------- IMPORTANT NOTICE. This E-Mail and any files transmitted with it, are confidential and may be privileged and are for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it, is strictly prohibited and may be unlawful. If you have received this E-Mail in error please return it to the sender. We should be grateful if you would also copy the communication to postmaster(a)doosanbabcock.com then delete the E-Mail and destroy any copies of it. It is your responsibility to scan any attachments for viruses. For further information, visit us at WWW.DOOSANBABCOCK.COM -------------------------------------------------------------

5 5

Server problems: resetting with cronjob?
by Stéfan van der Walt 25 Feb '09

25 Feb '09

Hi all, The server has been down intermittently all weekend, which makes it hard to edit and close tickets. Could we please install a cron job to restart trac and whatever else is running once daily? Thanks, Stéfan

9 21

Scientific packages for a distributed computing Amazon EC2 image?
by Peter Skomoroch 24 Feb '09

24 Feb '09

I'm collecting a wishlist of scientific and python related packages (numpy, scipy, etc) people would want installed on a Debian based Amazon EC2 machine image (AMI)<http://developer.amazonwebservices.com/connect/kbcategory.jspa?categoryID=1…>for distributed computing. I'll make more information available as the machine image develops, some of these will also go into the Machetec2<http://blog.infochimps.org/2009/02/06/start-hacking-machetec2-released/>AMI. Several variants of the AMI should become available in the next month. Please feel free to add any packages you would want pre-installed on the following wiki page: http://scipy.org/SciPyAmazonAmi Let me know if you spot any potential license conflicts with listed software. -- Peter N. Skomoroch 617.285.8348 http://www.datawrangling.com http://delicious.com/pskomoroch http://twitter.com/peteskomoroch

2 1

complex wrapper to ode
by John Travers 24 Feb '09

24 Feb '09

Hello, Attached is a patch which adds a wrapper class 'zode' to integrate.ode. It allows one to conviniently solve systems of odes with complex values using the existing real valued solvers vode, dopri5, dop853, instead of zode, by simply integrating the real/imag parts. Is this worth commiting? It appears to me to be considerably faster than zvode for my big systems of equations. I'm not sure why, as I intuitively thought all the data copying etc. would slow it down. But it is after all only a convenience, anyone can do it themselves. Cheers, John

2 2

matlab io - request for testing
by Matthew Brett 24 Feb '09

24 Feb '09

Hi, I have been beating up the matlab io rather severely in order to implement some cleanups, fixes, and add new options. I would very much appreciate it if people could pick up the current SVN and let me know whether they have any problems. Thanks a lot, Matthew

7 15