Re: [Numpy-discussion] Quick question on NumPy builds vs. Cython

[David Cournapeau]

On Tue, Aug 25, 2009 at 9:44 PM, Charles R
Harris wrote:
>
>
> On Tue, Aug 25, 2009 at 11:30 AM, David Cournapeau 
> wrote:
>>
>> Hi Dag,
>>
>> On Tue, Aug 25, 2009 at 12:19 PM, Dag Sverre
>> Seljebotn wrote:
>> > [Let me know if this should go to numpy-discuss instead.]
>> >
>>
>> I guess this can be discussed on the ML as well (I CC to the list).
>>
>> >
>> > I see that there are currently two modes, and that it is possible to
>> > build
>> > NumPy using a master .c-file #include-ing the rest. (Which is much more
>> > difficult to support using Cython, though not impossible.)
>> >
>> > Is there any plans for the one-file build to go away, or is supporting
>> > this
>> > a requirement?
>>
>> This is a requirement, as supporting this depends on non standard
>> compilers extensions (that's why it is not the default - but it works
>> well, I am always using this mode when working on numpy since the
>> build/test/debug cycle is so much shorter with numscons and this).
>>
>> The basic problem is as follows:
>>  - On Unix at least, a function is exported in a shared library by
>> default.
>>  - The usual way to avoid polluting the namespace is to put static in
>> front of it
>>  - You can't reuse a static function in another compilation unit
>> (there is no "friend static").
>>
>> So what happens in the multi-files build is that the function are
>> tagged as hidden instead of static, with hidden being
>> __attribute__((hidden)) for gcc, nothing for MS compiler (on windows,
>> you have to tag the exported functions, nothing is exported by
>> default), and will break on other platforms.
>
> Does the build actually break or is it the case that a lot of extraneous
> names become visible, increasing the module size and exposing functions that
> we don't what anyone to access?

I think the latter. The number of exported symbols is pretty high, though.

cheers,

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] mirr test correctly fails for given input.

[josef . pktd]

On Tue, Aug 25, 2009 at 11:38 PM, Charles R
Harris wrote:
> So is it a bug in the test or a bug in the implementation? The problem is
> that the slice values[1:] when
> values =  [-12,39000,3,21000,37000,46000] contains no negative
> number and a nan is returned. This looks like a bug in the test. The
> documentation also probably needs fixing.
>
> Chuck

There is a bug in the code, the nan is incorrectly raised. After
correcting the nan (checking on the original, instead of shortened
values), I got one failing test, that I corrected with the matching
number from Openoffice.

(The main problem that the function is more complicated than
necessary, is because np.npv doesn't allow the inclusion of the
investment in the initial period)

This needs reviewing, since it's late here.

Josef


import numpy as np
from numpy.testing import assert_almost_equal, assert_

from numpy import npv

def mirr(values, finance_rate, reinvest_rate):
"""
Modified internal rate of return.

Parameters
--
values : array_like
Cash flows (must contain at least one positive and one negative value)
or nan is returned.
finance_rate : scalar
Interest rate paid on the cash flows
reinvest_rate : scalar
Interest rate received on the cash flows upon reinvestment

Returns
---
out : float
Modified internal rate of return

"""

values = np.asarray(values, dtype=np.double)
initial = values[0]
values1 = values[1:]
n = values1.size
pos = values1 > 0
neg = values1 < 0
if not (np.sum(values[values>0]) > 0 and np.sum(values[values<0]) < 0):
return np.nan
numer = np.abs(npv(reinvest_rate, values1*pos))
denom = np.abs(npv(finance_rate, values1*neg))
if initial > 0:
return ((initial + numer) / denom)**(1.0/n)*(1 + reinvest_rate) - 1
else:
return ((numer / (-initial + denom)))**(1.0/n)*(1 + reinvest_rate) - 1





#tests from testsuite and Skipper plus isnan test

v1 = [-4500,-800,800,800,600,600,800,800,700,3000]
print mirr(v1,0.08,0.055)
assert_almost_equal(mirr(v1,0.08,0.055),
0.0666, 4)

