coordinates/point-at: bug in core list?

[NSoiffer]

The core list has (in the Geometry section) point-at. It is listed as having three args and the example is "P(1,2)". This seems wrong.

The general notion of a point could be in 2 or 3 dimensional space for core, and for higher math, it can take an arbitrary number of dimensions (>0?, >1?). Maybe in core physics, space-time already takes it to 4 dimensions.

I suggest we remove point-at and change it to coordinate with example speech the "point at $1, $2" and an alternative speech of point with coordinates $1 and $2 since it gives a reason for using the name coordinate. I'm also ok if people want to use point as the concept name.

[davidcarlisle]

yes I think the intention was this was the definition of P = $1 as the point at coordinates ($2,$3) but that compound definition doesn't seem core really. So coordinate of arity 2 and default rendering ($1,$2) ?

This reminds me that it might be useful to add a mathml example column as in the open list where the display highlights which of the displayed symbols is which intent argument.

[dginev]

This seems wrong.

As David mentions, this is not a bug. The use was originally fished out from some 6-th grade materials of Khan Academy. I have a video archived from back then.

There is additional diversity of notation, nicely documented in these materials:

For points, there is some variation in notation. In schools, $P(a|b)$ or $P(a,b)$ is often written instead of $P=(a;b)$

Having said that, I agree the point-at name breaks our naming convention. So it could be refactored. If we use point as suggested by Neil, then also using the newer defined-as concept in Core, a composed expression could be defined-as(P,point(1,2))

Here is the same idea, but distributed along the tree:

<mrow intent="defined-as($var,$definiens)">
  <mi arg="var">P</mi>
  <mrow arg="definiens" intent="point($x-axis,$y-axis)">
    <mo>(</mo>
    <mn arg="x-axis">1</mn>
    <mo>,</mo>
    <mn arg="y-axis">2</mn>
    <mo>)</mo>
  </mrow>
</mrow>

[dginev]

A note on point vs coordinate - we have another aliasing problem, as they can be used interchangeably, based on context. The materials I mentioned above say as much directly:

Since points are uniquely determined by their coordinates, we will not distinguish between a point P and its coordinates (a;b) in the following but we will consider both as the same object.

A human reader would be expected to produce both point and coordinate readings for (a;b), and I suspect a single synthetic readout will end up artificial in half of the uses. At least in Open I would expect implementers to support both - but how they do so is non-standard for now.

[davidfarmer]

We need "coordinate" so we can disambiguate (a,b).

Whether/how to support the point-at, I see as a different question.

[davidcarlisle]

@davidfarmer I agree. We have polar-coordinate but not cartesian-coordinate (or point) in core, we should add something. I think we should move this arity three named point version to open, it does not feel like a core construct to me.

[brucemiller]

The difference between "point" and "coordinate" seems to me to be more in the eye (or ear) of the beholder, and how you intend to use it, rather than fundamentally different objects. While it seems clear that AT would want the ability to distinguish, it's not clear to me how that should be conveyed from the author to the AT.

Different coordinate systems (whether you're thinking of points or coordinates) is certainly an unwelcome complication. Polar and Cartesian are obviously useful in K12. Open would presumably want to address parabolic, etc, etc. I'd wish for some property magic to save us from having to introduce whole menageries of new symbols... but again, I don't quite see how to do it.

And finally, if "something($x,$y)" finds its way into Core, I'd expect that "something($x,$y,$z)" is also K12 and wouldn't be far behind.