[Numpy-discussion] Numpy savetxt: change decimal separator
Hello everyone, I save data to a file with the following statement: np.savetxt(fileName, transpose((average_dist, std_deviation, maximum_dist, sum_of_dist)), delimiter = ';', fmt='%6.10f') is there a possibility to change the decimal seperator from a point to comma ? And another question I import this file to excel, is there also a possiblity to create a headline for each column, that the file looks like the following example: average; standard deviation; maximum distance; sum of distances 0,26565; 0,65565; 2,353535; 25, 5656 ... ... ... Thanks, Markus___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Numpy extension writing problems
Hi - I've never written a Python extension before, so I apologise in advance
for my lack of knowledge. I'm trying to interpret a variable length tuple of
variable length numpy arrays, convert then to C double arrays and pass them
to a C++ function. I'm using SIP (as I also need to deal with Qt).
Here is my rather poor code(I realise that variable length C arrays on the
stack are a gcc extension). a0 is the PyObject* for the tuple. It core dumps
on PyArray_AsCArray.
%MethodCode
const Py_ssize_t numitems = PyTuple_Size(a0);
double* data[numitems];
int sizes[numitems];
PyObject* objects[numitems];
int status = 0;
PyArray_Descr *descr = PyArray_DescrFromType(PyArray_DOUBLE);
for(Py_ssize_t i = 0; i != numitems; i++)
data[i] = NULL;
if( ! PyTuple_Check(a0) )
goto exit;
for(Py_ssize_t i = 0; i != numitems; i++)
{
objects[i] = PyTuple_GetItem(a0, i);
npy_intp size;
int ret = PyArray_AsCArray(objects[i], (void*)(data[i]),
size, 1, descr);
if(ret 0)
{
status = 1;
goto exit;
}
sizes[i] = size;
}
// this is the actual function to call
TestKlass::myfunc(data, sizes, numitems);
exit:
for(Py_ssize_t i = 0; i != numitems; i++)
{
if( data[i] != NULL )
{
PyArray_Free(objects[i], data[i]);
}
}
if(status != 0)
{
PyErr_SetString(PyExc_RuntimeError, conversion error);
sipIsErr = 1;
}
%End
Can someone give me a hint on where I'm going wrong? Can't I pass
PyTuple_GetItem objects to PyArray_AsCArray. Is there a numpy built in
routine which makes this easier?
Thanks
Jeremy
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy savetxt: change decimal separator
On Thu, Sep 24, 2009 at 2:07 AM, markus.proel...@ifm.com wrote: Hello everyone, I save data to a file with the following statement: np.savetxt(fileName, transpose((average_dist, std_deviation, maximum_dist, sum_of_dist)), delimiter = ';', fmt='%6.10f') is there a possibility to change the decimal seperator from a point to comma ? And another question I import this file to excel, is there also a possiblity to create a headline for each column, that the file looks like the following example: I don't know how to accomplish the first task, but for the latter the following lines should work: fid = open(fileName, 'w') fid.write(average; standard deviation; maximum distance; sum of distances) np.savetxt(fid, transpose((average_dist, std_deviation, maximum_dist, sum_of_dist)), delimiter = ';', fmt='%6.10f') fid.close() average; standard deviation; maximum distance; sum of distances 0,26565; 0,65565; 2,353535; 25, 5656 ... ... ... Thanks, Markus ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Gökhan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Resize Method for Numpy Array
Dear all,
I have an Hamletic doubt concerning the numpy array data type.
A general learned rule concerning the array usage in other high-level
programming languages is that array data-type are homogeneous datasets
of fixed dimension.
Therefore, is not clear to me why in numpy the size of an array can be
changed (either with the 'returning-value' resize() function either with
the 'in-place' array method resize()).
More in detail, if the existence of the first function
('returning-value') might make sense in array computing operation, the
existence of the 'in-place' method really make no sense for me.
Would you please be so kind to give some explanation for the existence of
resize operator for numpy array? If array size can be change, what are the real
advantages of using numpy array instead of list object?
Thanks in avdance
Best Regards___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Resize Method for Numpy Array
Alice Invernizzi wrote:
Dear all,
I have an Hamletic doubt concerning the numpy array data type.
A general learned rule concerning the array usage in other high-level
programming languages is that array data-type are homogeneous datasets
of fixed dimension.
Therefore, is not clear to me why in numpy the size of an array can be
changed (either with the 'returning-value' resize() function either with
the 'in-place' array method resize()).
More in detail, if the existence of the first function
('returning-value') might make sense in array computing operation, the
existence of the 'in-place' method really make no sense for me.
Would you please be so kind to give some explanation for the existence
of resize operator for numpy array? If array size can be change,
what are the real advantages of using numpy array instead of list object?
Thanks in avdance
Just to keep into the same line.
import numpy
a=numpy.arange(100.)
a.shape = 10, 10
b = a * 1 # just to get a copy
b.shape = 5, 2, 5, 5
b = (b.sum(axis=3)).sum(axis=1)
In that way, on b I have a binned image of a.
I would expect a.resize(5, 5) would have given something similar
(perhaps there is already something to make a binning). In fact
a.resize(5,5) is much closer to a crop than to a resize. I think the
resize name is misleading and should be called crop, but that is just my
view.
Armando
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Resize Method for Numpy Array
V. Armando Solé wrote: Sorry, there was a bug in the sent code. It should be: import numpy a=numpy.arange(100.) a.shape = 10, 10 b = a * 1 # just to get a copy b.shape = 5, 2, 5, 2 b = (b.sum(axis=3)).sum(axis=1) In that way, on b I have a binned image of a. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy savetxt: change decimal separator
On Sep 24, 2009, at 3:07 AM, markus.proel...@ifm.com wrote:
Hello everyone,
I save data to a file with the following statement:
np.savetxt(fileName, transpose((average_dist, std_deviation,
maximum_dist, sum_of_dist)), delimiter = ';', fmt='%6.10f')
is there a possibility to change the decimal seperator from a point
to comma ?
And another question I import this file to excel, is there also a
possiblity to create a headline for each column, that the file looks
like the following example:
average; standard deviation; maximum distance; sum of distances
0,26565; 0,65565; 2,353535; 25, 5656
For the first task, I don't know if there is any direct way in numpy
to change the decimal sep, but a little bit awkward trick as follows
should work:
mem_file = StringIO.StringIO()
np.savetxt(mem_file, ... )
new_data_str = mem_file.getvalue().replace('.', ',')
output_file = open(fileName, 'w')
output_file.write(new_data_str)
output_file.close()
Or you can use regex to get better match for the decimal seperator.
Thanks,
Junda___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Coercing object arrays to string (or unicode) arrays
Michael Droettboom wrote: As I'm looking into fixing a number of bugs in chararray, I'm running into some surprising behavior. In [14]: x = np.array(['abcdefgh', 'ijklmnop'], 'O') # Without specifying the length, it seems to default to sizeof(int)... ??? In [15]: np.array(x, 'S') Out[15]: array(['abcd', 'ijkl'], dtype='|S4') This sure looks like a bug, and I'm no expert, but I suspect that it's the size of a pointer (you are on a 32 system -- I am), which makes a bit of sense, as Object arrays store a pointer to the python objects. The question is, what should the array constructor do? perhaps the equivalent of: In [41]: np.array(x.tolist()) Out[41]: array(['abcdefgh', 'ijklmnop'], dtype='|S8') which you could use as a work around. Do you need to go through object arrays? could you go straight to a string array: np.array(['abcdefgh', 'ijklmnop'], np.string_) Out[35]: array(['abcdefgh', 'ijklmnop'], dtype='|S8') or just keep the strings in a list. Object arrays are weird, I think there are a lot of corner cases. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Coercing object arrays to string (or unicode) arrays
On 09/24/2009 01:02 PM, Christopher Barker wrote: Michael Droettboom wrote: As I'm looking into fixing a number of bugs in chararray, I'm running into some surprising behavior. In [14]: x = np.array(['abcdefgh', 'ijklmnop'], 'O') # Without specifying the length, it seems to default to sizeof(int)... ??? In [15]: np.array(x, 'S') Out[15]: array(['abcd', 'ijkl'], dtype='|S4') This sure looks like a bug, and I'm no expert, but I suspect that it's the size of a pointer (you are on a 32 system -- I am), which makes a bit of sense, as Object arrays store a pointer to the python objects. That was my guess, too, but I haven't yet delved into the code. I'm on 32-bit as well. The question is, what should the array constructor do? perhaps the equivalent of: In [41]: np.array(x.tolist()) Out[41]: array(['abcdefgh', 'ijklmnop'], dtype='|S8') which you could use as a work around. Yes, that's the behaviour I was expecting. Do you need to go through object arrays? could you go straight to a string array: np.array(['abcdefgh', 'ijklmnop'], np.string_) Out[35]: array(['abcdefgh', 'ijklmnop'], dtype='|S8') or just keep the strings in a list. The background here is that I'm fixing/resurrecting chararray, which provides vectorized versions of the standard Python string operations, endswith, ljust etc. I was using object arrays when the length of the output string can't be determined ahead of time. For example, the string __mod__ operator. I could probably get away with generating a list of strings instead, but it's a little bit inconsistent with how I'm doing things elsewhere, which is always to generate an array. Object arrays are weird, I think there are a lot of corner cases. Yeah, that's been my experience. But it would be nice to try to plug those corner cases up if possible. I'll spend some time investigating this particular one. Cheers, Mike ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Resize Method for Numpy Array
Alice Invernizzi wrote: Therefore, is not clear to me why in numpy the size of an array can be changed (either with the 'returning-value' resize() function either with the 'in-place' array method resize()). Would you please be so kind to give some explanation for the existence of resize operator for numpy array? I don't find I use it that much, but it can be useful for the same reason that it is for lists, etc. If array size can be change, what are the real advantages of using numpy array instead of list object? This I can really answer! the it's a known size property of an nd-array is probably the least useful one I can think of. I think the pre-known size aspect of array objects is really an artifact of wanting efficient storage and processing, rather than a feature -- particularly in a dynamic language. As for other advantages: arrays are homogeneous data -- giving far more efficiency in a dynamic language arrays are n-d -- you can slice and dice them as such -- it's easy to extract either a row or a column from a 2-d array, for instance. slices of arrays are arrays with a view on the same data: this makes it easy to manipulate portions of an array with the same code you'd manipulate a full array. array broadcasting easy and efficient interchange of raw data with other data types, from C, C++ , Fortran, etc code. and I could go on! You might actually ask the question the other way -- if you can re-size an array -- why do you ever need to use a list? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] chebyshev polynomials
Hi All, Would it be appropriate to add a class similar to poly but instead using chebyshev polynomials? That is, where we currently have 'poly', 'poly1d', 'polyadd', 'polyder', 'polydiv', 'polyfit', 'polyint', 'polymul', 'polysub', 'polyval', change poly to cheb. The rational here is two-fold: first, chebyshev series generally yield better conditioned fits than polynomials and second, I am going to add a more general remez algorithm to scipy for real functions defined on the unit circle in the complex plane and one of the consequences is that it is possible to generate minmax polynomial fits over an interval, but the natural form of the result is a chebyshev series. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Coercing object arrays to string (or unicode) arrays
I have filed a bug against this, along with a patch that fixes casting to fixed-size string arrays: http://projects.scipy.org/numpy/ticket/1235 Undefined-sized string arrays is a harder problem, which I'm deferring for later. Mike On 09/24/2009 01:19 PM, Michael Droettboom wrote: On 09/24/2009 01:02 PM, Christopher Barker wrote: Michael Droettboom wrote: As I'm looking into fixing a number of bugs in chararray, I'm running into some surprising behavior. In [14]: x = np.array(['abcdefgh', 'ijklmnop'], 'O') # Without specifying the length, it seems to default to sizeof(int)... ??? In [15]: np.array(x, 'S') Out[15]: array(['abcd', 'ijkl'], dtype='|S4') This sure looks like a bug, and I'm no expert, but I suspect that it's the size of a pointer (you are on a 32 system -- I am), which makes a bit of sense, as Object arrays store a pointer to the python objects. That was my guess, too, but I haven't yet delved into the code. I'm on 32-bit as well. The question is, what should the array constructor do? perhaps the equivalent of: In [41]: np.array(x.tolist()) Out[41]: array(['abcdefgh', 'ijklmnop'], dtype='|S8') which you could use as a work around. Yes, that's the behaviour I was expecting. Do you need to go through object arrays? could you go straight to a string array: np.array(['abcdefgh', 'ijklmnop'], np.string_) Out[35]: array(['abcdefgh', 'ijklmnop'], dtype='|S8') or just keep the strings in a list. The background here is that I'm fixing/resurrecting chararray, which provides vectorized versions of the standard Python string operations, endswith, ljust etc. I was using object arrays when the length of the output string can't be determined ahead of time. For example, the string __mod__ operator. I could probably get away with generating a list of strings instead, but it's a little bit inconsistent with how I'm doing things elsewhere, which is always to generate an array. Object arrays are weird, I think there are a lot of corner cases. Yeah, that's been my experience. But it would be nice to try to plug those corner cases up if possible. I'll spend some time investigating this particular one. Cheers, Mike ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] chebyshev polynomials
to, 2009-09-24 kello 11:51 -0600, Charles R Harris kirjoitti: Would it be appropriate to add a class similar to poly but instead using chebyshev polynomials? That is, where we currently have [clip] Yes, I think. scipy.special.orthogonal would be the best place for this, I think. Numpy would probably be a wrong place for stuff like this. Ideally, all the orthogonal polynomial classes in Scipy should be rewritten to use more a stable representation of the polynomials. Currently, they break down at high orders, which is a bit ugly. I started working on something related in the spring. The branch is here: http://github.com/pv/scipy-work/tree/ticket/921-orthogonal but as you can see, it hasn't got far (eg. orthopoly1d.__call__ is effectively a placeholder). Anyway, the idea was to divide the orthopoly1d class to subclasses, each having more stable polynomial-specific evaluation routines. Stability-preserving arithmetic would be supported at least within the polynomial class. As a side note, should the cheby* versions of `polyval`, `polymul` etc. just be dropped to reduce namespace clutter? You can do the same things already within just class methods and arithmetic. Cheers, Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Resize Method for Numpy Array
On Thu, Sep 24, 2009 at 09:58, Alice Invernizzi inverni...@cilea.it wrote:
Dear all,
I have an Hamletic doubt concerning the numpy array data type.
A general learned rule concerning the array usage in other high-level
programming languages is that array data-type are homogeneous datasets
of fixed dimension.
While this description is basically true of numpy arrays, I would
caution you that every language has a different lexicon, and the same
word can mean very different things in each. For example, Python lists
are *not* linked lists; they are like C++'s std::vectors with a
preallocation strategy to make appending cheap on average.
Therefore, is not clear to me why in numpy the size of an array can be
changed (either with the 'returning-value' resize() function either with
the 'in-place' array method resize()).
More in detail, if the existence of the first function
('returning-value') might make sense in array computing operation, the
existence of the 'in-place' method really make no sense for me.
Would you please be so kind to give some explanation for the existence of
resize operator for numpy array? If array size can be change, what are the
real advantages of using numpy array instead of list object?
The .resize() method is available for very special purposes and should
not be used in general. It will only allow itself to be used if there
were no views created from it; otherwise, it will raise an exception.
The reason is that it must necessarily reallocate memory for the new
size and copy the data over. Any views would be pointing to
deallocated data. .resize() can be useful when you are constructing
arrays from a stream of data of unknown length and you haven't let any
other code see the array, yet. It is not really a defining feature of
numpy arrays like the other features that Chris Barker has listed for
you.
--
Robert Kern
I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth.
-- Umberto Eco
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] chebyshev polynomials
On Thu, Sep 24, 2009 at 14:18, Pauli Virtanen p...@iki.fi wrote: As a side note, should the cheby* versions of `polyval`, `polymul` etc. just be dropped to reduce namespace clutter? You can do the same things already within just class methods and arithmetic. Just to clarify, you mean having classmethods that work on plain arrays of Chebyshev coefficients? I'm +1 on that. I'm -1 on only having a ChebyPoly class with instance methods, although it would be useful to have as an adjunct to the plain routines. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] chebyshev polynomials
to, 2009-09-24 kello 14:31 -0500, Robert Kern kirjoitti: On Thu, Sep 24, 2009 at 14:18, Pauli Virtanen p...@iki.fi wrote: As a side note, should the cheby* versions of `polyval`, `polymul` etc. just be dropped to reduce namespace clutter? You can do the same things already within just class methods and arithmetic. Just to clarify, you mean having classmethods that work on plain arrays of Chebyshev coefficients? I'm +1 on that. I'm -1 on only having a ChebyPoly class with instance methods, although it would be useful to have as an adjunct to the plain routines. I meant only having a ChebyPoly class with instance methods. Personally, I've always used poly1d instances instead of the poly* routines apart from polyfit. But perhaps this is not how everyone uses them. Using class methods is an interesting idea, though. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] chebyshev polynomials
On Thu, Sep 24, 2009 at 1:18 PM, Pauli Virtanen p...@iki.fi wrote: to, 2009-09-24 kello 11:51 -0600, Charles R Harris kirjoitti: Would it be appropriate to add a class similar to poly but instead using chebyshev polynomials? That is, where we currently have [clip] Yes, I think. scipy.special.orthogonal would be the best place for this, I think. Numpy would probably be a wrong place for stuff like this. Ideally, all the orthogonal polynomial classes in Scipy should be rewritten to use more a stable representation of the polynomials. Currently, they break down at high orders, which is a bit ugly. I started working on something related in the spring. The branch is here: http://github.com/pv/scipy-work/tree/ticket/921-orthogonal but as you can see, it hasn't got far (eg. orthopoly1d.__call__ is effectively a placeholder). Anyway, the idea was to divide the orthopoly1d class to subclasses, each having more stable polynomial-specific evaluation routines. Stability-preserving arithmetic would be supported at least within the polynomial class. I was thinking of storing the chebyshev internally as the values at the chebyschev points. This makes multiplication, differentiation and such quite easy (resample and multiply/divide appropriatately). Its equivalent to working in the fourier domain for convolution and differentiation. The transform back and forth is likewise othogonal, so stable. The intepolation also becomes simple using the barycentric version. As a side note, should the cheby* versions of `polyval`, `polymul` etc. just be dropped to reduce namespace clutter? You can do the same things already within just class methods and arithmetic. What do you mean? The evaluation can use various stable methods appropriate to the chebyshev series. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] chebyshev polynomials
On Thu, Sep 24, 2009 at 1:31 PM, Robert Kern robert.k...@gmail.com wrote: On Thu, Sep 24, 2009 at 14:18, Pauli Virtanen p...@iki.fi wrote: As a side note, should the cheby* versions of `polyval`, `polymul` etc. just be dropped to reduce namespace clutter? You can do the same things already within just class methods and arithmetic. Just to clarify, you mean having classmethods that work on plain arrays of Chebyshev coefficients? I'm +1 on that. I'm -1 on only having a ChebyPoly class with instance methods, although it would be useful to have as an adjunct to the plain routines. I have a set of functions that does the first (works on multidimensional arrays of coefficients, actually), but I am open to ideas of what such a chebyschev class with these methods should look like. An interval of definition should probably be part of the ctor. Thoughts? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] chebyshev polynomials
to, 2009-09-24 kello 13:53 -0600, Charles R Harris kirjoitti: [clip] I was thinking of storing the chebyshev internally as the values at the chebyschev points. This makes multiplication, differentiation and such quite easy (resample and multiply/divide appropriatately). Its equivalent to working in the fourier domain for convolution and differentiation. The transform back and forth is likewise othogonal, so stable. The intepolation also becomes simple using the barycentric version. Sounds like you know this stuff well :) The internal representation of each orthogonal polynomial type can probably be whatever works best for each case. It should be no problem to sugar ChebyPoly up after the main work has been done. As a side note, should the cheby* versions of `polyval`, `polymul` etc. just be dropped to reduce namespace clutter? You can do the same things already within just class methods and arithmetic. What do you mean? The evaluation can use various stable methods appropriate to the chebyshev series. This comment was just on the API -- the implementation of course should be appropriate. I have a set of functions that does the first (works on multidimensional arrays of coefficients, actually), but I am open to ideas of what such a chebyschev class with these methods should look like. An interval of definition should probably be part of the ctor. Thoughts? Having the following features could be useful: - __call__, .roots, .order: as in poly1d - .data - whatever is the internal representation - .coef - Chebyshev coefficients? - .limits - The interval - arithmetic: chebyshev op chebyshev - chebyshev - arithmetic: scalar op chebyshev - chebyshev - arithmetic: poly1d op chebyshev - chebyshev/poly1d (??) I'm not sure what __getitem__ and __array__ ought to return. Alternatives seem either to return the poly1d coefficients, or not to define these methods -- otherwise there will be confusion, especially if we want to use these in scipy.special.orthogonal. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy savetxt: change decimal separator
And another question I import this file to excel, is there also a possiblity to create a headline for each column, that the file looks like the following example: average; standard deviation; maximum distance; sum of distances 0,26565; 0,65565; 2,353535; 25, 5656 I was fiddeling with the same problem here: http://thread.gmane.org/gmane.comp.python.numeric.general/23418 So far, one can only open the file and prepend the header line. I just files an enhancement request for this: proposal: add a header and footer function to numpy.savetxt http://projects.scipy.org/numpy/ticket/1236 Regards, Timmie ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] chebyshev polynomials
On Thu, Sep 24, 2009 at 2:34 PM, Pauli Virtanen p...@iki.fi wrote: to, 2009-09-24 kello 13:53 -0600, Charles R Harris kirjoitti: [clip] I was thinking of storing the chebyshev internally as the values at the chebyschev points. This makes multiplication, differentiation and such quite easy (resample and multiply/divide appropriatately). Its equivalent to working in the fourier domain for convolution and differentiation. The transform back and forth is likewise othogonal, so stable. The intepolation also becomes simple using the barycentric version. Sounds like you know this stuff well :) The internal representation of each orthogonal polynomial type can probably be whatever works best for each case. It should be no problem to sugar ChebyPoly up after the main work has been done. As a side note, should the cheby* versions of `polyval`, `polymul` etc. just be dropped to reduce namespace clutter? You can do the same things already within just class methods and arithmetic. What do you mean? The evaluation can use various stable methods appropriate to the chebyshev series. This comment was just on the API -- the implementation of course should be appropriate. I have a set of functions that does the first (works on multidimensional arrays of coefficients, actually), but I am open to ideas of what such a chebyschev class with these methods should look like. An interval of definition should probably be part of the ctor. Thoughts? Having the following features could be useful: - __call__, .roots, .order: as in poly1d - .data - whatever is the internal representation - .coef - Chebyshev coefficients? - .limits - The interval - arithmetic: chebyshev op chebyshev - chebyshev - arithmetic: scalar op chebyshev - chebyshev - arithmetic: poly1d op chebyshev - chebyshev/poly1d (??) Multiplying by poly1d should be easy, just interpolate at the chebyshev points and multiply. Going the other way is a bit trickier. I'm wondering if having support for complex would be justified? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] np.any and np.all short-circuiting
Hello I noticed that python's any can be faster than numpy's any (and the similarly for all). Then I wondered why. I realized that numpy implements any as logical_or.reduce (and all as logical_and.reduce). This means that numpy cannot take advantage of short-circuiting. Looking at the timings confirmed my suspects. I think python fetches one element at the time from the array and as soon as any of them is true it returns true. Instead, numpy goes on until the end of the array even if the very first element is already true. Looking at the code I think I found a way to fix it. I don't see a reason why it should not work. It seems to work. But you never know. I wanted to run the test suite. I am unable to run the test on the svn version, neither from .../build/lib... nor form a different folder using sys.path.insert(0, '.../build/lib...'). In the first case I get NameError: name 'numeric' is not defined while in the second case zero tests are successfully performed :-) What is the correct way of running the tests (without installing the development version in the system)? Is there some expert of the inner numpy core able to tell whether the approach is correct and won't break something? I opened a ticket for this: http://projects.scipy.org/numpy/ticket/1237 Best, Luca In the following table any(x) is python's version, np.any(x) is numpy's, while *np.any(x)* is mine. '1.4.0.dev7417' x = np.zeros(10, dtype=bool) x[i] = True %timeit any(x) %timeit np.any(x) x = np.ones(10, dtype=bool) x[i] = False %timeit all(x) %timeit np.all(x) ANY i any(x)np.any(x)*np.any(x)* // 6.84 ms 831 µs189 µs 5 3.41 ms 832 µs98 µs 1 683 µs 831 µs24.7 µs 1000 68.9 µs 859 µs8.41 µs 1007.92 µs 888 µs6.9 µs 10 1.42 µs 832 µs6.68 µs 0 712 ns 831 µs6.65 µs ALL i all(x)np.all(x)*np.all(x)* // 6.65 ms 676 µs300 µs 5 3.32 ms 677 µs154 µs 1 666 µs 676 µs36.4 µs 1000 67.9 µs 686 µs9.86 µs 1007.53 µs 677 µs7.26 µs 10 1.39 µs 676 µs7.06 µs 0 716 ns 678 µs6.96 µs ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.any and np.all short-circuiting
On Thu, Sep 24, 2009 at 3:43 PM, Citi, Luca lc...@essex.ac.uk wrote: Hello I noticed that python's any can be faster than numpy's any (and the similarly for all). Then I wondered why. I realized that numpy implements any as logical_or.reduce (and all as logical_and.reduce). This means that numpy cannot take advantage of short-circuiting. Looking at the timings confirmed my suspects. I think python fetches one element at the time from the array and as soon as any of them is true it returns true. Instead, numpy goes on until the end of the array even if the very first element is already true. Looking at the code I think I found a way to fix it. I don't see a reason why it should not work. It seems to work. But you never know. I wanted to run the test suite. I am unable to run the test on the svn version, neither from .../build/lib... nor form a different folder using sys.path.insert(0, '.../build/lib...'). In the first case I get NameError: name 'numeric' is not defined while in the second case zero tests are successfully performed :-) What is the correct way of running the tests (without installing the development version in the system)? Is there some expert of the inner numpy core able to tell whether the approach is correct and won't break something? I opened a ticket for this: http://projects.scipy.org/numpy/ticket/1237 Best, Luca Did you delete your build directory first? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.any and np.all short-circuiting
On Thu, Sep 24, 2009 at 16:43, Citi, Luca lc...@essex.ac.uk wrote: What is the correct way of running the tests (without installing the development version in the system)? Build inplace: $ python setup.py build_src --inplace build_ext --inplace -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.any and np.all short-circuiting
Thank you for your instantaneuos reply! This is what I usually do: from the numpy folder I run (emptying the build folder if I just fetched svn updates) $ python setup build.py $ cd build/lib-... $ ipython In [1]: import numpy as np In [2]: np.__version__ Out[2]: '1.4.0.dev7417' Everything works except for the np.test() which gives NameError: name 'numeric' is not defined Otherwise I move into a diffeent folder, say /tmp and run ipython In [1]: import sys In [2]: sys.path.insert(0, '~/numpy/build/lib.linux-i686-2.6/') In [3]: import numpy as np In [4]: np.__version__ Out[4]: '1.4.0.dev7417' In [5]: np.test() Running unit tests for numpy NumPy version 1.4.0.dev7417 NumPy is installed in /_space_/Temp/numpy/build/lib.linux-i686-2.6/numpy Python version 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] nose version 0.10.4 -- Ran 0 tests in 0.002s OK Out[5]: nose.result.TextTestResult run=0 errors=0 failures=0 What should I do instead? Thanks, Luca ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.any and np.all short-circuiting
Thank you both for your help! $ python setup.py build_src --inplace build_ext --inplace I'll give it a try. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Resize Method for Numpy Array
Robert Kern skrev: While this description is basically true of numpy arrays, I would caution you that every language has a different lexicon, and the same word can mean very different things in each. For example, Python lists are *not* linked lists; they are like C++'s std::vectors with a preallocation strategy to make appending cheap on average. In Java and .NET jargon, Python lists are array lists, not linked lists. It is sad there is no cons or llist built-in type, something like: mycons = cons(car, cdr) mylist = llist(iterable) Of course we can write [car, cdr] or (car, cdr) for making linked lists in pure Python (without having to define class types), but both have issues.The first is storage inefficient, the latter is not mutable. Yes I know Guido left out linked lists for a purpose, so there is probably no use complaining on the Python ideas of Python dev lists... S.M. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Resize Method for Numpy Array
On Thu, Sep 24, 2009 at 17:32, Sturla Molden stu...@molden.no wrote: Robert Kern skrev: While this description is basically true of numpy arrays, I would caution you that every language has a different lexicon, and the same word can mean very different things in each. For example, Python lists are *not* linked lists; they are like C++'s std::vectors with a preallocation strategy to make appending cheap on average. In Java and .NET jargon, Python lists are array lists, not linked lists. It is sad there is no cons or llist built-in type, something like: mycons = cons(car, cdr) mylist = llist(iterable) Of course we can write [car, cdr] or (car, cdr) for making linked lists in pure Python (without having to define class types), but both have issues.The first is storage inefficient, the latter is not mutable. Yes I know Guido left out linked lists for a purpose, so there is probably no use complaining on the Python ideas of Python dev lists... collections.deque() is a linked list of 64-item chunks. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Resize Method for Numpy Array
Robert Kern skrev: collections.deque() is a linked list of 64-item chunks. Thanks for that useful information. :-) But it would not help much for a binary tree... Since we are on the NumPy list... One could image making linked lists using NumPy arrays with dtype=object. They are storage efficient like tuples, and mutable like lists. def cons(a,b): return np.array((a,b),dtype=object) But I guess the best way is to implement a real linked extension type in Cython. S.M. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] dtype '|S0' not understood
On 23-Sep-09, at 7:55 PM, David Warde-Farley wrote:
It seems that either dtype(str) should do something more sensible than
zero-length string, or it should be possible to create it with
dtype('|
S0'). Which should it be?
Since there wasn't any response I went ahead and fixed it by making
str and unicode dtypes allow a size of 0 when constructed with
protocol type codes. Either S0 and U0 should be constructable with
typecodes or they shouldn't be allowed at all; I opted for the latter
since a) it was simple and b) I don't know what a sensible default for
dtype(str) would be (length 1? length 10?).
Patch is at:
http://projects.scipy.org/numpy/ticket/1239
Review away!
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.any and np.all short-circuiting
I am sorry. I followed your suggestion. I re-checked out the svn folder and then compiled with $ python setup.py build_src --inplace build_ext --inplace but I get the same behaviour. If I am inside I get the NameError, if I am outside and use path.insert, it successfully performs zero tests. I have tried with numpy-1.3 with sys.path.insert and it works. I re-implemented the same patch for 1.3 and it passes all 2030 tests. http://projects.scipy.org/numpy/ticket/1237 I think the speed improvement is impressive. Thanks. I still wonder why I am unable to make the tests work with the svn version. Best, Luca ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Assigning an array to the field of a structure doesn't work
Hi I'm trying to understand the following code: import numpy as np dt=np.dtype([(c,np.int32,(2))]) data=np.ndarray([2],dtype=dt) x=np.array([0,10]) #the following line doesn't set data[0][c] = x #only data[0][c][0] changes data[0][c]=x #the following does set data[1][c][:]=x data[1][c][:]=x What I don't understand is why does, the assignment of data[0][c]=x not set c=x but the second one does? Thanks Jeremy ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.any and np.all short-circuiting
On Fri, Sep 25, 2009 at 9:50 AM, Citi, Luca lc...@essex.ac.uk wrote: I am sorry. I followed your suggestion. I re-checked out the svn folder and then compiled with $ python setup.py build_src --inplace build_ext --inplace but I get the same behaviour. If I am inside I get the NameError, if I am outside and use path.insert, it successfully performs zero tests. There is a problem with numpy tests when you import numpy with the install being in the current directory. It happens when you build in place and launch python in the source directory, but it also happens if you happen to be in site-packages, and import numpy installed there. When the issue was last discussed, Robert suggested it was a nose issue. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] chebyshev polynomials
On Thu, Sep 24, 2009 at 1:31 PM, Robert Kern robert.k...@gmail.com wrote: On Thu, Sep 24, 2009 at 14:18, Pauli Virtanen p...@iki.fi wrote: As a side note, should the cheby* versions of `polyval`, `polymul` etc. just be dropped to reduce namespace clutter? You can do the same things already within just class methods and arithmetic. Just to clarify, you mean having classmethods that work on plain arrays of Chebyshev coefficients? I'm +1 on that. I'm -1 on only having a ChebyPoly class with instance methods, although it would be useful to have as an adjunct to the plain routines. Let me see if I understand this correctly. You like the idea of a class with class methods, avoiding namespace polution, but you aren't so hot on having a chebyshev class like poly1d that contains the series info and overloads some of the operators? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] chebyshev polynomials
On Thu, Sep 24, 2009 at 21:00, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Sep 24, 2009 at 1:31 PM, Robert Kern robert.k...@gmail.com wrote: On Thu, Sep 24, 2009 at 14:18, Pauli Virtanen p...@iki.fi wrote: As a side note, should the cheby* versions of `polyval`, `polymul` etc. just be dropped to reduce namespace clutter? You can do the same things already within just class methods and arithmetic. Just to clarify, you mean having classmethods that work on plain arrays of Chebyshev coefficients? I'm +1 on that. I'm -1 on only having a ChebyPoly class with instance methods, although it would be useful to have as an adjunct to the plain routines. Let me see if I understand this correctly. You like the idea of a class with class methods, avoiding namespace polution, but you aren't so hot on having a chebyshev class like poly1d that contains the series info and overloads some of the operators? I'm not so hot on *only* having a chebyshev class like poly1d. As I said, it would be useful to have one, but I still want routines that work on plain arrays. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] chebyshev polynomials
On Thu, Sep 24, 2009 at 8:14 PM, Robert Kern robert.k...@gmail.com wrote:
On Thu, Sep 24, 2009 at 21:00, Charles R Harris
charlesr.har...@gmail.com wrote:
On Thu, Sep 24, 2009 at 1:31 PM, Robert Kern robert.k...@gmail.com
wrote:
On Thu, Sep 24, 2009 at 14:18, Pauli Virtanen p...@iki.fi wrote:
As a side note, should the cheby* versions of `polyval`, `polymul`
etc.
just be dropped to reduce namespace clutter? You can do the same
things
already within just class methods and arithmetic.
Just to clarify, you mean having classmethods that work on plain
arrays of Chebyshev coefficients? I'm +1 on that. I'm -1 on only
having a ChebyPoly class with instance methods, although it would be
useful to have as an adjunct to the plain routines.
Let me see if I understand this correctly. You like the idea of a class
with
class methods, avoiding namespace polution, but you aren't so hot on
having
a chebyshev class like poly1d that contains the series info and overloads
some of the operators?
I'm not so hot on *only* having a chebyshev class like poly1d. As I
said, it would be useful to have one, but I still want routines that
work on plain arrays.
So basically
'chebadd',
'chebder',
'chebdiv',
'chebfit',
'chebint',
'chebmul',
'chebsub',
'chebval',
All just taking 1d arrays with an assumed interval of [-1,1] except for
chebfit, which needs an interval, and maybe cheb{der,int,val} too also
taking intervals. Hmm, before I just had these things as a keyword variable
that defaulted to [-1,1].
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Antwort: Re: Numpy savetxt: change decimal separator
I was fiddeling with the same problem here:
http://thread.gmane.org/gmane.comp.python.numeric.general/23418
So far, one can only open the file and prepend the header line.
I just files an enhancement request for this:
proposal: add a header and footer function to numpy.savetxt
http://projects.scipy.org/numpy/ticket/1236
Regards,
Timmie
Hi Timmie,
thanks for that, this would be a very good first step, still having the
problem, that the local representation of the decimal point is not
covered...
Of course the porblem can be handeled by a further file parser and a
remove('.',',') method, but it looses a bit of the straight forward way.
Markus___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
