David | 1 Apr 03:40 2011
Picon

Re: [SciPy-Dev] ANN: Numpy 1.6.0 beta 1

On 03/31/2011 06:37 PM, Pearu Peterson wrote:
>
>
> On Thu, Mar 31, 2011 at 12:19 PM, David Cournapeau <cournape <at> gmail.com
> <mailto:cournape <at> gmail.com>> wrote:
>
>     On Wed, Mar 30, 2011 at 7:22 AM, Russell E. Owen <rowen <at> uw.edu
>     <mailto:rowen <at> uw.edu>> wrote:
>      > In article
>      > <AANLkTi=eeg8KL7639imRTL-iHg1ncqYoLDDSiD5tfYvs <at> mail.gmail.com
>     <mailto:eeg8KL7639imRTL-iHg1ncqYoLDDSiD5tfYvs <at> mail.gmail.com>>,
>      >  Ralf Gommers <ralf.gommers <at> googlemail.com
>     <mailto:ralf.gommers <at> googlemail.com>> wrote:
>      >
>      >> Hi,
>      >>
>      >> I am pleased to announce the availability of the first beta of NumPy
>      >> 1.6.0. Due to the extensive changes in the Numpy core for this
>      >> release, the beta testing phase will last at least one month. Please
>      >> test this beta and report any problems on the Numpy mailing list.
>      >>
>      >> Sources and binaries can be found at:
>      >> http://sourceforge.net/projects/numpy/files/NumPy/1.6.0b1/
>      >> For (preliminary) release notes see below.
>
>     I see a segfault on Ubuntu 64 bits for the test
>     TestAssumedShapeSumExample in numpy/f2py/tests/test_assumed_shape.py.
>     Am I the only one seeing it ?
>
> The test work here ok on Ubuntu 64 with numpy master. Could you try the
(Continue reading)

Paul Ivanov | 1 Apr 03:42 2011
Picon

Re: ANN: Numpy 1.6.0 beta 1


Ralf Gommers, on 2011-03-23 17:07,  wrote:
> Please test this beta and report any problems on the Numpy
> mailing list.

Hi,

I reopened http://projects.scipy.org/numpy/ticket/1768, as
'test_chisquare' still fails for me on a 32 bit machine. Lowering
the precision from 14 to 13 decimals makes the test pass,
however.

Other than that:

NumPy version 1.6.0b1
NumPy is installed in
/home/pi/.local/lib/python2.6/site-packages/numpy
Python version 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) [GCC
4.4.3]
nose version 0.11.1
--snip--
Ran 3399 tests in 23.052s

FAILED (KNOWNFAIL=3, SKIP=4, failures=1)

best,
--

-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 
(Continue reading)

Charles R Harris | 1 Apr 04:34 2011
Picon

Re: loadtxt/savetxt tickets



On Thu, Mar 31, 2011 at 8:42 AM, Ralf Gommers <ralf.gommers <at> googlemail.com> wrote:
On Thu, Mar 31, 2011 at 4:53 AM, Charles R Harris
<charlesr.harris <at> gmail.com> wrote:
>
>
> On Sun, Mar 27, 2011 at 4:09 AM, Paul Anton Letnes
> <paul.anton.letnes <at> gmail.com> wrote:
>>

<snip>

If you look in Trac under "All Tickets by Milestone" you'll find all
nine tickets together under 1.6.0. Five are bug fixes, four are
enhancements. There are some missing tests, but all tickets have
proposed patches.


OK. I changed 1562 to enhancement because it adds a keyword. With that change the current status looks like this.

Bug Fixes:

1163 -- convert int64 correctly
1458 -- make loadtxt unpack structured arrays
1071 -- loadtxt fails if the last column contains empty value, under discussion
1565 -- duplicate of 1163

Enhancements:

1107 -- support for blocks of data, adds two keywords.
1562 -- add ndmin keyword to aid in getting correct dimensions, doesn't apply on top of previous.
1616 -- remove use of readline so input isn't restricted to files.
1731 -- allow loadtxt to read given number of rows, adds keyword.
1752 -- return empty array when empty file encountered, conflicts with 1616.


Some of this might should go into genfromtxt. None of the patches have tests.

Chuck

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Eli Stevens (Gmail | 1 Apr 05:12 2011
Picon

Re: 1.6.0b1 half float buffer bug?

On Thu, Mar 31, 2011 at 11:45 AM, Ralf Gommers
<ralf.gommers <at> googlemail.com> wrote:
> On Thu, Mar 31, 2011 at 8:37 PM, Eli Stevens (Gmail)
> <wickedgrey <at> gmail.com> wrote:
>> Next up for me is to get a patch onto the CPython issue tracker, but
>> as soon as I have that done, I'll start working on adding unit tests
>> to my numpy fork.  I anticipate being able to get that done today.
>
> Sounds good.

CPython issue here:
http://bugs.python.org/issue11734

My numpy changes so far:
https://github.com/wickedgrey/numpy/compare/23965b6b665985390d7a...maintenance%2F1.6.x

>From my last commit message:
"Note that my changes to _internal were mostly of the "make it work"
variety; I'm not really understanding the wider scope.  Very much
needs review by wiser eyes."

I'd also appreciate some feedback on the unit test coverage; the
test_roundtrip_half function uncovered a problem that the other two
didn't (which surprised me), and I'd like to make sure that there
aren't more gaps in the tests that I've written.

Thanks for all the help!
Eli
Pauli Virtanen | 1 Apr 10:12 2011
Picon
Picon

Re: 1.6.0b1 half float buffer bug?

Thu, 31 Mar 2011 11:15:08 -0700, Mark Wiebe wrote:
[clip]
> My reading of Pauli's thoughts was that putting it in unilaterally is
> undesirable, something I definitely agree with. I think with Eli doing
> the legwork of getting input and acceptance from the relevant parties,
> we should help him out as much as possible.

Yes, this was the main concern. However, reading the thread on 
python-ideas, apart from the choice of the letter there does not seem to 
be much resistance, especially as we have a volunteer for implementing 
any changes required. :)

> Not getting this change into 1.6 makes the Cython support much more
> difficult because of their design based around the buffer protocol.
>
> Looking at the thread on python-users, I see mostly concern that the
> type be standard or have precedent elsewhere, which as an IEEE standard
> it definitely satisfies. The other question is on the chosen letter - we
> picked 'e' as 'h' was taken and it is close to 'f' and 'd', the other
> float types. If a letter change is deemed necessary, it would be good to
> get that into 1.6 as well, since this kind of change is easy now, but
> much more difficult later.

The buffer interface format string does not need to match what Numpy 
internally uses (although that would be clearer), so changing that later 
on, if the Python devs strongly disagree with the choice made, maybe does 
not have *too* much inertia. However, it could be good to come to an 
agreement soon, if possible.

	Pauli
Neal Becker | 1 Apr 15:18 2011
Picon

can't find doc for as_strided

Visiting http://docs.scipy.org/doc/numpy/reference/, as search for

as_strided

or

stride_tricks

shows nothing (useful).

For that matter, I don't see a reference to numpy.lib.
Darren Dale | 1 Apr 20:19 2011
Picon

nearing a milestone

Numpy is nearing a milestone:
http://sourceforge.net/projects/numpy/files/NumPy/stats/timeline?dates=2007-09-25+to+2011-04-01
Benjamin Root | 1 Apr 20:24 2011
Picon

Re: nearing a milestone

Yeah, but they have been downhill since November...

On Fri, Apr 1, 2011 at 1:19 PM, Darren Dale <dsdale24 <at> gmail.com> wrote:
Numpy is nearing a milestone:
http://sourceforge.net/projects/numpy/files/NumPy/stats/timeline?dates=2007-09-25+to+2011-04-01
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Ralf Gommers | 1 Apr 21:41 2011