#incorrect test ? corrected
v2 = [-12,39000,3,21000,37000,46000]
print mirr(v2,0.10,0.12)
assert_almost_equal(mirr(v2,0.10,0.12), 0.126094, 6)  # corrected from OO


v2 = [39000,3,21000,37000,46000]
assert_(np.isnan(mirr(v2,0.10,0.12)))


v3 = [100,200,-50,300,-200]
print mirr(v3,0.05,0.06)
assert_almost_equal(mirr(v3,0.05,0.06), 0.3428, 4)


#--
print mirr([100, 200, -50, 300, -200], .05, .06)
assert_almost_equal(mirr((100, 200,-50, 300,-200), .05, .06),
0.342823387842, 4)

V2 = [-4500,-800,800,800,600,600,800,800,700,3000]
print mirr(V2, 0.08, 0.055)
assert_almost_equal(mirr(V2, 0.08, 0.055), 0.06659718, 4)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] mirr test correctly fails for given input.

[Charles R Harris]

So is it a bug in the test or a bug in the implementation? The problem is
that the slice values[1:] when
values =  [-12,39000,3,21000,37000,46000] contains no negative
number and a nan is returned. This looks like a bug in the test. The
documentation also probably needs fixing.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quick question on NumPy builds vs. Cython

[Charles R Harris]

On Tue, Aug 25, 2009 at 11:30 AM, David Cournapeau wrote:

> Hi Dag,
>
> On Tue, Aug 25, 2009 at 12:19 PM, Dag Sverre
> Seljebotn wrote:
> > [Let me know if this should go to numpy-discuss instead.]
> >
>
> I guess this can be discussed on the ML as well (I CC to the list).
>
> >
> > I see that there are currently two modes, and that it is possible to
> build
> > NumPy using a master .c-file #include-ing the rest. (Which is much more
> > difficult to support using Cython, though not impossible.)
> >
> > Is there any plans for the one-file build to go away, or is supporting
> this
> > a requirement?
>
> This is a requirement, as supporting this depends on non standard
> compilers extensions (that's why it is not the default - but it works
> well, I am always using this mode when working on numpy since the
> build/test/debug cycle is so much shorter with numscons and this).
>
> The basic problem is as follows:
>  - On Unix at least, a function is exported in a shared library by default.
>  - The usual way to avoid polluting the namespace is to put static in
> front of it
>  - You can't reuse a static function in another compilation unit
> (there is no "friend static").
>
> So what happens in the multi-files build is that the function are
> tagged as hidden instead of static, with hidden being
> __attribute__((hidden)) for gcc, nothing for MS compiler (on windows,
> you have to tag the exported functions, nothing is exported by
> default), and will break on other platforms.
>

Does the build actually break or is it the case that a lot of extraneous
names become visible, increasing the module size and exposing functions that
we don't what anyone to access?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] filters for rows or columns

[Robert Kern]

On Tue, Aug 25, 2009 at 16:18, Giuseppe Aprea wrote:
> Hi,  I would like to do something like this
>
> a=array([[1,2,3,4],[5,6,7,8],[4,5,6,0]])
> idxList=[]
> for i in range(0,a.shape[1]):
>    if len(nonzero(a[:,i])[0])==1:   #want to extract column indices
> of those columns which only have one non vanishing element
>         idxList.append(i)
>
> I already used where on !D array but I don't know if there is some function or
> some kind of syntax which allow you to evaluate a condition for each
> column(row).

column_mask = ((a != 0).sum(axis=1) == 1)
idxArray = np.nonzero(column_mask)[0]  # if you must

-- 
Robert Kern

"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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] filters for rows or columns

[Giuseppe Aprea]

On Tue, Aug 25, 2009 at 8:13 PM, Robert Kern wrote:
> On Tue, Aug 25, 2009 at 11:07, Giuseppe Aprea wrote:
>> Hi list,
>>
>>
>> I wonder if there is any smarter way to apply a filter to a 2 dimensional 
>> array
>> than a for loop:
>>
>> a=array(...)
>> idxList=[]
>> for i in range(0,a.shape[1]):
>>       if (some condition on a[:,i]):
>>             idxList.append(i)
>
> Define a "some condition on a[:,i]" that is of interest to you, and I
> will show you how to do it. Roughly, you should define a function that
> takes 'a' and operates on it in bulk in order to get a boolean array
> of shape (a.shape[0],) evaluating the condition for each column. Then
> use numpy.where() on that boolean array to get indices if you actually
> need indices; frequently, you can just use the boolean array where you
> wanted the indices.
>
> --
> Robert Kern
>
> "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
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>

