|
|
|||||
|
|
|||||
|
OR4NO-SCAR™ is a specification of the
design process aimed at maximizing the reliability of Hardware and Software systems
for Pattern Recognition solutions based on Neural Networks. 1. The
Occam’s Razor states that one should not increase
(beyond reason) the number of entities required to realize anything. 2. Any
component that is not there cannot be broken. Any components that are not
needed must be removed. 3. Claim
2 does not apply to the concept of redundancy contained in NHTMR™ and PRTVA™. 4. The
smaller the number of available operations, the smaller the number of
possible states of the machine. We strictly apply Occam’s
Razor principle in the design and implementation of Hardware and Software
solutions dedicated to specific problems. We do not believe in the application
of the Occam’s Razor principle for the explanation
of complex phenomena such as those of physics and biology. Simplifying the
explanation or simulation of complex phenomena can often lead to completely
wrong results. As an example the complexity of the chemical-physical
phenomena of a biological neuron cannot be accurately mimicked by spiking neurons
on silicon. Instead, we strongly believe in applying Occam's
Razor Principle to all software and
hardware design processes. |
|
In 1996, Pedro Domingos
formally applied Occam’s Razor to machine learning,
introducing the following implications, which he called “Occam’s
Two Razors”: First razor: Given two models with the
same generalization error, the simpler one should be preferred because
simplicity is desirable in itself. NOTE: This statement is always true
and the rule should be applied. Second razor: Given two models with
the same training-set error, the simpler one should be preferred because it
is likely to have lower generalization error. |
|
A complex API allows the software designer
to perform sequences of operations that can be potentially harmful. Our software libraries expose in the
API only the essential methods that are used to obtain all the functionality.
These methods are parametrically optimized. The most suitable programming language
for safety critical applications is 1.
Restrict
all code to very simple control flow constructs, do
not use goto statements, setjmp
or longjmp construct, or direct or indirect
recursion. 2.
Give
all loops a fixed upper bound. 3.
Do
not use dynamic memory allocation after initialization. 4.
No
function should be longer than what can be printed on a single sheet of paper
in a standard format with one line per statement and one line per
declaration. 5.
The
code’s assertion density should average to minimally two assertions per
function. 6.
Declare
all data objects at the smallest possible level of scope. 7.
Each
calling function must check the return value of non-void functions, and each
called function must check the validity of all parameters provided by the
caller. 8.
The
use of the pre-processor must be limited to the inclusion of header files and
simple macro definitions. 9.
Limit
pointer use to single dereference and do not use function pointers. 10.Compile with all possible warnings active; all warnings should then be
addressed before the release of the software. We apply continuous cross-review
of the code between software engineers to ensure compliance with the
established coding standard. |
|
Each hardware project is
analyzed in a loop of revisions aimed at minimizing the number of components.
Each cycle is managed by a different engineer and the contraindications of
the possible elimination of a component are analyzed by the team. The cycle
ends when all engineers agree that maximum simplification has been achieved
without reductions in functionality or compromise of redundancy principles. |
|
|
|
©2024_Luca_Marchese_All_Rights_Reserved Aerospace_&_Defence_Machine_Learning_Company VAT:_IT0267070992 NATO_CAGE_CODE:_AK845 Email:_luca.marchese@synaptics.org |
|
Contacts_and_Social_Media
|
