Re: Pure Functions?

Hi all,

Disclaimer: I'm no logician or mathematician, I'm an engineer, sorry for
all the theoretically unfounded statements I will make below ;).

The initial goal of FnO was to have an implementation-independent
description of "something that transforms things", which I called with my
engineering hat on "a function". In the original scope, the types of
transformations are not limited: they could have side-effects, they could
produce non-deterministic results, they could change the types between
input and output (eg input is a string, output is a complete Date object),
etc etc. The only thing FnO currently specifies are the identifiers of the
inputs, and the identifiers of the outputs (I allowed multiple outputs to
take, eg, exception handling into account). I didn't dare to touch the type
system yet, because of all the edge cases Dörthe already mentioned
(integers '06' vs '6' vs '6.0').

Next to functions, you have Executions, that may or may not be results from
specific Implementations. As Dörthe already mentioned, an execution result
may differ from a mathematically correct result.

If I understand the discussion well, I would suggest that the type of
'provable' built-ins would be a subset of the more general fno:Function,
e.g. `fno:PureFunction rdfs:subClassOf fno:Function` (I'm pretty sure the
term "pure" function is incorrect).
If we then want to make sure that the Executions are within expectations,
we also need `fno:PureImplementation rdfs:subClassOf fno:Implementation`.
If we then encounter `math:cos a fno:PureFunction` and have in the reasoner
(e.g. EYE) `eye:cos a fno:PureImplementation` (and the mapping between
them, specifying that the abstract description math:cos used in N3 can be
executed in the EYE reasoner via implementation as described by eye:cos),
we can be assured that the Execution will always contain the correct
output. Additional restrictions could be added to "pure" functions,
depending on the requirements.

(Sidenote: you could also have a `prolog:cos a fno:PureImplementation` that
specifies how to execute the cos function in Prolog, so that any Prolog
reasoner could rely on those same descriptions)
(Sidenote2: @Dörthe, I think where we previously got stuck on was how to
link the FnO descriptions with the N3 rules, i.e., how do you clarify that
the abstract `a + b = c` is specified in N3 as `($a $b) math:sum $c`. In my
opinion that's a complementary discussion that we can refine along the way,
happy to discuss :) )

If this makes sense, happy to have a further look, however, I'll need help
with the semantic and logical implications :)

Kind regards,
Ben
Ben De Meester
Researcher Semantic Web
imec - Ghent University - IDLab | Faculty of Engineering and
Architecture | Department
of Electronics and Information Systems
Technologiepark-Zwijnaarde 122, 9052 Ghent, Belgium
t: +32 9 331 49 56 | e: ben.demeester@ugent.be | URL:
https://ben.de-meester.org/#me
<https://ben.de-meester.org/#me>


Op ma 18 jul. 2022 om 15:19 schreef Doerthe Arndt <
doerthe.arndt@tu-dresden.de>:

> Dear Henry,
>
> I put Ben in cc, because I think he could also be interested in
> discussions about the function ontology (as a side-note: I think I already
> had a similar discussion with him in the past about functions and partial
> functions, he will remember :) ).
>
> Here in the group, we discussed the function ontology as a possible way to
> formally describe built-in functions, but since there are other aspects
> open, this discussion has been postponed (but maybe someone reading this
> mail is willing to volunteer and write some specifications? :) ).
>
>
>
>  I have been working a bit recently with the function ontology
> https://fno.io/
> and was wondering if one could not have a pure function ontology subset of
> it.
>
>
> I also think it would be nice to have pure function ontology, especially
> if we want to describe built-ins: we should be able to say that two
> implementations of the sum function need to come to the same conclusion
> when, for example, being confronted with the values 2 and 4 (like in the
> example: https://fno.io/spec/#fn-returns). For our built-in functions it
> would not be acceptable when one result is 6 and one is 8. Yet, the problem
> of „equality“ is a little bit more complicated here:
> is "6"^^xsd:integer the same as „06"^^xsd:integer or "6"^^xsd:double? We
> could consider these solutions as equivalent and then see the equivalence
> classes as solutions. Of course these classes could not contain general
> error values ("time out" should not be equivalent to „4“ AND „6“).
>
> I think one problem we have here is that there is a difference between the
> expected output and the output of  a particular execution. One could for
> example still argue, that if we see the implementation, the current time
> and the input values as the actual input argument of the function then this
> function is still functional because it returns one single result (as time
> evolves, it is totally possible that we keep getting new random results
> from our function). Of course our description would become meaningless at
> some point.
>
> From what I see, it might be possible to simply add something like
> fno:CorrectOutput  as a counter part to fno:Output where we specify what we
> expect as opposed to what we get from the execution of a function. But I
> would not be surprised if Ben had a better solution for that? Do you work
> with shapes here, Ben?
>
>
> There is a nice mapping between the category Rel of sets and relations and
> the
> category Set of Sets and functions (somewhere in David Spivak’s work on
> the subject).
> I think all one needs is a relation from an functional property its
> restricted domain,
> to get a function.
>
>
> I did not read the work yet, but I would also say that this would be a way
> to get a function. So, if you would go here
> https://fno.io/spec/#example-generatedID-6 and consider the example,
> would you then propose to make the predicate ex:sumResult functional? I
> think this would be problematic since it could happen that one *execution
> *of a function returns an unexpected result (8 from above or simply
> ERROR). We again have two different aspects: the result of a mathematical
> function and  the result of a concrete execution. Ideally, these do not
> differ. In practice, they sometimes do
>
>
> It seems like having that could help clarify the function ontology. So I
> wrote it
> up here
>
> https://github.com/FnOio/fno-specification/issues/7
>
> But then I also get the feeling that this was thought of before, and
> that there was an issue that came up.  I am asking here as I think the
> experts that know should be here :-)
>
>
> I think this is not only a discussion for the N3 group as possible
> customers and also providers of formalisms, but also something for the
> creators of fno. So I’dlike to ask you directly, Ben, would you want fno to
> be used to describe functions from a mathematical point of view (if so, I
> believe Henry and I would be happy to help :)) or would you see that (for
> now) beyond the scope of fno and say it focusses more on concrete
> executions?
>
> Kind regards,
> Dörthe
>
>
>
>
> Henry Story
>
> https://co-operating.systems
> WhatsApp, Signal, Tel: +33 6 38 32 69 84‬
> Twitter: @bblfish
>
>
>
>