Difference between revisions of "Naive groupings as dumbed down functions"
m |
m (→What works, what doesn't?) |
||
| (15 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | Up: '''[[Software trouble pages]]''' | ||
As of time of writing (2021) few if any people seem to realize that naive groupings in 2D- or 3D- modelling software (with visual [[direct manipulation]] interface)<br> | As of time of writing (2021) few if any people seem to realize that naive groupings in 2D- or 3D- modelling software (with visual [[direct manipulation]] interface)<br> | ||
| Line 15: | Line 16: | ||
If it did never effect you the reader then be happy, you just where not ambitious enough in a complex systems kind of way. | If it did never effect you the reader then be happy, you just where not ambitious enough in a complex systems kind of way. | ||
| − | [[What we can do depends on | + | [[What we can X depends on what we can Y|What we can do depends on what we can say]]. Or rather on what we can express. <br> |
It's kind of Linguistic relativity (aka the Sapir–Whorf hypothesis) applied on <br> | It's kind of Linguistic relativity (aka the Sapir–Whorf hypothesis) applied on <br> | ||
the "language" of human-computer 3D modelling interfaces. | the "language" of human-computer 3D modelling interfaces. | ||
| − | == Effects of this constraint (more concrete) – What is the difference when lifting | + | == Effects of this constraint (more concrete) – What is the difference when lifting this constraint? == |
With lifting this limitation "proper groups" that are not dumbed down (let's call them pseudo-groups here) <br> | With lifting this limitation "proper groups" that are not dumbed down (let's call them pseudo-groups here) <br> | ||
| Line 36: | Line 37: | ||
=== Neighbor pseudo-group dependence === | === Neighbor pseudo-group dependence === | ||
| − | + | Pseudo-groups can change in complex ways depending on the neighboring pseudo-groups. | |
| − | * automatic adjustment of physical surface interdigitation to match up – See: [[Connection mechanism]] | + | Neighboring means logically linked here. |
| + | * automatic adjustment of physical surface interdigitation to match up – See: [[Connection method]], [[Connection mechanism]] | ||
* automatic adjustment of internal makeup to match up in functionality | * automatic adjustment of internal makeup to match up in functionality | ||
| + | * … | ||
=== Lifting the constrain of geometric disjunctness === | === Lifting the constrain of geometric disjunctness === | ||
| Line 47: | Line 50: | ||
=== Beyond the geometric meaning all-together === | === Beyond the geometric meaning all-together === | ||
| − | Well, this becomes just a "normal" function for organizing things long before anything becomes actual geometry.<br> | + | Well, this seems to becomes just a "normal" function for organizing things long before anything becomes actual geometry.<br> |
"Function" here is meant in the sense of a function in purely functional / denotative programming languages. <br> | "Function" here is meant in the sense of a function in purely functional / denotative programming languages. <br> | ||
| − | + | Referentially transparent languages that say "what is" not "what to do". <br> | |
| + | These are needed in order for to mathematical substitution to work. <br> | ||
| + | Well suited for 3D modeling. | ||
| + | |||
| + | An issue is that a lot of existing 2D- and 3D- modelling software provides us with <br> | ||
| + | the "anti-feature" the "hard wall" of not allowing for more different arguments and operations on their naive groupings. <br> | ||
| + | Related: [[Grouping of geometries]] & [[Gaps in software]] <br> | ||
'''If pseudo-groups are just functions then doesn't this make pseudo-groups pointless?''' <br> | '''If pseudo-groups are just functions then doesn't this make pseudo-groups pointless?''' <br> | ||
| − | Well, no. | + | Well, no. Pure functions (in the few cases we have them for programmatic 3D modelling) still come <br> |
| − | + | – without [[direct manipulation]] (no point & click operations flowing back to code that remains human readable) <br> | |
| − | + | – without advanced edit back-propagation options to older usage contexts like … <br> | |
| − | + | sending a mere "newer-version-is-available" notification and providing easy undo for too back-propagations that went too far as one finds in retrospect. <br> | |
| + | '''Basically functions as in today's programming languages are too weak in version management to be good for pseudo-groups.''' <br> | ||
| + | Version management in general needs vast improvements (as of 2023). | ||
== What works, what doesn't? == | == What works, what doesn't? == | ||
| − | Pretty much all mainstream visual [[point and click 3D modelling software]] fall foul of this limitation.<br> | + | Pretty much all mainstream visual [[point and click 3D modelling software]] fall foul of this "naive groupings as dumbed down functions" limitation.<br> |
| − | Side-note / suspicion: Typically closed source SW is not suitable for systems on the scale of [[gem-gum factories]] (as can be seen in most of our SW compilers being open source today). Even if closed source SW get ahead the short run, over the very long run it does not prevail. Depending too much on closed source for truly large scale systems that are developed over the course of many decades can lead to severe regressions. So be wary of new shiny toys. They may break easily just when you've started to really depend on them critically. | + | Side-note / suspicion: Typically closed source SW is not suitable for systems on the scale of [[gem-gum factories]] (as can be seen in most of our SW compilers being open source today). Even if closed source SW get ahead the short run, over the very long run it does not prevail. Depending too much on closed source for truly large scale systems that are developed over the course of many decades can lead to severe regressions. So be wary of new shiny toys that can't be opened. They may break easily just when you've started to really depend on them critically. |
[[Programmatic 3D modelling]] can avoid the limitation to "naive groups" to a large degree. <br> | [[Programmatic 3D modelling]] can avoid the limitation to "naive groups" to a large degree. <br> | ||
| Line 72: | Line 83: | ||
== Relation to [[APM]] == | == Relation to [[APM]] == | ||
| − | Q: What is the relation to [[advanced productive nanosystem]]s like: | + | '''Q: What is the relation to [[advanced productive nanosystem]]s like:''' |
* earlier [[modular molecular composite nanosystem]]s and | * earlier [[modular molecular composite nanosystem]]s and | ||
* later [[gemstone metamaterial on-chip factories]]? | * later [[gemstone metamaterial on-chip factories]]? | ||
| − | A: There is need for: | + | '''A: There is need for:''' |
* Chaining [[assembly levels]] (possibly in the form of stacking [[assembly layers]]) | * Chaining [[assembly levels]] (possibly in the form of stacking [[assembly layers]]) | ||
| − | * Chaining [[zone]]s within the [[assembly levels]] | + | * Chaining [[zone]]s within the [[assembly levels]] – See: [[Sequence of zones]] |
Changing some aspects of the design should kick off a constraint solving propagation through <br> | Changing some aspects of the design should kick off a constraint solving propagation through <br> | ||
the rest of the system ideally with no "manual" intervention needed. | the rest of the system ideally with no "manual" intervention needed. | ||
| − | All this pertains to: | + | '''All this pertains to:''' |
* [[Design of gem-gum on-chip factories]] and | * [[Design of gem-gum on-chip factories]] and | ||
* Design of earlier precursor systems like [[modular molecular composite nanosystem]]s | * Design of earlier precursor systems like [[modular molecular composite nanosystem]]s | ||
| Line 110: | Line 121: | ||
== Related == | == Related == | ||
| + | |||
| + | * '''[[Grouping of geometries]]''' | ||
| + | * Programmatic modelling tools like e.g. [[OpenSCAD]] more or less evading the problem. | ||
'''Software aspect:''' | '''Software aspect:''' | ||
| Line 117: | Line 131: | ||
'''[[APM]] aspect:''' | '''[[APM]] aspect:''' | ||
* [[RepRec pick and place robots]] | * [[RepRec pick and place robots]] | ||
| + | |||
| + | [[Category:Programming]] | ||
Revision as of 13:09, 11 October 2023
As of time of writing (2021) few if any people seem to realize that naive groupings in 2D- or 3D- modelling software (with visual direct manipulation interface)
are essentially just heavily down-graded functions that:
- only allow for taking geometry data and
- only allow for applying some very limited set of operations to it
sometimes just linear transformations like translate, rotate, scale (including mirroring), and shear, (... Lorentz boost?).
From the small set of people that model really complex systems (with complex physical geometries involved) most should have realized this at least in a subconscious way though.
Contents
Effects of this constraint (abstract high level view)
This down graded functionality heavily limits us on what we can 3D model.
If it did never effect you the reader then be happy, you just where not ambitious enough in a complex systems kind of way.
What we can do depends on what we can say. Or rather on what we can express.
It's kind of Linguistic relativity (aka the Sapir–Whorf hypothesis) applied on
the "language" of human-computer 3D modelling interfaces.
Effects of this constraint (more concrete) – What is the difference when lifting this constraint?
With lifting this limitation "proper groups" that are not dumbed down (let's call them pseudo-groups here)
can match the context they are plopped into in complex ways. Like e.g:
Geometric constraint resolving
Resolving geometric constraints in a way that is not just "homogeneous scaling" of all the geometry that lies within the pseudo-group.
Visualization of pseudo-groups
There may be options in improving the visualization of pseudo-grouping beyond
just highlighting the geometric elements that came from one pseudo-group.
But that can be done programmatically as the particular case demands (and as pseudo-groups allow for).
Neighbor pseudo-group dependence
Pseudo-groups can change in complex ways depending on the neighboring pseudo-groups. Neighboring means logically linked here.
- automatic adjustment of physical surface interdigitation to match up – See: Connection method, Connection mechanism
- automatic adjustment of internal makeup to match up in functionality
- …
Lifting the constrain of geometric disjunctness
Different pseusdo-groups may even occupy pretty much the same volume in space
like two mechanical metamaterial functions occupying one and the same volume.
Beyond the geometric meaning all-together
Well, this seems to becomes just a "normal" function for organizing things long before anything becomes actual geometry.
"Function" here is meant in the sense of a function in purely functional / denotative programming languages.
Referentially transparent languages that say "what is" not "what to do".
These are needed in order for to mathematical substitution to work.
Well suited for 3D modeling.
An issue is that a lot of existing 2D- and 3D- modelling software provides us with
the "anti-feature" the "hard wall" of not allowing for more different arguments and operations on their naive groupings.
Related: Grouping of geometries & Gaps in software
If pseudo-groups are just functions then doesn't this make pseudo-groups pointless?
Well, no. Pure functions (in the few cases we have them for programmatic 3D modelling) still come
– without direct manipulation (no point & click operations flowing back to code that remains human readable)
– without advanced edit back-propagation options to older usage contexts like …
sending a mere "newer-version-is-available" notification and providing easy undo for too back-propagations that went too far as one finds in retrospect.
Basically functions as in today's programming languages are too weak in version management to be good for pseudo-groups.
Version management in general needs vast improvements (as of 2023).
What works, what doesn't?
Pretty much all mainstream visual point and click 3D modelling software fall foul of this "naive groupings as dumbed down functions" limitation.
Side-note / suspicion: Typically closed source SW is not suitable for systems on the scale of gem-gum factories (as can be seen in most of our SW compilers being open source today). Even if closed source SW get ahead the short run, over the very long run it does not prevail. Depending too much on closed source for truly large scale systems that are developed over the course of many decades can lead to severe regressions. So be wary of new shiny toys that can't be opened. They may break easily just when you've started to really depend on them critically.
Programmatic 3D modelling can avoid the limitation to "naive groups" to a large degree.
But it comes with the huge shortcoming of lacking direct manipulation.
(Example "OpenSCAD": pseudo-groups are called "modules" here – they do not allow for taking functions as arguments though.)
There have been attempts in solving this dillemma.
See: Higher level computer interfaces for deveusers
Relation to APM
Q: What is the relation to advanced productive nanosystems like:
- earlier modular molecular composite nanosystems and
- later gemstone metamaterial on-chip factories?
A: There is need for:
- Chaining assembly levels (possibly in the form of stacking assembly layers)
- Chaining zones within the assembly levels – See: Sequence of zones
Changing some aspects of the design should kick off a constraint solving propagation through
the rest of the system ideally with no "manual" intervention needed.
All this pertains to:
- Design of gem-gum on-chip factories and
- Design of earlier precursor systems like modular molecular composite nanosystems
- Design of RepRec pick and place robots
On constraint solving
If propagation solving is supposed to be able to run in opposing directions with just one an the same code then
some sort of logic / relational programming seems to be the natural choice.
Logic constraint solving is notorious for hugely unpredictable run-times (time and space complexities) though.
So it might be desirable to limit this only to where it really turns out to be needed.
Experts in logic constraint solving may know more about eventual advances.
Purely functional programming with lazy evaluation allows for
constraint solving propagation in one direction (chosen in advance) in an elegant way employing "infinite" lists.
Lazyness (deferred evaluation) is also notorious for leading to unpredictable run-times.
But maybe less so than relational constraint solving.
Notes:
- both purely functional programming and relational programming is denotative
- ...
Some semi random example cases
- Constraint solving on gears with involute (or cycloid) toothing. (Gears larger than atomic scale of course.)
Related
- Grouping of geometries
- Programmatic modelling tools like e.g. OpenSCAD more or less evading the problem.
Software aspect:
- Higher level computer interfaces for deveusers
- Direct manipulation
- Gaps in software – The "wall" of groups not being extendable could be seen as one of the gaps/barriers
APM aspect:
