ezag / pyeuclid Goto Github PK

Hi,
Thanks for pyeuclid. Has anyone done any benchmarking on pyeuclid vs euclid ?
While I assume it is faster for many operations, but maybe after only a certain amount - it would definitely be interesting to see.

Cheers
S

I could download pyeculid with sudo pip3 install euclid.
But when importing euclid, we get a SyntaxError on line 137.
Of course, this does not happen if I import it with Python 2.x.
Is the package intended at all to work on Python 3.x?
If so, should we consider fixing the syntax?

Edit: This seems to be a name clash with a different Python package, since the line 137 that I get in the SyntaxError is raise AttributeError, name, which is not the same as line 137 in euclid.py here.

I suggest adding a named parameter max_determinent_for_degenerate with default value 0.001 to both these functions to preserve the current functionality.

In the version currently available from PyPI:

euclid.py: line 137
raise AttributeError, name is an invalid way to raise an exception in Python 3. Should be raise AttributeError(name) as it is in the current repo version. Haven't checked for other occurrences of this, but this is the first that comes up when trying to import.

Can the PyPI version be refreshed?

This is python code snippet that shows the problem:

intersection = segment.connect(pointLCS).intersect(segment)

Sometimes it returns None, which seems suspect.

In plain language, given any point and any first segment, a second segment that connects the point to the first segment should intersect the first segment.

I haven't really analyzed it yet. It could be that it fails when the point is colinear with the first segment. Or it could be a faulty set interpretation of segments: the end points of segments are not in the segment, i.e. the set of points in a segment is an open set. Or when the connecting segment has magnitude 0 i.e. a point, that causes problems? Or it may be when the first segment is vertical? Or maybe my understanding of geometry is incorrect: a connecting segment does not intersect?

I have been reading "Computational Geometry In C" by O'Rourke. He discusses the extreme difficulty of getting intersect() correct when using point slope algorithms, which pyeuclid does. There are many edge cases (such as vertical lines.) So I am considering the alternative which he proposes, using "signed area between three points."

This shows the test cases for pyeuclid are insufficient. But I can't find a complete set of test cases (axioms, postulates?) for geometry on the net. Seems like that would be useful.

I already have branched, just not made it public. The OO design of pyeuclid is strange, and one giant source code file is hard to read. The emphasis seems to be on performance, at the cost of correctness. I just need the geometrical objects, and use transformations from elsewhere (Qt.)

I pickled using highest protocol, which supposedly supports slots. But unpickling failed with infinite recursion. Then I commented out the metaclass and slots stuff in pyeuclid. Then it seemed to work.

Please note: lightly tested, I could be wrong. Possibly in my other hacking at PyEuclid I broke something.

Hi Eugen - It looks like your fork of PyEuclid is the most developed and complete. It looks like you got it all Python3 compatible and ready to be released as the next version on PyPI, but I don't see it there. Would you be willing to submit it? If you don't want to mess with it, I could talk to the previous submitters and take care of it.

FYI, here's how the original PyPI submission went down. https://code.google.com/p/pyeuclid/issues/detail?id=14

Cheers,
Evan

I've stumbled upon a bug in the otherwise-wonderful Python euclid library. It initially occurred with the Arch Linux package python-euclid3, and I've just reproduced it with the latest Git-cloned version from here.

Here's the problem reduced to a few lines in the interpreter. I'm not sure if there's anything special about the values 114,96 etc. -- when I tried it with simpler lines in the same directions, the problem went away.

>>> from pyeuclid.euclid import *
>>> seg = LineSegment2(Point2(114,96), Point2(117,93))
>>> vec = Vector2(0.71, -0.71)
>>> vec.angle(seg.v)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/chris/projects/vplotter/hpgl_to_vplot/pyeuclid/euclid.py", line 306, in angle
    return math.acos(self.dot(other) / (self.magnitude()*other.magnitude()))
ValueError: math domain error
>>>
>>> seg = LineSegment2(Point2(0,0), Point2(3,-3))
>>> vec = Vector2(1,-1)
>>> vec.angle(seg.v)
0.0

I'm using Python 3.7.2 on up-to-date 64-bit Arch Linux.

How do I convert the quaternion to a rotation vector?

This is not really a bug report nor a pull request, but in the lack of a mailing list for pyeuclid, I wanted to announce that I started a rewrite of euclid that uses numpy for all linear algebra, instead of doing the calculations in pure python. The trigger was that I was once again getting the wrong answer because of the arbitrary clipping of the inverse() function (based on the size of the determinant value). I named this new project npeuclid. I'm not sure whether to keep npeuclid as a separate project, or whether it should be merged in to euclid. I'm looking forward to both comments and contributions. One of the freedoms, and changes w.r.t. euclid, that I chose was to make the transformations stateless, so that a transformation such as t.rotate() returns a newly created transformation, but does not modify t. This is more "functional" like, and more similar to e.g. how pandas works.

Meanwhile I have only done 2D geometry, but adding 3D and quaternion math, should be quite trivial.

See: https://github.com/dov/npeuclid

In pyeuclid: isinstance(foopoint, Vector2) returns True. Also you can add points. This is non-intuitive, and counter to many books on graphics programming.

Also, in many graphics programs you have different coordinate systems (such as world, view, local, user, device, scene,... there are many different names for them.) I find it helpful to explicitly identify the coordinate system (also known as the frame) of a point or vector, and support it in the classes. A sort of type safety: two points/vector instances in different frames are not the same type. I think you could implement frame safety without requiring modifications to the API, and I am not concerned about any performance hit.

Are you interested in such modifications?

Also, there are other outstanding issues on the original pyeuclid. Do you know whether the original is still being maintained? (Evidently not or you wouldn't have forked it?)