Order of reasoning operations.

I encountered an issue with my own implementation on some tests I recently added [1]. In order to try to create tests that don’t depend too much on floating-point precision, I added tests such as the following:

{0.23 math:sin  _:x . _:x math:lessThan 0.2280; math:greaterThan 0.2279} => {:test3a a :SUCCESS} .

In existing tests, the result produced is 0.227977523535e+00. My own implementation, using the Ruby float package, gives 0.2279775235351884e0, which seems to have more precision. GIven that test results use graph isomorphism, precise values matter, so I came up with the above approach, but it is somewhat problematic. My first attempt was the following rather obvious statement:

{0.23 math:sin [math:lessThan 0.2280; math:greaterThan 0.2279]} => {:test3a a :SUCCESS} .

but, due to the way I parse, and the fact that statement order is preserved, it came out like the following:

{
  _:x  math:lessThan 0.2280 .
  _:x math:greaterThan 0.2279
  0.23 math:sin _:x
} => {:test3a a :SUCCESS} .

My processor processes each built-in in order, so the first statements don’t result in any solutions; the last does, but the overall formula evaluates to false because of the order of operations. This reminded my of something Jos said about data-flow, and that would indeed be an interesting way to approach it, but ordering the operations based on inputs and outputs used in their arguments, but it falls down for more complicated scenarios where arguments might, themselves, be quoted graphs, and it is not apparent without much more introspection about what variables might be bound as a result.

I’m curious what other approaches there might be to solving such data-flow issues. And, does the test formulation I used above make sense?

Gregg Kellogg
gregg@greggkellogg.net

[1]https://github.com/gkellogg/N3/blob/444e545d528f7b94affa089ca9f64e935b173c68/tests/N3Tests/math/trig.n3

Received on Wednesday, 2 September 2020 19:54:14 UTC