Hi,
Le 23/02/2012 02:24, Matthew Brett a écrit :
> Luckily I was in fact using longdouble in the live code,
I had never "exotic" floating point precision, so thanks for your post
which made me take a look at docstring and documentation.
If I got it right from the docstring, 'np.longdouble', 'np.lo
Le 23/02/2012 12:40, Francesc Alted a écrit :
>> However, I was surprised that float128 is not mentioned in the array of
>> > available types in the user guide.
>> > http://docs.scipy.org/doc/numpy/user/basics.types.html
>> > Is there a specific reason for this absence, or is just about visiting
>>
Le 23/02/2012 17:28, Charles R Harris a écrit :
> That's correct. They are both extended precision (80 bits), but
> aligned on 32bit/64bit boundaries respectively. Sun provides a true
> quad precision, also called float128, while on PPC long double is an
> odd combination of two doubles.
This is in
Le 23/02/2012 20:08, Mark Wiebe a écrit :
> +1, I think it's good for its name to correspond to the name in C/C++,
> so that when people search for information on it they will find the
> relevant information more easily. With a bunch of NumPy-specific
> aliases, it just creates more hassle for ever
Le 23/02/2012 20:32, Wes McKinney a écrit :
> If anyone wants to get involved in this particular problem right
> now, let me know!
Hi Wes,
I'm totally out of the implementations issues you described, but I have
some million-lines-long CSV files so that I experience "some slowdown"
when loading tho
Le 23/02/2012 21:08, Travis Oliphant a écrit :
> I think loadtxt is now the 3rd or 4th "text-reading" interface I've seen in
> NumPy.
Ok, now I understand why I got confused ;-)
--
Pierre
signature.asc
Description: OpenPGP digital signature
___
Num
Le 23/02/2012 22:38, Benjamin Root a écrit :
> labmate/officemate/advisor is using Excel...
... or an industrial partner with its windows-based software that can
export (when it works) some very nice field data from a proprietary
Honeywell data logger.
CSV data is better than no data ! (and better
Hi,
Le 24/02/2012 01:00, Matthew Brett a écrit :
> Right - no proposal to change float64 because it's not ambiguous - it
> is both binary64 IEEE floating point format and 64 bit width.
All right ! Focusing the renaming only on those "extended precision"
float types makes sense.
> The confusion here
Hi,
Le 24/02/2012 13:55, Nicolas Rougier a écrit :
> You should use a (M,N,2) array to store your vectors:
> [...]
> [...]
> numpy.dot(data,rotation)
looking at how numpy.dot generalizes the matrix product* to N-dim
arrays, I came to the same conclusion.
I just suspect that the 'rotation' array sh
Hi,
Great idea !
What's the plan to spread the word about this survey ? Is it about
forwarding the link to friends and colleagues ?
Le 24/02/2012 01:20, Travis Oliphant a écrit :
> After you complete the survey, I would really appreciate any feedback on
> questions that could be improved, remove
Le 24/02/2012 14:49, Bob Dowling a écrit :
> Thank you all (and especially the gentleman who spotted I was rotating
> in the wrong direction).
No I hadn't ! I had just mentioned the transpose issue for writing
"numpy.dot(data,rotation)".
So in the end the two sign flips cancel each other and Nicol
Le 24/02/2012 16:38, Robert Pyle a écrit :
>> I wonder what is the use case of these 80 bits numbers apart from what
>> > is described as "keeping intermediate results" when performing
>> > exponentiation on doubles ?
> In AIFF audio files, the sample rate is stored in the Common Chunk as an
> 80-
Hi,
Le 29/02/2012 16:22, Paweł Biernat a écrit :
> Is there any way to interact with Fortran's real(16) (supported by gcc
> and Intel's ifort) data type from numpy? By real(16) I mean the
> binary128 type as in IEEE 754. (In C this data type is experimentally
> supported as __float128 (gcc) and _Q
Hi,
Just to start the new month on a light & happy topic :
IPython 0.12 has entered Debian Testing !
--
Pierre
(I'm not at all involved in the process that enabled IPython make its
way to Testing. I've been watching this quite closely however. I
"suspect" there was a decent amount of work on
Le 02/03/2012 14:39, Nathaniel Smith a écrit :
> If/when someone adds __float128 support to numpy we should really just
> call it float128
I agree!
Other types could become "float80_128" and "float80_96", as mentioned
about a week ago by Matthew.
--
Pierre
signature.asc
Description: OpenPGP d
Hi Mark,
I went through the NA NEP a few days ago, but only too quickly so that
my question is probably a rather dumb one. It's about the usability of
bitpatter-based NAs, based on your recent post :
Le 03/03/2012 22:46, Mark Wiebe a écrit :
> Also, here's a thought for the usability of NA-float6
Hi,
Thanks you very much for your lights !
Le 06/03/2012 21:59, Nathaniel Smith a écrit :
> Right -- R has a very impoverished type system as compared to numpy.
> There's basically four types: "numeric" (meaning double precision
> float), "integer", "logical" (boolean), and "character" (string).
Hi,
Le 06/03/2012 22:19, Charles R Harris a écrit :
> Use polynomial.Polynomial and you won't have this problem.
I was not familiar with the "poly1d vs. Polynomial" choice.
Now, I found in the doc some more or less explicit guidelines in:
http://docs.scipy.org/doc/numpy/reference/routines.polynomi
Hi,
Le 07/03/2012 20:57, Eric Firing a écrit :
> In other words, good low-level support for numpy.ma functionality?
Coming back to *existing* ma support, I was just wondering whether it
was now possible to "np.save" a masked array.
(I'm using numpy 1.5)
In the end, this is the most annoying problem
Hi Charles,
Le 07/03/2012 18:00, Charles R Harris a écrit :
>
> That's a good idea, I'll take care of it. Note the caveat about the
> coefficients going in the opposite direction.
Great ! In the mean time I changed a bit the root polynomials reference
to emphasize the new Polynomial class.
http://
Hi,
Le 12/03/2012 00:21, Sturla Molden a écrit :
>
> It could also put Python/Numba high up on the Debian shootout ;-)
Can you tell a bit more about it ? (I just didn't understand the whole
sentence in fact ;-) )
Thanks !
--
Pierre
signature.asc
Description: OpenPGP digital signature
_
Le 09/03/2012 23:57, Ralf Gommers a écrit :
>
> The buildbot doesn't check the doc build. I've edited a few of the links.
Thanks for checking !
I had not realized that simply using the `numpy.package` notation was
enough to get a link to the package.
Best,
Pierre
signature.asc
Description: Op
Hi,
I have an off topic but somehow related question :
Le 19/03/2012 12:04, Matthieu Rigal a écrit :
> array = numpy.logical_and(numpy.logical_and(aBlueChannel < 1.0, aNirChannel >
> (aBlueChannel * 1.0)), aNirChannel < (aBlueChannel * 1.8))
Is there any significant difference between :
z = np.
Hi Eric,
Thanks for the hints !
Le 25/03/2012 20:33, Eric Firing a écrit :
> Using the bitwise operators in place of logical operators is a hack to
> get around limitations of the language; but, if done carefully, it is a
> useful one.
What is the rationale behind not overloading __and__ & othe
Hi,
A quick question I've had in mind for some time but didn't find a solution :
Is there a significant difference between "numpy.percentile" and
"scipy.stats.scoreatpercentile" ?
Of course the signatures are somewhat different, but I have the feeling
that the overall purpose is the same. Am I mi
Hi Nicole,
Le 27/03/2012 11:12, Nicole Stoffels a écrit :
> *if __name__ == '__main__':
>
> data_records = random.random((459375, 24))
> correlation = corrcoef(data_records)*
May I assume that your data_record is made of 24 different variables of
which you have 459375 observations ?
Le 27/03/2012 18:56, josef.p...@gmail.com a écrit :
> similar to std, var, histogram, ... some functions from scipy.stats
> are now in numpy.
Ok, historical reasons then. Fair enough.
Would a "See also: numpy.percentile" make sense in stats.scoreatpercentile ?
> However, in contrast to std, var, I
Hi,
Le 03/04/2012 22:10, Frédéric Bastien a écrit :
> I would like to add this parameter to Theano. So my question is, will
> the interface change or is it stable?
I don't know for the stability, but for the existence of this new parameter:
https://github.com/numpy/numpy/blob/master/numpy/core/fr
Hi,
I'm looking for the entry point in Numpy doc for the percentile function.
I'm assuming it should sit in routines.statistics but do not see it :
http://docs.scipy.org/doc/numpy/reference/routines.statistics.html
Am I missing something ? If indeed the percentile entry should be added,
do you ag
Hi,
Le 05/04/2012 15:00, Olivier Delalleau a écrit :
> Ok, it looks weird indeed. I was using numpy 1.6.1 myself, not sure if
> it's a bug that's been fixed in 1.6.
> Try without the keyword argument (b.flatten('C')), see if at least
> that works.
I can reproduce Chao's bug with my numpy 1.5.
As
Hi Chao,
Le 05/04/2012 17:17, Chao YUE a écrit :
> nice to know this. can also use b.transpose().flatten() to circumvent it.
Just a short remark : b.T is a shorcut for b.transpose() ;-)
Best,
Pierre
signature.asc
Description: OpenPGP digital signature
_
Sorry for the noise on the ML, I thougt I had made a private reply...
--
Pierre
Le 05/04/2012 18:53, Pierre Haessig a écrit :
> Hi Chao,
>
> Le 05/04/2012 17:17, Chao YUE a écrit :
>> nice to know this. can also use b.transpose().flatten() to circumvent it.
> Just a short
Le 06/04/2012 14:06, mark florisson a écrit :
> Could someone please ban this person from the mailing list, he keeps
> sending spam.
I was about to ask the same thing.
In the mean time, I googled the name of this gentleman and found a
possible match with a person working for the French national in
Hi,
Le 24/04/2012 15:14, Charles R Harris a écrit :
>
> a) All arrays should be implicitly masked, even if the mask isn't
> initially allocated. The maskna keyword can then be removed, taking
> with it the sense that there are two kinds of arrays.
>
From my lazy user perspective, having masked an
Hi,
Glad to see that 1.7 is coming soon !
Le 21/06/2012 12:11, Travis Oliphant a écrit :
> NumPy 1.7 is a significant release and has several changes many of which are
> documented in the release notes.
I browsed the sources on github and ended up here :
https://github.com/numpy/numpy/tree/mai
Hi,
While getting through the ufunc documentation,
(http://docs.scipy.org/numpy/docs/numpy-docs/reference/ufuncs.rst/)
I took the liberty to change one line in the code segment which
generates the "can cast safely" table. I wanted to increase the
readability if the table by increasing its contrast
Le 28/06/2012 02:34, Nathaniel Smith a écrit :
> Yes it does. If you want to avoid this extra copy, and have a
> pre-existing output array, you can do:
>
> np.add(a, b, out=c)
And is there a temporary copy when using inplace operators like:
c = a.copy()
c += b
Is there a temporary (c+b) array wh
Hi Nathaniel,
Le 27/06/2012 20:22, Nathaniel Smith a écrit :
> According to the Travis-CI build logs, this code produces
> non-deterministic behaviour in master:
You mean non-deterministic across different builds, not across different
executions on the same build, right ?
I just ran a small loop :
Hi,
Le 28/06/2012 15:35, Travis Oliphant a écrit :
> It really is inplace. As Nathaniel mentioned --- all ufuncs take an out
> keyword.
>
> The inplace mechanism uses this so that one input and the output are the same.
Thanks for the feedback about inplace assignment.
On the other hand, just
Hi,
Le 28/09/2012 21:02, Neal Becker a écrit :
> In [19]: u = np.arange (10)
>
> In [20]: v = np.arange (10)
>
> In [21]: u[v] = u
>
> In [22]: u[v] = np.arange(11)
>
> silence...
I've same behavior with my numpy 1.6.2.
It indeed looks strange that the end of the data vector is dropped in
silence
Hi,
Le 14/01/2013 11:35, Jaakko Luttinen a écrit :
> Ok, thanks, maybe I'll try to make the tests valid in all Python
> versions. It seems there's only one line which I'm not able to transform.
>
> In doc/sphinxext/tests/test_docscrape.py, on line 559:
> assert doc['Summary'][0] == u'öäöäöäöäö
Hi,
Le 14/01/2013 00:39, Nathaniel Smith a écrit :
> (The nice thing about np.filled() is that it makes np.zeros() and
> np.ones() feel like clutter, rather than the reverse... not that I'm
> suggesting ever getting rid of them, but it makes the API conceptually
> feel smaller, not larger.)
Coming
Hi Neal,
Le 11/01/2013 16:40, Neal Becker a écrit :
> I wanted to be able to handle the case of
>
> unwrap (arg (x1) + arg (x2))
>
> Here, phase can change by more than 2pi.
It's not clear to me what you mean by "change more than 2pi" ? Do you
mean that the consecutive points of in input can incre
Le 14/01/2013 18:33, Benjamin Root a écrit :
>
>
> How about "initialized()"?
>
>
> A verb! +1 from me!
Shouldn't it be "initialize()" then ? I'm not so fond of it though,
because initialize is pretty broad in the field of programming.
What about "refurbishing" the already existing "tile()" fu
Hi,
Le 14/01/2013 20:17, Alan G Isaac a écrit :
> >>> a = np.tile(5,(1,2,3))
> >>> a
> array([[[5, 5, 5],
> [5, 5, 5]]])
> >>> np.tile(1,a.shape)
> array([[[1, 1, 1],
> [1, 1, 1]]])
>
> I had not realized a scalar first argument was possible.
I didn't know either ! I discovered
Hi,
Le 14/01/2013 20:05, Benjamin Root a écrit :
> I do like the way you are thinking in terms of the broadcasting
> semantics, but I wonder if that is a bit awkward. What I mean is, if
> one were to use broadcasting semantics for creating an array, wouldn't
> one have just simply used broadcasti
Hi Neal,
Le 14/01/2013 15:39, Neal Becker a écrit :
> This code should explain all:
>
> import numpy as np
> arg = np.angle
>
> def nint (x):
> return int (x + 0.5) if x >= 0 else int (x - 0.5)
>
> def unwrap (inp, y=np.pi, init=0, cnt=0):
> o = np.empty_li
Hi,
Le 17/01/2013 23:31, Matthew Brett a écrit :
>> Would it be too weird or clumsy to extend the empty and empty_like functions
>> >to do the filling?
>> >
>> >np.empty((10, 10), fill=np.nan)
>> >np.empty_like(my_arr, fill=np.nan)
> That sounds like a good idea to me. Someone wanting a fast way t
Le 18/01/2013 23:22, Matthew Brett a écrit :
> I personally find 'fill' OK. I'd read:
>
> a = np.empty((10, 10), fill=np.nan)
>
> as
>
> "make an empty array shape (10, 10) and fill with nans"
+1
(and now we have *two* verbs ! )
--
Pierre
signature.asc
Description: OpenPGP digital signature
Hi,
Le 28/01/2013 17:31, Till Stensitzki a écrit :
> This is the calculates exp(-Kt).dot(y0) for a list a ts.
If your time vector ts is *regularly* discretized with a timestep h, you
could try an iterative computation
I would (roughly) write this as :
Ah = np.expm(A*h) # or use the "diagonalizat
Hi,
Le 28/01/2013 18:14, Till Stensitzki a écrit :
> On way would be just use cython, but i think this problem
> common enough to have a solution into scipy.
> (Solution of a simple compartment model.)
I see the solution you propose as a specialized ODE solver for linear
systems.
Then, what about
Hi everybody,
(just coming from a discussion on the performance of Matplotlib's
(x)corr function which uses np.correlate)
There have been already many discussions on how to compute
(cross-)correlations of time-series in Python (like
http://stackoverflow.com/questions/6991471/computing-cross-corre
Hi,
Le 22/02/2013 17:40, Matthew Brett a écrit :
> >From complete ignorance, do you think it is an option to allow a
> (n_left, n_right) tuple as a value for 'mode'?
>
That may be an option. Another one would be to add some kind of `bounds`
option which would be set to None by default but would ac
Hi,
Le 23/02/2013 20:25, Nathaniel Smith a écrit :
> My gut feeling is that we have too many methods on ndarray, not too
> few, but in any case, can you elaborate? What's the rationale for why
> np.abs(a) is so much harder than a.abs(), and why this function and
> not other unary functions?
(Just
Le 01/12/2011 02:44, Karl Kappler a écrit :
> Also note that I have had a similar problem with much smaller arrays,
> say 24 x 3076
Hi Karl,
Could you post a self-contained code with such a "small" array (or even
smaller. the smaller, the better...) so that we can run it and play with
it ?
--
P
Le 01/12/2011 14:52, Thouis (Ray) Jones a écrit :
> Is this expected behavior?
>
np.array([-345,4,2,'ABC'])
> array(['-34', '4', '2', 'ABC'], dtype='|S3')
>
>
With my numpy 1.5.1, I got indeed a different result:
In [1]: np.array([-345,4,2,'ABC'])
Out[1]:
array(['-345', '4', '2', 'ABC'],
Le 06/12/2011 23:13, Wes McKinney a écrit :
> I think R has two functions read.csv and read.csv2, where read.csv2 is
> capable of dealing with things like European decimal format.
>
I may be wrong, but from R's help I understand that read.csv, read.csv2,
read.delim, ...
are just calls to read.tabl
Le 07/12/2011 12:42, Pierre GM a écrit :
> Ever tried to use genfromtxt ?
You'll guess I didn't ... next time I'll do ;-)
Thanks for the tip !
Best,
Pierre
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinf
Le 09/12/2011 09:31, Robert Kern a écrit :
> We have some global state
> that we need to keep, and this gets interfered with in a multiple
> interpreter environment.
I recently got interested in multiprocessing computation with numpy and
now I get scare by your statement !
Please don't tell me it
Le 09/12/2011 15:00, Robert Kern a écrit :
Using multiprocessing is fine. That starts up multiple interpreters in
*different* processes. Yang is using a non-Python program that embeds
the CPython interpreter and starts up multiple copies of it in the
same process.
Ok, now I think I understand. I
Hi Sebastien,
Le 05/01/2012 15:02, Sébastien Barthélémy a écrit :
> However http://docs.scipy.org/doc/numpy/reference/generated/numpy.savez.html
> says:
>
> numpy.savez(file, *args, **kwds)¶
>
> Save several arrays into a single file in uncompressed .npz format.
>
> Moreover, this last page
Hi Eliot,
Le 19/01/2012 07:50, Elliot Saba a écrit :
> I recently needed to calculate the cross-covariance of two random
> vectors, (e.g. I have two matricies, X and Y, the columns of which are
> observations of one variable, and I wish to generate a matrix pairing
> each value of X and Y)
I d
Le 20/01/2012 16:30, Sturla Molden a écrit :
> Often we just want the upper-right p x p quadrant.
Thanks for the explanation.
If I understood it correctly, you're interested in the
*cross*-covariance block of the matrix (and now I understand better
Elliot's message). Actually, I thought that was th
Le 22/01/2012 11:28, Nadav Horesh a écrit :
> >>> special.erf(26.5)
> 1.0
> >>> special.erf(26.6)
> Traceback (most recent call last):
> File "", line 1, in
> special.erf(26.6)
> FloatingPointError: underflow encountered in erf
> >>> special.erf(26.7)
> 1.0
>
I can confirm this same behavi
Le 22/01/2012 01:40, josef.p...@gmail.com a écrit :
> same here,
> When I rewrote scipy.stats.spearmanr, I matched the numpy behavior for
> two arrays, while R only returns the cross-correlation part.
Since I've seen no negative feedback, I jumped to the next step by
creating a Trac account and po
Le 26/01/2012 15:57, Bruce Southey a écrit :
> Can you please provide a
> couple of real examples with expected output that clearly show what
> you want?
>
Hi Bruce,
Thanks for your ticket feedback ! It's precisely because I see a big
potential impact of the proposed change that I send first a ML
Le 26/01/2012 16:50, Pauli Virtanen a écrit :
> the current behavior is not a bug,
I completely agree that numpy.cov(m,y) does what it says !
I (and apparently some other people) are only questioning why there is
such a behavior ? Indeed, the second variable `y` is presented as "An
additional se
Le 26/01/2012 19:19, josef.p...@gmail.com a écrit :
> The discussion had this reversed, numpy matches the behavior of
> MATLAB, while R (statistics) only returns the cross covariance part as
> proposed.
>
I would also say that there was an attempt to match MATLAB behavior.
However, there is big di
Hi Bruce,
Sorry for the delay in the answer.
Le 27/01/2012 17:28, Bruce Southey a écrit :
> The output is still a covariance so do we really need yet another set
> of very similar functions to maintain?
> Or can we get away with a new keyword?
>
The idea of an additional keyword seems appealing.
10 lines of numpy related code...
Best,
Pierre
#!/usr/bin/python
# -*- coding: UTF-8 -*-
""" Autocorrelation timing study
Pierre Haessig â February 2012
"""
from __future__ import division, print_function
import numpy as np
import matplotlib.pyplot as plt
from
Le 01/02/2012 21:09, Benjamin Root a écrit :
> I can't reproduce this bug with the latest numpy from github master.
> Perhaps it has been fixed by now?
Hi,
I've no idea what's going on, but here is my $0.02 contribution. I
reproduced the bug (numpy 1.5.1) with a rather minimal script. See attache
I have a pretty silly question about initializing an array a to a given
scalar value, say A.
Most of the time I use a=np.ones(shape)*A which seems the most
widespread idiom, but I got recently interested in getting some
performance improvement.
I tried a=np.zeros(shape)+A, based on broadcastin
Le 13/02/2012 19:17, eat a écrit :
> wouldn't it be nice if you could just write:
> a= np.empty(shape).fill(A)
> this would be possible if .fill(.) just returned self.
Thanks for the tip. I noticed several times this was not working
(because of course, in the mean time, I forgot it...)
but I had to
Le 15/02/2012 04:07, Bruce Southey a écrit :
> The one thing that gets over looked here is that there is a huge
> diversity of users with very different skill levels. But very few
> people have an understanding of the core code. (In fact the other
> thread about type-casting suggests that it is ext
Le 04/02/2012 23:19, Ralf Gommers a écrit :
scipy.signal is the right place I think. numpy shouldn't grow too many
functions like this.
[going back in time on the autocorrelation topic]
I see scipy.signal being the good place. However, I have the (possibly
wrong) feeling that Matplotlib is
Le 16/02/2012 16:20, josef.p...@gmail.com a écrit :
I don't see any way to fix multivariate_normal for this case, except
for dropping svd or for random perturbing a covariance matrix with
multiplicity of singular values.
Hi,
I just made a quick search in what R guys are doing. It happens there
Hi Sudheer,
Le 14/03/2013 10:18, Sudheer Joseph a écrit :
> Dear Numpy/Scipy experts,
> Attached is a script
> which I made to test the numpy.correlate ( which is called py
> plt.xcorr) to see how the cross correlation is calculated. From this
> it app
Hi,
Le 19/03/2013 08:12, Sudheer Joseph a écrit :
> *Thank you Pierre,*
> It appears the numpy.correlate uses the
> frequency domain method for getting the ccf. I would like to know how
> serious or exactly what is the issue with normalization?. I have
> computed cross corre
Hi Nicolas,
Le 23/05/2013 15:45, Nicolas Rougier a écrit :
> if I use either a or b as output, results are wrong (and nothing in the dot
> documentation prevents me from doing this):
>
> a = np.array([[1, 2], [3, 4]])
> b = np.array([[1, 2], [3, 4]])
> np.dot(a,b,out=a)
>
> -> array([[ 6, 20],
>
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
Hi Hugo,
Le 14/08/2013 15:34, Hugo Gagnon a écrit :
> What is the best way, if any, to "do something" whenever array elements
> are changed in-place? For example, if I have a = arange(10), then
> setting a[3] = 1 would, say, call a function automatically.
I've never seen such a signal mechanism s
Hi,
Le 13/09/2013 10:32, Mark Bakker a écrit :
> Now that you mention it, (3L,4L) probably indeed occurs on Windows 64
> bit installations.
> Not sure about Mac 64 bit. I haven't tried that.
>
> So, is it desirable that the 32bit returns different integers than the
> 64bit? I would guess not.
Wha
Hi Robert,
Le 13/09/2013 11:22, Robert Kern a écrit :
>
> The Python `int` type represents a C `long` integer. On almost all
> 32-bit platforms, a C `long` is 32-bits, and memory addresses and
> offsets are also 32-bits. On 64-bit platforms, memory addresses and
> offsets are 64-bits, but nothing
"Jaime Fernández del Río" a écrit :
>I recently came up with a way of vectorizing some recursive sequence
>calculations. While it works, I am afraid it is relying on
>implementation
>details potentially subject to change. The basic idea is illustrated by
>this function, calculating the first n it
Hi,
Along the line of what David said, I just looked at the flags :
a = np.arange(10)
a.flags
[...]
OWNDATA : True
a = a[:3]
a.flags
[...]
OWNDATA : False
Indeed, after a=a[:3], a is not the same Python object but still points
to the data of the first object.
What I didn't find (by q
Hi,
Le 27/10/2013 19:28, Freddie Witherden a écrit :
> I wish to sort these points into a canonical order in a fashion which is
> robust against small perturbations. In other words changing any
> component of any of the points by an epsilon ~ 1e-12 should not affect
> the resulting sorted order.
Le 28/10/2013 13:40, Robert Kern a écrit :
> > What I didn't find (by quick googling) is how to access the original
> > array. Is it possible to access it (with Python code) ?
>
> a.base
Thanks! Is there a specific paragraph I missed in the user guide ?
I had googled "numpy access original array"
Hi Freddie,
Le 29/10/2013 10:21, Freddie Witherden a écrit :
> The order itself does not need to satisfy any specific properties.
I can't agree with you : if there is no specific property, then keeping
the list *unchanged* would be a fine solution (and very fast and very
very robust) ;-)
what abo
Le 29/10/2013 11:37, Pierre Haessig a écrit :
> def compare(point, other):
> delta = point - other
> argmax = np.abs(delta).argmax()
> delta_max = delta[argmax]
> if delta_max > 0:
> return 1
> elif delta_max < 0:
> return -1
Hi,
I just noticed (with numpy 1.7.1) that the following code
import numpy as np
np.savetxt('a.csv', [1], fmt=u'%.3f')
fails with:
1045 else:
1046 for row in X:
-> 1047 fh.write(asbytes(format % tuple(row) + newline))
1048 if len(footer) > 0:
Le 13/11/2013 17:54, Daπid a écrit :
>
> np.savetxt('a.csv', [1], fmt=str('%.3f'))
Thanks, that's what I did too.
I'm just still wondering whether there is a cleaner solution...
>
> Without the str, I get a clearer error:
> ValueError: invalid fmt: u'%.3f'
>
Yeah, the commit by Warren Weckesser m
Hello,
In order to repeat rows or columns of an array as
http://stackoverflow.com/questions/1550130/cloning-row-or-column-vectors
I can use np.repeat as suggested by pv. However, looking at the flags of
the resulting array, data seems to be copied and actually repeated in
memory. This is not appli
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 is more dangerous than helping.
> Though with some care you can easily implement such functions u
Hi,
Le 25/02/2014 09:19, Chris a écrit :
> I have some old code that uses cPickle.loads which used to work, but now
> reports an error in loading the module Numeric. Since Numeric has been
> replaced by numpy, this makes sense, but, how can I get cPickle.loads to
> work? I tested the code again on
Hi,
Le 06/03/2014 12:17, Albert Jornet Puig a écrit :
> I am working with *apply_along_axis* method and I would like to apply
> a method that requires to pass named arguments
> (scipy.stats.mstats.mquantiles with prob[]). But currently, it is not
> possible with *apply_along_axis*.
>
> I wonder if
Le 10/03/2014 10:38, Christophe Bal a écrit :
> is there a SVG version of the NumPy logo ? This would be to be used on
> my website.
Could it be one of those
https://github.com/numpy/numpy/tree/master/branding/icons ?
(don't know if it's up to date though)
best,
Pierre
Hi,
Le 22/03/2014 19:13, Nathaniel Smith a écrit :
> After 88 emails we don't have a conclusion in the other thread (see
> [1] for background). But we have to come to some conclusion or another
> if we want @ to exist :-). So I'll summarize where the discussion
> stands and let's see if we can fin
Hi,
Le 07/12/2014 08:10, Stephan Hoyer a écrit :
> In [5]: %timeit xray.core.utils.as_shape(x, y.shape)
> 10 loops, best of 3: 17 µs per loop
>
> Would this be a welcome addition to numpy's lib.stride_tricks? If so,
> I will put together a PR.
>
>
Instead of putting this function in stride_t
of 20ms instead of 1ms (and because the sine is periodic, this was not
obvious).
In addition, to get a good estimation of the delay with cross
correlation, you need many perdiods.
Here is a modification of your notebook :
http://nbviewer.ipython.org/gist/pierre-haessig/e2dda384ae0e08943
As a side note, I've still in mind the proposal I made back in 2013 to
make np.correlate faster
http://numpy-discussion.10968.n7.nabble.com/another-discussion-on-numpy-correlate-and-convolution-td32925.html
The basic idea is to enable the user to select the exact range of lags
he wants. Unfortu
1 - 100 of 109 matches
Mail list logo
