Dag wrote:
> General feedback is welcome; in particular, I need more opinions about
> what syntax people would like. We seem unable to find something that we
> really like; this is the current best candidate (cdef is the way you
> declare types on variables in Cython):
>
> cdef int i = 4, j = 6
> c
Since there's been a lot of Cython discussion lately I thought I'd speak
up and start a thread specifically for my project.
We've just recently set a clear direction for my Google Summer of Code
project for integrating NumPy in a better way with Cython. What we ended
up with is that I will over th
On Fri, Jun 20, 2008 at 11:21 PM, Charles R Harris <
[EMAIL PROTECTED]> wrote:
> Shouldn't this raise an NotImplementedError exception?
>
> In [7]: type(remainder(complex192(1), complex192(1)))
> Out[7]:
>
I suspect these types should both have Py_TPFLAGS_CHECKTYPES bit set in the
tp_flag so tha
Shouldn't this raise an NotImplementedError exception?
In [7]: type(remainder(complex192(1), complex192(1)))
Out[7]:
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
What should we do about this:
DeprecationWarning: complex divmod(), // and % are deprecated
Note that these functions are not defined in numpy, rather complex numbers
are promoted to python objects and the appropriate method/pyfunction is
called. For fmod this returns an attribute error because
Howdy,
I made some progress on the issue I mentioned earlier:
http://lists.idyll.org/pipermail/testing-in-python/2008-June/000709.html
As indicated there, a bug report has been filed with Python itself:
http://bugs.python.org/issue3158
But in the meantime, Alan may want to apply the monkeypatc
On Fri, Jun 20, 2008 at 7:22 PM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> It may be worth bringing it up wtih the nose guys here:
>
> http://lists.idyll.org/listinfo/testing-in-python
>
> The nose author seems very responsive, and Titus Brown is on the list
> and cares a lot about numpy/scipy, a
On Fri, Jun 20, 2008 at 3:04 PM, Alan McIntyre <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 20, 2008 at 5:35 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>> So NoseTester.run() basically just calls nose.run(). That basically
>> just instantiates nose.core.TestProgram and returns the .success
>> attribute
On Fri, Jun 20, 2008 at 16:52, Alan McIntyre <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 20, 2008 at 5:44 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>> Specifically, what changes are you thinking of making?
>> numpy.test(coverage=True) already triggers nose's coverage feature.
>
> Actually, that wasn'
On Fri, Jun 20, 2008 at 5:35 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> So NoseTester.run() basically just calls nose.run(). That basically
> just instantiates nose.core.TestProgram and returns the .success
> attribute of it. Unfortunately, the TextTestResults object (a nose
> subclass of unittes
On Fri, Jun 20, 2008 at 5:44 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> Specifically, what changes are you thinking of making?
> numpy.test(coverage=True) already triggers nose's coverage feature.
Actually, that wasn't supposed to get added in my last checkin; I was
experimenting with it and for
On Fri, Jun 20, 2008 at 4:38 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> No. It just affects the Fortran compiler (if any) used to build numpy.
> The only place this might affect you is if you use a LAPACK or BLAS
> that needs to be linked with a Fortran compiler. Generally, you don't
> have to s
On Fri, Jun 20, 2008 at 16:35, Alan McIntyre <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Nose has a plugin (included in the current version of nose) that uses
> Ned Batchelder's coverage module
> (http://nedbatchelder.com/code/modules/coverage.html) to provide
> coverage information. Is it acceptable
On Fri, Jun 20, 2008 at 16:27, Adam Mercer <[EMAIL PROTECTED]> wrote:
> Hi
>
> If I specify a fortran compiler when building numpy, does that have
> any effect on what is installed? In other words, must I build numpy
> against a fortran compiler in order to successfully build and use
> extension wr
Hi all,
Nose has a plugin (included in the current version of nose) that uses
Ned Batchelder's coverage module
(http://nedbatchelder.com/code/modules/coverage.html) to provide
coverage information. Is it acceptable to use this capability in nose
to provide coverage reporting for NumPy? The cover
On Fri, Jun 20, 2008 at 16:01, Alan McIntyre <[EMAIL PROTECTED]> wrote:
> - numpy.test now returns an object with a wasSuccessful method; under
> the old test framework it returned a unittest._TextTestResult, but
> since nose.run only returns success/failure, I'm just wrapping this
> result in a d
Hi
If I specify a fortran compiler when building numpy, does that have
any effect on what is installed? In other words, must I build numpy
against a fortran compiler in order to successfully build and use
extension written in fortran - such as scipy?
Cheers
Adam
_
On 6/20/08, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
> I am trying to figure the right way of looping throught ndarrays using
> Cython, currently. Things seem to have evolved a bit compared to what
> some documents on the web claim (eg "for i from 0<=i faster than "for i in range(n)").
Regard
Hi all,
Just wanted to get feedback about the following changes before I make
them. Please speak up if any of this seems objectionable to you.
- The old test framework classes will be restored, but will not be
used anywhere in NumPy's tests. If your old tests still don't work
with the restored
On Fri, Jun 20, 2008 at 15:17, Sebastian Haase <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 20, 2008 at 9:37 AM, David Cournapeau
> <[EMAIL PROTECTED]> wrote:
>> Robert Kern wrote:
>>>
>>> They should deprecated for one minor version and then deleted.
>>
>> Ok, thanks for the clarification. Since I was
On Fri, Jun 20, 2008 at 9:37 AM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
> Robert Kern wrote:
>>
>> They should deprecated for one minor version and then deleted.
>
> Ok, thanks for the clarification. Since I was not aware of this, and did
> not see this information on the wiki, I added it in
>
I realise this, but 1659 tests in 8.739s with Nose as opposed to just
over 1000 tests in right around 1 second with the previous test system
means there is some kind of slowdown involved besides just the number
of tests being found. Not that I mind: I'm not looking for blazing
speed when running te
On Fri, Jun 20, 2008 at 14:11, Matthew Brett <[EMAIL PROTECTED]> wrote:
> Hi,
>
> As a matter of interest, what is the relationship, if any, between (in Cython)
>
> import numpy
>
> and
>
> cnp.import_array()
>
> Are they initializing different copies of the same thing?
No. "import numpy" is essen
On Fri, Jun 20, 2008 at 14:13, Gael Varoquaux
<[EMAIL PROTECTED]> wrote:
> On Fri, Jun 20, 2008 at 02:07:08PM -0500, Robert Kern wrote:
>> > Does somebody have a example of fast looping through ndarrays using
>> > modern Cython idioms?
>
>> If you're using normal Python indexing, then that's where
Oups, forgot the attachement.
On Fri, Jun 20, 2008 at 09:13:34PM +0200, Gael Varoquaux wrote:
> On Fri, Jun 20, 2008 at 02:07:08PM -0500, Robert Kern wrote:
> > > Does somebody have a example of fast looping through ndarrays using
> > > modern Cython idioms?
> > If you're using normal Python inde
On Fri, Jun 20, 2008 at 02:07:08PM -0500, Robert Kern wrote:
> > Does somebody have a example of fast looping through ndarrays using
> > modern Cython idioms?
> If you're using normal Python indexing, then that's where all your
> time is being spent. You need to grab the actual .data pointer and d
Hi,
As a matter of interest, what is the relationship, if any, between (in Cython)
import numpy
and
cnp.import_array()
Are they initializing different copies of the same thing?
Best,
Matthew
___
Numpy-discussion mailing list
Numpy-discussion@scipy.
On Fri, Jun 20, 2008 at 09:17, Gael Varoquaux
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am trying to figure the right way of looping throught ndarrays using
> Cython, currently. Things seem to have evolved a bit compared to what
> some documents on the web claim (eg "for i from 0<=i faster than "for i
On Fri, Jun 20, 2008 at 11:11 AM, Andrew Straw <[EMAIL PROTECTED]> wrote:
> Fernando Perez wrote:
>> I verified further by putting the import_array() back into the .pyx
>> file and indeed:
>>
>> - i_a() in .pxd -> missing from .c file.
>> - i_a() in .pyx -> OK in .c file.
>>
>> It thus seems that
Fernando Perez wrote:
> I verified further by putting the import_array() back into the .pyx
> file and indeed:
>
> - i_a() in .pxd -> missing from .c file.
> - i_a() in .pyx -> OK in .c file.
>
> It thus seems that we must keep the import_array call out of the .pxd
> and users still need to remem
On Thu, Jun 19, 2008 at 9:18 PM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 19, 2008 at 5:29 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
>>> I just tested the changes and there seem to be no ill effects. Should
>>> I go ahead and commit it? I'll do it in a single commit with no othe
Hi,
I am trying to figure the right way of looping throught ndarrays using
Cython, currently. Things seem to have evolved a bit compared to what
some documents on the web claim (eg "for i from 0<=ihttp://projects.scipy.org/mailman/listinfo/numpy-discussion
David Cournapeau wrote:
> Lane Brooks wrote:
>
>> I have successfully written several extension modules that use the numpy
>> CAPI to manipulate numpy arrays. I have to say numpy is great.
>>
>> I am now having a problem, however, when calling numpy capi functions
>> when running python embed
Lane Brooks wrote:
> I have successfully written several extension modules that use the numpy
> CAPI to manipulate numpy arrays. I have to say numpy is great.
>
> I am now having a problem, however, when calling numpy capi functions
> when running python embedded in a third party, closed source,
I have successfully written several extension modules that use the numpy
CAPI to manipulate numpy arrays. I have to say numpy is great.
I am now having a problem, however, when calling numpy capi functions
when running python embedded in a third party, closed source,
application. It segfaults
Hi,
While trying to reproduce some bugs on windows with recent numpy, I
got major failures for the whole test suite, with something related to
numeric not found in numpy\core\__init__.py (__all__ += numeric.__all__
line). Nose crashes because at that line, meaning most of the tests
fail; n
I apologise for the horrible spelling mistake in the mail title!
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Jun 20, 2008 at 4:28 AM, izak marais <[EMAIL PROTECTED]> wrote:
> Hi
>
> Is there a reason why the syntax is rand(n,n), but zeros((n,n)) to create an
> n*n array? If not, perhaps this could be cleaned up?
>
SciPy's rand() is just a convenience wrapper:
>>> help(rand)
Help on built-in fun
Hi
Is there a reason why the syntax is rand(n,n), but zeros((n,n)) to create an
n*n array? If not, perhaps this could be cleaned up?
Regards,
Izak Marais
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/ma
Hi Anne,
Thanks for the approach ideas - I'll take a look at this soon to try to
understand it. Currently I'm visiting a LabView-based lab who already
have something that works, and works fast, so I'm being encouraged to
use LabView, but I'd like to show them more of the joys of Python. The
mem
Robert Kern wrote:
>
> They should deprecated for one minor version and then deleted.
Ok, thanks for the clarification. Since I was not aware of this, and did
not see this information on the wiki, I added it in
http://scipy.org/scipy/numpy/wiki/ApiDeprecation. Let me know if there
is something
On Fri, Jun 20, 2008 at 02:15, David Cournapeau
<[EMAIL PROTECTED]> wrote:
> I guess my concern is what do we do with deprecated functions: do we
> keep them, for how long ? There are some deprecate in current numpy
> which dates back to the pre 1.0 release. Maybe that's not really important.
They
Robert Kern wrote:
>
> I don't see a reason to wrap it in a decorator. It saves no significant
> effort.
>
If the warning is spit out in any case (whether the user uses the
default value or not), and if we don't need versioning, I understand it
is not that useful.
I guess my concern is what
On Fri, Jun 20, 2008 at 01:54, David Cournapeau
<[EMAIL PROTECTED]> wrote:
> Robert Kern wrote:
>> It will be hard to write something generic. The individual functions
>> will still have to write code that handles the old arguments anyways,
>> so all it would do is move the warning message from a
Robert Kern wrote:
>
> As long as we keep the policy that DeprecationWarnings last precisely
> one minor version, I don't think it really adds any information.
>
I was not aware of this policy. Obviously, it has no use in that case.
>
> It will be hard to write something generic. The individua
45 matches
Mail list logo
