headers
Michael Culbertson | 2 Sep 2004 22:42

optimize.fmin: xtol/ftol

Hello,

  I think there is an error in the termination of the Simplex optimization
algorithm implemented by scipy.optimize.fmin().  According to the doc
string, xtol and ftol are _relative_ values:

      xtol -- acceptable relative error in xopt for convergence.
      ftol -- acceptable relative error in func(xopt) for convergence.

Yet, as I read the termination condition:

        if (max(Num.ravel(abs(sim[1:]-sim[0]))) <= xtol \
            and max(abs(fsim[0]-fsim[1:])) <= ftol):
            break

the values are taken as absolute quantities.  Shouldn't the condition
include some division of the difference by one of the values or a
multiplication of the relative tolerances by one of the values for a
proper relative comparison?  Or, have I misinterpreted the statements
above?

Thanks,
Michael Culbertson
Permalink | Reply | 0 comments |
headers
Fernando Perez | 7 Sep 2004 07:28
Picon
Favicon

Python & Scientific computing links?

Hi all,

at the excellent BOF session run by Joe Harrington at scipy'04, one of the 
things that came out was the need for more organized and centralized 
documentation about using Python for various aspects of scientific computing.

An effort is under way to tackle this problem, but I'll let Joe report in full 
on the whole idea in due time.  As my tiny contribution to this, I offered to 
collect a simple page of links and short summaries of any project out on the 
web which is reasonably connected to scientific computing.

Obviously I have my own bookmarks list which I'll use as a starting point, but 
I'm asking here for all of you to simply mail me your favorite list of links 
on this topic.  Feel free to add extra info which may help me, but it's OK if 
it's just a list of URLs.  I'll collect them, check that at least things are 
active, and write a short summary for each project (probably copy/paste from 
their own pages).

In a couple of weeks, I'll mail this page to Joe so it can go into the 
relevant area of the Scipy.org website, where it will most likely end up as a 
Wiki page.  From that point on, the community can continue to improve it, 
correct my mistakes, and keep it updated as new projects of interest appear or 
old ones vanish.

Best,

f.
Permalink | Reply | 0 comments |
headers
bulatov | 9 Sep 2004 00:13

Re: Python & Scientific computing links?

Here's a list of Artificial Intelligence/Machine Learning links I compiled with
help from comp.lang.python 

http://yaroslav.hopto.org/pubwiki/index.php/ai-python

Yaroslav

Цитирую Fernando Perez <Fernando.Perez <at> colorado.edu>:

> Hi all,
> 
> at the excellent BOF session run by Joe Harrington at scipy'04, one of the 
> things that came out was the need for more organized and centralized 
> documentation about using Python for various aspects of scientific
> computing.
> 
> An effort is under way to tackle this problem, but I'll let Joe report in
> full 
> on the whole idea in due time.  As my tiny contribution to this, I offered to
> 
> collect a simple page of links and short summaries of any project out on the
> 
> web which is reasonably connected to scientific computing.
> 
> Obviously I have my own bookmarks list which I'll use as a starting point,
> but 
> I'm asking here for all of you to simply mail me your favorite list of links
> 
> on this topic.  Feel free to add extra info which may help me, but it's OK if
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Fernando Perez | 9 Sep 2004 01:04
Picon
Favicon

Re: Python & Scientific computing links?

bulatov <at> cs.orst.edu wrote:
> Here's a list of Artificial Intelligence/Machine Learning links I compiled with
> help from comp.lang.python 
> 
> http://yaroslav.hopto.org/pubwiki/index.php/ai-python

Great, thanks!

f
Permalink | Reply | 0 comments |
headers
eric jones | 12 Sep 2004 11:32

SciPy WishList and Priorities

Hey group,

One of the request at the SciPy '04 conference was a list of priorities, 
etc. that the developers felt needed to be addressed.  It is a target 
rich environment... :-)

I've put together a stream-of-conciousness set of notes on the Wiki with 
my 0.02 worth.  Travis )., Pearu, and others, feel free to add to this.

    http://www.scipy.org/wikis/featurerequests/PrioritiesAndWishlist

I haven't really specified an priorities or actionable plans yet (feel 
free to add this yourself...), but we know have a place to start discussing.

Thanks for all who came to the conference.  I thought it was another 
great success and there was a lot of useful discussion about where we 
should go and how.  It really feels like to community is becoming 
organized and mature enough to attack some of the issues that have been 
outstanding for a long time.  Hopefully the community will make notable 
progress by the time SciPy '05 roles around.

thanks,
eric
Permalink | Reply | 4 comments |
headers
Fernando Perez | 13 Sep 2004 22:00
Picon
Favicon

Re: SciPy WishList and Priorities

eric jones wrote:
> Hey group,
> 
> One of the request at the SciPy '04 conference was a list of priorities, 
> etc. that the developers felt needed to be addressed.  It is a target 
> rich environment... :-)
> 
> I've put together a stream-of-conciousness set of notes on the Wiki with 
> my 0.02 worth.  Travis )., Pearu, and others, feel free to add to this.
> 
>     http://www.scipy.org/wikis/featurerequests/PrioritiesAndWishlist
> 

