Re: Order of reasoning operations.

Yes Gregg, it is a good test case (after adding a dot after 0.2279)

$ cat test.n3
> @prefix math: <http://www.w3.org/2000/10/swap/math#>.
> @prefix : <http://example.org/test#>.
> {
>   _:x  math:lessThan 0.2280 .
>   _:x math:greaterThan 0.2279 .
>   0.23 math:sin _:x
> } => {:test3a a :SUCCESS} .


and both CWM and EYE produce

$ cwm test.n3 --think --data 2> /dev/null
> #Processed by Id
>         #    using base file:///tmp/test.n3
>              @prefix : <http://example.org/test#> .
>     :test3a     a :SUCCESS .


$ eye --nope test.n3 --pass 2> /dev/null
> #Processed by EYE v20.0825.2124 josd
> #eye --nope test.n3 --pass
> @prefix math: <http://www.w3.org/2000/10/swap/math#>.
> @prefix : <http://example.org/test#>.
> :test3a a :SUCCESS.
>

EYE it makes use of coroutining i.e. it suspends
the subgoals math:lessThan and math:greaterThan till
their subjects get grounded by math:sin.

-- https://josd.github.io/
<http://josd.github.io/>


On Wed, Sep 2, 2020 at 9:54 PM Gregg Kellogg <gregg@greggkellogg.net> wrote:

> 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
>