glen/dyna3
1
0
Fork 0
Code Issues 14 Pull Requests 1 Actions Projects Releases 2 Wiki Activity

Update Interface

Glen Whitney 2024-07-03 00:07:23 +00:00
parent f7fa0b65d5
commit 6f6468d217
1 changed files with 2 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Interface.md

@ -14,6 +14,8 @@ I think the text representation should be completely order-independent if that's
Some questions: Some questions:
- Does the text representation also record current contingent aspects of the construction? E.g., the position of a point among its allowed positions, even if it is not constrained to that specific position? For example in GeoGebra, if you enter `Q=(1, -2)` in its text rep, then the point Q is plotted in the graphical view at that position, but it is fully draggable, and as you drag it, the text representation/definition of it changes in the text window. (I think it is choosing rational coordinates, but it is hard to be certain as they are displayed in decimal.) This has a very nice feel to it. If you want to create a point that is pinned to a specific location there's a different command you can write, e.g. `F = Point({-1,1})` (there may be other possible commands). Then F is plotted at that location, but with different appearance, and it is not draggable. I don't know that I love those notations, but ideally we would have both of those possibilities in Dyna3. - Does the text representation also record current contingent aspects of the construction? E.g., the position of a point among its allowed positions, even if it is not constrained to that specific position? For example in GeoGebra, if you enter `Q=(1, -2)` in its text rep, then the point Q is plotted in the graphical view at that position, but it is fully draggable, and as you drag it, the text representation/definition of it changes in the text window. (I think it is choosing rational coordinates, but it is hard to be certain as they are displayed in decimal.) This has a very nice feel to it. If you want to create a point that is pinned to a specific location there's a different command you can write, e.g. `F = Point({-1,1})` (there may be other possible commands). Then F is plotted at that location, but with different appearance, and it is not draggable. I don't know that I love those notations, but ideally we would have both of those possibilities in Dyna3.
- Or more generally, is the text representation the "save file" of the construction? I think if the answer is yes, then the answer to the previous question has to be "yes" as well. But then I think more has to be true: the styles/labels/visibility/etc. etc. of every element also must appear in the text representation, which further probably means that portions of the text representation have to be hide-able to keep it from becoming too busy.
- How do the derivations interact with the declarations? Continuing the example above, does `M=midpoint(A,B)` stay that way in the text, or does it just expand to `Point M; AM = BM = AB/2`? The latter would seem to make it harder to see what's going on, so it doesn't seem to be a good idea. But suppose you type out `Point X; CX=DX=CD/2;` -- does it automatically "collapse" to `X = midpoint(C,D)`? Or even to be crazier, suppose you do `Point X; Segment s = AB; X on s; AX = XB;` -- does that _also_ collapse to `X = midpoint (A,B)`? How far does Dyna3 go in trying to prove that X really is the midpoint of AB? And what happens if that's deduced from a bunch of other declarations and constraints, and so maybe then displayed as a midpoint derivation, but one of the necessary constraints is deleted, does the text representation flip back to some other description of X, and if so, exactly what? This seems like it could be a morass. Perhaps when something is defined as derived from other things, it has a slightly different status -- maybe it doesn't get its own variables, but is always computed on the fly, dragging it is implemented by temporarily adding a draggable thing with the right definition/constraints, which all evaporate after the drag, constraints on it are rephrased internally into constraints on the things it is derived from, etc. This is a perspective in which somehow `M = midpoint(P,Q)` makes M _intrinsically_ the midpoint of PQ, rather than just currently the midpoint either by accident or even just by other individual constraints, some of which could later be removed, freeing up M to leave from its midpoint. If you use the derived form, then its the whole package, take it or leave it. If you decide you want M just to be equidistant from P and Q rather than the exact midpoint, you really have to redefine M; you can't just eliminate one condition from it. So in that sense a derivation wouldn't be just an abbreviation, it would be more strict than that. That approach seems less fraught. - How do the derivations interact with the declarations? Continuing the example above, does `M=midpoint(A,B)` stay that way in the text, or does it just expand to `Point M; AM = BM = AB/2`? The latter would seem to make it harder to see what's going on, so it doesn't seem to be a good idea. But suppose you type out `Point X; CX=DX=CD/2;` -- does it automatically "collapse" to `X = midpoint(C,D)`? Or even to be crazier, suppose you do `Point X; Segment s = AB; X on s; AX = XB;` -- does that _also_ collapse to `X = midpoint (A,B)`? How far does Dyna3 go in trying to prove that X really is the midpoint of AB? And what happens if that's deduced from a bunch of other declarations and constraints, and so maybe then displayed as a midpoint derivation, but one of the necessary constraints is deleted, does the text representation flip back to some other description of X, and if so, exactly what? This seems like it could be a morass. Perhaps when something is defined as derived from other things, it has a slightly different status -- maybe it doesn't get its own variables, but is always computed on the fly, dragging it is implemented by temporarily adding a draggable thing with the right definition/constraints, which all evaporate after the drag, constraints on it are rephrased internally into constraints on the things it is derived from, etc. This is a perspective in which somehow `M = midpoint(P,Q)` makes M _intrinsically_ the midpoint of PQ, rather than just currently the midpoint either by accident or even just by other individual constraints, some of which could later be removed, freeing up M to leave from its midpoint. If you use the derived form, then its the whole package, take it or leave it. If you decide you want M just to be equidistant from P and Q rather than the exact midpoint, you really have to redefine M; you can't just eliminate one condition from it. So in that sense a derivation wouldn't be just an abbreviation, it would be more strict than that. That approach seems less fraught.
--- ---