View source for Naive groupings as dumbed down functions


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>
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 <br>sometimes just linear transformations like translate, rotate, scale (including mirroring), and shear, <small>(... Lorentz boost?)</small>.

<small>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.</smalL>

__TOC__
[[File:GroupingsAsDumbedDownFunctions.png|800px|thumb|center|Groupings as dumbed down functions.]]

== Effects of this constraint (abstract high level view) ==

This down graded functionality heavily limits us on what we can 3D model. <br>
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 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>
the "language" of human-computer 3D modelling interfaces.

== Effects of this constraint (more concrete) – What is the difference when lifting it? ==

With lifting this limitation "proper groups" that are not dumbed down (let's call them pseudo-groups here) <br>
can match the context they are plopped into in complex ways. Like e.g:<br>

=== 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. <br>   

=== Visualization of pseudo-groups ===

There may be options in improving the visualization of pseudo-grouping beyond <br> 
just highlighting the geometric elements that came from one pseudo-group. <br>
But that can be done programmatically as the particular case demands (and as pseudo-groups allow for).

=== Neighbor pseudo-group dependence ===

Depending on the neighboring (that is: logically linked to) pseudo-groups pseudo-groups can change in complex ways 
* 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 <br> 
like two [[mechanical metamaterial]] functions occupying one and the same volume.

=== Beyond the geometric meaning all-together ===

Well, this 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>
Languages that say "what is" not "what to do". That is needed in order for to mathematical substitution to work. 

'''If pseudo-groups are just functions then doesn't this make pseudo-groups pointless?''' <br>
Well, no. 
The 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 them. <small>(Related: [[Gaps in software]])</small> <br>
While denotative functions (in the few cases we have them for programmatic 3D modelling) still come without [[direct manipulation]].

== What works, what doesn't? ==

Pretty much all mainstream visual [[point and click 3D modelling software]] fall foul of this 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.

[[Programmatic 3D modelling]] can avoid the limitation to "naive groups" to a large degree. <br>
But it comes with the huge shortcoming of lacking [[direct manipulation]]. <br>
(Example "[[OpenSCAD]]": pseudo-groups are called "modules" here – <small>they do not allow for taking functions as arguments though</small>.)

'''There have been attempts in solving this dillemma.''' <br>
See: [[Higher level computer interfaces for deveusers]]

== Relation to [[APM]] ==

'''Q: What is the relation to [[advanced productive nanosystem]]s like:'''
* earlier [[modular molecular composite nanosystem]]s and
* later [[gemstone metamaterial on-chip factories]]?

'''A: There is need for:'''
* Chaining [[assembly levels]] (possibly in the form of stacking [[assembly layers]])
* 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>
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 nanosystem]]s
* 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 <br>
some sort of '''logic / relational programming''' seems to be the natural choice. <br>
Logic constraint solving is notorious for hugely unpredictable run-times (time and space complexities) though. <br>
So it might be desirable to limit this only to where it really turns out to be needed. <br>

Experts in logic constraint solving may know more about eventual advances.

'''Purely functional programming with lazy evaluation''' allows for <br>
constraint solving propagation in one direction (chosen in advance) in an elegant way employing "infinite" lists. <br>
Lazyness (deferred evaluation) is also notorious for leading to unpredictable run-times. <br> 
But maybe less so than relational constraint solving. <br>

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 ==

'''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:'''
* [[RepRec pick and place robots]]