On Mar 29, 2012, at 12:53 PM, Tim Cera wrote:
> I was hoping pad would get finished some day. Maybe 1.9?
You have been a great sport about this process. I think it will result in
something quite nice.
>
> Alright - I do like the idea of passing a function to pad, with a bunch of
> pre-
On Thu, Mar 29, 2012 at 11:53 AM, Tim Cera wrote:
> I was hoping pad would get finished some day. Maybe 1.9?
Well, you *did* ask ;-)
>
> Alright - I do like the idea of passing a function to pad, with a bunch of
> pre-made functions in place.
>
> Maybe something like:
>
> a = np.arange(1
Ilan:
Thanks for your post.
I can import from the command-line and IronPython console, but not from a C#
DLR app (using embedded python scripts.)
Any suggestions?
Regards,
William Johnston
-Original Message-
From: Ilan Schnell
Sent: Thursday, March 29, 2012 3:11 PM
To: Discussion o
Hello William,
It's just a matter of importing numpy into IronPython. See also,
http://enthought.com/repo/.iron/NumPySciPyforDotNet.pdf
- Ilan
On Thu, Mar 29, 2012 at 12:47 PM, William Johnston
wrote:
>
> Hello,
>
> Can numpy for .NET be used in a DLR C# application?
>
> Regards,
> William Jo
I was hoping pad would get finished some day. Maybe 1.9?
Alright - I do like the idea of passing a function to pad, with a bunch of
pre-made functions in place.
Maybe something like:
a = np.arange(10)
b = pad('mean', a, 2, stat_length=3)
where if the first argument is a string, use one
Hello,
Can numpy for .NET be used in a DLR C# application?
Regards,
William Johnston
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mar 29, 2012, at 11:52 AM, Nathaniel Smith wrote:
> On Thu, Mar 29, 2012 at 5:38 PM, Nathaniel Smith wrote:
>> On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant wrote:
>>> While namespaces are a really good idea, I'm not a big fan of both "module"
>>> namespaces and underscore namespaces. I
On Thu, Mar 29, 2012 at 5:45 PM, Charles R Harris
wrote:
>
>
> On Thu, Mar 29, 2012 at 10:38 AM, Nathaniel Smith wrote:
>>
>> On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant
>> wrote:
>> > While namespaces are a really good idea, I'm not a big fan of both
>> > "module"
>> > namespaces and under
On Thu, Mar 29, 2012 at 5:38 PM, Nathaniel Smith wrote:
> On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant wrote:
>> While namespaces are a really good idea, I'm not a big fan of both "module"
>> namespaces and underscore namespaces. It seems pretty redundant to me to
>> have pad.pad_mean.
>>
>
On Thu, Mar 29, 2012 at 10:38 AM, Nathaniel Smith wrote:
> On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant
> wrote:
> > While namespaces are a really good idea, I'm not a big fan of both
> "module"
> > namespaces and underscore namespaces. It seems pretty redundant to me
> to
> > have pad.pad
On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant wrote:
> While namespaces are a really good idea, I'm not a big fan of both "module"
> namespaces and underscore namespaces. It seems pretty redundant to me to
> have pad.pad_mean.
>
> On the other hand, one could argue that pad.mean could be conf
While namespaces are a really good idea, I'm not a big fan of both "module"
namespaces and underscore namespaces. It seems pretty redundant to me to have
pad.pad_mean.
On the other hand, one could argue that pad.mean could be confused with
calculating the mean of a padded array. So, it see
On Thu, Mar 29, 2012 at 7:55 AM, Tim Cera
>> I think there is also a question of using a prefix pad_xxx for the
>> function names as opposed to pad.xxx.
"Namespaces are one honking great idea -- let's do more of those!"
> If I had it as pad.mean, pad.median, ...etc. then someone could
>
> f
On Wed, Mar 28, 2012 at 6:08 PM, Charles R Harris wrote:
>
> I think there is also a question of using a prefix pad_xxx for the
> function names as opposed to pad.xxx.
>
If I had it as pad.mean, pad.median, ...etc. then someone could
from numpy.pad import *
a = np.arange(5)
# then y
thanks to all. more than what I need.
cheers,
chao
2012/3/29 Derek Homeier
> On 29 Mar 2012, at 14:49, Robert Kern wrote:
>
> >> all work. For a more general check (e.g. if it is any type of integer),
> you can do
> >>
> >> np.issubclass_(a.dtype.type, np.integer)
> >
> > I don't recommend usi
On 29 Mar 2012, at 14:49, Robert Kern wrote:
>> all work. For a more general check (e.g. if it is any type of integer), you
>> can do
>>
>> np.issubclass_(a.dtype.type, np.integer)
>
> I don't recommend using that. Use np.issubdtype(a.dtype, np.integer) instead.
Sorry, you're right, this works
On Thu, Mar 29, 2012 at 13:47, Derek Homeier
wrote:
> On 29 Mar 2012, at 13:54, Chao YUE wrote:
>
>> how can I check type of array in if condition expression?
>>
>> In [75]: type(a)
>> Out[75]:
>>
>> In [76]: a.dtype
>> Out[76]: dtype('int32')
>>
>> a.dtype=='int32'?
>
> this and
>
> a.dtype=='i4
On 29 Mar 2012, at 13:54, Chao YUE wrote:
> how can I check type of array in if condition expression?
>
> In [75]: type(a)
> Out[75]:
>
> In [76]: a.dtype
> Out[76]: dtype('int32')
>
> a.dtype=='int32'?
this and
a.dtype=='i4'
a.dtype==np.int32
all work. For a more general check (e.g. if it
if type(a) == numpy.ndarray:
...
if a.dtype == 'int32':
...
-=- Olivier
Le 29 mars 2012 07:54, Chao YUE a écrit :
> Dear all,
>
> how can I check type of array in if condition expression?
>
> In [75]: type(a)
> Out[75]:
>
> In [76]: a.dtype
> Out[76]: dtype('int32')
>
> a.dtype=='int32'?
Dear all,
how can I check type of array in if condition expression?
In [75]: type(a)
Out[75]:
In [76]: a.dtype
Out[76]: dtype('int32')
a.dtype=='int32'?
thanks!
Chao
--
***
Chao YUE
Laboratoire des Sciences du
On Thu, Mar 29, 2012 at 11:04, Thouis (Ray) Jones wrote:
> It seems to be a bug in the unicode string length computation in
> arraytypes.c.src:UNICODE_compare(), based on comparison to the code in
> arrayobject.c:_myunicmp() and arrayobject.c:_compare_strings().
>
> Patch below (against maintenanc
It seems to be a bug in the unicode string length computation in
arraytypes.c.src:UNICODE_compare(), based on comparison to the code in
arrayobject.c:_myunicmp() and arrayobject.c:_compare_strings().
Patch below (against maintenance/1.6.x, but the bug also looks to be
present in master based on my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 08.03.2012 um 20:39 schrieb Pauli Virtanen:
> 08.03.2012 17:37, Christoph Gohle kirjoitti:
>> thanks for testing. I have now tried on different platforms. I get
>> all kinds of crashes on os x (now with numpy 1.6.1) and windows
>> with numpy 1.6.0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 08.03.2012 um 20:39 schrieb Pauli Virtanen:
> 08.03.2012 17:37, Christoph Gohle kirjoitti:
>> thanks for testing. I have now tried on different platforms. I get
>> all kinds of crashes on os x (now with numpy 1.6.1) and windows
>> with numpy 1.6.0
24 matches
Mail list logo
