Interoperable interactive geometry for Europe
I forgot my login data
Register


Report a bug


Fan club

Quick Intro Videos
click to start movie
Create A Simple
GeoGebra Resource (25Mb)
click to start movie
Filing a review
click to start movie
Find a Resource

SPONSORS
This platform is brought to you by the intergeo project, funded under the eContent Plus programme of the European commission and by partners

locus

Definition: Given a geometric diagram with an object P (usually a point) whose position depends on the position of a second object Q (usually another point) that has a one-dimensional degree of freedom (for example by restricting it to another object s, which is a circle, line,…), the locus defined by the tracer point P and the mover point Q is the geometric set traced by P as Q runs over all its possible positions on s.

That is:

Locus = Construction + mover object + tracer object

where the mover object belong to a 1-dimensional family of objects (points in a line, pencil of lines, …).

Loci are standard element in DGS, but come in very many flavors. Implementations vary a lot. For some DGS, a locus is just a “cloud of points”, without any further structure. Other DGS can identify some simple cases (for example, when the locus is a conic), or even treat the locus as any object, that is, the locus can participate in another construction. Hence, a locus is not necessarily a final object.

This should be in the constraints CD. Also a Locus in the elements CD has to exist, as the resulting mathematical object could be almost anything (like an algebraic curve).

Initial coordinates for the Locus element could be a finite set of coordinates of the tracer object.

See also: locus_defined_by_point_on_line, locus_defined_by_point_on_line_segment, locus_defined_by_point_on_circle, locus_defined_by_point_on_locus, locus_defined_by_line_through_point

Discussion on the need to provide the element on which the mover point lies

It is true that in the examples you can guess the range of the mover point, since it has a constraint such as "point_on_line", etc. But, in general, guessing this could get complicated. For instance, imagine your P is the projection on a line of some other point Q with its own constraints; you can still use P to define a locus, but it might be complicated for a DGS to figure out exactly which line it should use (besides, maybe you don't mean the whole projection line, but only the ray/segment upon which Q may be projected)

The real reason to specift this constraint this way is that you don't have to guess, and so it is much easier to implement. And, in addition, this allows for "reusing" a relationship to define several loci.

Imagine you define some relation X=f(P) and then use these constraints:

free_point(P)
locus_defined_by_point_on_line(loc1,X,P,l1)
locus_defined_by_point_on_line(loc2,X,P,l2)

Then you can move the point P freely (2D) with the mouse and see how X crosses two "boundaries" (the loci). Here you really have to indicate the lines to build the loci.

Or maybe P belongs in a line, but you want to paint the locus in two colors, so you split it in two:

point_on_line(P,l)
locus_defined_by_point_on_line(loc1,X,P,segment1)
locus_defined_by_point_on_line(loc2,X,P,segment2)

Ulli: In Cinderella it is possible to define a locus by a free point moving on any line that is incident to it (which could be arbitrarily many).