Metric concepts

[dcoeurjo]

Simplification of Metric concepts:

• CLocalPremetric removed (does not make sense, even for path based norms)
• Code cleanup in models of CMetric (to remove CLocalMetric concept requirements, the local method).

[JacquesOlivierLachaud]

It is not exactly related, but I remember when using metrics that I miss a "squaredLength" method to speed up things. It is possible to add this (like in CGAL) in Metric ?

[dcoeurjo]

There is this sort of things in DistanceTransformation (to get error free DT values) but I agree that it could be useful in CMetric. How would you name this method ?

• exactDistance
• exactDistanceValue
• exactRepresentation
  ?

(in all cases, the exactmeans exact w.r.t. a given model of CEucldienRing)

[dcoeurjo]

@JacquesOlivierLachaud, any advice for the "exact..." function name ?

[JacquesOlivierLachaud]

In fact, I was more proposing to add another method that returns the squared length ("squaredLength" ?). So the exactness is one aspect, the computation speed is another.
I am of course not against an "exact*" method. Certainly, there must be some specific type here.

[dcoeurjo]

ok but 'squared' won't make sense for l_p nor path based metrics.

[JacquesOlivierLachaud]

You are right. However, 99% of distance computation are with Euclidean distance (or power metric with also squares). Therefore, such a method induces a lot of computation savings at many places (for instance in DistanceBreadthFirstVisitor). So two options:

• either specialize EuclideanDistance with squaredLength
• or give a "pLength" or "unnormalizeLength" method.

[dcoeurjo]

For l_p models, such function already exists under the name exactDistanceRepresentation. At this point, it is not required in the concept. My comment was: should we add this to CMetric (why not) ? how the function should be named ?

[dcoeurjo]

( exactDistanceRepresentation is private at this point for l_p stuff)

[dcoeurjo]

Working on it.. I'll reopen it when ready