Aspects of a manual approach to functionality ennaction
For production planning asking a question such as "I want to maintain my body" is being tackled by me with the bounding of descriptions and then a discerning body. Some would then see a progression from this to be to train a neural net what this english sentence means but I think english is far too messy. Developing a method of describing desire which can succinctly encode as much intent as "i want to maintain my body" that I can then be picked...
Were I to develop systems before developing a more concise way of relating my understanding to a computers parsing and operational ability and developing methods of adapting code to changing worlds then I would have to use existing methods or I can use said existing methods to create a bespoke way of describing how the computer may infer this way. Should I develop this description I want it to be fairly frictionless to update this description and to update existing data created with this description.
Existing modelling methods are:
- Modelling using a format created using a general programming language
- Modelling using a general programming language
Comparison of existing modelling methods
I have felt a desire to not describe systems using formats that I have created but to stick with the general nature of a general programming language, I wish to avoid a situation where I effectively create a custom modelling language within software. Especially considering that the primary code should be accepting of continuous iteration itself. An example is in modelling production processes as I believe the implementor of the modelling environment will not be able to adequately predict the complexity needed to model Maximising speed of code writing helps mitigate this but in some cases such as those that would require implementation of a powerful general modelling environment, these tools already exist
Using the production process example and modelling within a python class definition:
I should maintain a definition of a common protocol which other elements of my programmatic system can use to see what to
expect when interacting with a production process definition. This could be a `getOutputType()` method. A discerning programmatic instance may
want to know how many work hours it is predicted to take n number of people. We could expose a `workHours( nPeople: int)` function or a
`workHours( people: list[ Person])` function that could calculate it based upon a persons skills. We could expose a list of action objects
which themselves have a work hours value which we can sum up.
With a production process one could encode ( the structure which is common to all of that set of processes such as all lettuce production) within
a class definition and then instances can then be used to store data which is unique to that instanciation of that product definition
Here the ( type-> instance) structure where we suck platos marble cock isnt holding up and that is fine, it is a tool that I am using to achieve my goal
Moving on from this descriptive zone, the process of creating instances of platonic things works well with commonly repeated data such as numbers