Nearest outputs squared distances for equidistant exact inputs across 1D, irrational, and vector coordinates

Questions
, ,
1

Hello, I am trying to use the DiscreteHausdorffDistance resource function and noticed I was getting some strange results. After some experimentation, it appears to be a result of some weird behavior that the Nearest function has when multiple elements have the same fractional distance from the target. To be precise, it squares the distances for no apparent reason. See the image for an example, as well as demonstrating that it does not happen with integer distances.

strangeNearestBehavior
strangeNearestBehavior457Ă—349 5.46 KB

Am I missing something? Is this intended behavior? If so, how do I disable it? If not, how do I let someone in the technical staff know about it to fix it?

2

The problem disappears with floating point input:

In[11]:= Nearest[{1/4., 3/4.} -> "Distance", 1/2]

Out[11]= {0.25, 0.25}

Also the floating point distance in case of integer input is strange.

3

Alternatively, specifying infinite WorkingPrecision removes the bug:

Nearest[{1/4,3/4}->"Distance",1/2,WorkingPrecision->Infinity]

(*{1/4,1/4}*)

This does seem like a bug to me as well: I don’t think this is intended behavior for Nearest

4

Further testing… Issue is not limited to simple rational numbers. Affects all exact symbolic ties, including irrationals and multidimensional coordinates.

  1. Irrationals are affected:
Nearest[{Pi/4, 3 Pi/4} -> "Distance", Pi/2]
(* Returns {Pi^2/16, Pi^2/16} *)
  1. Higher dimensions are affected:
Nearest[{{1/4, 1/4}, {3/4, 3/4}} -> "Distance", {1/2, 1/2}]
(* Returns {1/8, 1/8} (squared) instead of true distance Sqrt[2]/4 *)

  1. DistanceFunction does not bypass it: Explicitly setting DistanceFunction -> EuclideanDistance still returns the squared exact distances.

  2. Ties are the trigger: Breaking the exact tie slightly successfully returns the correct, non-squared distance.

Nearest[{1/4, 3/4 + 1/100} -> "Distance", 1/2]
(* Returns {1/4} *)

Seems like an issue in the internal spatial indexing or tie-breaking logic specifically when Nearest handles perfectly equidistant exact inputs.

5

No, it is not the intended behavior. I filed a bug report for this.