Should be something like np.arange(f.size) (the current example is not valid)

Of course, thanks

per PEP8, please add spaces after commas.

thanks

can you give a reference here?

ok

This is starting to look a little repetitive. Can you maybe break this out into a few helper functions so it's easier to follow the high level logic?

Alternatively, maybe you can reuse some of the logic for the scalar case dx vs array of coordinates x? e.g., just set a, b and c different?

Done. And also optimised further...now when entering the uniform_spacing branches is ~10-30% faster than original np.gradient

np.gradient 13.1845779419
gradient_opt vector 10.7180240154
gradient_noopt vector 20.1845788956
gradient_opt scalar 10.6630008221
gradient_noopt scalar 13.2290189266

Much better, thanks

I would avoid this sort of optimization if possible -- it adds more complexity to the implementation and function behavior for a questionable performance benefit.

uhm, IMHO it doesn't add too much complexity and may help save a bit of memory, but ok I'll remove it

I have done a couple of tests and it actually seems to provide a non-negligible speed-up:

np.gradient 0.835474014282
gradient_opt scalar 0.849312067032
gradient_noopt scalar 0.865785121918
gradient_opt vector 0.984735012054 
gradient_noopt vector 1.54027509689

I think that it is probably worth keeping it.

Write this in a way that avoids the need to write these checks twice.

Added a reference for finite difference derivation.

Is there a good online reference, e.g., on Wikipedia? That is preferable to a book if possible.

this is good?
http://websrv.cs.umt.edu/isis/index.php/Finite_differencing:_Introduction

I would prefer a source that seems more likely to stick around than a random wikipage, e.g., Wikipedia or a journal article that can be accessed online.

An academic paper available online that describes the method in detail would be ideal, including a description of all necessary assumptions.

Totally agree, but I have searched a bit and while you can find tons of book/slides/lectures I haven't found much papers that provides a clear introduction/presentation for our specific case.
This provides a generic method to compute the coefficients but in our case the Taylor expansion one is enough
That's why in the end I opted for the book.
I could derive it myself and add it directly to the documentation but I don't know if it is appropriate.

Is the discussion on this page helpful??
http://scicomp.stackexchange.com/questions/480/how-can-i-numerically-differentiate-an-unevenly-sampled-function

If this is equivalent to a special case of the method described in the paper you link, that would probably be a better reference here. It would still be good to briefly summarize the assumptions as well (i.e., piece-wise polynomial interpolation, if I understand correctly).

I have added the Notes section and explained how the approximation formula for the interior points is derived. I also tried to clarify why it has a second order of accuracy in case of evenly spaced data to answer questions raised with #8605.
I have removed the references but I can add them back (maybe both the book and the paper) if you think that they are needed.

I am not sure whether I like this version of ifs more that the previous one with duplicated checks. what do you think?

I think this is a step in the right direction. I'll have more detailed suggestions, but let's settle on the overall API first.

This optimisation leads to non negligible speedup

Can you put this note in a comment in the code here?

Done

Done. And also optimised further...now when entering the uniform_spacing branches is ~10-30% faster than original np.gradient

np.gradient 13.1845779419
gradient_opt vector 10.7180240154
gradient_noopt vector 20.1845788956
gradient_opt scalar 10.6630008221
gradient_noopt scalar 13.2290189266

The lines should be broken to keep them < 80 characters. It is OK to do that for references as long as you keep the indentation.

fixed. thanks

This should be TypeError, which is what you get when you don't supply required arguments to a function.

SyntaxError is reserved for Python itself (e.g., if you forget to close parentheses).

Fixed, thanks

Not a fan of this heavy indentation. Why not:

basic_test = {
    50:   {'fd': 8,  'scott': 8,  'rice': 15, 'sturges': 14,
           'auto': 14},
    500:  {'fd': 15, 'scott': 16, 'rice': 32, 'sturges': 20,
           'auto': 20},
    5000: {'fd': 33, 'scott': 33, 'rice': 69, 'sturges': 27,
           'auto': 33}
}

I believe it's just personal preference. If the point of splitting is not excessively reducing the space left before the EOL, I usually prefer to visually align to brackets since I believe it improves readability.

p.s. In my own code I would have kept the original despite the line length for readability

Alignment is actually not PEP8, but for test data it is often useful so we aren't quite as strict about it. That said, the non-aligned versions aren't as bad as one might think and one gets used to them.

@charris If I am not wrong, the alignment I used IS pep8 (https://www.python.org/dev/peps/pep-0008/#id17) (it is the first one presented).

I was referring to the multiple spaces after the : to align the opening brackets. There isn't an example, but aligning on = and multiple spaces are both discouraged, so by extension...

OT: I note on rereading PEP8 that breaking before binary operators is now preferred for new code. I don't recall that from before, but that would be my own preference. Unfortunately, the after recommendation remains for C code...

oh, I see now... sorry... I misinterpreted... you are totally right on multiple spaces.

p.s. I like the before breaking too ;)