> > Right now it looks like there is a mix of attitudes, about the
> > financial
> > functions. They are a small enough addition, that I don't think it
> > matters terribly much what we do with them. So, it seems to me that
> > keeping them in numpy.lib and following the rule for that names
I'm just a numpy user, but for what it's worth, I would much prefer to
have a single numpy namespace with a small as possible number of
objects inside that namespace. To me, 'as small as possible' means
that it only includes the array and associated array manipulation
functions (searchsorted, where
On Fri, Apr 4, 2008 at 3:31 PM, Anne Archibald <[EMAIL PROTECTED]>
wrote:
> On 04/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> > On Fri, 4 Apr 2008, Gael Varoquaux apparently wrote:
> > > I really thing numpy should be as thin as possible, so
> > > that you can really say that it is only a
On 04/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> On Fri, 4 Apr 2008, Gael Varoquaux apparently wrote:
> > I really thing numpy should be as thin as possible, so
> > that you can really say that it is only an array
> > manipulation package. This will also make it easier to
> > sell as a
On Fri, Apr 4, 2008 at 9:49 AM, Travis E. Oliphant
<[EMAIL PROTECTED]> wrote:
> However, if clearly better interfaces can be discovered, then we could
> change it. For now, the functions are not imported into the numpy
> namespace but live in
>
> numpy.lib.financial
>
> I could see a future
On Fri, Apr 4, 2008 at 10:17 AM, Joris De Ridder <
[EMAIL PROTECTED]> wrote:
>
> On 04 Apr 2008, at 16:11, Travis E. Oliphant wrote:
>
> >
> > There are only two reasons that I can think of right now to keep
> > them in
> > NumPy instead of moving them to SciPy.
> >
> > 1) These are "basic" funct
On 04 Apr 2008, at 16:11, Travis E. Oliphant wrote:
>
> There are only two reasons that I can think of right now to keep
> them in
> NumPy instead of moving them to SciPy.
>
> 1) These are "basic" functions and a scipy toolkit would contain
> much more.
Isn't this something you want to avoi
-1 for any functions added to numpy.
As only an end-user, I realize I have little right to a say in these
sorts of issues, but for whatever it may be worth, I strongly agree
with Gael's viewpoint. We should be aiming towards modular systems for
function distribution, and now that it seems that the
On Fri, 4 Apr 2008, Gael Varoquaux apparently wrote:
> I really thing numpy should be as thin as possible, so
> that you can really say that it is only an array
> manipulation package. This will also make it easier to
> sell as a core package for developpers who do not care
> about "calculator"
+1 for simple financial functions in numpy, and congrats that it's on
OLPC! If we have an FFT in numpy, we should have an internal rate of
return. Anyone with investments needs that, and that's more people
than those needing an FFT.
I agree that Excel will bring in the most familiarity, but thei
On Fri, Apr 04, 2008 at 09:11:37AM -0500, Travis E. Oliphant wrote:
> There are only two reasons that I can think of right now to keep them in
> NumPy instead of moving them to SciPy.
> 1) These are "basic" functions and a scipy toolkit would contain much more.
> 2) These are widely used and wou
A Friday 04 April 2008, Travis E. Oliphant escrigué:
> Sebastian Haase wrote:
> > Hi Travis,
> > This sounds of course very interesting, but could you elaborate on
> > the reasoning why this should not rather be "only" in SciPy !? I
> > thought many people think that numpy was already too crowded a
Sebastian Haase wrote:
> Hi Travis,
> This sounds of course very interesting, but could you elaborate on the
> reasoning why this should not rather be "only" in SciPy !?
> I thought many people think that numpy was already too crowded and
> should concentrate mostly on being a basic array handling
Sebastian Haase wrote:
> Hi Travis,
> This sounds of course very interesting, but could you elaborate on the
> reasoning why this should not rather be "only" in SciPy !?
> I thought many people think that numpy was already too crowded and
> should concentrate mostly on being a basic array handling
On Fri, Apr 04, 2008 at 03:58:39PM +0200, Sebastian Haase wrote:
> This sounds of course very interesting, but could you elaborate on the
> reasoning why this should not rather be "only" in SciPy !?
> I thought many people think that numpy was already too crowded and
> should concentrate mostly on
Hi Travis,
This sounds of course very interesting, but could you elaborate on the
reasoning why this should not rather be "only" in SciPy !?
I thought many people think that numpy was already too crowded and
should concentrate mostly on being a basic array handling facility.
I'm sure you have a go
Hi all,
Last night I put together some simple financial functions based on the
basic ones available in Excel (and on a financial calculator). It seems
to me that NumPy ought to have these basic functions.
There may be some disagreement about what to call them and what the
interface should be
17 matches
Mail list logo
