On Sun, 2013-09-22 at 10:54 -0400, David Reed wrote:
> Sebastian,
>
>
> I apologize, that did work. I forgot to autoreload. Can you explain
> why the original code did work at the debug prompt?
>
Probably the debug prompt clears the errors or such. There was a bug (it
a
g in the index
machinery that is bugging you, which I may have forgotten until now?
- Sebastian
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, 2013-09-27 at 09:26 -0400, Benjamin Root wrote:
>
> Boolean indexing could use a facelift. First, consider the following
> (albeit minor) annoyance:
>
Done. Well will be deprecation warnings for the time being, though.
>
> Next, it would be nice if boolean indexing returned a view
On Fri, 2013-09-27 at 08:45 -0700, Jaime Fernández del Río wrote:
>
> On Fri, Sep 27, 2013 at 5:27 AM, Sebastian Berg
> wrote:
>
> And most importantly, is there any behaviour thing in the
> index
> machinery that is bugging you, which
seems that solve() doesn't like arrays like zeros((3, 0)). I get
> this with 1.8.0rc1 on Ubuntu 13.04 and Python 2.7.4:
>
Hey,
can you create an issue on github so I don't forget it? This needs
another special case to handle with the new gufunc based code. (Added
checks there recently
look if it might be breaking code out there. (even if the buffer
protocol change is correct and this should be fixed on cythons end in
that case)
- Sebastian
> (@seberg, does that look right?)
>
> I guess maybe we could go back and make sure it stays broken in 1.8,
> but it's
On Wed, 2013-10-02 at 12:54 +0200, Sebastian Berg wrote:
> On Wed, 2013-10-02 at 10:04 +0100, Nathaniel Smith wrote:
> > This is a complicated issue to describe but i think the bottom line is
> > that the test is just wonky here. the behaviour it's checking for is:
> >
trix[ii,...][:,mask]`
(first view based slicing, then the advanced boolean index. Since the
first part (if `ii` is an integer) will not copy the data, this will
also work for assignments).
- Sebastian
> Cheers!
> Ben Root
>
>
>
> ___
&
precision).
- Sebastian
> The problem I'm having is in creating an empty array to fill with
> complex values without knowing a priori what the input data type is.
>
> For example, I have a real or int array `a`.
>
> I want to create an array `b` which can hold values from 1j
Hi,
you projects looks really great!
I was wondering if you are making use of any pre-existing javascript
plotting library like flot or flotr2 ?
And if not, what are your reasons ?
Thanks,
Sebastian Haase
On Thu, Oct 24, 2013 at 9:55 PM, Jason Grout
wrote:
> On 10/24/13 1:42 PM, Peter W
e
the itemsize instead). How is ndarray broken by this?
- Sebastian
> Frédéric Bastien wrote:
>
> > Just don't compile with NPY_RELAXED_STRIDES_CHECKING to have the old
> > behavior I think (which is an not always the same strides depending of
> > how it was created, I
ES_CHECKING (i.e. cython had this problem
since its memoryview would reject numpy's contiguous arrays as not
contiguous), you should not need to special case anything.
- Sebastian
>
> Thanks, Neil, for bringing this to my
operators |,^,| (and
the unary ~ even if it is weird) behave identical. This would not affect
sums of boolean arrays. For the moment I saw one "annoying" change in
numpy, and that is `abs(x - y)` being used for allclose and working
nicely currently.
-
On Thu, 2013-12-05 at 23:02 -0500, josef.p...@gmail.com wrote:
> On Thu, Dec 5, 2013 at 10:56 PM, Alexander Belopolsky wrote:
> > On Thu, Dec 5, 2013 at 5:37 PM, Sebastian Berg
> > wrote:
> >> there was a discussion that for numpy booleans math operators +,-,* (and
On Fri, 2013-12-06 at 15:30 -0500, josef.p...@gmail.com wrote:
> On Fri, Dec 6, 2013 at 2:59 PM, Nathaniel Smith wrote:
> > On Fri, Dec 6, 2013 at 11:55 AM, Alexander Belopolsky
> > wrote:
> >>
> >>
> >>
> >> On Fri, Dec 6, 2013 at 1:46 PM, Alan G Isaac wrote:
> >>>
> >>> On 12/6/2013 1:35 PM,
s it is more dangerous than helping.
Though with some care you can easily implement such functions using
stride_tricks.
Regards,
Sebastian
> On scipy lectures, there is a suggestion to use as_strided :
> http://scipy-lectures.github.io/advanced/advanced_numpy/#example-fake-dime
On Tue, 2013-12-17 at 16:41 +0100, Pierre Haessig wrote:
> Le 13/12/2013 13:45, Sebastian Berg a écrit :
> >> What are the other options for such a repeat ?
> > No, I don't think there are any other options. stride tricks are a bit
> > hidden, since in many cases it i
ease.
Or am I missing something and the old behavior was actually intended?
- Sebastian
[1] https://github.com/numpy/numpy/issues/4109
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
'U' dtype works under the
> hood, but from my user perspective it seems to work just fine
> in terms of interacting with Python 3 strings. Is there a
> technical problem with doing basically the same thing for an
> 's' dtype, but using
n it into a DataFrame.
If your datatype is object, I doubt that using an intermediate list is a
real overhead, since the list will use much less memory then the string
objects anyway.
- Sebastian
>
> Maybe a variable length string/unicode type would help in the long term.
>
> Leo
&
2, 9])
>
> >>> a[w] += v
>
>
>
> I was expecting ‘a’ to be array([20., 3., 9.]. Instead I get
>
>
>
> >>> a
>
> array([ 10., 2., 9.])
>
>
>
> This with numpy version 1.6.1.
>
> Is t
op
of the necessary data copying. Though performance may vary because of
memory order, etc.
- Sebastian
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/list
en to work if it happens to be that `a[0] is b[0]`. This
currently has no deprecation, since the logic is in the inner loop and I
am not sure if it is easy to add well there.
Are there objections/comments to these changes?
Regards,
Sebastian
___
Nu
On Sat, 2014-01-25 at 00:18 +, Nathaniel Smith wrote:
> On 25 Jan 2014 00:05, "Sebastian Berg"
> wrote:
> >
> > Hi all,
> >
> > in https://github.com/numpy/numpy/pull/3514 I proposed some changes
> to
> > the comparison operators. This include
of the few cases where take should still
outperform advanced indexing.
- Sebastian
[1] Mostly multiple integer array indices, which take does not support
and arbitrary memory order.
[2] subspace here means the non-advanced indexing part. In the case of
arr[integer_array, :] the (or a) subspace
in the near future (but
if someone wants hints on how to go about it, just ask).
- Sebastian
> Travis
>
> On Feb 2, 2014 11:07 AM, "Charles R Harris"
> wrote:
> Sebastian has done a lot of work to refactor/rationalize numpy
> indexing. The changes are
erence, a kwarg may be an option (but
would think about that some more).
- Sebastian
> """
> [...] the following numpy code hangs until I `kill -9` it.
>
> ```
> $ python runtests.py --shell
> $ python
> Python 2.7.5+
> [GCC 4.8.1] on linux2
> >>&g
On Sa, 2014-02-15 at 17:35 -0500, josef.p...@gmail.com wrote:
> On Sat, Feb 15, 2014 at 5:12 PM, Skipper Seabold wrote:
> > On Sat, Feb 15, 2014 at 5:08 PM, wrote:
> >>
> >> On Sat, Feb 15, 2014 at 4:56 PM, Sebastian Berg
> >> wrote:
> >> &
or is undefined and it can crash although I do not
> personally have an example of this. These modes of failure cannot be
> recovered from as easily as recovering from an exception.
>
Yeah, I meant that. But it has a big "if", that the failure is basically
a bug in the library you happ
If I am aware
of uint vs int, I am already aware I can just cast to float.
- Sebastian
> Sturla
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
__
ill not be broken in some way...
PS: The code implementing the "advanced index or nd-index" logic is
here:
https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/mapping.c#L196
- Sebastian
Another confusing example:
In [9]: a = np.arange(10)
In [10]: a[[(0, 1), (2, 3)] * 1
On Di, 2014-02-18 at 09:05 -0700, Charles R Harris wrote:
> Hi All,
>
>
> There is an old ticket, #1499, that suggest adding a segment_axis
> function.
>
> def segment_axis(a, length, overlap=0, axis=None, end='cut', endvalue=0):
> """Generate a new array that chops the given array along the
On Di, 2014-02-18 at 17:09 +0100, Sebastian Berg wrote:
> Hey all,
>
> Now also NumPy commonly uses lists here to build up indexing tuples
> (since they are mutable), however would it really be so bad if we had to
> do `arr[tuple(slice_list)]` in the end to resolve this issue? So
st year
> we were way later.
>
>
> Todo is now:
>
> 1. fix up ideas page with scipy/numpy descriptions, idea difficulty
> levels and preferably some more ideas.
>
Considering that little has been moving there, the datetime cleanup
might be a decent project[1]? But to be ho
h. A hack would be to split it into two:
np.float128(1.1234567890) + np.float128(1234567890e-something)
Though it would be better for the numpy parser to parse the full
precision when given a string.
- Sebastian
> I was considering using a tiny cython wrapper of strtold() to do a
> conversion
d to do it anyway
because the sequence check like that seems standard in python 3. There
is an issue about it open on github with some discussion about this
issue.
- Sebastian
> Sturla
>
> ___
> NumPy-Discussion mailing list
> NumPy-D
to seeing this
> get in!
>
Best way to make sure it happens soon is to open a pull request about
it ;).
- Sebastian
>
> Be Well
> Anthony
>
>
> On Fri, Feb 28, 2014 at 4:59 AM, Robert Kern
> wrote:
> On Fri, Feb 28, 2014 at 9:03 AM, Sebastian Berg
>
you. Also for sieving through all those issues
before :).
- Sebastian
>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
__
rent casting when scalars are involved (don't trust the
scalar dtype to win).
(Of course in this context, you always have to imagin an `np.asarray`
call)
- Sebastian
>
>
> Nicolas
> ___
>
r the logic behind it either
There were changes in the casting logic in 1.7, I think. I can't really
remember changes after that, so if there is a change, we might want to
check it out. (Or I am just missing something completly :))
- Sebastian
>
> On Mon, Mar 3, 2014 at 10:06
;
> but I can live with Z += 300,300
>
Just to note. That actually does the temporary cast anyway doing the
calculation in double precision and then casting the result. If you want
to make sure it stays in single precision you will need to make that an
array with float32 dtype.
- Sebastian
s and insights are
very welcome :).
Regards,
Sebastian
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mi, 2014-03-05 at 10:21 -0800, David Goldsmith wrote:
>
>
>
> Date: Wed, 05 Mar 2014 17:45:47 +0100
> From: Sebastian Berg
> Subject: [Numpy-discussion] Adding weights to cov and corrcoef
> To: numpy-discussion@scipy.org
> Message-
On Do, 2014-03-06 at 19:51 +, Nathaniel Smith wrote:
> On Wed, Mar 5, 2014 at 4:45 PM, Sebastian Berg
> wrote:
> >
> > Hi all,
> >
> > in Pull Request https://github.com/numpy/numpy/pull/3864 Neol Dawe
> > suggested adding new parameters to our `cov` and `
On Do, 2014-03-06 at 16:30 -0500, josef.p...@gmail.com wrote:
> On Thu, Mar 6, 2014 at 3:49 PM, Ralf Gommers wrote:
> >
> >
> >
> > On Thu, Mar 6, 2014 at 1:40 PM, Sebastian Berg
> > wrote:
> >>
> >> On Mi, 2014-03-05 at 10:21 -0800, David Gol
n on tight/same/ or weak (maybe that means
then 'same' because it's easier to remember !?)
My two cents,
Sebastian Haase
On Tue, Mar 18, 2014 at 7:13 AM, Eelco Hoogendoorn
wrote:
>
>
> Perhaps this a bit of a thread hyjack; but this discussion got me thinking
&
t;
>
>
>
> That's a lot of errors. Do you think they should be reverted
> permanently or just for 1.9?
Good question. Just to note, I don't mind reverting/removing these. I
was somewhat aware that the double ellipsis caused a lot scipy failures,
but they se
this to be the case or not). The shape itself does
not matter, only the (relative) number of dimensions does for the
decision which of the two signatures is used.
In other words, since you do not use `...` your examples always use the
(M, K) logic.
- Sebastian
>
> However, this is not what
On Di, 2014-04-01 at 16:25 +0100, Nathaniel Smith wrote:
> On Tue, Apr 1, 2014 at 3:57 PM, Sebastian Berg
> wrote:
> > If `a` has exactly one dimension more then `b`, the first case is used.
> > Otherwise (..., M, K) is used instead. To make sure you always get the
> > ex
= ndarray(shape=[length], buffer=ba, offset=16, dtype="float64")
arr_view[...] = v
should do the trick.
- Sebastian
>
> --
> View this message in context:
> http://numpy-discussion.10968.n7.nabble.com/numpy-copyto-alternative-for-previous-versions-than-1-7-0-tp37282p37
like nonzero which give something like that.
- Sebastian
> Thanks,
> Alan Isaac
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
ng that
> branch might cause some incompatibilities.
>
I am a bit worried here that comparisons might make trouble.
> Object array creation new conversion to int
>
>
> This one needs a decision. Julian, Sebastian, thoughts?
>
Maybe for all to consider this is about what h
On Mi, 2014-04-23 at 10:11 -0400, josef.p...@gmail.com wrote:
> On Wed, Apr 23, 2014 at 5:32 AM, Sebastian Berg
> wrote:
> > On Di, 2014-04-22 at 15:35 -0600, Charles R Harris wrote:
> >> Hi All,
> >>
> >>
> >> I'd like to branch 1.9.x at the
an be greatly simplified:
> plt.plot(array4D[0][0][0:4][0],array4D[0][0][0:4][0],'bo')
>
> can be done as:
> plt.plot(array4D[0, 0, 0:4, 0], array4D[0, 0, 0:4, 0], 'bo')
>
Yeah, also arr[0:4][0] is the same as arr[0]. So you actually *must* use
an array and t
ement.
If you are interested in this, you could check the fancy indexing inner
loop and see if replacing the copyswap with the specialized strided
transfer functions (it is used further down in a different branch of the
loop) actually makes things faster. I would expect so for some void
types anyw
ement.
If you are interested in this, you could check the fancy indexing inner
loop and see if replacing the copyswap with the specialized strided
transfer functions (it is used further down in a different branch of the
loop) actually makes things faster. I would expect so for some void
types anyw
any reference to
> fftw.
>
I don't know the details, but this is not supported currently. It did
work for some old versions of numpy I think.
- Sebastian
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://m
y, a better
> > type system, missing values, etc., but doing that is difficult given the
> > current design.
>
> I won't be at the conference unfortunately (I'm on the wrong continent
> and have family commitments then anyway), but I think there's lots of
> exciting s
4]] = [1,2]`, but
I guess workarounds are not an option with matplotlib, so have to think
about it.
- Sebastian
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-di
On Di, 2014-06-10 at 10:43 +0200, Sebastian Berg wrote:
> On Mo, 2014-06-09 at 18:21 -0600, Charles R Harris wrote:
> >
> >
> >
> > On Mon, Jun 9, 2014 at 6:10 PM, Charles R Harris
> > wrote:
> >
>
>
> >
> >
On Di, 2014-06-10 at 10:50 +0100, Nathaniel Smith wrote:
> On 10 Jun 2014 09:44, "Sebastian Berg"
> wrote:
> > The other error looks a bit different because of the nonzero logic,
> but
> > probably is the same, i.e. also boolean indexing. The last one is
>
On Di, 2014-06-10 at 11:24 +0100, Nathaniel Smith wrote:
> On 10 Jun 2014 11:15, "Sebastian Berg"
> wrote:
> >
> > On Di, 2014-06-10 at 10:50 +0100, Nathaniel Smith wrote:
> > > On 10 Jun 2014 09:44, "Sebastian Berg"
>
> > > wrote:
&
one has, go ahead ;). It should fix all
those indexing errors (though numpy has harmless test failures with it
currently). Deprecationwarnings (and not there yet FutureWarnings for
the error type change) should be given then.
- Sebastian
> Christoph
> _
ty idiomatic.
- Sebastian
>
> Nicolas
>
>
> On 22 Jun 2014, at 10:30, Eelco Hoogendoorn
> wrote:
>
> > Perhaps you could simplify some statements, but at least the algorithmic
> > complexity is fine, and everything is vectorized, so I doubt you will get
&
gt; problems would already help me a lot.
True and true. I don't see a problem with fromiter being more general,
just someone has to sit down and add new error checks/cleanup stuff for
the object case. The assignment could probably also be optimized, not
sure how hard that is, I would expect it i
The named columns seem like a decent point to me. For
toggling indexing options, I wonder if usually function calls or
temporary object construction (at least for numpy) ala:
arr.ox[...]
arr.indx(option)[...]
are not better in any case.
- Sebastian
>
> ___
On Fr, 2014-07-04 at 17:32 +0200, Marc Hulsman wrote:
> On 07/03/2014 02:44 PM, Sebastian Berg wrote:
> > True and true. I don't see a problem with fromiter being more general,
> > just someone has to sit down and add new error checks/cleanup stuff
> > for the object
hould* already do this with a band
aid-solution, by just falling back to the old funky stuff if there is a
failure. If someone is good with python exception handling and string
formatting in C, please feel free to have a look ;).
- Sebastian
> > If the issues are fixed in matplotlib and pa
est https://github.com/numpy/numpy/pull/4804
This is called only after the normal indexing code gave an exception
already and maybe we can make the warnings more informative.
- Sebastian
>
> Ben
>
>
>
> On Sat, Jul 5, 2014 at 11:24 AM, Sebastian Berg
> wrote:
>
t` on the lhs rather than a
> reshape on the rhs. At least that was one suggested fix, I don't know
> if it works...
>
Frankly, I wouldn't necessarily suggest using .flat assignments instead.
`.flat` will basically enforce the old behavior, w
re
typically invisible...
>
> a[mask_in] = np.array([2.0]) # This works and repeats 2.0 twice. I
> thought this wasn't supposed to happen anymore?
>
Again, broadcasting of values onto out shape.
- Sebastian
>
> Ben Root
>
>
> ___
< 0] = 0
Where it might be that the array has no elements smaller 0. Though I
admit I would write 0 here, and not [0].
- Sebastian
>
> Ben
>
>
>
> On Sun, Jul 6, 2014 at 3:59 PM, Charles R Harris
> wrote:
>
>
>
> On Sun,
st this, what about
banning such functions to something like numpy.interactive/numpy.helpers
which you can then import * (or better specific functions) from?
I think the fact that you need many imports on startup should rather be
fixed by an ipython scientific mode or other startup imports.
- Sebast
On Mo, 2014-07-07 at 09:50 -0400, josef.p...@gmail.com wrote:
>
>
>
> On Mon, Jul 7, 2014 at 9:11 AM, Sebastian Berg
> wrote:
> On Mo, 2014-07-07 at 08:25 -0400, Alan G Isaac wrote:
> > On 7/7/2014 7:17 AM, Daπid wrote:
> > > How about a
on storing element[i] =
value.encode(specified_encoding).
There is always the never ending small issue of trailing null bytes. If
we want to be fully compatible, such a type would have to store the
string length explicitly to support trailing null bytes.
- Sebastian
>
> Chuck
>
&
ors), it did something, but usually not the right thing. This is
fixed in recent versions (not sure if 1.8 or only now with 1.9)
- Sebastian
> The first example shows the problem and we looked at the source for
> np.cross and believe we found the bug - an unnecessary swapaxes when
> returnin
On Mi, 2014-07-16 at 09:07 +0100, Nathaniel Smith wrote:
> Weirdly, I never received Chuck's original email in this thread.
> Should some list admin be informed?
>
I send some mails yesterday and they never arrived... Not sure if it is
a problem on my side or not.
> I also am not sure what/where
be too magic, but it's my preferred solution.
>
Making it a warning may be another option. Changing `.T` to promote to
2-d (also maybe to actually only transpose the last two axes for higher
D arrays), could be nice, but getting there might take quite a long
FutureWarning or even Er
e.num
Out[17]: 7
In [18]: np.arange(30).dtype.num
Out[18]: 7
frankly, I am not sure what needs to change at all, except the normal
array creation and the sum promotion rule. I am probably naive here, but
what is the ABI change that is necessary for that?
I guess the problem you see is breaking co
On Wed, 2014-07-23 at 22:06 +0200, Sebastian Berg wrote:
> On Wed, 2014-07-23 at 21:50 +0200, Julian Taylor wrote:
> > On 23.07.2014 20:54, Robert Kern wrote:
> > > On Wed, Jul 23, 2014 at 6:19 PM, Julian Taylor
> > > wrote:
> > >> hi,
> > >>
that a new user will have difficulty
understanding when he can be sure it is used.
- Sebastian
>
> On Fri, Jul 25, 2014 at 8:00 PM, Alan G Isaac
> wrote:
> On 7/25/2014 1:40 PM, Eelco Hoogendoorn wrote:
> > A
g that is very
much worth it speed wise...
- Sebastian
>
> On Sat, Jul 26, 2014 at 12:39 PM, Sturla Molden
> wrote:
> Sebastian Berg wrote:
>
> > chose more stable algorithms for such statistical functions.
> The
> > pairwise
On Mo, 2014-07-28 at 14:37 +0200, Eelco Hoogendoorn wrote:
> To rephrase my most pressing question: may np.ones((N,2)).mean(0) and
> np.ones((2,N)).mean(1) produce different results with the
> implementation in the current master? If so, I think that would be
> very much regrettable; and if this is
On Mo, 2014-07-28 at 15:35 +0200, Sturla Molden wrote:
> On 28/07/14 15:21, alex wrote:
>
> > Are you sure they always give different results? Notice that
> > np.ones((N,2)).mean(0)
> > np.ones((2,N)).mean(1)
> > compute means of different axes on transposed arrays so these
> > differences 'cance
On Mo, 2014-07-28 at 15:50 +0200, Fabien wrote:
> On 28.07.2014 15:30, Daπid wrote:
> > An example using float16 on Numpy 1.8.1 (I haven't seen diferences with
> > float32):
>
> Why aren't there differences between float16 and float32 ?
>
float16 calculations are actually float32 calculations. I
On Mo, 2014-07-28 at 16:31 +0200, Eelco Hoogendoorn wrote:
> Sebastian:
>
>
> Those are good points. Indeed iteration order may already produce
> different results, even though the semantics of numpy suggest
> identical operations. Still, I feel this different behavior withou
r array sizes, you could blow up the
first array from (N,) to (N-M+1,M) and then check if any row matches
completely. There may be better tricks available though, especially if
array1 is large.
- Sebastian
> Thank
> ___
> NumPy-Discussi
and
matrix-vector would require the user to use (1, n) or (n, 1) matrices.
If someone can convince me that this is a big deal, flags might be the
only option, though...
- Sebastian
>
> +1
>
>
> -Chris
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceano
discussion, so
maybe someone who might use such a feature has a preference. I know we
had a short discussion about this before, but it was a while ago. For
example another option would be to have the two weights as two keyword
arguments, instead of a boolean switch.
Regards,
Sebastian
eason for not relaxing the
restriction, unless there is some technical issue, but I doubt that.
- Sebastian
>
>
> On Thu, Aug 14, 2014 at 3:07 PM, Pierre-Andre Noel
> wrote:
> (I created issue 4965 earlier today on this
s act on the view. hopefully, you wont even have to
> touch the guts of einsum at the C level, because id say that isn't for
> the faint of heart...
>
I am not sure if einsum isn't pure C :). But even if, it should be doing
something identical already for duplicate indices on the
Hi,
Our short example-data:
>>> np.arange(10).reshape(1,5,2)
array([[[0, 1],
[2, 3],
[4, 5],
[6, 7],
[8, 9]]])
Shape is (1,5,2)
Two possibilies:
>>> data.reshape(5,2)
array([[0, 1],
[2, 3],
[4, 5],
[6, 7],
[8, 9]])
Or just:
>>> data[0]
On Do, 2014-08-28 at 00:08 +0900, phinn stuart wrote:
> Hi everyone, how can I convert (1L, 480L, 1440L) shaped numpy array
> into (480L, 1440L)?
>
Just slice it arr[0, ...] will do the trick. If you are daring,
np.squeeze also works, or of course np.reshape.
- Sebastian
>
>
On Fr, 2014-08-29 at 08:31 -0400, Neal Becker wrote:
> How do I run tests?
>
> python setup.py --help-commands claims 'test' is a command, but doesn't seem
> to
> work:
>
There is a runtests script you can use, it should do the building, too.
Or just install and then run `np.test()` (or run no
promotion
> b = np.insert(a, 4, (4, 'd'))
> Traceback (most recent call last):
> File "", line 1, in
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/numpy/lib/function_base.py",
> line 3464, in insert
> new[slobj] = values
> Va
On Sa, 2014-08-30 at 09:04 +0100, Sebastian Berg wrote:
> On Fr, 2014-08-29 at 22:10 -0400, Benjamin Root wrote:
> > Consider the following:
> >
> > a = np.array([(1, 'a'), (2, 'b'), (3, 'c')], dtype=[('foo', 'i'),
> > (
On Mi, 2014-09-03 at 18:47 -0600, Charles R Harris wrote:
>
>
>
> On Wed, Sep 3, 2014 at 5:48 PM, Eelco Hoogendoorn
> wrote:
> +1; though I am relatively new to the scene, Jaime's
> contributions have always stood out to me as thoughtful.
>
>
> On Thu,
On So, 2014-09-07 at 12:33 +0200, Julian Taylor wrote:
> Hello,
>
> We are proud to announce the 1.9.0 release of NumPy.
>
Awesome, thanks for the release management!
- Sebastian
> This release includes numerous performance improvements, most
> significantly the inde
you have an
array-priority > 0 -> return NotImplemented). So yeah, why do the
operators use numpy_ufunc at all? (unless due to implementation)
If we have a function numpy_ufunc would probably make sense, since that
circumvents the python dispatch mechanism.
- Sebastian
>
> Thoughts?
>
lse], dtype=bool),
> array([True], dtype=bool)])
>
> ValueError: The truth value of an array with more than one element is
> ambiguous. Use a.any() or a.all()
>
> Am I missing something here?
>
`np.asarray([array([1, 2]), array([1])])` is an object array, not a
boolean arr
301 - 400 of 892 matches
Mail list logo
