Hi Michael, Am 19.07.2011 um 23:58 schrieb Michael SCHINDLER: > In principle I agree on minimising global settings. For the epsilon, > however, I find it somehow logical to have two possibilities to > control the epsilon of a given operation: Either by explicitly setting > one, or by changing the default parameter (the module-global one). > What is the main reason to change the epsilon? I would say if someone > has large (really huge) plots. One would then rather change the > overall epsilon instead of each operation.
When this is really true, that there are situations where you want to change the epsilon all over the place, you are right, that we need to be able to adjust it at a single place globally. Just a historical remark: This was also the reason why we introduced the unit module with its set function. Even though such global settings are a bad design, we came to the final conclusion, that we would need such a global setting. The reason is that simple, that you need it all over the place. Whenever you create a path or just a path element, you need to specify the scale. And you want to have those instance available without attaching it to a canvas (yet). Hence it is no solution to postpone the unit-resolving to the canvas/page/document/writer/whatever. You need to have it available everywhere and we decided to have a global setting for that. Global settings may seem to be a bad design in general, but for a end-user-friendly graphics library, you probably just want to have those global settings. If we need such a small epsilon (small in terms of postscript points) at many different situations, it is probably feasible to move it to the unit module. Please note that epsilon is always measured in postscript points. It is used for *_pt-methods, -variables, and -attributes, where everything has already been converted to postscript points. For large plots epsilon might be too small (more precise than necessary). But the real problem arises when you work with tiny items as then the (relative) error becomes big. I don't know whether this has any practical relevance. And this is the source of my uncertainty whether we really need to be able to adjust epsilon globally. (Note that there is no global epsilon in the graph. Sure we have a universal scale, the graph coordinates, for that case. But still, as the graph can be scaled, the real size of epsilon could be quite different. But the comparison is wrong: the epsilon in the graph is used to prevent numerical artefacts due to floating point input values. As long as the threshold is triggered as intended, the value of epsilon is not important at all. It does not define a numerical precision.) > For me, the epsilon is not a property of path.path. We should add it > rather to the conversion path.path.normpath(epsilon=...) and to all > the functions calling such a conversion, as I mentioned above. As far as I know we have that already. My idea was that if we have an epsilon attached to a normpath instance, we could do so for the path as well. And as we are discussing the deprecation of path.path(pathitem, pathitem, ...) in favor of path.path([pathitem, pathitem, ...]) we can now add the epsilon the this constructor too. >> [...] > [...] > I somehow miss your point, sorry. As far as I remember, the > _minrelspeed already implements this idea. We had a long discussion > whether it is really and independent parameter and not linked to the > epsilon as a measure of a curvature radius. The invalid is absolutely > necessary because there are some ill-defined geometrical situations. No, _minrelspeed is the wrong solution as it does not "repair" the normpath in the first place. You can remove those instabilities from the normsubpathitems completely, if you remove cusps and other "speed"-related problems when constructing the normpath. Let me implement it. It will result in a huge simplification for a lot of code working on normpaths. Best, André -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) [email protected], http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________ PyX-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pyx-devel
