Talk:Point location

message: The wikipedia article gives a definition: "problem is, given a partition of the space into disjoint regions, to determine the region where a query point lies." It is followed by an example which may be described as the "mouse click problem". (find which GUI element is clicked by mouse).
There is a significant difference between the real-world problem ("mouse click problem", MCP) and the mathematical model ("point location in spatial subdivision",  PLP) which indeed, may be used to solve the MCP (but in a very cumbersome way, I may say).
My point is that I see no ref stating that MCP may be solved with the help of PLP. The footnote added does not state MLP as a case of PLP, nor the suggested solution uses PLP as an underlying model. (The article summary does say "Algorithms for point location in the visible scene are also given", but this is a vague statement;  the exact def is in the article's Section 8 and it does not involve any "partition of the space into disjoint regions".) - Altenmann >talk 03:37, 14 August 2023 (UTC)
replies: text: P.S. I did  suggest rewriting the lede to make the problem definition more generic and involve a general-purpose identification of an object by a point, and the example in question would be good, but in the dust and smoke it went unnoticed. An interesting  real-life problem would be in gaming: the user clicks the mouse, and the gaming engine traces the ray along the line of sight to locate the object clicked. - Altenmann >talk 03:49, 14 August 2023 (UTC)
replies: text: Ray tracing really is a different problem, unless you want to formulate it as a messy problem in a five-dimensional Euclidean space of 3d rays, subdivided into 5d cells within which all rays go to the same obstacle. That would require sourcing and even if sources could be found it would be very technical. Also, you are still missing the point. The mouse click problem can be formulated as a special case of the problem of point location in a planar subdivision. It is not the most general formulation of the problem (but neither are the versions restricting the problem to monotone subdivisions or triangulations) and it is not spatial. You can make a spatial problem by using another a dimension to represent the prioritization of rectangles, but then you have a formulation that is not in terms of point location. You can also formulate the mouse click problem as a range minimization problem where the elements are rectangles, the ranges are the subsets of rectangles that contain a specific mouse click point, and the minimized values represent the prioritization; again, this is an equivalent problem but a different formulation (that is also not point location). —David Eppstein (talk) 06:03, 14 August 2023 (UTC)
replies: text: "You can also formulate the mouse click problem as..." - almost correct, with the exception that a more precise statement would be "You can also model the mouse click problem as...". Mouse-click problem is a "real world problem" and "range minimization" or smth. else is a mathematical model. To solve the mouse click problem modeling it as an instance of point location in a spatial subdivision is even worse than the brute-force method of simply checking the point against all GUI rectangles (marked with their "height" in the GUI stack): surely you are aware that an overlay of N rectangles may generate a subdivision of size O(N^2).  - Altenmann >talk 07:03, 14 August 2023 (UTC)
replies: text: Its value as an example in the lead of this article is unrelated to its value as an implementation technique. Formulating the problem in this way is not the same as solving it. But also, if you had a subdivision that was changing infrequently and many point locations to perform, O(n^2) could be an acceptable price to pay in preprocessing to make the queries fast. The bigger problem with the windowing example is that the number of windows is likely small enough and the real-time response time needed slow enough that simply sequentially searching the ordered list of windows for the first one to contain the click would work well enough. —David Eppstein (talk) 07:13, 14 August 2023 (UTC)

text: I don't see anything worthy of response to in this, other than to point out that I find the form of address you are using to be rude and insulting. Please do not do that. —David Eppstein (talk) 00:14, 15 August 2023 (UTC)
replies: text: Please provide the preferred form of addressing to you.  - Altenmann >talk 00:22, 15 August 2023 (UTC)
replies: text: My full user name is always acceptable, because it is my user name. If you wish to refer to me by name rather than user name, then in the context of my professional expertise, which this is, "Dr. Eppstein" or "Prof. Eppstein" are both acceptable. (Mr. Eppstein is fine in non-technical contexts, but only in those contexts.) If you are from a Germanic-speaking nation that does this and want to be super formal, I won't complain if you use "Prof. Dr. Eppstein", but I would be skeptical of anyone else using that. If you were on friendly terms with me, which after dragging me to the drama boards you are not, I would instead suggest "David". One Wikipedia editor, a friend from long ago, gets to use a nickname; he knows who he is. —David Eppstein (talk) 06:19, 15 August 2023 (UTC)
thread_title: Summary of disagreement

message: :The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.
The result of the move request was: No consensus.  EdJohnston (talk) 20:10, 6 September 2023 (UTC)
replies: text: Point location →  – confusingly ambiguous title: even search in Wikipedia gives more hits for the meaning "position, coordinates,  of a point", not to say about the acupuncture meaning :-) - Altenmann >talk 01:52, 14 August 2023 (UTC)

text: Oppose. There is no other article from which this needs disambiguation, so the argument that this is needed as WP:NATDIS does not work. This article is not merely about the problem of point location (that is, the specification of what the input-output behavior of a point location method should be) but also about its solutions, applications, etc. So tacking on "problem" to the article title is not merely pointless noise; it makes the title more specific in a way that it should not be. Additionally, it fails WP:COMMONNAME: searching Google Scholar for intitle:"point location" finds only one out of the first ten that uses "point location problem", and overall only 64 out of 921. It is used, but not frequently. (Before someone brings up WP:WAX arguments, the same thing applies to many of our other computer science articles on "X problem": in many cases, the "problem" part of the title is redundant or worse and should be removed.) —David Eppstein (talk) 03:08, 14 August 2023 (UTC)
replies: text:  I didnt request disambiguation, merely for a tighter term. As for the word "problem" in the title, we have plenty of " problem" pages (only recently I happened to edit "einstein problem") and it is only natural to talk in them  about their solutions, extensions, and what's not. I can agree that in many cases the word "problem" is redundant, but I didn't think this is the case here, hence the move proposal. - Altenmann >talk 03:40, 14 August 2023 (UTC)
replies: text: If you didn't request disambiguation, what is your "confusingly ambiguous title" supposed to mean? As for "as for the word "problem" in the title", that is exactly the sort of WP:WAX argument that I was hoping to preempt. —David Eppstein (talk) 05:58, 14 August 2023 (UTC)

text: Note: WikiProject Computer science has been notified of this discussion. ModernDayTrilobite (talk • contribs) 16:06, 21 August 2023 (UTC)
thread_title:  Requested move 14 August 2023