Re: [Numpy-discussion] Problem in swig
Hi,
I don't know exactly, but try replacing the one line
%apply (float* INPLACE_ARRAY1, int DIM1) {(float *a, int na), (float
*b, int nb)};
with two lines:
%apply (float* INPLACE_ARRAY1, int DIM1) {(float *a, int na)};
%apply (float* INPLACE_ARRAY1, int DIM1) {(float *b, int nb)};
Don't know about the '{' '}' brakets. b could probably be more
general as INPUT_ARRAY1
HTH
-S.
On Thu, May 20, 2010 at 1:43 AM, Steven Nien steven.n...@gmail.com wrote:
I want to pass 1 integer and 2 numpy array into the C function as
followings:
void update_incident_field(int k, float *a, int na, float *b, int nb) {
for (i=0; ina; i ++) {
a[i] = a[i] + b[i] * k;
}
}
But I don't know how to write the interface code (***.i)
Can someone help me?
Thanks!
The swig interface code I written(did't work, strange output)
%module example
%{
#define SWIG_FILE_WITH_INIT
#include example.h
%}
%include numpy.i
%init %{
import_array();
%}
%apply (float* INPLACE_ARRAY1, int DIM1) {(float *a, int na), (float *b, int
nb)};
%include example.h
___
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] Runtime error in numpy.polyfit
On Thu, May 20, 2010 at 10:17 AM, David Goldsmith d.l.goldsm...@gmail.comwrote: On Wed, May 19, 2010 at 3:50 PM, William Carithers wccarith...@lbl.govwrote: Hi David and Josef, OK, I updated to numpy-1.4.1 and scipy-0.7.2 and this problem went away. Thanks for your help. BTW, trying to upgrade using the .dmg files from Sourceforge didn't work. It kept saying that it needed System Python 2.6 even though Python 2.6 is already installed. In fact, it was packaged with the OSX 10.6 upgrade. I had to download the tarballs and install from source. The numpy/scipy binaries on sourceforge are built for the dmg installers from http://python.org/, which is the recommended place to get python from. The python provided by Apple is outdated by several release cycles, and can not be used with those binaries. I agree the help message about needing system python is not particularly helpful. Cheers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] question about creating numpy arrays
I gave two counterexamples of why. The examples you gave aren't counterexamples. See below... On Wed, May 19, 2010 at 7:06 PM, Darren Dale dsdal...@gmail.com wrote: On Wed, May 19, 2010 at 4:19 PM, josef.p...@gmail.com wrote: On Wed, May 19, 2010 at 4:08 PM, Darren Dale dsdal...@gmail.com wrote: I have a question about creation of numpy arrays from a list of objects, which bears on the Quantities project and also on masked arrays: import quantities as pq import numpy as np a, b = 2*pq.m,1*pq.s np.array([a, b]) array([ 12., 1.]) Why doesn't that create an object array? Similarly: Consider the use case of a person creating a 1-D numpy array: np.array([12.0, 1.0]) array([ 12., 1.]) How is python supposed to tell the difference between np.array([a, b]) and np.array([12.0, 1.0]) ? It can't, and there are plenty of times when one wants to explicitly initialize a small numpy array with a few discrete variables. m = np.ma.array([1], mask=[True]) m masked_array(data = [--], mask = [ True], fill_value = 99) np.array([m]) array([[1]]) Again, this is expected behavior. Numpy saw an array of an array, therefore, it produced a 2-D array. Consider the following: np.array([[12, 4, 1], [32, 51, 9]]) I, as a user, expect numpy to create a 2-D array (2 rows, 3 columns) from that array of arrays. This has broader implications than just creating arrays, for example: np.sum([m, m]) 2 np.sum([a, b]) 13.0 If you wanted sums from each object, there are some better (i.e., more clear) ways to go about it. If you have a predetermined number of numpy-compatible objects, say a, b, c, then you can explicitly call the sum for each one: a_sum = np.sum(a) b_sum = np.sum(b) c_sum = np.sum(c) Which I think communicates the programmer's intention better than (for a numpy array, x, composed of a, b, c): object_sums = np.sum(x) # --- As a numpy user, I would expect a scalar out of this, not an array If you have an arbitrary number of objects (which is what I suspect you have), then one could easily produce an array of sums (for a list, x, of numpy-compatible objects) like so: object_sums = [np.sum(anObject) for anObject in x] Performance-wise, it should be no more or less efficient than having numpy somehow produce an array of sums from a single call to sum. Readability-wise, it makes more sense because when you are treating objects separately, a *list* of them is more intuitive than a numpy.array, which is more-or-less treated as a single mathematical entity. I hope that addresses your concerns. Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] question about creating numpy arrays
On Thu, May 20, 2010 at 9:44 AM, Benjamin Root ben.r...@ou.edu wrote: I gave two counterexamples of why. The examples you gave aren't counterexamples. See below... On Wed, May 19, 2010 at 7:06 PM, Darren Dale dsdal...@gmail.com wrote: On Wed, May 19, 2010 at 4:19 PM, josef.p...@gmail.com wrote: On Wed, May 19, 2010 at 4:08 PM, Darren Dale dsdal...@gmail.com wrote: I have a question about creation of numpy arrays from a list of objects, which bears on the Quantities project and also on masked arrays: import quantities as pq import numpy as np a, b = 2*pq.m,1*pq.s np.array([a, b]) array([ 12., 1.]) Why doesn't that create an object array? Similarly: Consider the use case of a person creating a 1-D numpy array: np.array([12.0, 1.0]) array([ 12., 1.]) How is python supposed to tell the difference between np.array([a, b]) and np.array([12.0, 1.0]) ? It can't, and there are plenty of times when one wants to explicitly initialize a small numpy array with a few discrete variables. What do you mean it can't? 12.0 and 1.0 are floats, a and b are not. While, yes, they can be coerced to floats, this is a *lossy* transformation--it strips away information contained in the class, and IMHO should not be the default behavior. If I want the objects, I can force it: In [7]: np.array([a,b],dtype=np.object) Out[7]: array([2.0 m, 1.0 s], dtype=object) This works fine, but feels ugly since I have to explicitly tell numpy not to do something. It feels to me like it's violating the principle of in the face of ambiguity, resist the temptation to guess. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problem in swig
I tried the following:
%module example
%{
#define SWIG_FILE_WITH_INIT
//#include example.h
%}
%include numpy.i
%init %{
import_array();
%}
%apply (float* INPLACE_ARRAY1, int DIM1) {(float *a, int na), (float
*b, int nb)};
%inline
{
void update_incident_field(int k, float *a, int na, float *b, int nb)
{
for (i=0; ina; i ++)
{
a[i] = a[i] + b[i] * k;
}
}
}
$ swig -python example.i
and the resulting example_wrap.c file looks OK for me. What strange
output did you get?
On May 19, 2010, at 7:43 PM, Steven Nien wrote:
I want to pass 1 integer and 2 numpy array into the C function as
followings:
void update_incident_field(int k, float *a, int na, float *b, int
nb) {
for (i=0; ina; i ++) {
a[i] = a[i] + b[i] * k;
}
}
But I don't know how to write the interface code (***.i)
Can someone help me?
Thanks!
The swig interface code I written(did't work, strange output)
%module example
%{
#define SWIG_FILE_WITH_INIT
#include example.h
%}
%include numpy.i
%init %{
import_array();
%}
%apply (float* INPLACE_ARRAY1, int DIM1) {(float *a, int na), (float
*b, int nb)};
%include example.h
ATT2.txt
** Bill Spotz **
** Sandia National Laboratories Voice: (505)845-0170 **
** P.O. Box 5800 Fax: (505)284-0154 **
** Albuquerque, NM 87185-0370Email: wfsp...@sandia.gov **
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] question about creating numpy arrays
[sorry, my last got cut off] On Thu, May 20, 2010 at 11:37 AM, Darren Dale dsdal...@gmail.com wrote: On Thu, May 20, 2010 at 10:44 AM, Benjamin Root ben.r...@ou.edu wrote: I gave two counterexamples of why. The examples you gave aren't counterexamples. See below... I'm not interested in arguing over semantics. I've discovered an issue with how numpy deals with lists of objects that derive from ndarray, and am concerned about the implications for classes that extend ndarray. On Wed, May 19, 2010 at 7:06 PM, Darren Dale dsdal...@gmail.com wrote: On Wed, May 19, 2010 at 4:19 PM, josef.p...@gmail.com wrote: On Wed, May 19, 2010 at 4:08 PM, Darren Dale dsdal...@gmail.com wrote: I have a question about creation of numpy arrays from a list of objects, which bears on the Quantities project and also on masked arrays: import quantities as pq import numpy as np a, b = 2*pq.m,1*pq.s np.array([a, b]) array([ 12., 1.]) Why doesn't that create an object array? Similarly: Consider the use case of a person creating a 1-D numpy array: np.array([12.0, 1.0]) array([ 12., 1.]) How is python supposed to tell the difference between np.array([a, b]) and np.array([12.0, 1.0]) ? It can't, and there are plenty of times when one wants to explicitly initialize a small numpy array with a few discrete variables. m = np.ma.array([1], mask=[True]) m masked_array(data = [--], mask = [ True], fill_value = 99) np.array([m]) array([[1]]) Again, this is expected behavior. Numpy saw an array of an array, therefore, it produced a 2-D array. Consider the following: np.array([[12, 4, 1], [32, 51, 9]]) I, as a user, expect numpy to create a 2-D array (2 rows, 3 columns) from that array of arrays. This has broader implications than just creating arrays, for example: np.sum([m, m]) 2 np.sum([a, b]) 13.0 If you wanted sums from each object, there are some better (i.e., more clear) ways to go about it. If you have a predetermined number of numpy-compatible objects, say a, b, c, then you can explicitly call the sum for each one: a_sum = np.sum(a) b_sum = np.sum(b) c_sum = np.sum(c) Which I think communicates the programmer's intention better than (for a numpy array, x, composed of a, b, c): object_sums = np.sum(x) # --- As a numpy user, I would expect a scalar out of this, not an array If you have an arbitrary number of objects (which is what I suspect you have), then one could easily produce an array of sums (for a list, x, of numpy-compatible objects) like so: object_sums = [np.sum(anObject) for anObject in x] Performance-wise, it should be no more or less efficient than having numpy somehow produce an array of sums from a single call to sum. Readability-wise, it makes more sense because when you are treating objects separately, a *list* of them is more intuitive than a numpy.array, which is more-or-less treated as a single mathematical entity. I hope that addresses your concerns. I appreciate the response, but you are arguing that it is not a problem, and I'm certain that it is. It may not be numpy It may not be numpy's problem, I can accept that. But it is definitely a problem for quantities. I'm trying to determine just how big a problem it is. I had hoped that one day quantities might become a part of numpy or scipy, but this appears to be a fundamental issue and it makes me doubt that inclusion would be appropriate. Thank you for the suggestion about calling the sum method instead of numpy's function. That is a reasonable workaround. Darren ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] question about creating numpy arrays
On 05/20/2010 10:53 AM, Darren Dale wrote: [sorry, my last got cut off] On Thu, May 20, 2010 at 11:37 AM, Darren Daledsdal...@gmail.com wrote: On Thu, May 20, 2010 at 10:44 AM, Benjamin Rootben.r...@ou.edu wrote: I gave two counterexamples of why. The examples you gave aren't counterexamples. See below... I'm not interested in arguing over semantics. I've discovered an issue with how numpy deals with lists of objects that derive from ndarray, and am concerned about the implications for classes that extend ndarray. On Wed, May 19, 2010 at 7:06 PM, Darren Daledsdal...@gmail.com wrote: On Wed, May 19, 2010 at 4:19 PM,josef.p...@gmail.com wrote: On Wed, May 19, 2010 at 4:08 PM, Darren Daledsdal...@gmail.com wrote: I have a question about creation of numpy arrays from a list of objects, which bears on the Quantities project and also on masked arrays: import quantities as pq import numpy as np a, b = 2*pq.m,1*pq.s np.array([a, b]) array([ 12., 1.]) Why doesn't that create an object array? Similarly: Consider the use case of a person creating a 1-D numpy array: np.array([12.0, 1.0]) array([ 12., 1.]) How is python supposed to tell the difference between np.array([a, b]) and np.array([12.0, 1.0]) ? It can't, and there are plenty of times when one wants to explicitly initialize a small numpy array with a few discrete variables. m = np.ma.array([1], mask=[True]) m masked_array(data = [--], mask = [ True], fill_value = 99) np.array([m]) array([[1]]) Again, this is expected behavior. Numpy saw an array of an array, therefore, it produced a 2-D array. Consider the following: np.array([[12, 4, 1], [32, 51, 9]]) I, as a user, expect numpy to create a 2-D array (2 rows, 3 columns) from that array of arrays. This has broader implications than just creating arrays, for example: np.sum([m, m]) 2 np.sum([a, b]) 13.0 If you wanted sums from each object, there are some better (i.e., more clear) ways to go about it. If you have a predetermined number of numpy-compatible objects, say a, b, c, then you can explicitly call the sum for each one: a_sum = np.sum(a) b_sum = np.sum(b) c_sum = np.sum(c) Which I think communicates the programmer's intention better than (for a numpy array, x, composed of a, b, c): object_sums = np.sum(x) #--- As a numpy user, I would expect a scalar out of this, not an array If you have an arbitrary number of objects (which is what I suspect you have), then one could easily produce an array of sums (for a list, x, of numpy-compatible objects) like so: object_sums = [np.sum(anObject) for anObject in x] Performance-wise, it should be no more or less efficient than having numpy somehow produce an array of sums from a single call to sum. Readability-wise, it makes more sense because when you are treating objects separately, a *list* of them is more intuitive than a numpy.array, which is more-or-less treated as a single mathematical entity. I hope that addresses your concerns. I appreciate the response, but you are arguing that it is not a problem, and I'm certain that it is. It may not be numpy It may not be numpy's problem, I can accept that. But it is definitely a problem for quantities. I'm trying to determine just how big a problem it is. I had hoped that one day quantities might become a part of numpy or scipy, but this appears to be a fundamental issue and it makes me doubt that inclusion would be appropriate. Thank you for the suggestion about calling the sum method instead of numpy's function. That is a reasonable workaround. Darren ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion Hi, np.array is an array creating function that numpy.array takes a array_like input and it *will* try to convert that input into an array. (This also occurs when you give np.array a masked array as an input.) This a 'feature' especially when you don't use the dtype argument and applies to any numpy function that takes array_like inputs. I do not quantities, but you either have to get the user to use the appropriate quantities functions or let it remain 'user beware' when they do not use the appropriate functions. In the longer term you have to get numpy to 'do the right thing' with quantities objects. Bruce ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] question about creating numpy arrays
On Thu, May 20, 2010 at 10:30 AM, Ryan May rma...@gmail.com wrote: On Thu, May 20, 2010 at 9:44 AM, Benjamin Root ben.r...@ou.edu wrote: I gave two counterexamples of why. The examples you gave aren't counterexamples. See below... On Wed, May 19, 2010 at 7:06 PM, Darren Dale dsdal...@gmail.com wrote: On Wed, May 19, 2010 at 4:19 PM, josef.p...@gmail.com wrote: On Wed, May 19, 2010 at 4:08 PM, Darren Dale dsdal...@gmail.com wrote: I have a question about creation of numpy arrays from a list of objects, which bears on the Quantities project and also on masked arrays: import quantities as pq import numpy as np a, b = 2*pq.m,1*pq.s np.array([a, b]) array([ 12., 1.]) Why doesn't that create an object array? Similarly: Consider the use case of a person creating a 1-D numpy array: np.array([12.0, 1.0]) array([ 12., 1.]) How is python supposed to tell the difference between np.array([a, b]) and np.array([12.0, 1.0]) ? It can't, and there are plenty of times when one wants to explicitly initialize a small numpy array with a few discrete variables. What do you mean it can't? 12.0 and 1.0 are floats, a and b are not. While, yes, they can be coerced to floats, this is a *lossy* transformation--it strips away information contained in the class, and IMHO should not be the default behavior. If I want the objects, I can force it: In [7]: np.array([a,b],dtype=np.object) Out[7]: array([2.0 m, 1.0 s], dtype=object) This works fine, but feels ugly since I have to explicitly tell numpy not to do something. It feels to me like it's violating the principle of in the face of ambiguity, resist the temptation to guess. I have thought about this further, and I think I am starting to see your point (from both of you). Here are my thoughts: As I understand it, numpy.array() (rather, array_like()) essentially builds the dimensions of the array by first identifying if there is an iterable object, and then if the contents of the iterable is also iterable, until it reaches a non-iterable. Therefore, the question becomes, why is numpy.array() implicitly coercing the non-iterable type into a numeric? Is there some reason that I am not seeing for why there is an implicit coercion? At first glance, I did not see a problem with this behavior, and I have come to expect it (hence my original reply). But now, I am not quite so sure. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma ___ 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] dtype and array creation
On Thu, May 20, 2010 at 4:04 PM, Keith Goodman kwgood...@gmail.com wrote: Why do the follow expressions give different dtype? np.array([1, 2, 3], dtype=str) array(['1', '2', '3'], dtype='|S1') np.array(np.array([1, 2, 3]), dtype=str) array(['1', '2', '3'], dtype='|S8') you're on a 64bit machine? S8 is the same size as the float np.array([8]).itemsize 4 np.array(np.array([1, 2, 3]), dtype=str) array(['1', '2', '3'], dtype='|S4') np.array([8]).view(dtype='S4') array(['\x08'], dtype='|S4') np.array([8]).view(dtype='S1') array(['\x08', '', '', ''], dtype='|S1') But I don't know whether this is a desired feature, numpy might reuse the existing buffer (?) Josef ___ 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] dtype and array creation
On Thu, May 20, 2010 at 4:19 PM, josef.p...@gmail.com wrote: On Thu, May 20, 2010 at 4:04 PM, Keith Goodman kwgood...@gmail.com wrote: Why do the follow expressions give different dtype? np.array([1, 2, 3], dtype=str) array(['1', '2', '3'], dtype='|S1') np.array(np.array([1, 2, 3]), dtype=str) array(['1', '2', '3'], dtype='|S8') you're on a 64bit machine? S8 is the same size as the float not float, it should be int, here is float on my Win32: np.array(np.array([1., 2, 3]), dtype=str) array(['1.0', '2.0', '3.0'], dtype='|S8') np.array([8.]).itemsize 8 np.array([8]).itemsize 4 np.array(np.array([1, 2, 3]), dtype=str) array(['1', '2', '3'], dtype='|S4') np.array([8]).view(dtype='S4') array(['\x08'], dtype='|S4') np.array([8]).view(dtype='S1') array(['\x08', '', '', ''], dtype='|S1') But I don't know whether this is a desired feature, numpy might reuse the existing buffer (?) Josef ___ 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] dtype and array creation
On Thu, May 20, 2010 at 1:19 PM, josef.p...@gmail.com wrote: On Thu, May 20, 2010 at 4:04 PM, Keith Goodman kwgood...@gmail.com wrote: Why do the follow expressions give different dtype? np.array([1, 2, 3], dtype=str) array(['1', '2', '3'], dtype='|S1') np.array(np.array([1, 2, 3]), dtype=str) array(['1', '2', '3'], dtype='|S8') you're on a 64bit machine? S8 is the same size as the float np.array([8]).itemsize 4 np.array(np.array([1, 2, 3]), dtype=str) array(['1', '2', '3'], dtype='|S4') np.array([8]).view(dtype='S4') array(['\x08'], dtype='|S4') np.array([8]).view(dtype='S1') array(['\x08', '', '', ''], dtype='|S1') But I don't know whether this is a desired feature, numpy might reuse the existing buffer (?) Yes, I'm on a 64-bit machine. That's what I thought so I tried this: a = np.array([1, 2, 3]) type(a[0]) type 'numpy.int64' np.array([a[0], a[1], a[2]], dtype=str) array(['1', '2', '3'], dtype='|S1') But it gives '|S1' too. I guess I'm lost. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] dtype and array creation
On Thu, May 20, 2010 at 4:28 PM, Keith Goodman kwgood...@gmail.com wrote:
On Thu, May 20, 2010 at 1:19 PM, josef.p...@gmail.com wrote:
On Thu, May 20, 2010 at 4:04 PM, Keith Goodman kwgood...@gmail.com wrote:
Why do the follow expressions give different dtype?
np.array([1, 2, 3], dtype=str)
array(['1', '2', '3'],
dtype='|S1')
np.array(np.array([1, 2, 3]), dtype=str)
array(['1', '2', '3'],
dtype='|S8')
you're on a 64bit machine?
S8 is the same size as the float
np.array([8]).itemsize
4
np.array(np.array([1, 2, 3]), dtype=str)
array(['1', '2', '3'],
dtype='|S4')
np.array([8]).view(dtype='S4')
array(['\x08'],
dtype='|S4')
np.array([8]).view(dtype='S1')
array(['\x08', '', '', ''],
dtype='|S1')
But I don't know whether this is a desired feature, numpy might reuse
the existing buffer (?)
Yes, I'm on a 64-bit machine.
That's what I thought so I tried this:
a = np.array([1, 2, 3])
type(a[0])
type 'numpy.int64'
np.array([a[0], a[1], a[2]], dtype=str)
array(['1', '2', '3'],
dtype='|S1')
But it gives '|S1' too. I guess I'm lost.
for sure it doesn't look very consistent, special treatment of 0-dim ?
np.array(a[0], dtype=str)
array('1',
dtype='|S1')
np.array(a[:1], dtype=str)
array(['1'],
dtype='|S4')
a[:1].shape
(1,)
a[0].shape
()
Josef
___
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] dtype and array creation
Thu, 20 May 2010 13:04:11 -0700, Keith Goodman wrote: Why do the follow expressions give different dtype? np.array([1, 2, 3], dtype=str) array(['1', '2', '3'], dtype='|S1') np.array(np.array([1, 2, 3]), dtype=str) array(['1', '2', '3'], dtype='|S8') Scalars seem to be handled specially. Anyway, automatic determination of the string size is a bit dangerous to rely on with non-strings in the array: np.array([np.array(12345)], dtype=str) array(['1234'], dtype='|S4') When I looked at this the last time, it wasn't completely obvious how to make this to do something more sensible. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problem in swig
Hi
Thanks for all your help!
I found the strange result was caused by my algorithm(CUDA).
The swig part is very ok:)
On Thu, May 20, 2010 at 11:18 PM, Bill Spotz wfsp...@sandia.gov wrote:
I tried the following:
%module example
%{
#define SWIG_FILE_WITH_INIT
//#include example.h
%}
%include numpy.i
%init %{
import_array();
%}
%apply (float* INPLACE_ARRAY1, int DIM1) {(float *a, int na), (float
*b, int nb)};
%inline
{
void update_incident_field(int k, float *a, int na, float *b, int nb)
{
for (i=0; ina; i ++)
{
a[i] = a[i] + b[i] * k;
}
}
}
$ swig -python example.i
and the resulting example_wrap.c file looks OK for me. What strange
output did you get?
On May 19, 2010, at 7:43 PM, Steven Nien wrote:
I want to pass 1 integer and 2 numpy array into the C function as
followings:
void update_incident_field(int k, float *a, int na, float *b, int
nb) {
for (i=0; ina; i ++) {
a[i] = a[i] + b[i] * k;
}
}
But I don't know how to write the interface code (***.i)
Can someone help me?
Thanks!
The swig interface code I written(did't work, strange output)
%module example
%{
#define SWIG_FILE_WITH_INIT
#include example.h
%}
%include numpy.i
%init %{
import_array();
%}
%apply (float* INPLACE_ARRAY1, int DIM1) {(float *a, int na), (float
*b, int nb)};
%include example.h
ATT2.txt
** Bill Spotz **
** Sandia National Laboratories Voice: (505)845-0170 **
** P.O. Box 5800 Fax: (505)284-0154 **
** Albuquerque, NM 87185-0370Email: wfsp...@sandia.gov **
___
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
[Numpy-discussion] astype None
While automating some unit tests for my labeled array class, larry, I assumed that np.array([1, 2], dtype=dtype) would give the same result as np.array([1, 2]).astype(dtype) But it doesn't for dtype=None: np.array([1, 2, 3], dtype=None) array([1, 2, 3]) np.array([1, 2, 3]).astype(None) array([ 1., 2., 3.]) I prefer the behavior of array where dtype=None is a no-op. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Numpy doc string license
I'd like to include modified numpy doc strings in my package. Do I just put a note in my license file that says my package contains numpy doc strings and then paste in the numpy license? My package is distributed under a Simplifed BSD license, if that matters. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] astype None
On Thu, May 20, 2010 at 9:00 PM, Keith Goodman kwgood...@gmail.com wrote:
While automating some unit tests for my labeled array class, larry, I
assumed that
np.array([1, 2], dtype=dtype)
would give the same result as
np.array([1, 2]).astype(dtype)
But it doesn't for dtype=None:
np.array([1, 2, 3], dtype=None)
array([1, 2, 3])
np.array([1, 2, 3]).astype(None)
array([ 1., 2., 3.])
I prefer the behavior of array where dtype=None is a no-op.
Since nobody who knows this answered, I try my explanation
It's all in the docs
astype(None) cast to a specified type
here the dtype is None
None is by default float_
np.dtype(None)
dtype('float64')
np.array([1, 2, 3], dtype=None)
np.asarray([1, 2, 3], dtype=None)
here dtype is a keyword argument where None is not a dtype but
triggers the default, which is:
dtype : data-type, optional
By default, the data-type is inferred from the input data.
Shall we start a list of inconsistent looking corner cases ?)
Josef
___
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] Numpy doc string license
On Thu, May 20, 2010 at 21:21, Keith Goodman kwgood...@gmail.com wrote: I'd like to include modified numpy doc strings in my package. Do I just put a note in my license file that says my package contains numpy doc strings and then paste in the numpy license? My package is distributed under a Simplifed BSD license, if that matters. That should work just fine. -- 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] astype None
On Thu, May 20, 2010 at 7:36 PM, josef.p...@gmail.com wrote:
On Thu, May 20, 2010 at 9:00 PM, Keith Goodman kwgood...@gmail.com wrote:
While automating some unit tests for my labeled array class, larry, I
assumed that
np.array([1, 2], dtype=dtype)
would give the same result as
np.array([1, 2]).astype(dtype)
But it doesn't for dtype=None:
np.array([1, 2, 3], dtype=None)
array([1, 2, 3])
np.array([1, 2, 3]).astype(None)
array([ 1., 2., 3.])
I prefer the behavior of array where dtype=None is a no-op.
Since nobody who knows this answered, I try my explanation
It's all in the docs
astype(None) cast to a specified type
here the dtype is None
None is by default float_
np.dtype(None)
dtype('float64')
np.array([1, 2, 3], dtype=None)
np.asarray([1, 2, 3], dtype=None)
here dtype is a keyword argument where None is not a dtype but
triggers the default, which is:
dtype : data-type, optional
By default, the data-type is inferred from the input data.
Shall we start a list of inconsistent looking corner cases ?)
It's easy to find this sort of stuff with short nose tests. Here's a
quick hacked example:
import numpy as np
from numpy.testing import assert_equal
def test_astype_dtype():
array.astype test
dtypes = [float, int, str, bool, complex, object, None]
seqs = ([0, 1], [1.0, 2.0])
msg1 = 'arrays failed on dtype %s and sequence %s'
msg2 = 'dtype are different when dtype=%s and seq=%s'
for dtype in dtypes:
for seq in seqs:
ar1 = np.array(list(seq), dtype=dtype)# array does dtype
ar2 = np.array(list(seq)).astype(dtype) # astype does dtype
yield assert_equal, ar1, ar2, msg1 % (dtype, seq)
yield assert_equal, ar1.dtype, ar2.dtype, msg2 % (dtype, seq)
The output is
===
FAIL: array.astype test
...
AssertionError:
Items are not equal: dtype are different when dtype=None and seq=[0, 1]
ACTUAL: dtype('int64')
DESIRED: dtype('float64')
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy doc string license
On Thu, May 20, 2010 at 7:38 PM, Robert Kern robert.k...@gmail.com wrote: On Thu, May 20, 2010 at 21:21, Keith Goodman kwgood...@gmail.com wrote: I'd like to include modified numpy doc strings in my package. Do I just put a note in my license file that says my package contains numpy doc strings and then paste in the numpy license? My package is distributed under a Simplifed BSD license, if that matters. That should work just fine. Thanks, Robert. BTW, time to bump the NumPy license date to 2010: Copyright (c) 2005-2009, NumPy Developers. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
