On Wed, Jun 12, 2013 at 7:55 PM, Anne Archibald wrote:
> On 9 June 2013 13:23, David Cournapeau wrote:
>>
>> So it depends on the CPU, the OS and the compiler. Using long double
>> for anything else than compatibility (e.g. binary files) is often a
>> mistake IMO, and highly unportable.
>
>
> Now
On 12 June 2013 18:27, Chris Barker - NOAA Federal
wrote:
>> without documentation and testing.
>
> This one is easy: add documentation and testing!
This lecture may help you. It uses unittest, though, but the idea is
applicable to whatever system you use:
https://python.g-node.org/python-summer
On Wed, Jun 12, 2013 at 12:00 PM, Phil Hodge wrote:
> On 06/12/2013 02:55 PM, Eric Firing wrote:
> I would interpret np.filled as a test, asking whether the array is
> filled. If the function is supposed to do something related to
> assigning values, the name should be a verb.
or a noun: ones,
On Wed, Jun 12, 2013 at 6:48 AM, Nathaniel Smith wrote:
> Sounds like a doc bug. (Probably someone being over-careful -- the
> default for many operations in numpy is that it's undefined whether
> they return a view or not, so if it makes a difference to you you need
> to take an explicit copy or
On Wed, Jun 12, 2013 at 3:38 PM, Moroney, Catherine M (398D)
wrote:
> Thanks for the tip. I thought it must be something simple like that. When I
> convert
> the arrays to numpy.int32 things behave normally.
>
> Another question though: a numpy.all() on the signed-int arrays shows that
> they
Thanks for the tip. I thought it must be something simple like that. When I
convert
the arrays to numpy.int32 things behave normally.
Another question though: a numpy.all() on the signed-int arrays shows that they
are equal. So why would the subtraction of the unsigned arrays wrap around
l
Hello,
I've got two arrays of the same shape that I read in from a file, and I'm
trying to
difference them. Very simple stuff, but I'm getting weird answers.
Here is the code:
>>> counts1 = hfile1.read_grid_field("CFbA",
>>> "TerrainReferencedRCCMFraction_Num")
>>> counts2 = hfile2.read_grid_
On Wed, Jun 12, 2013 at 3:25 PM, Moroney, Catherine M (398D)
wrote:
> Hello,
>
> I've got two arrays of the same shape that I read in from a file, and I'm
> trying to
> difference them. Very simple stuff, but I'm getting weird answers.
>
> Here is the code:
>
counts1 = hfile1.read_grid_fiel
On Wed, Jun 12, 2013 at 3:25 PM, Moroney, Catherine M (398D) <
catherine.m.moro...@jpl.nasa.gov> wrote:
> Hello,
>
> I've got two arrays of the same shape that I read in from a file, and I'm
> trying to
> difference them. Very simple stuff, but I'm getting weird answers.
>
> Here is the code:
>
>
On 06/12/2013 07:27 PM, Julian Taylor wrote:
> I'm guessing you are using openblas?
I can confirm hanging with OpenBLAS using OpenMP.
> there are known hanging problems with openblas and multiprocessing.
> you can work around them by disabling threading in openblas
> (OPENBLAS_NUM_THREADS=1).
T
On 06/12/2013 02:55 PM, Eric Firing wrote:
> Consensus on np.filled? absolutely not, you do not have a consensus.
I would interpret np.filled as a test, asking whether the array is
filled. If the function is supposed to do something related to
assigning values, the name should be a verb.
Phil
On 9 June 2013 13:23, David Cournapeau wrote:
> So it depends on the CPU, the OS and the compiler. Using long double
> for anything else than compatibility (e.g. binary files) is often a
> mistake IMO, and highly unportable.
>
Now this I have to comment on. Long double is highly questionable for
On 2013/06/12 8:13 AM, Warren Weckesser wrote:
> That's why I suggested 'filledwith' (add the underscore if you like).
> This also allows a corresponding masked implementation, 'ma.filledwith',
> without clobbering the existing 'ma.filled'.
Consensus on np.filled? absolutely not, you do not have a
On Wed, Jun 12, 2013 at 11:49 AM, Eric Firing wrote:
> On 2013/06/12 4:18 AM, Nathaniel Smith wrote:
>> Now imagine a different new version of this page, if we overload
>> 'empty' to add a fill= option. I don't even know how we document that
>> on this page. The list will remain:
>>empty
>>
Hi,
On Wed, Jun 12, 2013 at 7:49 PM, Eric Firing wrote:
> On 2013/06/12 4:18 AM, Nathaniel Smith wrote:
>> Now imagine a different new version of this page, if we overload
>> 'empty' to add a fill= option. I don't even know how we document that
>> on this page. The list will remain:
>>empty
>
On 2013/06/12 4:18 AM, Nathaniel Smith wrote:
> Now imagine a different new version of this page, if we overload
> 'empty' to add a fill= option. I don't even know how we document that
> on this page. The list will remain:
>empty
>ones
>zeros
Opposite of "empty": "full". So that is an
On 2013/06/12 2:10 AM, Nathaniel Smith wrote:
> Hi all,
>
> It looks like we've gotten a bit confused and need to untangle
> something. There's a PR to add new functions 'np.filled' and
> 'np.filled_like':
>https://github.com/numpy/numpy/pull/2875
> And there was a discussion about this on the
On Wed, Jun 12, 2013 at 2:00 PM, Nathaniel Smith wrote:
> On 12 Jun 2013 18:20, "Ralf Gommers" wrote:
> >
> >
> >
> >
> > On Wed, Jun 12, 2013 at 6:36 PM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
> >>
> >> On Wed, Jun 12, 2013 at 5:10 AM, Nathaniel Smith wrote:
> >>
> >> >
On 12 Jun 2013 18:20, "Ralf Gommers" wrote:
>
>
>
>
> On Wed, Jun 12, 2013 at 6:36 PM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
>>
>> On Wed, Jun 12, 2013 at 5:10 AM, Nathaniel Smith wrote:
>>
>> > Personally I think that overloading np.empty is horribly ugly, will
>> > continu
On 12.06.2013 18:07, Uwe Schmitt wrote:
> Dear all,
>
> the following code hangs on my Ubuntu machine.
> I use self compiled numpy 1.7.1 and Python
> 2.7.3
>
> -
>
> import numpy
> import numpy.linalg
> import multiprocessing
>
> def classify():
> X = numpy.random.random((10,3))
> p
On Wed, Jun 12, 2013 at 6:36 PM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> On Wed, Jun 12, 2013 at 5:10 AM, Nathaniel Smith wrote:
>
> > Personally I think that overloading np.empty is horribly ugly, will
> > continue confusing newbies and everyone else indefinitely, and I'm
>
Dear Uwe:
I can't reproduce this using the system default versions of Python and
NumPy on Ubuntu 13.04:
$ python uwe.py
before svd
this message is not printed
>>> sys.version_info
sys.version_info(major=2, minor=7, micro=4, releaselevel='final', serial=0)
>>> numpy.__version__
'1.7.1'
Any idea
On Wed, Jun 12, 2013 at 5:10 AM, Nathaniel Smith wrote:
> Personally I think that overloading np.empty is horribly ugly, will
> continue confusing newbies and everyone else indefinitely, and I'm
> 100% convinced that we'll regret implementing such a warty interface
> for something that should be
> I have some code more or less 500 lines, but very messy code. All codes
> containing several functions are in one module, besides, without
> documentation and testing.
>
> Could anyone give me some advice to organize my messy code in an accurate
> style including test function as well?
This is a
On June 12, 2013 at 17:56:33, Daπid (davidmen...@gmail.com) wrote: On 12 June 2013 17:29, wrote: > +2 on this. > I like a good name like `filled` for a function that I expect to use regularly. > it's short and descriptive. FTIW, I am for this one too. That is not only clear, but a name that one ma
On Sat, Jun 8, 2013 at 7:31 PM, wrote:
> On Sat, Jun 8, 2013 at 7:05 PM, Sebastian Berg
> wrote:
>> On Sat, 2013-06-08 at 08:52 -0400, josef.p...@gmail.com wrote:
>>> Is there anything to require a numpy array with a minimum numeric dtype?
>>>
>>> To avoid lower precision calculations and be upw
Dear all,
the following code hangs on my Ubuntu machine.
I use self compiled numpy 1.7.1 and Python
2.7.3
-
import numpy
import numpy.linalg
import multiprocessing
def classify():
X = numpy.random.random((10,3))
print "before svd"
numpy.linalg.svd(X)
print "this message is n
On 12 June 2013 17:29, wrote:
> +2 on this.
> I like a good name like `filled` for a function that I expect to use
> regularly.
> it's short and descriptive.
FTIW, I am for this one too. That is not only clear, but a name that
one may try even before checking the docs.
Emtpy-filled sounds too
On Wed, Jun 12, 2013 at 10:18 AM, Nathaniel Smith wrote:
> On Wed, Jun 12, 2013 at 1:28 PM, Matthew Brett
> wrote:
> > On Wed, Jun 12, 2013 at 1:10 PM, Nathaniel Smith wrote:
> >> Personally I think that overloading np.empty is horribly ugly, will
> >> continue confusing newbies and everyone el
On Wed, Jun 12, 2013 at 4:30 PM, Alan G Isaac wrote:
> On 6/12/2013 10:49 AM, Pierre Haessig wrote:
>> I find the "docs would look nice and consistent" argument pretty convincing.
>> +1 for np.filled.
>
> In Maple and Mathematica, these are called constant arrays.
> Thus (?) another possible name
> Le 12/06/2013 16:18, Nathaniel Smith a écrit :
>> Now imagine a new version of this page, if we add 'filled'. There will
>> be a list at the top with functions named:
>>empty
>>filled
>>ones
>>zeros
>> It's immediately obvious what all of these things do, and how they
>> differ fr
On Wed, Jun 12, 2013 at 10:45 AM, Warren Weckesser
wrote:
>
>
>
> On Wed, Jun 12, 2013 at 10:18 AM, Nathaniel Smith wrote:
>>
>> On Wed, Jun 12, 2013 at 1:28 PM, Matthew Brett
>> wrote:
>> > On Wed, Jun 12, 2013 at 1:10 PM, Nathaniel Smith wrote:
>> >> Personally I think that overloading np.emp
Hi,
Le 12/06/2013 16:18, Nathaniel Smith a écrit :
> Now imagine a new version of this page, if we add 'filled'. There will
> be a list at the top with functions named:
> empty
> filled
> ones
> zeros
> It's immediately obvious what all of these things do, and how they
> differ from each o
On Wed, Jun 12, 2013 at 10:18 AM, Nathaniel Smith wrote:
> On Wed, Jun 12, 2013 at 1:28 PM, Matthew Brett
> wrote:
> > On Wed, Jun 12, 2013 at 1:10 PM, Nathaniel Smith wrote:
> >> Personally I think that overloading np.empty is horribly ugly, will
> >> continue confusing newbies and everyone el
On Wed, Jun 12, 2013 at 1:28 PM, Matthew Brett wrote:
> On Wed, Jun 12, 2013 at 1:10 PM, Nathaniel Smith wrote:
>> Personally I think that overloading np.empty is horribly ugly, will
>> continue confusing newbies and everyone else indefinitely, and I'm
>> 100% convinced that we'll regret implemen
On Tue, Jun 11, 2013 at 5:24 PM, Jaime Fernández del Río
wrote:
> I noticed today that the documentation for np.transpose states, for the
> return value, that "A view is returned whenever possible."
>
> Is there really any situation where swapping axes around could trigger the
> need to copy data,
On Wed, Jun 12, 2013 at 1:47 PM, Daniele Nicolodi wrote:
> On 12/06/2013 14:29, Robert Kern wrote:
>> On Wed, Jun 12, 2013 at 1:26 PM, Daniele Nicolodi wrote:
>>
>>> There where the additional proposal (mostly neglected on the original
>>> thread) to add the 'fill' optional parameter to the array
Hi,
I have some code more or less 500 lines, but very messy code. All codes
containing several functions are in one module, besides, without documentation
and testing.
Could anyone give me some advice to organize my messy code in an accurate style
including test function as well?
Any answers
On Wed, Jun 12, 2013 at 8:47 AM, Daniele Nicolodi wrote:
> On 12/06/2013 14:29, Robert Kern wrote:
>> On Wed, Jun 12, 2013 at 1:26 PM, Daniele Nicolodi wrote:
>>
>>> There where the additional proposal (mostly neglected on the original
>>> thread) to add the 'fill' optional parameter to the array
On 12/06/2013 14:29, Robert Kern wrote:
> On Wed, Jun 12, 2013 at 1:26 PM, Daniele Nicolodi wrote:
>
>> There where the additional proposal (mostly neglected on the original
>> thread) to add the 'fill' optional parameter to the array constructor:
>>
>> np.ndarray(shape, fill=value)
>>
>> has an
--Pierre GMSent with AirmailOn June 12, 2013 at 14:10:27, Nathaniel Smith (n...@pobox.com) wrote: Hi all, It looks like we've gotten a bit confused and need to untangle something. There's a PR to add new functions 'np.filled' and 'np.filled_like': https://github.com/numpy/numpy/pull/2875 And there
On Wed, Jun 12, 2013 at 1:24 PM, Sebastian Berg
wrote:
> On Tue, 2013-06-11 at 09:24 -0700, Jaime Fernández del Río wrote:
>> I noticed today that the documentation for np.transpose states, for
>> the return value, that "A view is returned whenever possible."
>>
> I guess a subclass could cause a
On Wed, Jun 12, 2013 at 1:26 PM, Daniele Nicolodi wrote:
> There where the additional proposal (mostly neglected on the original
> thread) to add the 'fill' optional parameter to the array constructor:
>
> np.ndarray(shape, fill=value)
>
> has an obvious meaning to me.
>
> I also don't really see
Hi,
On Wed, Jun 12, 2013 at 1:10 PM, Nathaniel Smith wrote:
> Hi all,
>
> It looks like we've gotten a bit confused and need to untangle
> something. There's a PR to add new functions 'np.filled' and
> 'np.filled_like':
> https://github.com/numpy/numpy/pull/2875
> And there was a discussion abo
On 12/06/2013 14:10, Nathaniel Smith wrote:
> It looks like we've gotten a bit confused and need to untangle
> something. There's a PR to add new functions 'np.filled' and
> 'np.filled_like':
> https://github.com/numpy/numpy/pull/2875
> And there was a discussion about this on the list back in Ja
On Tue, 2013-06-11 at 09:24 -0700, Jaime Fernández del Río wrote:
> I noticed today that the documentation for np.transpose states, for
> the return value, that "A view is returned whenever possible."
>
>
I guess a subclass could cause a copy (the code looks like subclassing
doing something fancy
Hi all,
It looks like we've gotten a bit confused and need to untangle
something. There's a PR to add new functions 'np.filled' and
'np.filled_like':
https://github.com/numpy/numpy/pull/2875
And there was a discussion about this on the list back in January:
http://thread.gmane.org/gmane.comp.p
Sudheer Joseph yahoo.com> writes:
> I am doing a project involving regression of a model variable with
> observed variable and wanted to find t-values dynamically as the number of
available observations
> involved in comparison changes. Is there a tool in numpy/scipy which gives
the appropriate
Dave Hirschfeld gmail.com> writes:
> The example below demonstrates the fact that the datetime64
> constructor ignores the dtype argument if passed in. Is this
> conscious design decision or a bug/oversight?
Bug. There's probably no dtype argument, but the constructor
just ignores all arguments:
Dear experts,
I am doing a project involving regression of a model variable
with observed variable and wanted to find t-values dynamically as the number of
available observations involved in comparison changes. Is there a tool in
numpy/scipy which gives the appropriate t-value i
The example below demonstrates the fact that the datetime64 constructor
ignores the dtype argument if passed in. Is this conscious design decision or
a bug/oversight?
In [55]: from datetime import datetime
...: d = datetime.now()
...:
In [56]: d
Out[56]: datetime.datetime(2013, 6, 12,
51 matches
Mail list logo
