Re: Order of reasoning operations.

Indeed, for bidirectional built-ins it is more complicated and typically
a subgoal will be suspended till either the subject or the object of the
built-in are grounded. For instance the math:degree implementation
in EYE looks as follows

'<http://www.w3.org/2000/10/swap/math#degrees>'(X, Y) :-
>     when(
>         (   ground(X)
>         ;   ground(Y)
>         ),
>         (   getnumber(X, U),
>             Y is U*180/pi,
>             !
>         ;   getnumber(Y, W),
>             X is W*pi/180
>         )
>     ).


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


On Thu, Sep 3, 2020 at 2:30 AM Gregg Kellogg <gregg@greggkellogg.net> wrote:

> 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#>.
>> @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.
>
>
> 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>
> 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
>>
>
>