Naive groupings as dumbed down functions

From apm
Jump to: navigation, search

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)
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 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:

A: There is need for:

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:

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

Software aspect:

APM aspect:

Retrieved from "http://apm.bplaced.net/w/index.php?title=Naive_groupings_as_dumbed_down_functions&oldid=15605"