[IPOL discuss] python as an addition to c++

[Ofer]

I like the idea of IPOL and that what got me into this mailing list.
I don't have such an algorithm, as I currently code in Matlab and am only
currently transitioning to python.





On Thu, Jun 6, 2013 at 3:17 PM, Jean-Michel Morel
<morel at cmla.ens-cachan.fr>wrote:

>   By the way, Ofer, do you have some algorithm in mind that you would
> have liked to publish in IPOL?  If so, can you send us
>  a description, or the underlying paper?
>  Best,
> Jean-Michel
>
>
> On Thu, Jun 6, 2013 at 9:56 AM, Ofer <ofer.bartal at weizmann.ac.il> wrote:
>
>>   I just want to add that it is not uncommon for python code to call
>> subroutines written in c/c++ in cases where speed is an issue.
>>  So software can be written in effective combinations of python and c/c++.
>>  Python code can be inefficient compared to c/c++, but pure c/c++ code
>> can also be written inefficiently.
>> As I understand, part of the current review process requires that the
>> c/c++ be well written and adequately efficient.
>> Perhaps it could be part of the review process of submissions of python
>> code to require that certain subroutines be written in c/c++ for efficiency.
>>  In general, python code is more compact and easier to understand, which
>> could potentially make the code easier for review.
>>
>>
>>
>>
>> On Thu, Jun 6, 2013 at 10:30 AM, Miguel Colom <colom at cmla.ens-cachan.fr>wrote:
>>
>>>  Quoting Nicolas Limare <nicolas.limare at cmla.ens-cachan.fr>:
>>> >> A parallelized C/C++ as those we have in the current IPOL
>>> >> publications are complete programs that once compiled run at their
>>> >> fastest speed using CPU native instructions.
>>> >> They're only limited by the power of the machine where the run on.
>>> >
>>> > I am no very sure of that, Miguel. We could also say that they are
>>> > very limited by the skills of the developper in low-level
>>> > optimizations. And sometimes the Python/NumPy internals will be better
>>> > coded than a researcher's C code, and the python version could be
>>> > faster. I'll try with a (simplistic) code of mine, to have some
>>> > numbers for a comparison.
>>>
>>>  Yes, I think that it's an easy check: to look in the published code
>>> for operations (patch comparisons, and so on) that in principle are
>>> not handled by libraries, since they're the algorithm code.
>>>
>>> All these code is likely to slow down the execution of the algorithm
>>> in it's Python version.
>>>
>>> However, I'm not saying that we should oppose to the use of Python
>>> code. We have to study the pros and cons and decide accordingly.
>>>
>>> Python is a very good language and many people use it for scientific
>>> computations. But we have must have in mind that we are likely to face
>>> an important performance loss if we use it.
>>>
>>>
>>> --
>>> IPOL - Image Processing On Line   - http://ipol.im/
>>>
>>> contact     edit at ipol.im          - http://www.ipol.im/meta/contact/
>>> news+feeds  twitter @IPOL_journal - http://www.ipol.im/meta/feeds/
>>> announces   announce at list.ipol.im - http://tools.ipol.im/mm/announce/
>>> discussions discuss at list.ipol.im  - http://tools.ipol.im/mm/discuss/
>>>
>>
>>
>> --
>> IPOL - Image Processing On Line   - http://ipol.im/
>>
>> contact     edit at ipol.im          - http://www.ipol.im/meta/contact/
>> news+feeds  twitter @IPOL_journal - http://www.ipol.im/meta/feeds/
>> announces   announce at list.ipol.im - http://tools.ipol.im/mm/announce/
>> discussions discuss at list.ipol.im  - http://tools.ipol.im/mm/discuss/
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tools.ipol.im/mailman/archive/discuss/attachments/20130606/003277de/attachment.html>