Re: can't find doc for as_strided

On Fri, Apr 1, 2011 at 3:18 PM, Neal Becker <ndbecker2 <at> gmail.com> wrote:
> Visiting http://docs.scipy.org/doc/numpy/reference/, as search for
>
> as_strided
>
> or
>
> stride_tricks
>
> shows nothing (useful).

That's because as_strided is not exposed. It's a private function (see
commit f912322e) used in broadcast_arrays, which is there:
http://docs.scipy.org/doc/numpy/reference/generated/numpy.broadcast_arrays.html

>
> For that matter, I don't see a reference to numpy.lib.

Things in numpy.lib that are not private are available in the numpy
namespace (see numpy.lib.function_base.histogram in the doc wiki vs.
numpy.histogram in the reference guide).

Ralf
Ralf Gommers | 1 Apr 21:51 2011

Re: np.histogramdd of empty data

On Thu, Mar 31, 2011 at 8:00 PM, Benjamin Root <ben.root <at> ou.edu> wrote:
>
>
> On Thu, Mar 31, 2011 at 12:32 PM, Ralf Gommers <ralf.gommers <at> googlemail.com>
> wrote:
>>
>> ---------- Forwarded message ----------
>> From: Ralf Gommers <ralf.gommers <at> googlemail.com>
>> Date: Thu, Mar 31, 2011 at 7:31 PM
>> Subject: Re: [Numpy-discussion] np.histogramdd of empty data
>> To: Nils Becker <n.becker <at> amolf.nl>
>>
>>
>> On Thu, Mar 31, 2011 at 12:33 PM, Nils Becker <n.becker <at> amolf.nl> wrote:
>> > Hi Ralf,
>> >
>> > I cloned numpy/master and played around a little.
>> >
>> > when giving the bins explicitely, now histogram2d and histogramdd work
>> > as expected in all tests i tried.
>> >
>> >
>> > However, some of the cases with missing bin specification appear
>> > somewhat inconsistent.
>> >
>> > The first question is if creating arbitrary bins for empty data and
>> > empty bin specification is better than raising an Exception:
>> >
>> > Specifically:
>>
>> Bins of size 0 should give a meaningful error, I was just fixing that
>> as part of #1788 in
>> https://github.com/rgommers/numpy/tree/ticket-1788-histogramdd
>>
>> > numpy.histogram2d([],[],bins=[0,0])
>> >> (array([ 0.,  0.]), array([ 0.]), array([ 0.]))
>>
>> Now gives:
>>    ValueError: Element at index 0 in `bins` should be a positive integer.
>>
>> > numpy.histogram([],bins=0)
>> >> ValueError: zero-size array to minimum.reduce without identity
>>
>> Now gives:
>>    ValueError: `bins` should be a positive integer.
>>
>>
>> > so 1-d and 2-d behave not quite the same.
>> >
>> > also, these work (although with arbitrary bin edges):
>> >
>> > numpy.histogram2d([],[],bins=[1,1])
>> >> (array([ 0.,  0.]), array([ 0.,  1.]), array([ 0.,  1.]))
>> >
>> > numpy.histogram2d([],[],bins=[0,1])
>> >> (array([ 0.,  0.]), array([ 0.]), array([ 0.,  1.]))
>> >
>> > while this raises an error:
>> >
>> > numpy.histogram([],bins=1)
>> >> ValueError: zero-size array to minimum.reduce without identity
>>
>> Now gives:
>>    (array([0]), array([ 0.,  1.]))
>>
>
> Just for consistency's sake, maybe the same should be done for np.bincount()
> and np.digitize() for empty data (but known bins)?  I don't know if your fix
> to histogram does this or not, but the latest pull from numpy master doesn't
> do this.

It doesn't. There was a ticket for that already, #1387. I added the
desired behavior there. Since those functions are written in C it's a
little more time-consuming to fix.

Ralf

Gmane