Hi Michael, Am 16.07.2011 um 10:04 schrieb Michael SCHINDLER: > This epsilon is used only in make_choices, to throw away too short > elements, and to determine the orientation of a path. It is not, > however, used in solve_choices. I checked all positions where numbers > are compared to unity, and all were continuous functions where a small > numerical error will result in a negligible change of the control > points of curves. Your example in the graph is obviously > discontinuous. > > I did a checkin to keep track of these changes only, and then proceed > with eliminating the mp_* helper functions which do only a > multiplication or a division, ... > These are relicts of the integer numerics in metapost (as were the > comparisons with unity).
Great. I've seen that you could remove quite some code due your analysis. While we did not yet adjust the path.path constructor, I'm kind of uncertain regarding the epsilon. At the moment you introduced an epsilon to the metapost.path.path constructor. I know that this is exactly what I suggested. But as I see the current situation, I have still some open questions. I don't think we need to change anything right now, but we should keep an eye to the overall picture and the situation is somehow unclear to me at present. First of all I was surprised that you introduced a module-global epsilon and a set function. I fully understand that you decided to just mimic the normpath solution. But why do we have all this? It is due to the fact, that path.path instances do not have an epsilon attached. However, we have quite some methods in the path which require an epsilon as they rely on numerical approximations being available for normpath instances. Normpath instances (or to be more accurate normsubpath instances) do have an epsilon attached. You can have different normsubpaths using different precisions without touching the global epsilon in the normpath module at all. I don't want to comment on that, I just want to remind ourself, that this is the current situation. I don't know whether this is right or wrong. But I was expecting to have a signature metapost.path.path(items, epsilon=1e-5) and no global epsilon in the metapost.path module. The reason is that we have a single point in the constructor, where this epsilon is used. I think we should to try to minimize global settings. As for now we did not change the path.path constructor. We could introduce an epsilon here too, which would be used when the path is converted to a normpath. In that sense it would be similar to the epsilon attached to a normsubpath, it is just the attached precision to be used when doing computations for the path. (If we start to attach an epsilon to path.path, we may want to do so for path.normpath too instead of attaching it to path.normsubpath.) In the end we might want to remove the module global epsilon from the normpath module completely. This is one way to go. I don't know whether it is the right direction, but it looks attractive to me right now. Another direction I can think of would be to include the numerical precision epsilon (always measured in postscript points) in the units module. Then it could be a single global setting to be used by the path, the normpath, the normsubpath and probably other modules. (Using the size of the graph I could even calculate a dimensionless epsilon in graph coordinates out of this epsilon.) While I like this general idea, I'm not confident whether this is a good solution. We should bear in mind that there is this idea to introduce a second stability measure to normpaths to remove cusps. I consider this a major issue/improvement, as it would allow us to get rid of the "invalid" return values in some of the normsubpathitems methods. Right now I'm puzzled. 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
------------------------------------------------------------------------------ Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
_______________________________________________ PyX-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pyx-devel
