<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 17, 2014 at 3:06 AM, Åsmund Tokheim <span dir="ltr"><<a href="mailto:asmundto@gmail.com" target="_blank">asmundto@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Sorry, but I fail to see such case - if point is close, it will be also close on at least one of 3 planes (x,y), (x,z), (y,z) <br>
</div></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><div class=""><div></div>

</div><div>Let's say that your table has the points (1, 1, 1000), (1, 2000, 1), (2000,1,1) and (2, 2, 2). Unless I'm completely mistaken, a 1. nearest neighbour search from (0, 0, 0) using your algorithm would return (1, 1, 1000) as the nearest neighbour. The correct point should however be (2, 2, 2), which is somewhat close in all planes, but not very close in any plane.</div>
</div></div></div></div></blockquote><div><br></div>Hmm ... I see now the problem - I was working under assumption that correct point would be "overwritten" by bad one. But in this case - on every mapping (xy, xz, yz) - the overwrite happens by different point. Good catch, thanks.<br>
<br>> My only concern is that the <-> operator won't use the index when you apply an arbitrary function like <span style="font-family:arial,sans-serif;font-size:13px">translate_xz to its input.<br><br></span></div>
<div class="gmail_quote"><span style="font-family:arial,sans-serif;font-size:13px">It will if I'll index the function, and not the point.<br><br></span></div><div class="gmail_quote"><span style="font-family:arial,sans-serif;font-size:13px">Regards,<br>
<br>depesz<br></span></div></div></div>