I somehow feel like I have to explain myself (maybe because Mateusz is
not coming to my rescue in defending his design). The following
statements are true:
- Had I written the polys module, there would be no C-like "functional"
interfaces. There would be very few global functions (all in objects),
and they surely wouldn't have awkward prefixes like sdp_...
- While I do know a lot about writing efficient C and C++ code, I know
basically nothing about what python code is efficient.
- In particular, for highly performance-sensitive code, this is why I
suggested sticking to whatever design there was, *made up by someone
who most likely knows better how to write highly-efficient python
code that I do*.
On 30.03.2012 21:51, Aaron Meurer wrote:
On Fri, Mar 30, 2012 at 2:22 PM, Ronan Lamy<[email protected]> wrote:
Le vendredi 30 mars 2012 à 22:15 +0300, Sergiu Ivanov a écrit :
Hello,
I will answer to a comment by Tom here, partly because it's more
comfortable for me to write E-mails. Should anyone feel this switch
is wrong, we can always turn back to discussing on Melange.
Tom Bachmann March 30, 2012, 9:37 a.m.
Regarding Object-Oriented redesign of polys code: please consider that
Mateusz (the main author of everything in polys/) has put a lot of
thought and work into the code. Note also that for many applications in
mind, the performance of Groebner basis algorithms is highly sensitive.
Thus at least the core functionality should be implemented in as raw a
form as possible. This also facilitates later potential
re-implementation in e.g. C. In any case, Mateusz is the most likely
mentor for this project, so it's him you have to get on bord. Note also
that in domains/, there are already classes for rings, polynomialrings
etc (although they implement functionality somewhat different from what
you envision).
Writing C in Python gives you the speed of Python and the
maintainability of C. If you want fast Pythonic code, you need to use
Cython or PyPy (well, ATM, PyPy is crap at dealing with big integers,
but hopefully, one day...). They both target idiomatic Python code, so
code using classes in a pythonic way, without over-engineering, is
actually likely to be faster than a mass of global functions with many
extraneous arguments.
Yes, I absolutely don't doubt that a lot of thought has been put into
the code I was looking at. However, the polys module is not
absolutely devoid of classes, therefore I think that my additions
aren't that unusual :-)
Nevertheless, the fact that I try to use the object-oriented approach
in my implementation in no way hinders the eventual exclusion of
classes. The classes I am suggesting are only going to include a
couple methods; it should be very easy to take these methods out and
turn them into simple functions, thus forgetting about classes.
That's the job of a compiler. You shouldn't worry about it at all.
Regarding object-oriented structures for algebraic objects: please
note that various people in various GSOC projects, and also without
GSOC, seem to be thinking about implementing this sort of thing. In
fact I myself have been toying with the idea of implementing a
commutative algebra / algebraic geometry module that provides various
of the classes. What I am trying to say is: implementation and
optimization of the groebner-walk algorithm is most likely the most
importand, and hardest, part of your project, and it would be a great
addition to sympy. It seems less important, and more messy, to get the
"meta-infrastructure" set up and past tons of discussion on the list
(this is not to discourage you, just a heads up...).
Thank you for pointing out the classes in domains/ ! I haven't
managed to come over them. As you have noted, these classes indeed
focus on something different from what I envision to achieve with the
classes I suggest. I will make an explicit point (and I will also
modify the proposal accordingly) that I in no way plan to fully
implement rings and polynomial rings as algebraic structures. My goal
is making my code future-compatible with the eventual introduction of
these algebraic structures. Frankly speaking, I won't be surprised if
the classes which I will (maybe) implement will eventually be thrown
away and substituted with something else. However, migrating the
Groebner walk to this "something" else should be much easier because
of the foundations I am going to lay in this project.
As far as I can tell, "domains" don't represent algebraic structures but
are metadata for concrete types. So I agree with your assessment.
From what I remember, there are logical base classes like Ring and
Field, of which the domains are subclasses.
On the other hand, as I say in the proposal, the classes Ring, Ideal,
etc. will only have the most basic of the functionality; I can't even
consider them to be skeletons of the corresponding algebraic
structures. This is why I don't expect much trouble with getting such
changes merged, especially if I have discussed the modifications
before.
More technicalities: "high-level" classes should apparently go into
"...tools.py" files in polys/. Look at e.g. polytools.py --- it has a
GroebnerBasis class!
Well, that's an awkward and evidently confusing convention. Feel free to
reorganise the code more logically.
I agree. We should reorganize the polys so that the three layers are
clearer, probably by using three subdirectories.
Aaron Meurer
Oh, indeed! Thank you so much! I have seen it appear across the
code, but I couldn't trace the name to the origins and eventually
forgot about it :-(
I will modify my proposal accordingly.
[If the above sounded rather critical: let me stress that you seem to have put a lot of
work and thought into this, and the proposal is very solid. All of my comments should be
considered as "minor".]
Thank you very much for your feedback! And thank you for worrying for
the possibility of interpreting your comments as critical :-)
Sergiu
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