Sorry if I'm being dense, but how can I edit that page?  I'd like to add some 
comments, and even though I logged in, the only wiki buttons I see are for 
printing and email.  Am I missing something?

Best,

f
Permalink | Reply | 3 comments |
headers
Travis E. Oliphant | 14 Sep 2004 02:20
Favicon

Re: [AstroPy] Python version of IDL Astron library

Since Tom invited me into the discussion, I will comment, despite the 
fact that I am not an astronomer.

> Hi folks-
> 
> Sorry to have missed all of the interesting discussion on this; I was
> at the HEAD meeting (on a panel on astrostatistics software, among
> other things---lots of folks are interested in Python, by the way).
> 
> Joe's summary of the main issues was very good.  I agree on many
> points; here are some possible disagreements.
> 
> 
>>UNDERLYING PACKAGES
>>
>>1. Numarray for all new code, and to teach to new users.

The reality is that Numarray is not ready as a drop-in replacement for 
Numeric but people keep introducing it to new users as if it were ready. 
   This is a real problem in the community right now.

These issues have been discussed before and are on the scipy.org wiki 
that Eric has started.  Basically the issues preventing a drop-in 
replacement are 1) small arrays are too slow, 2) no backward-compatible 
ufunc C-API --- nothing like the compatibility API for arrays exists for 
ufuncs.  3) migrating legacy code is way too time consuming and effort 
filled for almost no gain.

While not optimal the current best solution is to make Numarray more 
aware of Numeric arrays and vice versa, so that unnecessary memory
(Continue reading)

Permalink | Reply | 6 comments |
headers
Travis E. Oliphant | 14 Sep 2004 02:27
Favicon

Re: [AstroPy] Python version of IDL Astron library


> 
> Regarding coordination with SciPy, it may be worth pointing out
> that the astrostat project I have funded by AISR supports Travis 
> Oliphant for a month a year to support the project.  He's offered
> to host our Inference package at SciPy.org.  Perhaps I can persuade
> him to make that just a part of a larger set of packages, and get
> his help behind hosting our effort at SciPy.org (in this last year of 
> funding!).

You can easily persuade me to help making anything that is deemed 
acceptable a part of the scipy package.  We want SciPy to be general 
purpose and easily available.

I am anxious to hear about what I can do to help get your inference 
routines into SciPy.

-Travis
Permalink | Reply | 0 comments |
headers
Perry Greenfield | 14 Sep 2004 02:43

Re: Re: [AstroPy] Python version of IDL Astron library


On Sep 13, 2004, at 8:20 PM, Travis E. Oliphant wrote:
>
> The reality is that Numarray is not ready as a drop-in replacement for 
> Numeric but people keep introducing it to new users as if it were 
> ready.   This is a real problem in the community right now.
>
> These issues have been discussed before and are on the scipy.org wiki 
> that Eric has started.  Basically the issues preventing a drop-in 
> replacement are 1) small arrays are too slow, 2) no 
> backward-compatible ufunc C-API --- nothing like the compatibility API 
> for arrays exists for ufuncs.  3) migrating legacy code is way too 
> time consuming and effort filled for almost no gain.
>
> While not optimal the current best solution is to make Numarray more 
> aware of Numeric arrays and vice versa, so that unnecessary memory 
> copying is not happening.
>
Well, we want to go beyond that to the point that scipy and other 
Numeric packages can support numarray and Numeric simultaneously. We 
intend to do most of the work to make it so with scipy. f2py already 
has been adapted to work with numarray, and we would
also take a look at the ufunc api issue to deal with that. I think we 
should start
on this fairly soon (certainly within a month or so). This is pretty 
much our
highest priority now that numarray 1.1 is out.

Perry
(Continue reading)

Permalink | Reply | 0 comments |
headers
eric jones | 14 Sep 2004 09:54

Re: Re: [AstroPy] Python version of IDL Astron library

Travis E. Oliphant wrote:

> Since Tom invited me into the discussion, I will comment, despite the 
> fact that I am not an astronomer.
>
>> Hi folks-
>>
>> Sorry to have missed all of the interesting discussion on this; I was
>> at the HEAD meeting (on a panel on astrostatistics software, among
>> other things---lots of folks are interested in Python, by the way).
>>
>> Joe's summary of the main issues was very good.  I agree on many
>> points; here are some possible disagreements.
>>
>>
>>> UNDERLYING PACKAGES
>>>
>>> 1. Numarray for all new code, and to teach to new users.
>>
>
> The reality is that Numarray is not ready as a drop-in replacement for 
> Numeric but people keep introducing it to new users as if it were 
> ready.   This is a real problem in the community right now.
>
> These issues have been discussed before and are on the scipy.org wiki 
> that Eric has started.  Basically the issues preventing a drop-in 
> replacement are 1) small arrays are too slow, 2) no 
> backward-compatible ufunc C-API --- nothing like the compatibility API 
> for arrays exists for ufuncs.  3) migrating legacy code is way too 
> time consuming and effort filled for almost no gain.
(Continue reading)

Permalink | Reply | 4 comments |

Gmane