[SciPy-dev] Scipy workflow (and not tools).

[Ondrej Certik]

On Thu, Feb 26, 2009 at 5:55 AM, Alex Griffing <argriffi at ncsu.edu> wrote:
>
>> 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.
>
> Hi I'm also mostly a lurker.  Here's a story about the time I tried to
> contribute to scipy.
>
> Maybe a year ago I wanted a procedure to attempt to optimize some aspect
> of a multidimensional function.  I found scipy.optimize, but the
> procedure that I tried failed by dividing by zero.  Undaunted, I started
> digging in the scipy source code, finding the error in the broyden2
> function.  The problem was that the algorithm was finding the correct
> solution in fewer than the default number of iterations and was dividing
> by an error term that was zero.
>
> I sent an email to a scipy mailing list saying that this function needed
> some kind of check to see if it was done (error near zero) so that it
> could stop iterating so that it would not divide by zero.  I got a reply
> saying that I needed to write a patch that included the fix to the
> function and a new test that used to fail but that now passes.  So I
> simplified my failing code, I changed the broyden2 function in a way
> that I thought would fix the problem, and I sent the code to the mailing
> list.  I got a reply saying that what they meant by a patch was an svn diff.
>
> So I installed svn and I checked out the scipy code with the idea that I
> could change my local copy, test my changes, and send the diff to the
> mailing list.  After spending some time trying to get this working, I
> stopped for the following reasons:
>
> 1) Binary format and path problems were causing me grief.
> 2) I already had a scipy that worked, and I didn't want to break this.
> 3) Neil's comment:
> """
> If I want to make a change, I have to check out the trunk and then
> develop my change *completely without the benefit of version control*.
> I am not allowed to make any intermediate commits while I learn my way
> through the coding process.  I must submit a fully formed patch without
> ever being able to checkpoint my own progress.  This is basically a
> deal-breaker for me.
> """
>

Hi Alex,

it was my who was trying to help you with this. The problem was, that
people who have svn access to scipy (e.g. I don't) are very busy, and
do you must submit your patches in a way so that it is easy for them
to apply it. I agree that git is much easier to use for that, but imho
it's not difficult to create a patch with svn as well, especially if
you have a working scipy on your computer.

Just checkout the svn, copy your working scipy files over it, do "svn
di" and send us the patch.

> I think I still use code that works around this bug by using the
> iteration keyword argument to specify a fewer-than-default number of
> iterations so that the error never reaches zero.

If you find time, please do send us the patch with the fix+tests, it
will be applied.

Thanks a lot,
Ondrej