Hi,  I would like to do something like this

a=array([[1,2,3,4],[5,6,7,8],[4,5,6,0]])
idxList=[]
for i in range(0,a.shape[1]):
if len(nonzero(a[:,i])[0])==1:   #want to extract column indices
of those columns which only have one non vanishing element
 idxList.append(i)

I already used where on !D array but I don't know if there is some function or
some kind of syntax which allow you to evaluate a condition for each
column(row).

regards
g
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] A better median function?

[Sturla Molden]

Chad Netzer skrev:
> My current plan of attack is to deliver a partition() function that
> basically returns an array such that elements less than the pivot(s)
> come first, then the pivot(s), then the elements greater than the
> pivot(s).  

I'm actually trying to write a fast median replacement myself. I was 
thinking in the same lines, except I don't store those two arrays. I 
just keep track of counts in them. For the even case, I also keep track 
the elements closest to the pivot (smaller and bigger). It's incredibly 
simple actually. So lets see who gets there first :-)

Sturla Molden





___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] c++ comments in parse_datetime.c

[Charles R Harris]

On Tue, Aug 25, 2009 at 1:05 PM, Pierre GM  wrote:

>
> On Aug 25, 2009, at 1:59 PM, Skipper Seabold wrote:
>
> > On Tue, Aug 25, 2009 at 1:51 PM, Charles R
> > Harris wrote:
> >> Hi Travis,
> >>
> >> The new parse_datetime.c file contains a lot of c++ style comments
> >> that
> >> should be fixed. Also, the new test for mirr is failing on all the
> >> buildbots.
>
> Comments sent to Marty who wrote the parse_datetime.c as part of his
> GSoC: Marty, I guess you have a bit of cleaning up to do.
> (As a snarky side note, Marty posted on the list a few weeks ago
> asking just for this kind of comments... But all is well and better
> late than never.)


My bad, then, I missed it. So let me add

1) Because the default compilation is to include all the files in a master
file, the local defines should be undef'ed at the end to avoid namespace
pollution.

2) Never do this:

 if (bug) return -1;

or this

if (bug) {blah; blah;}

do it this way

if (bug) {
return -1;
}

The last is more for Travis in the most recent commit ;)

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] c++ comments in parse_datetime.c

[Pierre GM]

On Aug 25, 2009, at 1:59 PM, Skipper Seabold wrote:

> On Tue, Aug 25, 2009 at 1:51 PM, Charles R
> Harris wrote:
>> Hi Travis,
>>
>> The new parse_datetime.c file contains a lot of c++ style comments  
>> that
>> should be fixed. Also, the new test for mirr is failing on all the
>> buildbots.

Comments sent to Marty who wrote the parse_datetime.c as part of his  
GSoC: Marty, I guess you have a bit of cleaning up to do.
(As a snarky side note, Marty posted on the list a few weeks ago  
asking just for this kind of comments... But all is well and better  
late than never.)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] c++ comments in parse_datetime.c

[Charles R Harris]

On Tue, Aug 25, 2009 at 11:51 AM, Charles R Harris <
charlesr.har...@gmail.com> wrote:

> Hi Travis,
>
> The new parse_datetime.c file contains a lot of c++ style comments that
> should be fixed. Also, the new test for mirr is failing on all the
> buildbots.
>

Also,

1) There are two macros with gotos, which is a no-no. You could use inline
functions instead or just write out the code where needed.

2) Multiline comments like so:
/*
 * blah, blah
 */

3) Think twice about using trailing comments.

4) The constant defines should be collected in one spot and documented.

5) Use blank lines between all function definitions.

6) Use {} around all if statement blocks

7) Format else like so:
}
else if (bug) {
blah;
}

8) The file contains hard tabs and trailing whitespace.

9) A number of lines are longer than 80 characters.

