>> 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
On Thu, Sep 24, 2009 at 8:14 PM, Robert Kern wrote:
> On Thu, Sep 24, 2009 at 21:00, Charles R Harris
> wrote:
> >
> >
> > On Thu, Sep 24, 2009 at 1:31 PM, Robert Kern
> wrote:
> >>
> >> On Thu, Sep 24, 2009 at 14:18, Pauli Virtanen wrote:
> >>
> >> > As a side note, should the cheby* versions
On Thu, Sep 24, 2009 at 21:00, Charles R Harris
wrote:
>
>
> On Thu, Sep 24, 2009 at 1:31 PM, Robert Kern wrote:
>>
>> On Thu, Sep 24, 2009 at 14:18, Pauli Virtanen wrote:
>>
>> > As a side note, should the cheby* versions of `polyval`, `polymul` etc.
>> > just be dropped to reduce namespace clu
On Thu, Sep 24, 2009 at 1:31 PM, Robert Kern wrote:
> On Thu, Sep 24, 2009 at 14:18, Pauli Virtanen 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 metho
On Fri, Sep 25, 2009 at 9:50 AM, Citi, Luca 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
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
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 ha
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 mak
On Thu, Sep 24, 2009 at 18:05, Sturla Molden wrote:
> 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 lis
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
On Thu, Sep 24, 2009 at 17:32, Sturla Molden 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 *n
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
>
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
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
On Thu, Sep 24, 2009 at 16:43, Citi, Luca 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 worl
On Thu, Sep 24, 2009 at 3:43 PM, Citi, Luca 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
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 t
On Thu, Sep 24, 2009 at 2:34 PM, Pauli Virtanen 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 (
>> 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 fid
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 w
On Thu, Sep 24, 2009 at 1:31 PM, Robert Kern wrote:
> On Thu, Sep 24, 2009 at 14:18, Pauli Virtanen 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 metho
On Thu, Sep 24, 2009 at 1:18 PM, Pauli Virtanen 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.
to, 2009-09-24 kello 14:31 -0500, Robert Kern kirjoitti:
> On Thu, Sep 24, 2009 at 14:18, Pauli Virtanen 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 meth
On Thu, Sep 24, 2009 at 14:18, Pauli Virtanen 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 classmetho
On Thu, Sep 24, 2009 at 09:58, 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 dimen
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 pr
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/2
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 t
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 resi
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 d
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')
> Ou
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 deci
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.
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 cl
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 a
On Thu, Sep 24, 2009 at 2:07 AM, 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 seper
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).
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 imp
38 matches
Mail list logo
