Re: Order of reasoning operations.

> On Sep 2, 2020, at 5:16 PM, Jos De Roo <josderoo@gmail.com> wrote:
> 
> 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# <http://www.w3.org/2000/10/swap/math#>>.
> @prefix : <http://example.org/test# <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# <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# <http://www.w3.org/2000/10/swap/math#>>.
> @prefix : <http://example.org/test# <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.

Do you have some built-in knowledge about which arguments are inputs and which outputs? For built-ins that can be bi-directional, this seems complicated.

But, it strikes me that each built-in could be run separately to see what variables are bound, and then run with those bound variables against those which previously generated no bindings with some repetition.

Thanks for the suggestion.

Gregg

> -- https://josd.github.io/
>  <http://josd.github.io/>
> 
> On Wed, Sep 2, 2020 at 9:54 PM Gregg Kellogg <gregg@greggkellogg.net <mailto: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 <mailto:gregg@greggkellogg.net>
> 
> [1]https://github.com/gkellogg/N3/blob/444e545d528f7b94affa089ca9f64e935b173c68/tests/N3Tests/math/trig.n3 <https://github.com/gkellogg/N3/blob/444e545d528f7b94affa089ca9f64e935b173c68/tests/N3Tests/math/trig.n3>