Yours Truly,
The Pedant ;)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] c++ comments in parse_datetime.c

[Skipper Seabold]

On Tue, Aug 25, 2009 at 1:51 PM, Charles R
Harris wrote:
> Hi Travis,
>
> The new parse_datetime.c file contains a lot of c++ style comments that
> should be fixed. Also, the new test for mirr is failing on all the
> buildbots.
>
> Chuck
>

Hi,

For mirr it looks like the lines in the patch


pos = values * (values>0)
neg = values * (values<0)

were copied to the trunk as

pos = values > 0
neg = values < 0

This is probably my fault for not submitting the patch as a diff.

Skipper
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] filters for rows or columns

[Robert Kern]

On Tue, Aug 25, 2009 at 11:07, Giuseppe Aprea wrote:
> Hi list,
>
>
> I wonder if there is any smarter way to apply a filter to a 2 dimensional 
> array
> than a for loop:
>
> a=array(...)
> idxList=[]
> for i in range(0,a.shape[1]):
>       if (some condition on a[:,i]):
>             idxList.append(i)

Define a "some condition on a[:,i]" that is of interest to you, and I
will show you how to do it. Roughly, you should define a function that
takes 'a' and operates on it in bulk in order to get a boolean array
of shape (a.shape[0],) evaluating the condition for each column. Then
use numpy.where() on that boolean array to get indices if you actually
need indices; frequently, you can just use the boolean array where you
wanted the indices.

-- 
Robert Kern

"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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] filters for rows or columns

[Giuseppe Aprea]

Hi list,


I wonder if there is any smarter way to apply a filter to a 2 dimensional array
than a for loop:

a=array(...)
idxList=[]
for i in range(0,a.shape[1]):
   if (some condition on a[:,i]):
 idxList.append(i)


thanks in advance.

g
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] c++ comments in parse_datetime.c

[Skipper Seabold]

On Tue, Aug 25, 2009 at 1:59 PM, Skipper Seabold wrote:
> On Tue, Aug 25, 2009 at 1:51 PM, Charles R
> Harris wrote:
>> Hi Travis,
>>
>> The new parse_datetime.c file contains a lot of c++ style comments that
>> should be fixed. Also, the new test for mirr is failing on all the
>> buildbots.
>>
>> Chuck
>>
>
> Hi,
>
> For mirr it looks like the lines in the patch
> 
>
> pos = values * (values>0)
> neg = values * (values<0)
>
> were copied to the trunk as
>
> pos = values > 0
> neg = values < 0
>
> This is probably my fault for not submitting the patch as a diff.
>

Oops nevermind I didn't see that npv is now provided pos*values and neg*values.

Skipper
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] c++ comments in parse_datetime.c

[Charles R Harris]

Hi Travis,

The new parse_datetime.c file contains a lot of c++ style comments that
should be fixed. Also, the new test for mirr is failing on all the
buildbots.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quick question on NumPy builds vs. Cython

[David Cournapeau]

Hi Dag,

On Tue, Aug 25, 2009 at 12:19 PM, Dag Sverre
Seljebotn wrote:
> [Let me know if this should go to numpy-discuss instead.]
>

I guess this can be discussed on the ML as well (I CC to the list).

>
> I see that there are currently two modes, and that it is possible to build
> NumPy using a master .c-file #include-ing the rest. (Which is much more
> difficult to support using Cython, though not impossible.)
>
> Is there any plans for the one-file build to go away, or is supporting this
> a requirement?

This is a requirement, as supporting this depends on non standard
compilers extensions (that's why it is not the default - but it works
well, I am always using this mode when working on numpy since the
build/test/debug cycle is so much shorter with numscons and this).

The basic problem is as follows:
  - On Unix at least, a function is exported in a shared library by default.
  - The usual way to avoid polluting the namespace is to put static in
front of it
  - You can't reuse a static function in another compilation unit
(there is no "friend static").

So what happens in the multi-files build is that the function are
tagged as hidden instead of static, with hidden being
__attribute__((hidden)) for gcc, nothing for MS compiler (on windows,
you have to tag the exported functions, nothing is exported by
default), and will break on other platforms.

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion