Matt Whiteside 1,20,18
Q. In the note at the end, it says there are 24 relation classes in the NCL function library. I thought there were 27 or 28. Did something change here, or am I just misremembering?
A. There is a bit of history here to recount. We realized we had a threshold logic. The study of threshold logic peaked in the early 70s. and we went through the threshold logic literature. The key find was about function classification of functions of 4 or fewer inputs. It turned out that all of the threshold function classes of four or fewer inputs matched Boolean function classes of four or fewer inputs. But there were three 4 input Boolean classes that were not threshold functions. It occurred to us that if we included threshold circuits in the library (26 THXOR, 27 THAND, 28 THCOMP) that mapped to these three function classes then we would have a complete mapping between NCL and Boolean functions of 4 or fewer inputs. We could design with Boolean logic and map to NCL
This seemed like a great idea at the time but mixing NCL and Boolean logic has not worked out well. Part of the problem is that NCL never quite differentiated itself from Boolean logic as a fundamental logic. Designing with Boolean logic missed basic aspects of NCL. There have been multiple efforts to map clocked Boolean designs to NCL which can be done but the two domains are sufficiently different that efficiency does not map between the two. Also, adding the three threshold circuits to the library and treating them as primitive functions created subtle issues with completeness behavior.
The language relates directly to the threshold behaviors, does not relate to Boolean logic and so there is no need for the 3 added circuits. In the context of the language the library is just a complete set of networks of 4 or fewer inputs. I think that considering NCL and its library as a fundamental logic has been misleading and the wrong way to think about it. In the context of the language there is no need of a fundamental logic.
The other issue is the one input function. It is really just a wire or association that connects functions. So should it be considered a function behavior. I have decided that it makes the most consistent sense to not treat it as a function. So if we just consider the 2, 3 and 4 input threshold functions and remove the three circuits we are left with 24 threshold functions which is all the language needs.
The other question frequently asked is why is the inverter not in the function library? Inversion only occurs at specific places in closure paths in the model. Inversion is not used in any other place or context within the model. All the functions in the library can be used anywhere in a data flow or closure flow. So the inversion is properly considered a property of the model instead of a property of the logic of the model and is not included in the library.