## undefined

This symbol is used to specify that a symbol can not be defined for some reason.

For example, this is the case of a point that belongs to the intersection of two circles with empty intersection. Note that some systems could avoid the particular situation of this example providing points over the complexes.

## Examples

## Further discussion

proposal Submitted by Santiago.Egido on Thu, 07/16/2009 - 13:53. This is not a decision made, but a proposal that should be approved/modified/rejected in a telcon. Immediate feedback is encouraged, of course.Let me start by distinguishing between “undefined value”, a DGS dependent value, such as a null pointer or an empty list, and “undefined behaviour”, when we allow DGS’s to do several things. Looks like in the website there has been some confusion, because both “undefineds” tend to appear together; I’ll try to be clear.

The discussion that follows is inspired in the intersection of two lines; if can be a point, but also nothing (parallel lines), or a whole line (coincident lines). How are we to manage the case when we try to store the “atypical values” of an intersection into a point? The conclusions arrived to in this discussion will apply to other constraints.

Besides; occasionally a construction will have to indicate that the “initial value” of an element is undefined. Think of a construction that in its initial state has two parallel lines that can be moved and their intersection point will be used somewhere. We have better things to worry about, granted, but it is in fact the first element in http://intern.inter2geo.eu/node/366.

FIRST QUESTION

I don’t think that undefined, or undefined_value, should be an element, because something like <undefined_value id=”P”></undefined_value> does not indicate that P is a point.

I think it would better be a value, and so, in the elements part, to indicate that P is an undefined point, we could have this:

<point id=”P”> <undefined_value></undefined_value> </point>

instead of the usual XML structure for points with defined coordinates:

<point id="P"> <homogeneous_coordinates> <double>… <homogeneous_coordinates> </point> I know that this is ugly, and will force implementors to always considers two cases whenever they read an element, but compatibility with OpenMath forces us to discard solutions such as <point id=”P” undefined=”true”>. I hope somebody provides an alternative solution.

SECOND QUESTION

This is a proposal to specify the behaviour of the constraint point_intersection_of_two_lines .

If the intersection exists and is a point, return it.

If the two lines are parallel and there is no “finite intersection”, the behaviour of this function is DGS dependent:

- Those DGS that can handle projective geometry are free to return a “point in the infinite”
- Other DGS will return the undefined value

- return the undefined value
- return the intersection line

NaN solution, Yves Submitted by Santiago.Egido on Fri, 07/17/2009 - 09:11. Undefined can be: 1) if reading in complex (which GeoGebra does not understand)

<point id="P"> <homogeneous_coordinates> <double>NaN</double> <double>NaN</double> <double>NaN</double> </homogeneous_coordinates> </point>

Comment by Ulli Submitted by Santiago.Egido on Mon, 07/20/2009 - 08:48. Hm… Wouldn’t it make sense to just don’t specify values if you don’t know them? Just imagine you are loading a construction from a “non-projective” DGS into a projective one. Then the non-projective should not tell the other that these are undefined, but just should not say anything. It’s like Schopenhauer: If you don’t know what to say, just shut up.

;-)

The NaN values and so on might occur sometimes, in particular if a system really knows what it does.