This bugzilla service is closed. All entries have been migrated to

Bug 301

Summary: ParametrizedLine origin assumptions affect isApprox
Product: Eigen Reporter: Andy Somerville <andy.somerville>
Component: GeometryAssignee: Nobody <eigen.nobody>
Status: NEW ---    
Severity: Unknown CC: gael.guennebaud, hauke.heibel, jacob.benoit.1
Priority: ---    
Version: 3.0   
Hardware: All   
OS: All   

Description Andy Somerville 2011-06-22 23:58:07 UTC
ParametrizedLine operates under the assumption that origins passed in are standardized. If developers create two lines that are mathematically identical, but are created with different origins, functions such as isApprox will fail unexpectedly.

There's a chance I'm misunderstanding something, but it seems that this is a bug.

There are two solutions I can think of:

* As in the warning about the direction being normalized, we could warn that the origin is assumed to be a particular dim - 1 intercept, 
* We could calculate some standardized origin internally though this might cause lowered performance for those creating large numbers of ParametrizedLines.
Comment 1 Gael Guennebaud 2011-06-23 09:53:43 UTC
Note that this is a *parametrized* line, so the origin is very important and unique. That said, we could clarify that in the class documentation and in the doc of isApprox. We could even imagine adding another "is approx" like function neglecting the parametrization, and/or add a function to transform it to a canonical form...
Comment 2 Andy Somerville 2011-06-24 00:41:45 UTC
> Note that this is a *parametrized* line, so the origin is very important and

I wasn't aware of the distinction. (It's been a while since linear algebra)

Does this perhaps argue for a separate class that is just "Line" or "CannonicalLine" which is not parametrized?
Comment 3 Andy Somerville 2011-07-04 20:03:03 UTC
It took me a while to arrive at the idea that for even slightly non parallel lines, the concept of approximately "same" is nonsensical in the sense that any two non parallel lines will intersect *somewhere* and in that neighborhood they will seem approximately the same. Sorry, part of making an awesome, easy to use matrix lib is putting up us less mathematically focused people : )

Users can of course do their own direction comparison, but IMO it might be nice to encapsulate this in a "isApproxParallel" which would simply compare the directions + negative directions with some epsilon, which would be cleaner than people doing it by hand all over the place.  Combined with the distance function that's already there, I think this would be a helpful addition for people doing lots of line comparison.

I'll write up a patch tomorrow in case the Eigen team agrees.
Comment 4 Nobody 2019-12-04 10:54:23 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: