[SciPy-Dev] Multivariate ctypes integration PR

[Nathan Woods]

Anyone? Anyone?

>From the lack of response to my email two weeks ago, I guess that there
isn't really a good way to distribute a library function for testing. When
ctypes functionality was initially included, the test function used was
part of the standard library, to avoid this same problem. I propose that we
therefore do one of two things.

One, we incorporate the changes as a user-beware feature, and strongly
suggest that users who are willing to do the work necessary to use the
functionality (a minority, presumably) do their own testing. In order to
use the speed improvements here, a user has to code their function in C,
compile it to a library, and load that library using ctypes. Then, that
ctypes function can be passed to scipy. I think we can agree that anyone
who is willing to put in that work for performance can be expected to run a
test or two to make sure everything is working.

Two, we shelve the project until a better solution is available. This will
probably require some alternative to ctypes, which is just too clunky to
distribute well. Unfortunately, I think that shelving this till later will
essentially kill it at this point.

Nathan


On Tue, Apr 15, 2014 at 3:38 PM, Nathan Woods <charlesnwoods at gmail.com>wrote:

> Hey everyone,
>
> Sorry to be the squeaky wheel again, but this needs to see some movement
> pretty soon. We only have another few weeks where we can work on this
> enhancement before the school year ends.
>
> The big challenge that we believe needs to be fixed is with the tests. We
> need a way to compile (or distribute) a C function from source to  a
> library with a given name, generally and at install time, in order to
> include the C route tests in the SciPy test suite. Is there a way to use
> distutils for this?
>
> If there's anything else that we can do on our end to speed things up,
> we'd be more than happy to help however we can.
>
> N
>
>
> On Mon, Mar 31, 2014 at 1:27 PM, Nathan Woods <charlesnwoods at gmail.com>wrote:
>
>> We had a question about how to implement one of the suggested
>> improvements:
>>
>> "- The code should more carefully check that the whole ctypes signature
>>   matches"
>>
>>  From what we can tell (see e.g.
>> http://stackoverflow.com/questions/18775389/is-there-a-way-to-load-the-constant-values-stored-in-a-header-file-via-ctypes),
>> there is no way to automatically generate the ctypes function signature
>> directly from a .h header file or c function prototype. This means that any
>> ctypes library function must be assumed to have the function signature that
>> the user claims it does (by specifying argtypes & restype). Unfortunately,
>> the ctypes library load & specification commands are executed by the user,
>> not by the library, so there's no way to enforce the function signature.
>>
>> Maybe there's a way in Cython or f2py, but we think that ctypes should
>> probably be supported anyway, even if it is with an "use at own risk"
>> disclaimer.
>>
>> Nathan
>>
>>
>>
>> On Fri, Mar 14, 2014 at 12:08 PM, Brian Lee Newsom <
>> Brian.Newsom at colorado.edu> wrote:
>>
>>> Thank you to everyone involved in assisting to move this forward. It is
>>> definitely a confusing project for me but something I am committed to
>>> finishing and getting in the library as soon as possible.  I appreciate the
>>> help and I will do my best to address the issues Pauli presented.
>>>
>>> Thanks,
>>> Brian
>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20140428/04b2db5b/attachment.html>