[scikit-image][RFC] Line Segmentation in Handwritten Documents
Hello all, I'm currently in the process of implementing line segmentation as a part of a writer identification system that identifies a given writer from their handwritten script or text. I thought the "Handwritten Text Line Segmentation" may be a good feature to add to scikit-image. Please, tell me what you think. This is the paper I plan to implement: A Statistical approach to line segmentation in handwritten,documents https://cedar.buffalo.edu/~srihari/papers/SPIE-2007-lineSeg.pdf. Best, Mina Sami
Hi Mina, and thanks for writing! That is a cool paper! Typically, though, we use scikit-image for established algorithms, rather than the latest and greatest. What I would do in your situation (indeed, what I *did* do for my skeleton analysis package, jni.github.io/skan, for example) is to make a separate Python package that is compatible with scikit-image (that is, uses standard data formats like NumPy arrays), but separate. We would be very happy to help spread the word about your work! Incidentally, speaking of papers, if you used scikit-image in developing your system, it would be great if you could cite our paper! [1] Thanks, Juan. ..[1]: https://peerj.com/articles/453/ On Fri, Mar 15, 2019, at 8:06 AM, Mina wrote:
Hello all,
I'm currently in the process of implementing line segmentation as a part of a writer identification system that identifies a given writer from their handwritten script or text. I thought the "Handwritten Text Line Segmentation" may be a good feature to add to scikit-image. Please, tell me what you think. This is the paper I plan to implement: A Statistical approach to line segmentation in handwritten,documents https://cedar.buffalo.edu/~srihari/papers/SPIE-2007-lineSeg.pdf.
Best,
Mina Sami
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
Alright then, will do just that and inform you when done. Will surely cite scikit-image as well. Thanks a lot! On 3/15/19 12:54 AM, Juan Nunez-Iglesias wrote:
Hi Mina, and thanks for writing!
That is a cool paper! Typically, though, we use scikit-image for established algorithms, rather than the latest and greatest. What I would do in your situation (indeed, what I *did* do for my skeleton analysis package, jni.github.io/skan http://jni.github.io/skan, for example) is to make a separate Python package that is compatible with scikit-image (that is, uses standard data formats like NumPy arrays), but separate. We would be very happy to help spread the word about your work!
Incidentally, speaking of papers, if you used scikit-image in developing your system, it would be great if you could cite our paper! [1]
Thanks,
Juan.
..[1]: https://peerj.com/articles/453/
On Fri, Mar 15, 2019, at 8:06 AM, Mina wrote:
Hello all,
I'm currently in the process of implementing line segmentation as a part of a writer identification system that identifies a given writer from their handwritten script or text. I thought the "Handwritten Text Line Segmentation" may be a good feature to add to scikit-image. Please, tell me what you think. This is the paper I plan to implement: A Statistical approach to line segmentation in handwritten,documents https://cedar.buffalo.edu/~srihari/papers/SPIE-2007-lineSeg.pdf.
Best,
Mina Sami
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
Hey Juan, I found this thread quite interesting, and somewhat relevant. I was in the process of developing some framework(or rather a package) for GANs, and was wondering about the design strategy. Being a newbie developer, I found the intent of making a package really exciting. I was thinking if you could share some pointers regarding how did you approach in designing your package (https://jni.github.io/skan/), (btw it was very well designed). Being a naive in development of packages, could you provide me with some resources/pointers towards appropriate approach of making a package?
Hi Yash, and thanks for writing! To be honest, I have not yet found a single resource that I was happy with for developing packages. Maybe I should make one. To get you started: 1) write documentation. The more the better. You uncover a lot of quirks in your API when you write docs. Usually we write an API in a stream-of-consciousness, “ok I’d like a function here” mode. When writing documentation, effectively telling others how to use our library, we do some editing. For writing documentation, this is my go-to source: https://www.divio.com/blog/documentation/ https://www.divio.com/blog/documentation/. Initially I only wrote reference materials for skan (docstrings). The paper reviewers rightly pointed out that how-to and explanation materials were also needed, and the API evolved a lot when I wrote those. I also highly recommend doctr (https://drdoctr.github.io https://drdoctr.github.io/) and nb2plots (https://github.com/matthew-brett/nb2plots https://github.com/matthew-brett/nb2plots). The latter lets you integrate jupyter notebooks into your sphinx (generated) documentation. 2) Make a setup.py. For these I always just find a model. Skan’s should suit most people. 3) Finally, put your project up on PyPI. The best guide I know of for this is the “official” one: https://packaging.python.org/tutorials/packaging-projects/ https://packaging.python.org/tutorials/packaging-projects/ 4) For good measure, you can put your package on conda-forge. They have an excellent walk-through here: https://conda-forge.org/#add_recipe https://conda-forge.org/#add_recipe I hope this helps! Feel free to announce your package on this list when it’s out there! =) Juan.
On 16 Mar 2019, at 4:51 pm, Yash Sharma
wrote: Hey Juan, I found this thread quite interesting, and somewhat relevant. I was in the process of developing some framework(or rather a package) for GANs, and was wondering about the design strategy. Being a newbie developer, I found the intent of making a package really exciting. I was thinking if you could share some pointers regarding how did you approach in designing your package (https://jni.github.io/skan/), (btw it was very well designed). Being a naive in development of packages, could you provide me with some resources/pointers towards appropriate approach of making a package? _______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
Hey Juan, Thanks for a descriptive reply! I needed to ask you more points regarding the API design that you followed. Can you share some ideas as to how did you go about designing your API?
I am very interested in this question and discussion as well. Maybe we
should start a separate thread.
Cheers
Stefanie
Am Sa., 16. März 2019, 14:06 hat Yash Sharma
Hey Juan, Thanks for a descriptive reply! I needed to ask you more points regarding the API design that you followed. Can you share some ideas as to how did you go about designing your API? _______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
Well, I wouldn't say I'm an expert in API design, and I actually don't consider skan to be particularly well designed (see: those seams I mentioned I figured out as I wrote the docs — they're not fully patched up), but sure, I'll bite. =) Maybe others on the list have ideas. (a) scikit-image and scikit-learn are both great APIs. I suggest looking at them most closely when designing yours. (b) I fall very deep on the functional side of "functional vs object oriented". This means: - no state; function outputs depend only on their inputs. - use standard objects and classes as much as possible rather than defining your own classes. - don't reuse variable names. (c) when should you reach for classes? Pietro Berkes wrote the pattern very succinctly in a recent lecture of his. If you find yourself writing def f1(x, y, z): ..., def f2(x, y, z): ..., etc, where x, y, and z are always the same bunch of data, then you should probably write a class that contains those three bits. BUT, I would still aim to write functions, as above, rather than methods of the class. Hope this helps! =) Juan. On Sun, Mar 17, 2019, at 12:12 AM, Stefanie Lück wrote:
I am very interested in this question and discussion as well. Maybe we should start a separate thread.
Cheers Stefanie
Am Sa., 16. März 2019, 14:06 hat Yash Sharma
geschrieben: Hey Juan, Thanks for a descriptive reply! I needed to ask you more points regarding the API design that you followed. Can you share some ideas as to how did you go about designing your API? _______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
Hi, I've mostly been on the user side regarding APIs so take this with a grain of salt and beware that this is based on my opinion and experience so it's certainly subjective. ;) One aspect that hasn't been mentioned yet is the benefit of expressive and boring module, function and parameter names. This applies to programming in general but can be important for API design as well. Consider this case: a new user has a specific problem and wants to know whether your API contains a function that can solve it. If the user is able to glean the purpose of functions by just looking at their signatures you have just reduced the friction to finding the solution significantly. The user no longer needs to read every docstring to rule out a function. If someone new isn't able to find the solution to his problem manually but has to resort to a page's search field, there may be room to improve the API. This may be obvious to some but I mention this because I feel like code written in the scientific community is often on the terse side with abbreviations everywhere. This applies especially to the implementation itself (maybe it's the mathematical background?) but to a lesser extent to API design too. In both cases readability suffers a lot. This doesn't mean you shouldn't use well known, established abbreviations such as "FFT" but one should avoid them for anything else. I agree with all points raised by Juan below, especially (a). Following already established practices and guidelines in your field is very often an excellent idea. Best regards, Lars On 18/03/2019 09:41, Juan Nunez-Iglesias wrote:
Well, I wouldn't say I'm an expert in API design, and I actually don't consider skan to be particularly well designed (see: those seams I mentioned I figured out as I wrote the docs — they're not fully patched up), but sure, I'll bite. =) Maybe others on the list have ideas.
(a) scikit-image and scikit-learn are both great APIs. I suggest looking at them most closely when designing yours. (b) I fall very deep on the functional side of "functional vs object oriented". This means: - no state; function outputs depend only on their inputs. - use standard objects and classes as much as possible rather than defining your own classes. - don't reuse variable names. (c) when should you reach for classes? Pietro Berkes wrote the pattern very succinctly in a recent lecture of his. If you find yourself writing def f1(x, y, z): ..., def f2(x, y, z): ..., etc, where x, y, and z are always the same bunch of data, then you should probably write a class that contains those three bits. BUT, I would still aim to write functions, as above, rather than methods of the class.
Hope this helps! =)
Juan.
On Sun, Mar 17, 2019, at 12:12 AM, Stefanie Lück wrote:
I am very interested in this question and discussion as well. Maybe we should start a separate thread.
Cheers Stefanie
Am Sa., 16. März 2019, 14:06 hat Yash Sharma
mailto:yashrsharma44@gmail.com> geschrieben: Hey Juan, Thanks for a descriptive reply! I needed to ask you more points regarding the API design that you followed. Can you share some ideas as to how did you go about designing your API? _______________________________________________ scikit-image mailing list -- scikit-image@python.org mailto:scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org mailto:scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
Hello,
Thanks Juan and Lars for sharing your experience. Still it would be great
to have a good tutorial, as Juan mentioned earlier I was also unable to
find a good resource which keeps stops me starting to write a package. I
also would like to know how you decide whether the code should be a
separate package or directly fused to scikit-image? I have several ideas,
code and projects which might be useful for scikit-image users but I don't
know how to start contributions.
In addition I am looking for a good example of a computer vision paper, in
case anyone could recommend me an article which follows best practices in
reproducible science, I would appreciate it.
Thanks in advance
Stefanie
Am Mo., 18. März 2019, 11:52 hat Lars Grueter
Hi, I've mostly been on the user side regarding APIs so take this with a grain of salt and beware that this is based on my opinion and experience so it's certainly subjective. ;)
One aspect that hasn't been mentioned yet is the benefit of expressive and boring module, function and parameter names. This applies to programming in general but can be important for API design as well. Consider this case: a new user has a specific problem and wants to know whether your API contains a function that can solve it. If the user is able to glean the purpose of functions by just looking at their signatures you have just reduced the friction to finding the solution significantly. The user no longer needs to read every docstring to rule out a function. If someone new isn't able to find the solution to his problem manually but has to resort to a page's search field, there may be room to improve the API.
This may be obvious to some but I mention this because I feel like code written in the scientific community is often on the terse side with abbreviations everywhere. This applies especially to the implementation itself (maybe it's the mathematical background?) but to a lesser extent to API design too. In both cases readability suffers a lot. This doesn't mean you shouldn't use well known, established abbreviations such as "FFT" but one should avoid them for anything else.
I agree with all points raised by Juan below, especially (a). Following already established practices and guidelines in your field is very often an excellent idea.
Best regards, Lars
On 18/03/2019 09:41, Juan Nunez-Iglesias wrote:
Well, I wouldn't say I'm an expert in API design, and I actually don't consider skan to be particularly well designed (see: those seams I mentioned I figured out as I wrote the docs — they're not fully patched up), but sure, I'll bite. =) Maybe others on the list have ideas.
(a) scikit-image and scikit-learn are both great APIs. I suggest looking at them most closely when designing yours. (b) I fall very deep on the functional side of "functional vs object oriented". This means: - no state; function outputs depend only on their inputs. - use standard objects and classes as much as possible rather than defining your own classes. - don't reuse variable names. (c) when should you reach for classes? Pietro Berkes wrote the pattern very succinctly in a recent lecture of his. If you find yourself writing def f1(x, y, z): ..., def f2(x, y, z): ..., etc, where x, y, and z are always the same bunch of data, then you should probably write a class that contains those three bits. BUT, I would still aim to write functions, as above, rather than methods of the class.
Hope this helps! =)
Juan.
On Sun, Mar 17, 2019, at 12:12 AM, Stefanie Lück wrote:
I am very interested in this question and discussion as well. Maybe we should start a separate thread.
Cheers Stefanie
Am Sa., 16. März 2019, 14:06 hat Yash Sharma
mailto:yashrsharma44@gmail.com> geschrieben: Hey Juan, Thanks for a descriptive reply! I needed to ask you more points regarding the API design that you followed. Can you share some ideas as to how did you go about designing your API? _______________________________________________ scikit-image mailing list -- scikit-image@python.org mailto:scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org mailto:scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
Hi Stefanie,
A journal dedicated to computer vision papers implemented in a reproducible
manner is IPOL: https://www.ipol.im/
Papers are accompanied by code and an on-line demo, although the
implementations there are in C or C++ rather than Python.
In terms of what should go into scikit-image vs. a third-party package, it
can be a bit subjective, but primary criteria are:
1.) Is the method likely to be of broad interest? (one indication of this
is the number of citations to a paper describing the method)
2.) How easy is the implementation to understand and maintain going forward?
Once we add something to the scikit-image API we are making a commitment to
support it indefinitely. The original contributor of the method may not
always be available, so the code needs to be relatively clear and easy for
another dev to understand and modify as needed.
3.) Is the contributed code under compatible license terms? e.g.
GPL-licensed code has more restrictions than scikit-image's BSD 3-clause
license and cannot be included within the project.
4.) Is the method unencumbered by patents? We only implement freely usable
algorithms in scikit-image.
- Greg
On Mon, Mar 18, 2019 at 2:38 PM Stefanie Lück
Hello,
Thanks Juan and Lars for sharing your experience. Still it would be great to have a good tutorial, as Juan mentioned earlier I was also unable to find a good resource which keeps stops me starting to write a package. I also would like to know how you decide whether the code should be a separate package or directly fused to scikit-image? I have several ideas, code and projects which might be useful for scikit-image users but I don't know how to start contributions.
In addition I am looking for a good example of a computer vision paper, in case anyone could recommend me an article which follows best practices in reproducible science, I would appreciate it.
Thanks in advance Stefanie
Am Mo., 18. März 2019, 11:52 hat Lars Grueter
geschrieben: Hi, I've mostly been on the user side regarding APIs so take this with a grain of salt and beware that this is based on my opinion and experience so it's certainly subjective. ;)
One aspect that hasn't been mentioned yet is the benefit of expressive and boring module, function and parameter names. This applies to programming in general but can be important for API design as well. Consider this case: a new user has a specific problem and wants to know whether your API contains a function that can solve it. If the user is able to glean the purpose of functions by just looking at their signatures you have just reduced the friction to finding the solution significantly. The user no longer needs to read every docstring to rule out a function. If someone new isn't able to find the solution to his problem manually but has to resort to a page's search field, there may be room to improve the API.
This may be obvious to some but I mention this because I feel like code written in the scientific community is often on the terse side with abbreviations everywhere. This applies especially to the implementation itself (maybe it's the mathematical background?) but to a lesser extent to API design too. In both cases readability suffers a lot. This doesn't mean you shouldn't use well known, established abbreviations such as "FFT" but one should avoid them for anything else.
I agree with all points raised by Juan below, especially (a). Following already established practices and guidelines in your field is very often an excellent idea.
Best regards, Lars
On 18/03/2019 09:41, Juan Nunez-Iglesias wrote:
Well, I wouldn't say I'm an expert in API design, and I actually don't consider skan to be particularly well designed (see: those seams I mentioned I figured out as I wrote the docs — they're not fully patched up), but sure, I'll bite. =) Maybe others on the list have ideas.
(a) scikit-image and scikit-learn are both great APIs. I suggest looking at them most closely when designing yours. (b) I fall very deep on the functional side of "functional vs object oriented". This means: - no state; function outputs depend only on their inputs. - use standard objects and classes as much as possible rather than defining your own classes. - don't reuse variable names. (c) when should you reach for classes? Pietro Berkes wrote the pattern very succinctly in a recent lecture of his. If you find yourself writing def f1(x, y, z): ..., def f2(x, y, z): ..., etc, where x, y, and z are always the same bunch of data, then you should probably write a class that contains those three bits. BUT, I would still aim to write functions, as above, rather than methods of the class.
Hope this helps! =)
Juan.
On Sun, Mar 17, 2019, at 12:12 AM, Stefanie Lück wrote:
I am very interested in this question and discussion as well. Maybe we should start a separate thread.
Cheers Stefanie
Am Sa., 16. März 2019, 14:06 hat Yash Sharma
mailto:yashrsharma44@gmail.com> geschrieben: Hey Juan, Thanks for a descriptive reply! I needed to ask you more points regarding the API design that you followed. Can you share some ideas as to how did you go about designing your API? _______________________________________________ scikit-image mailing list -- scikit-image@python.org mailto:scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org mailto:scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
Hi Gregory,
Thank you very much for your reply which was very useful for me.
Best regards
Stefanie
Am Mo., 18. März 2019, 21:20 hat Gregory Lee
Hi Stefanie,
A journal dedicated to computer vision papers implemented in a reproducible manner is IPOL: https://www.ipol.im/ Papers are accompanied by code and an on-line demo, although the implementations there are in C or C++ rather than Python.
In terms of what should go into scikit-image vs. a third-party package, it can be a bit subjective, but primary criteria are:
1.) Is the method likely to be of broad interest? (one indication of this is the number of citations to a paper describing the method) 2.) How easy is the implementation to understand and maintain going forward? Once we add something to the scikit-image API we are making a commitment to support it indefinitely. The original contributor of the method may not always be available, so the code needs to be relatively clear and easy for another dev to understand and modify as needed. 3.) Is the contributed code under compatible license terms? e.g. GPL-licensed code has more restrictions than scikit-image's BSD 3-clause license and cannot be included within the project. 4.) Is the method unencumbered by patents? We only implement freely usable algorithms in scikit-image.
- Greg
On Mon, Mar 18, 2019 at 2:38 PM Stefanie Lück
wrote: Hello,
Thanks Juan and Lars for sharing your experience. Still it would be great to have a good tutorial, as Juan mentioned earlier I was also unable to find a good resource which keeps stops me starting to write a package. I also would like to know how you decide whether the code should be a separate package or directly fused to scikit-image? I have several ideas, code and projects which might be useful for scikit-image users but I don't know how to start contributions.
In addition I am looking for a good example of a computer vision paper, in case anyone could recommend me an article which follows best practices in reproducible science, I would appreciate it.
Thanks in advance Stefanie
Am Mo., 18. März 2019, 11:52 hat Lars Grueter
geschrieben: Hi, I've mostly been on the user side regarding APIs so take this with a grain of salt and beware that this is based on my opinion and experience so it's certainly subjective. ;)
One aspect that hasn't been mentioned yet is the benefit of expressive and boring module, function and parameter names. This applies to programming in general but can be important for API design as well. Consider this case: a new user has a specific problem and wants to know whether your API contains a function that can solve it. If the user is able to glean the purpose of functions by just looking at their signatures you have just reduced the friction to finding the solution significantly. The user no longer needs to read every docstring to rule out a function. If someone new isn't able to find the solution to his problem manually but has to resort to a page's search field, there may be room to improve the API.
This may be obvious to some but I mention this because I feel like code written in the scientific community is often on the terse side with abbreviations everywhere. This applies especially to the implementation itself (maybe it's the mathematical background?) but to a lesser extent to API design too. In both cases readability suffers a lot. This doesn't mean you shouldn't use well known, established abbreviations such as "FFT" but one should avoid them for anything else.
I agree with all points raised by Juan below, especially (a). Following already established practices and guidelines in your field is very often an excellent idea.
Best regards, Lars
Well, I wouldn't say I'm an expert in API design, and I actually don't consider skan to be particularly well designed (see: those seams I mentioned I figured out as I wrote the docs — they're not fully patched up), but sure, I'll bite. =) Maybe others on the list have ideas.
(a) scikit-image and scikit-learn are both great APIs. I suggest looking at them most closely when designing yours. (b) I fall very deep on the functional side of "functional vs object oriented". This means: - no state; function outputs depend only on
On 18/03/2019 09:41, Juan Nunez-Iglesias wrote: their
inputs. - use standard objects and classes as much as possible rather than defining your own classes. - don't reuse variable names. (c) when should you reach for classes? Pietro Berkes wrote the pattern very succinctly in a recent lecture of his. If you find yourself writing def f1(x, y, z): ..., def f2(x, y, z): ..., etc, where x, y, and z are always the same bunch of data, then you should probably write a class that contains those three bits. BUT, I would still aim to write functions, as above, rather than methods of the class.
Hope this helps! =)
Juan.
On Sun, Mar 17, 2019, at 12:12 AM, Stefanie Lück wrote:
I am very interested in this question and discussion as well. Maybe we should start a separate thread.
Cheers Stefanie
Am Sa., 16. März 2019, 14:06 hat Yash Sharma
mailto:yashrsharma44@gmail.com> geschrieben: Hey Juan, Thanks for a descriptive reply! I needed to ask you more points regarding the API design that you followed. Can you share some ideas as to how did you go about designing your API? _______________________________________________ scikit-image mailing list -- scikit-image@python.org mailto:scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org mailto:scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
On the topic of documentation: I'm not really in a position of using Python
much these days, but I find that I use the Elegant SciPy book frequently as
a reference. In the language of the link, it kind of spans How-To Guide and
Explanation (but is still compact), which is a strikingly rare combination
in an era where there are seemingly so many resources for any given topic.
I wanted to point out some potential use cases for Python libraries, to
help build user stories for where effort might go. Python has the advantage
of guidance by the scientific community, that other language communities
lack. Nevertheless, it might be necessary to work elsewhere, in some
environment with no Numpy/Scipy/Scikit stack, to build without much
infrastructure, or conversely, to analyze and restate something which "just
works" into more traditional scientific language, so that something can be
better understood for further analysis, or built on in a more robust manner.
Neither of these scenarios can really directly benefit from anything other
than conforming functionality against verified implementations. So, for
example, speed increases to Python implementations don't really contribute
to work of this type, and as well, the obfuscation that comes from
optimizations can decrease understanding. So from this perspective, the
documentation is the most important part (and plays to Python's original
strengths as "executable pseudocode").
The most helpful information tends to be minimal working examples, that
have few dependencies, and are annotated so that translation of knowledge
to functionality is as straightforward as possible. So a Rosetta Code-style
suite of runnable examples is valuable, or other multi-lingual
presentations that effectively impart knowledge by abstracting away from
language particulars, or expose relationships between seemingly-different
structures *across* languages or environments. Working output often does
not have the luxury of being contained in a single language, and may very
well consist of a bunch of GUI programs with different data formats hooked
together, with an algorithm built out of available primitives that happen
to be available partly in one, partly in another. So the "understanding"
part (which is listed in the diagram of the link as the theoretical
knowledge that's most useful when studying) winds up being far more useful
in a wide variety of production use cases, where the goal might be closer
to embedding scientific understanding into an already running system.
On Sat, Mar 16, 2019 at 9:12 AM Stefanie Lück
I am very interested in this question and discussion as well. Maybe we should start a separate thread.
Cheers Stefanie
Am Sa., 16. März 2019, 14:06 hat Yash Sharma
geschrieben: Hey Juan, Thanks for a descriptive reply! I needed to ask you more points regarding the API design that you followed. Can you share some ideas as to how did you go about designing your API? _______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Phone 917 375 8730 Email david@davidsarma.org Web http://www.davidsarma.org
participants (7)
-
David Sarma
-
Gregory Lee
-
Juan Nunez-Iglesias
-
Lars Grueter
-
Mina
-
Stefanie Lück
-
Yash Sharma