Functions returning points/lines should preserve provenance when called again with the same inputs #31

New issue

Open

opened 2025-06-29 04:24:36 +00:00 by zyxw59 · 1 comment

zyxw59 commented

2025-06-29 04:24:36 +00:00

(Migrated from github.com)

Consider the following:

origin = (0, 0);
N = dir 0;
E = dir 90;
fn horiz(y) = (origin >> E) ^^ y;
fn vert(x) = (origin >> N) ^^ x;

a = horiz(5) & vert(0);
b = horiz(5) & vert(1);
c = horiz(5) & vert(2);

The resulting points a, b, and c will not be considered colinear, despite all lying on the line horiz(5). The issue is that each time horiz is called, it generates a new line, with its own provenance, even if the inputs are the same.

Consider the following: ``` origin = (0, 0); N = dir 0; E = dir 90; fn horiz(y) = (origin >> E) ^^ y; fn vert(x) = (origin >> N) ^^ x; a = horiz(5) & vert(0); b = horiz(5) & vert(1); c = horiz(5) & vert(2); ``` The resulting points `a`, `b`, and `c` will not be considered colinear, despite all lying on the line `horiz(5)`. The issue is that each time `horiz` is called, it generates a new line, with its own provenance, even if the inputs are the same.

zyxw59 commented

2025-08-26 16:48:20 +00:00

(Migrated from github.com)

One challenge here is that it would make floating-point equality somewhat loadbearing. Maybe this is okay, especially since the use case mentioned here is generally going to come up with integer literals (or at worst, simple rational expressions), where floating point equality isn't problematic. But this could also justify explicitly adding a Rational type as part of #2