Rework functions to use ufuncs?

[person142]

The implementation of e.g. nper:

https://github.com/numpy/numpy-financial/blob/master/numpy_financial/_financial.py#L229

requires the usual “split the array up using boolean indexes and then do different things to each hunk” stuff that you have to do when writing a function with conditional logic that operates on an entire array. This tends to lead to convoluted, hard-to-maintain code. (And nper still has more edge cases that need to be handled, so there will need to be more boolean arrays!)

One solution to this problem is to write ufuncs so that you can work with scalars and just use conditional logic. The numpy_financial functions can’t be full ufuncs because they have default arguments, but most of them can be very thin wrappers around a ufunc.

The disadvantage of introducing ufuncs is that you introduce compiled code, but perhaps it is worth it? Code for generating the loops from scalar kernels can be grabbed from SciPy (though it can be stripped down for numpy_financial since less languages need to be supported).

[Kai-Striega]

This could be a good idea. The exiting split/index implementations does become convoluted especially, as you have already said, for functions with multiple edge cases. I'm not familiar enough with the low level details behind ufuncs to talk about the pros and cons in depth.

Regarding the compiled code, as we won't really need the performance benefits, is it simpler to user frompyufunc for the underlying functions?

@WarrenWeckesser thoughts?

[Kai-Striega]

@charris could I ask for your opinion on this?

Personally, I agree with @person142 that the current approach (“split the array up using Boolean indexes and then do different things to each hunk”) isn't great and could be improved by using ufuncs. However, I haven't worked with the C side of ufuncs enough to be able to discuss the pro/cons in depth.

[person142]

I guess lurking in the background there's also a bigger question of "what is the future of numpy_financial?" If the answer is "the package will be these 10 functions forever" then maybe the extra effort isn't warranted. If there are more ambitious goals in mind then you're going to want compiled code at some point anyway...

[Kai-Striega]

With regard to the scope, ideally we'd be able to determine what the people actually using the financial functions will actually use. Even if we were to add more functions, with no-one to use them, the extra effort wouldn't be warranted regardless. There were some rejected PRs (e.g. np-11058 or gh-9414) so at least some demand for extensions exist.

If we do choose to expand I think the demand for "full" libraries is already filled (e.g. QuantLib). I like the scope of a financial calculator as proposed by Travis in the original discussion.

NumPy already contains functions that make it equivalent to a basic scientific calculator, should it not also contain the functions that make it equivalent to the same calculator when placed in "financial" mode? -- Travis O.

That would also include dealing with dates and many of the intricacies of the financial industry - which I don't have the expertise to maintain, or could reasonably expect someone else to have. @joelowj and @duncangh you've both been involved with numpy's financial functions, do you have any input on the future scope?

[joelowj]

@Kai-Striega, you're right. I agree with you that even if we add more functions, it will hardly get any traction as there are plenty of libraries out there that have filled the gap.

[duncangh]

IMHO, with regard to scope, I think that the best strategy would be to offer the most general and abstract functionality at the base of the field of finance. For instance, instead of catering to more complex issues like date functionality, I would recommend to allow higher level libraries to do that functionality. The best cross section to focus on, in my opinion, would be the industry fundamentals, such as present value of future cash flows. With that said, I think that the pull request which implemented a CAPM model would fall well within an appropriate scope of the project beyond what currently exists. Just my two cents.

…

On Sun, Nov 24, 2019 at 1:44 AM Joel Ong ***@***.***> wrote: @Kai-Striega <https://github.com/Kai-Striega>, you're right. I agree with you that even if we add more functions, it will hardly get any traction as there are plenty of libraries out there that have filled the gap. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23?email_source=notifications&email_token=ADTT4HLEFEA7FXCBY5BKMQ3QVIPFXA5CNFSM4JGKFKY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFAE5IY#issuecomment-557862563>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADTT4HMSMRELTAJALJGIK73QVIPFXANCNFSM4JGKFKYQ> .

-- Graham Duncan (919) 819-4302 <https://twitter.com/graham__duncan> <https://github.com/duncangh> <https://duncangh.com>

[joelowj]

@duncangh @Kai-Striega. Based on my experience in the industry, most of the fundamental stuff which mostly involved calculating ratios, cash flow and etc, are more suited to be done on Excel. At the same time, the more technical people in finance are the quants who would not be too interested in this basic financial functions.

Unless we are clear who are the people we are targeting and what exactly are this functions, I don't think it is worth pursuing.