Difference between revisions of "Data decompression chain"
From apm
(basic page) |
m (incomplete ...) |
||
Line 22: | Line 22: | ||
* physical object | * physical object | ||
* virtual simulation | * virtual simulation | ||
+ | |||
+ | === CSG Scenegraphs & functional programming === | ||
+ | |||
+ | Modeling of static 3D models is purely declarative. | ||
+ | * example: OpenSCAD | ||
+ | ... | ||
+ | |||
== Similar situations in today's computer architectures == | == Similar situations in today's computer architectures == |
Revision as of 21:30, 11 February 2016
The data decompression chain is the sequence of expansion steps from
- very compact highest level abstract blueprints of technical systems to
- discrete and simple lowest level instances that are much larger in size.
Contents
3D modelling
(TODO: add details)
- high language 1: functional, logical, connection to computer algebra system
- high language 2: imperative, functional
- constructiv esolid geometry graph (CSG graph), parametric surfaces
- quadrik nets C1
- triangle nets C0
- toolpaths
- Primitive signals: step-signals, rail-switch-states, clutch-states, ...
Targets
- physical object
- virtual simulation
CSG Scenegraphs & functional programming
Modeling of static 3D models is purely declarative.
- example: OpenSCAD
...
Similar situations in today's computer architectures
- high level language -> compiler infrastructure (e.g. llvm) -> assembler language -> actual actions of the target data processing machine
Related
- Control hierarchy
- mergement of GUI-IDE & code-IDE
- The reverse: while decompressing is a technique compressing is an art - (a vague analog to derivation and integration)
See: the source of new axioms Warning! you are moving into more speculative areas.