A bug causing errors with using methods of ufuncs created with
frompyfunc was mentioned on the list over a year ago:
http://mail.scipy.org/pipermail/numpy-discussion/2011-
September/058501.html
Is there any word on the status of this bug? I wasn't able to find
a ticket in the b
On Tue, Jan 8, 2013 at 11:17 AM, Till Stensitz wrote:
> Hi,
> i did some profiling and testing of my data-fitting code.
> One of its core parts is doing some linear least squares,
> until now i used np.linalg.lstsq. Most of time the size
> a is (250, 7) and of b is (250, 800).
>
> Today i compare
Hi Olivier,
>> Yes, certainly. But in either the proposed or 1.5 behavior, if the
>> values in x are close to the limits of the type, this can happen also.
>
>
> My previous email may not have been clear enough, so to be sure: in my above
> example, if the random number is 3, then the result
On Tue, Jan 8, 2013 at 6:17 PM, Till Stensitz wrote:
> Hi,
> i did some profiling and testing of my data-fitting code.
> One of its core parts is doing some linear least squares,
> until now i used np.linalg.lstsq. Most of time the size
> a is (250, 7) and of b is (250, 800).
>
> Today i compared
Le mardi 8 janvier 2013, Andrew Collette a écrit :
> Hi,
>
> > Keep in mind that in the third option (current 1.6 behavior) the dtype is
> > large enough to hold the random number, but not necessarily to hold the
> > result. So for instance if x is an int16 array with only positive values,
> > the
Hi,
> Keep in mind that in the third option (current 1.6 behavior) the dtype is
> large enough to hold the random number, but not necessarily to hold the
> result. So for instance if x is an int16 array with only positive values,
> the result of this addition may contain negative values (or not, d
Le mardi 8 janvier 2013, Andrew Collette a écrit :
> Hi Dag,
>
> > So you are saying that, for an array x, you want
> >
> > x + random.randint(10)
> >
> > to produce an array with a random dtype?
>
> Under the proposed behavior, depending on the dtype of x and the value
> from random, this wou
On Tue, Jan 8, 2013 at 1:17 PM, Till Stensitz wrote:
> Hi,
> i did some profiling and testing of my data-fitting code.
> One of its core parts is doing some linear least squares,
> until now i used np.linalg.lstsq. Most of time the size
> a is (250, 7) and of b is (250, 800).
My guess is that thi
Hi Dag,
> So you are saying that, for an array x, you want
>
> x + random.randint(10)
>
> to produce an array with a random dtype?
Under the proposed behavior, depending on the dtype of x and the value
from random, this would sometimes add-with-rollover and sometimes
raise ValueError.
Under
On 01/08/2013 10:32 PM, Dag Sverre Seljebotn wrote:
> On 01/08/2013 06:20 PM, Andrew Collette wrote:
>> Hi,
>>
>>> I think you are voting strongly for the current casting rules, because
>>> they make it less obvious to the user that scalars are different from
>>> arrays.
>>
>> Maybe this is the sou
On 01/08/2013 06:20 PM, Andrew Collette wrote:
> Hi,
>
>> I think you are voting strongly for the current casting rules, because
>> they make it less obvious to the user that scalars are different from
>> arrays.
>
> Maybe this is the source of my confusion... why should scalars be
> different from
2013/1/8 Chris Barker - NOAA Federal :
> On Tue, Jan 8, 2013 at 12:43 PM, Alan G Isaac wrote:
>>> New users don't use narrow-width dtypes... it's important to remember
>
>> 1. I think the first statement is wrong.
>> Control over dtypes is a good reason for
>> a new use to consider NumPy.
>
> Abso
2013/1/8 Sebastian Berg :
> On Tue, 2013-01-08 at 19:59 +, Nathaniel Smith wrote:
>> On 8 Jan 2013 17:24, "Andrew Collette" wrote:
>> >
>> > Hi,
>> >
>> > > I think you are voting strongly for the current casting rules, because
>> > > they make it less obvious to the user that scalars are diff
On Tue, Jan 8, 2013 at 12:43 PM, Alan G Isaac wrote:
>> New users don't use narrow-width dtypes... it's important to remember
> 1. I think the first statement is wrong.
> Control over dtypes is a good reason for
> a new use to consider NumPy.
Absolutely.
> Because NumPy supports broadcasting,
>
On Tue, 2013-01-08 at 19:59 +, Nathaniel Smith wrote:
> On 8 Jan 2013 17:24, "Andrew Collette" wrote:
> >
> > Hi,
> >
> > > I think you are voting strongly for the current casting rules, because
> > > they make it less obvious to the user that scalars are different from
> > > arrays.
> >
> > M
Hi Nathaniel,
(Responding to both your emails)
> The problem is that rule for arrays - and for every other party of
> numpy in general - are that we *don't* pick types based on values.
> Numpy always uses input types to determine output types, not input
> values.
Yes, of course... array operatio
On 1/8/2013 3:04 PM, Nathaniel Smith wrote:
> New users don't use narrow-width dtypes... it's important to remember
> in this discussion that in numpy, non-standard dtypes only arise when
> users explicitly request them, so there's some expressed intention
> there that we want to try and respect.
On Tue, Jan 8, 2013 at 7:28 PM, Alan G Isaac wrote:
> On 1/8/2013 1:48 PM, Olivier Delalleau wrote:
>> As I mentioned in another post, I also agree that it would make things
>> simpler and safer to just yield the same result as if we were using a
>> one-element array.
>
> Yes!
> Anything else is g
On 8 Jan 2013 17:24, "Andrew Collette" wrote:
>
> Hi,
>
> > I think you are voting strongly for the current casting rules, because
> > they make it less obvious to the user that scalars are different from
> > arrays.
>
> Maybe this is the source of my confusion... why should scalars be
> different
On 1/8/2013 1:48 PM, Olivier Delalleau wrote:
> As I mentioned in another post, I also agree that it would make things
> simpler and safer to just yield the same result as if we were using a
> one-element array.
Yes!
Anything else is going to drive people insane,
especially new users.
Alan Isaac
2013/1/8 Andrew Collette :
> Hi,
>
>> I think you are voting strongly for the current casting rules, because
>> they make it less obvious to the user that scalars are different from
>> arrays.
>
> Maybe this is the source of my confusion... why should scalars be
> different from arrays? They shoul
Hi,
i did some profiling and testing of my data-fitting code.
One of its core parts is doing some linear least squares,
until now i used np.linalg.lstsq. Most of time the size
a is (250, 7) and of b is (250, 800).
Today i compared it to using pinv manually,
to my surprise, it is much faster. I
Hi,
> I think you are voting strongly for the current casting rules, because
> they make it less obvious to the user that scalars are different from
> arrays.
Maybe this is the source of my confusion... why should scalars be
different from arrays? They should follow the same rules, as closely
as
Hi,
On Mon, Jan 7, 2013 at 10:58 PM, Andrew Collette
wrote:
> Hi,
>
>> Taking 2) first, in this example:
>>
>>> return self.f[dataset_name][...] + heightmap
>>
>> assuming it is not going to upcast, would you rather it overflow than
>> raise an error? Why? The second seems more explicit and
On Mon, Jan 7, 2013 at 10:23 PM, Ondřej Čertík wrote:
>> http://www.commandlinefu.com/commands/view/2031/install-an-mpkg-from-the-command-line-on-osx
>
> This requires root access. Without sudo, I get:
>
> $ installer -pkg /Volumes/Python\ 2.7.3/Python.mpkg/ -target ondrej
> installer: This packag
On Mon, Jan 7, 2013 at 11:36 PM, Ralf Gommers wrote:
>
>
>
> On Tue, Jan 8, 2013 at 3:12 AM, Ondřej Čertík
> wrote:
>>
>> On Sun, Jan 6, 2013 at 2:04 AM, Ralf Gommers
>> wrote:
>> >
>> >
>> >
>> > On Sun, Jan 6, 2013 at 3:21 AM, Ondřej Čertík
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> Currently th
On Mon, Jan 7, 2013 at 7:31 AM, Matthew Brett wrote:
> Hi,
>
> On Sun, Jan 6, 2013 at 10:40 PM, Chris Barker - NOAA Federal
> wrote:
>> On Sun, Jan 6, 2013 at 2:04 AM, Ralf Gommers wrote:
Which exact Python do we need to use on Mac? Do we need to use the
binary installer from python.or
On Sat, Jan 5, 2013 at 1:03 PM, Robin wrote:
>>> If not, is there a reasonable way to build numpy.linalg such that
>>> it interfaces with MKL correctly ?
I managed to get this to work in the end. Since Matlab uses MKL with
ILP64 interface it is not possible to get Numpy to use that without
modifi
28 matches
Mail list logo
