On why code LLMs should be trained on the edges between tests and the code that they test, that could be visualized as a mindmap DAG with cycles
On why code LLMs should be trained on the edges between tests and the code that they test, that could be visualized as a mindmap DAG with cycles
django_extensions/management/modelviz.py: https://github.com/django-extensions/django-extensions/blob/...
viewflow supports BPMN: https://github.com/viewflow/viewflow https://github.com/viewflow/cookbook/blob/main/guardian_perm...
Wikipedia mentions security concerns with low-code and no-code apps; and it's rare to impossible for a tool to support round-trip from code -> diagram UI -> code. And the test for isomorphism or functional equivalenve after normalization.
https://news.ycombinator.com/item?id=39139198 :
> All program evolution algorithms tend to produce bloated, convoluted, redundant programs ("spaghetti code"). To avoid this, MOSES performs reduction at each stage, to bring the program into normal form. The specific normalization used is based on Holman's "elegant normal form", which mixes alternate layers of linear and non-linear operators. The resulting form is far more compact than, say, for example, boolean disjunctive normal form. Normalization eliminates redundant terms, and tends to make the resulting code both more human-readable, and faster to execute.
"Elements of an expert system for determining the satisfiability of general Boolean expressions" (1990) https://dl.acm.org/doi/10.5555/100095 :
> Neither the constraint calculus nor the satisfiability-determination (SD) algorithm require that an expression be in either Conjunctive or Disjunctive Normal Form.
IR: Intermediate Representation: https://en.wikipedia.org/wiki/Intermediate_representation
How many ways can a compiler generate a code graph from a code graph?