<
cjordan1@uw.edu> wrote:
> On Fri, Feb 17, 2012 at 11:31 PM, Matthew Brett <
matthew.brett@gmail.com> wrote:
>> Hi,
>>
>> On Fri, Feb 17, 2012 at 10:18 PM, Christopher Jordan-Squire
>> <
cjordan1@uw.edu> wrote:
>>> On Fri, Feb 17, 2012 at 8:30 PM, Sturla Molden <
sturla@molden.no> wrote:
>>>>
>>>>
>>>> Den 18. feb. 2012 kl. 05:01 skrev Jason Grout <
jason-sage@creativetrax.com>:
>>>>
>>>>> On 2/17/12 9:54 PM, Sturla Molden wrote:
>>>>>> We would have to write a C++ programming tutorial that is based on Pyton knowledge instead of C knowledge.
>>>>>
>>>>> I personally would love such a thing. It's been a while since I did
>>>>> anything nontrivial on my own in C++.
>>>>>
>>>>
>>>> One example: How do we code multiple return values?
>>>>
>>>> In Python:
>>>> - Return a tuple.
>>>>
>>>> In C:
>>>> - Use pointers (evilness)
>>>>
>>>> In C++:
>>>> - Return a std::tuple, as you would in Python.
>>>> - Use references, as you would in Fortran or Pascal.
>>>> - Use pointers, as you would in C.
>>>>
>>>> C++ textbooks always pick the last...
>>>>
>>>> I would show the first and the second method, and perhaps intentionally forget the last.
>>>>
>>>> Sturla
>>>>
>>
>>> On the flip side, cython looked pretty...but I didn't get the
>>> performance gains I wanted, and had to spend a lot of time figuring
>>> out if it was cython, needing to add types, buggy support for numpy,
>>> or actually the algorithm.
>>
>> At the time, was the numpy support buggy? I personally haven't had
>> many problems with Cython and numpy.
>>
>
> It's not that the support WAS buggy, it's that it wasn't clear to me
> what was going on and where my performance bottleneck was. Even after
> microbenchmarking with ipython, using timeit and prun, and using the
> cython code visualization tool. Ultimately I don't think it was
> cython, so perhaps my comment was a bit unfair. But it was
> unfortunately difficult to verify that. Of course, as you say,
> diagnosing and solving such issues would become easier to resolve with
> more cython experience.
>
>>> The C files generated by cython were
>>> enormous and difficult to read. They really weren't meant for human
>>> consumption.
>>
>> Yes, it takes some practice to get used to what Cython will do, and
>> how to optimize the output.
>>
>>> As Sturla has said, regardless of the quality of the
>>> current product, it isn't stable.
>>
>> I've personally found it more or less rock solid. Could you say what
>> you mean by "it isn't stable"?
>>
>
> I just meant what Sturla said, nothing more:
>
> "Cython is still 0.16, it is still unfinished. We cannot base NumPy on
> an unfinished compiler."