On Wed, Jun 6, 2012 at 5:11 AM, Travis Oliphant wrote:
> During the original discussion, Gael pointed out that the changes would
> probably break some code (which might need to be cleaned up but still). I
> think it was underestimated how quickly people would upgrade and see the
> changes and t
>
> I don't think that would work, because looking more closely, I don't
> think they're actually doing anything like what
> __array_interface__/PEP3118 are designed for. They just have some
> custom class ("sage.rings.real_mpfr.RealLiteral", I guess an arbitrary
> precision floating point of some
During the original discussion, Gael pointed out that the changes would
probably break some code (which might need to be cleaned up but still). I
think it was underestimated how quickly people would upgrade and see the
changes and therefore be able to report problems.
We are talking about a
Can the following function be written using numpy.clip? In some other way?
Does numpy.clip satisfy condition 4 below? Does numpy.clip satisfy some
closely related condition?
Define a function clipcast:
output = clipcast(arr, dtype=None, out=None)
1. All arrays have int or float dtypes.
2.
On Tue, Jun 5, 2012 at 4:15 PM, Charles R Harris
wrote:
> There are other advantages to pulling down the patch. Fixups can be merged
> together, commit comments enhanced, whitespace removed, style cleanups can
> be added, tests can be run, and the PR is automatically rebased. I still
> like fast f
On Tue, Jun 5, 2012 at 4:59 PM, Fernando Perez wrote:
> A couple of notes from the IPython workflow in case it's of use to you
> guys:
>
> On Tue, Jun 5, 2012 at 10:52 AM, Charles R Harris
> wrote:
> >
> > For the commits themselves, the github button doesn't do fast forward or
> > whitespace cl
A couple of notes from the IPython workflow in case it's of use to you guys:
On Tue, Jun 5, 2012 at 10:52 AM, Charles R Harris
wrote:
>
> For the commits themselves, the github button doesn't do fast forward or
> whitespace cleanup, so I have the following alias in .git/config
>
> getpatch = !sh
On 5 June 2012 22:36, Dag Sverre Seljebotn wrote:
> On 06/05/2012 10:47 PM, mark florisson wrote:
>> On 5 June 2012 20:17, Nathaniel Smith wrote:
>>> On Tue, Jun 5, 2012 at 7:08 PM, mark florisson
>>> wrote:
On 5 June 2012 17:38, Nathaniel Smith wrote:
> On Tue, Jun 5, 2012 at 4:12 PM
On 5 June 2012 22:29, Nathaniel Smith wrote:
> On Tue, Jun 5, 2012 at 9:47 PM, mark florisson
> wrote:
>> On 5 June 2012 20:17, Nathaniel Smith wrote:
>>> On Tue, Jun 5, 2012 at 7:08 PM, mark florisson
>>> wrote:
On 5 June 2012 17:38, Nathaniel Smith wrote:
> On Tue, Jun 5, 2012 at 4:
On 06/05/2012 10:47 PM, mark florisson wrote:
> On 5 June 2012 20:17, Nathaniel Smith wrote:
>> On Tue, Jun 5, 2012 at 7:08 PM, mark florisson
>> wrote:
>>> On 5 June 2012 17:38, Nathaniel Smith wrote:
On Tue, Jun 5, 2012 at 4:12 PM, mark florisson
wrote:
> On 5 June 2012 14:58,
On Tue, Jun 5, 2012 at 9:47 PM, mark florisson
wrote:
> On 5 June 2012 20:17, Nathaniel Smith wrote:
>> On Tue, Jun 5, 2012 at 7:08 PM, mark florisson
>> wrote:
>>> On 5 June 2012 17:38, Nathaniel Smith wrote:
On Tue, Jun 5, 2012 at 4:12 PM, mark florisson
wrote:
> On 5 June 2012
On 5 June 2012 20:17, Nathaniel Smith wrote:
> On Tue, Jun 5, 2012 at 7:08 PM, mark florisson
> wrote:
>> On 5 June 2012 17:38, Nathaniel Smith wrote:
>>> On Tue, Jun 5, 2012 at 4:12 PM, mark florisson
>>> wrote:
On 5 June 2012 14:58, Nathaniel Smith wrote:
> On Tue, Jun 5, 2012 at 12
On Tue, Jun 5, 2012 at 1:14 PM, Nathaniel Smith wrote:
> On Tue, Jun 5, 2012 at 6:52 PM, Charles R Harris
> wrote:
> >
> >
> > On Tue, Jun 5, 2012 at 10:25 AM, Nathaniel Smith wrote:
> >>
> >> On Tue, Jun 5, 2012 at 4:19 PM, Charles R Harris
> >> wrote:
> >> >
> >> >
> >> > On Sun, Jun 3, 2012
On Tue, Jun 5, 2012 at 7:08 PM, mark florisson
wrote:
> On 5 June 2012 17:38, Nathaniel Smith wrote:
>> On Tue, Jun 5, 2012 at 4:12 PM, mark florisson
>> wrote:
>>> On 5 June 2012 14:58, Nathaniel Smith wrote:
On Tue, Jun 5, 2012 at 12:55 PM, mark florisson
wrote:
> It would be g
On Tue, Jun 5, 2012 at 6:52 PM, Charles R Harris
wrote:
>
>
> On Tue, Jun 5, 2012 at 10:25 AM, Nathaniel Smith wrote:
>>
>> On Tue, Jun 5, 2012 at 4:19 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Sun, Jun 3, 2012 at 12:04 PM, Ralf Gommers
>> >
>> > wrote:
>> >>
>> >>
>> >>
>> >> On Sun, Ju
>> On Tue, Jun 5, 2012 at 8:41 PM, Zachary Pincus
>> wrote:
>>>
There is a fine line here. We do need to make people clean up lax code
in order to improve numpy, but hopefully we can keep the cleanups
reasonable.
>>>
>>> Oh agreed. Somehow, though, I was surprised by this, even th
On Tue, Jun 5, 2012 at 7:47 PM, Ralf Gommers
wrote:
>
>
> On Tue, Jun 5, 2012 at 8:41 PM, Zachary Pincus
> wrote:
>>
>> > There is a fine line here. We do need to make people clean up lax code
>> > in order to improve numpy, but hopefully we can keep the cleanups
>> > reasonable.
>>
>> Oh agreed.
On Tue, Jun 5, 2012 at 6:59 PM, Benjamin Root wrote:
>
>
> On Tue, Jun 5, 2012 at 10:37 AM, Robert Kern wrote:
>
>> On Tue, Jun 5, 2012 at 2:54 PM, Neal Becker wrote:
>> > I think it's unfortunate that functions like logical_or are limited to
>> binary.
>> >
>> > As a workaround, I've been using
On Tue, Jun 5, 2012 at 8:41 PM, Zachary Pincus wrote:
> > There is a fine line here. We do need to make people clean up lax code
> in order to improve numpy, but hopefully we can keep the cleanups
> reasonable.
>
> Oh agreed. Somehow, though, I was surprised by this, even though I keep
> tabs on t
> There is a fine line here. We do need to make people clean up lax code in
> order to improve numpy, but hopefully we can keep the cleanups reasonable.
Oh agreed. Somehow, though, I was surprised by this, even though I keep tabs on
the numpy lists -- at no point did it become clear that "big ch
On Tue, Jun 5, 2012 at 11:51 AM, Zachary Pincus wrote:
> > It isn't just the array() calls which end up getting problems. For
> > example, in 1.5.x
> >
> > sage: f = 10; type(f)
> >
> > sage: numpy.arange(f)
> > array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) #int64
> >
> > while in 1.6.x
> >
> > sage: nu
On 5 June 2012 17:38, Nathaniel Smith wrote:
> On Tue, Jun 5, 2012 at 4:12 PM, mark florisson
> wrote:
>> On 5 June 2012 14:58, Nathaniel Smith wrote:
>>> On Tue, Jun 5, 2012 at 12:55 PM, mark florisson
>>> wrote:
It would be great if we implement the NEP listed above, but with a few
On Tue, Jun 5, 2012 at 11:52 AM, Charles R Harris wrote:
>
>
> On Tue, Jun 5, 2012 at 10:25 AM, Nathaniel Smith wrote:
>
>> On Tue, Jun 5, 2012 at 4:19 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Sun, Jun 3, 2012 at 12:04 PM, Ralf Gommers <
>> ralf.gomm...@googlemail.com>
>> > wrote:
>> >>
On 5 June 2012 18:21, Neal Becker wrote:
> Would lazy eval be able to eliminate temps in doing operations such as:
>
> np.sum (u != 23)?
>
> That is, now ops involving selecting elements of matrixes are often performed
> by
> first constructing temp matrixes, and the operating on them.
>
> __
On Tue, Jun 5, 2012 at 10:25 AM, Nathaniel Smith wrote:
> On Tue, Jun 5, 2012 at 4:19 PM, Charles R Harris
> wrote:
> >
> >
> > On Sun, Jun 3, 2012 at 12:04 PM, Ralf Gommers <
> ralf.gomm...@googlemail.com>
> > wrote:
> >>
> >>
> >>
> >> On Sun, Jun 3, 2012 at 6:43 PM, Charles R Harris
> >> wro
> It isn't just the array() calls which end up getting problems. For
> example, in 1.5.x
>
> sage: f = 10; type(f)
>
> sage: numpy.arange(f)
> array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) #int64
>
> while in 1.6.x
>
> sage: numpy.arange(f)
> array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9], dtype=object)
>
> We
On Tue, Jun 5, 2012 at 8:34 AM, Nathaniel Smith wrote:
> I don't think that would work, because looking more closely, I don't
> think they're actually doing anything like what
> __array_interface__/PEP3118 are designed for. They just have some
> custom class ("sage.rings.real_mpfr.RealLiteral", I
Would lazy eval be able to eliminate temps in doing operations such as:
np.sum (u != 23)?
That is, now ops involving selecting elements of matrixes are often performed
by
first constructing temp matrixes, and the operating on them.
___
NumPy-Discussi
On Tue, Jun 5, 2012 at 10:37 AM, Robert Kern wrote:
> On Tue, Jun 5, 2012 at 2:54 PM, Neal Becker wrote:
> > I think it's unfortunate that functions like logical_or are limited to
> binary.
> >
> > As a workaround, I've been using this:
> >
> > def apply_binary (func, *args):
> >if len (args
On Tue, Jun 5, 2012 at 10:49 AM, Nathaniel Smith wrote:
> On Tue, Jun 5, 2012 at 1:17 AM, Benjamin Root wrote:
> >
> >
> > On Monday, June 4, 2012, Chris Barker wrote:
> >>
> >> On Mon, Jun 4, 2012 at 11:10 AM, Patrick Redmond
> >> wrote:
> >> > Here's how I sorted primarily by field 'a' descen
On Tue, Jun 5, 2012 at 4:12 PM, mark florisson
wrote:
> On 5 June 2012 14:58, Nathaniel Smith wrote:
>> On Tue, Jun 5, 2012 at 12:55 PM, mark florisson
>> wrote:
>>> It would be great if we implement the NEP listed above, but with a few
>>> extensions. I think Numpy should handle the lazy evalua
On Tue, Jun 5, 2012 at 4:19 PM, Charles R Harris
wrote:
>
>
> On Sun, Jun 3, 2012 at 12:04 PM, Ralf Gommers
> wrote:
>>
>>
>>
>> On Sun, Jun 3, 2012 at 6:43 PM, Charles R Harris
>> wrote:
>>>
>>> Hi All,
>>>
>>> Numpy is approaching a time of transition. Ralf will be concentrating his
>>> effort
On Mon, Jun 4, 2012 at 10:12 PM, Dag Sverre Seljebotn
wrote:
> On 06/04/2012 09:06 PM, Mike Hansen wrote:
>> On Mon, May 28, 2012 at 3:15 AM, Mike Hansen wrote:
>>> In trying to upgrade NumPy within Sage, we notices some differences in
>>> behavior between 1.5 and 1.6. In particular, in 1.5, we
On Sun, Jun 3, 2012 at 12:04 PM, Ralf Gommers
wrote:
>
>
> On Sun, Jun 3, 2012 at 6:43 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> Hi All,
>>
>> Numpy is approaching a time of transition. Ralf will be concentrating his
>> efforts on Scipy
>
>
> I'll write a separate post on tha
On 5 June 2012 14:58, Nathaniel Smith wrote:
> On Tue, Jun 5, 2012 at 12:55 PM, mark florisson
> wrote:
>> It would be great if we implement the NEP listed above, but with a few
>> extensions. I think Numpy should handle the lazy evaluation part, and
>> determine when expressions should be evalua
On Tue, Jun 5, 2012 at 5:40 AM, Nathaniel Smith wrote:
> On Tue, Jun 5, 2012 at 11:06 AM, Thouis (Ray) Jones wrote:
> > All of the failing tests seem to have been caused by the buffer copy
> bug, fixed in https://github.com/mwiebe/numpy/tree/nditer_buffer_flag(but
> not yet pulled into numpy).
On Tue, Jun 5, 2012 at 1:17 AM, Benjamin Root wrote:
>
>
> On Monday, June 4, 2012, Chris Barker wrote:
>>
>> On Mon, Jun 4, 2012 at 11:10 AM, Patrick Redmond
>> wrote:
>> > Here's how I sorted primarily by field 'a' descending and secondarily by
>> > field 'b' ascending:
>>
>> could you multiply
On Tue, Jun 5, 2012 at 2:54 PM, Neal Becker wrote:
> I think it's unfortunate that functions like logical_or are limited to binary.
>
> As a workaround, I've been using this:
>
> def apply_binary (func, *args):
> if len (args) == 1:
> return args[0]
> elif len (args) == 2:
> re
On Mon, Jun 4, 2012 at 6:08 PM, Chris Barker wrote:
> could you multiply the numeric field by -1, sort, then put it back
>
Yeah, that works great for my situation. Thanks Chris!
On Mon, Jun 4, 2012 at 8:17 PM, Benjamin Root wrote:
> While that may work for this users case, that would not work fo
On Tue, Jun 5, 2012 at 12:55 PM, mark florisson
wrote:
> It would be great if we implement the NEP listed above, but with a few
> extensions. I think Numpy should handle the lazy evaluation part, and
> determine when expressions should be evaluated, etc. However, for each
> user operation, Numpy w
I think it's unfortunate that functions like logical_or are limited to binary.
As a workaround, I've been using this:
def apply_binary (func, *args):
if len (args) == 1:
return args[0]
elif len (args) == 2:
return func (*args)
else:
return func (
ap
On Tue, Jun 5, 2012 at 12:15 PM, Thouis Jones wrote:
> On Mon, Jun 4, 2012 at 11:49 PM, Nathaniel Smith wrote:
>> On Mon, Jun 4, 2012 at 10:00 PM, Thouis (Ray) Jones wrote:
>>> On Mon, Jun 4, 2012 at 4:27 PM, Thouis (Ray) Jones wrote:
I could look into this. There are only ~10 places the
Hey,
Another discussion on lazy evaluation, given the recent activity here:
https://github.com/ContinuumIO/numba/pull/6#issuecomment-6117091
A somewhat recent previous thread can be found here:
http://mail.scipy.org/pipermail/numpy-discussion/2012-February/060862.html
, and a NEP here:
https://git
On Tue, Jun 5, 2012 at 11:06 AM, Thouis (Ray) Jones wrote:
> All of the failing tests seem to have been caused by the buffer copy bug,
> fixed in https://github.com/mwiebe/numpy/tree/nditer_buffer_flag (but not
> yet pulled into numpy).
>
> I also have a version that implements tracing, with pur
On Mon, Jun 4, 2012 at 11:49 PM, Nathaniel Smith wrote:
> On Mon, Jun 4, 2012 at 10:00 PM, Thouis (Ray) Jones wrote:
>> On Mon, Jun 4, 2012 at 4:27 PM, Thouis (Ray) Jones wrote:
>>> I could look into this. There are only ~10 places the code generates
>>> this error, so it should be a pretty min
45 matches
Mail list logo
