Difference between revisions of "Naive groupings as dumbed down functions"

Revision as of 22:58, 21 November 2021

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.

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.
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 it?

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

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
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.
"Function" here is meant in the sense of a function in purely functional / denotative programming languages.
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?
Well, no. The 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 them. (Related: Gaps in software)
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.

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

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