[SciPy-dev] scipy.optimize.nonlin rewrite
Mon Dec 8 13:38:31 CST 2008
On Mon, Dec 8, 2008 at 12:42, Ondrej Certik <firstname.lastname@example.org> wrote:
> On Mon, Dec 8, 2008 at 7:11 PM, Pauli Virtanen <email@example.com> wrote:
>> Hi Ondrej,
>> Mon, 08 Dec 2008 18:43:47 +0100, Ondrej Certik wrote:
>>> First let me apologize for taking me so long to reply. I wrote this code
>>> in the first place and I am happy that Pauli has rewritten it. I agree
>>> with the general direction, but I think this change should not go into
>>> 0.7.0, as it changes the interface and it is not well tested yet.
>>> Also, you renamed all the working broyden implementations that I use as
>>> BadBroyden, so I suggest to name them GoodBroyden, more below.
>> Quick comment (I'll post a more thorough reply later on). The "good" and
>> "bad" Broyden's method are names referring to specific ways to update the
>> Jacobian (at least these were the names I learned here in a univ.
>> course), cf. also ; they do not really refer to goodness or badness of
>> the methods, and definitely not to quality of implementation. (If you
>> meant I had mislabeled one of these, please correct me.)
>> ..  http://en.wikipedia.org/wiki/Broyden%27s_method
> Ah, ok --- that wiki didn't exist yet when I wrote this. I only knew
> first Broyden method and a second Broyden method. Well, still I think
> it's weird to call something that works well by BadBrodyen, but if
> that's what people are used to, then ok. Do you have some good
> reference of this, besides wiki?
> And in any case, all of this should be explained in the docstrings.
If there's an alternate set of names, I would suggest going with
those. "Bad" and "Good" are simply going to confuse people.
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- Umberto Eco
More information about the Scipy-dev