Grouping of geometries - Revision history

Apm at 08:39, 5 May 2024

2024-05-05T08:39:22Z

← Older revision		Revision as of 10:39, 5 May 2024
Line 90:		Line 90:

	[[Category:Programming]]		[[Category:Programming]]
			[[Category:Software]]

Apm: /* Modularity */

2023-10-11T08:18:10Z

Modularity

← Older revision		Revision as of 10:18, 11 October 2023
Line 72:		Line 72:

	Modularity is a highly desirable property for getting comprehensible, maintainable, and scalable systems. <br>		Modularity is a highly desirable property for getting comprehensible, maintainable, and scalable systems. <br>
	Grouping of geometries in [[~~position~~ space\|~~phase~~ space]] is not the only form of modularity though. <br>		Grouping of geometries in [[phase space\|position space]] is not the only form of modularity though. <br>
	Groupings in higher dimensional or even abstract programmatic spaces can be just as helpful and in many cases is even much more helpful. <br>		Groupings in higher dimensional or even abstract programmatic spaces can be just as helpful and in many cases is even much more helpful. <br>
	When looking at the compiled down to concrete geometry result of these programmatic groupings (functional definitions) in real space <br>		When looking at the compiled down to concrete geometry result of these programmatic groupings (functional definitions) in real space <br>

Apm: Modularity

2023-10-11T08:17:46Z

Modularity

← Older revision		Revision as of 10:17, 11 October 2023
Line 68:		Line 68:

	{{Todo\|More investigation is needed in the microcomponent-as-group-problem direction.}}		{{Todo\|More investigation is needed in the microcomponent-as-group-problem direction.}}

			== Modularity ==

			Modularity is a highly desirable property for getting comprehensible, maintainable, and scalable systems. <br>
			Grouping of geometries in [[position space\|phase space]] is not the only form of modularity though. <br>
			Groupings in higher dimensional or even abstract programmatic spaces can be just as helpful and in many cases is even much more helpful. <br>
			When looking at the compiled down to concrete geometry result of these programmatic groupings (functional definitions) in real space <br>
			then one can see that interfaces may be highly variable complexly intermediating and not even spacially singly connected. <br>
			Kinda like like shoes, bikinis, and the sheets of a newspaper are one thing that is multiple things.

			Quick recomposability of larger structures makes interfaces <br>
			that are ad hoc modified to the problem at hand much more feasible. <br>
			The actual interfaces remain hidden in the abstract programmatic space before compilation.

			See: [[Modularity and abstraction]]

	== Related ==		== Related ==

	* [[Naive groupings as dumbed down functions]]		* [[Naive groupings as dumbed down functions]]
			* [[Modularity and abstraction]]

	[[Category:Programming]]		[[Category:Programming]]

Apm: /* Microcomponents */ some updates

2023-10-11T08:03:41Z

Microcomponents: some updates

← Older revision		Revision as of 10:03, 11 October 2023
Line 55:		Line 55:
	withing quantity of old usage contexts that is too large for immediate manual case by case checking.		withing quantity of old usage contexts that is too large for immediate manual case by case checking.

	== Microcomponents ==		== Microcomponents and standard part crystolecules ==

	In physical systems [[microcomponent]]s could be seen as such groupings with all ~~its~~ detriments.		In physical systems of [[gemstone based APM]] [[microcomponent]]s could be seen as such groupings with all the detriments of groupings. <br>
	But microcomponents are low level instances of a high level abstract software representation.		But microcomponents are low level instances of a high level abstract software representation. <br>
	Systems of microcomponents are compiled (decompressed) results of a high level highly compressed abstract software representation		Systems of microcomponents are compiled ([[decompression chain\|decompressed]]) results of a high level highly compressed abstract software representation <br>
	that does not suffer from the "grouping"-problem. <br>		that does not suffer from the "grouping"-problem. <br>

			Desire for standardized physical interfaces may force a bit more naive block like grouping at this particular size scale. <br>
			But both at smaller and bigger scales things may turn out much more interwoven and complex.

			Standard [[crystolecule]]s also have a strong group-of-geometry character.

	{{Todo\|More investigation is needed in the microcomponent-as-group-problem direction.}}		{{Todo\|More investigation is needed in the microcomponent-as-group-problem direction.}}

Apm: /* Awfully implemented inheritance */ cleared the wikitodo

2023-10-11T07:41:34Z

Awfully implemented inheritance: cleared the wikitodo

@@ Line 28: / Line 28: @@
 == Awfully implemented inheritance ==
-* Desired: semi manual backward update distribution ...
+Base geometry and overrides is in principle a good idea (assuming overrides being further overridable). <br>
-{{wikitodo|elaborate}}
+<small>(not referring to terrible ad-hoc invented OOP inheritance like in C++)</smalL>
 == Microcomponents ==

Apm: Massive improvements on intro and section == Heavily restricted functions ==

2023-10-11T07:02:48Z

Massive improvements on intro and section == Heavily restricted functions ==

← Older revision		Revision as of 09:02, 11 October 2023
Line 2:		Line 2:
	Up: '''[[Software trouble pages]]'''		Up: '''[[Software trouble pages]]'''

	~~Grouping~~ functionality for geometries like found in ~~very~~ many rastergraphic, vectorgraphic and 3D-modelling programs ~~that~~ have a graphical user interface and mouse interaction is ~~(beside holding things together against accidental breakup)~~ supposed to make the grouped things reusable.		The grouping functionality for geometries like it is found in <br>
			many rastergraphic, vectorgraphic and 3D-modelling programs which have <br>
			a graphical user interface and mouse interaction is supposed to make the grouped things reusable.
			(well and to holding things together such that they can be drag and dropped moved as a whole)

	While this works for ~~the very simplest~~ cases the approach fails for anything beyond that.		While this approach works for "simple" cases the approach fails for anything beyond that.

	The problems are that:		The problems are that:

	* Groupings are ~~crippled~~ functions.		* Groupings are basically just heavily restricted functions.
	* When duplicated groupings are often irreversibly detached from the original.		* When duplicated groupings are often irreversibly detached from the original.
	* Groupings have usually no or ~~broken~~ inheritance.		* Groupings have usually no or awfully implemented inheritance.

	== ~~Crippled~~ functions ==		== Heavily restricted functions ==

	Groupings have a fixed set of parameters that all are implicitly hidden in most cases.		Groupings have a fixed set of parameters that all are implicitly hidden in most cases. <br>
	~~Linear~~ transformations: translation (insertion point), scaling, rotation, sometimes shearing.		The implicit parameters are usually only linear transformations applied to the whole grouping: <br>
	Other transformations (~~programmatic in general not only continuous~~ nonlinear like swirls and such~~) are usually not possible~~. Even ~~less if one wants~~ nontrivial changes where the same object may ~~even have~~ completely different ~~looks~~ (good abstractions ~~ high levels of [[data compression]]).		That is: translation (insertion point), scaling, rotation, sometimes shearing. <br>
			Other transformations are usually not possible. <br>
			Other transformations does not just meas simple weird (and rarely useful) nonlinear transformations like swirls and such but <br>
			General programmatic transformations changing specific details in specific ways on specific potentially highly nontrivial conditions. <br>
			Even nontrivial changes where the same "object" may end up with a completely different look. <br>
			(good abstractions ~~ high levels of [[data compression]]).

	== ~~Broken~~ inheritance ==		== Awfully implemented inheritance ==

	* Desired: semi manual backward update distribution ...		* Desired: semi manual backward update distribution ...

Apm: Up: '''Software trouble pages'''

2023-07-11T11:18:42Z

Up: '''Software trouble pages'''

← Older revision		Revision as of 13:18, 11 July 2023
Line 1:		Line 1:
	{{stub}}		{{stub}}
			Up: '''[[Software trouble pages]]'''

	Grouping functionality for geometries like found in very many rastergraphic, vectorgraphic and 3D-modelling programs that have a graphical user interface and mouse interaction is (beside holding things together against accidental breakup) supposed to make the grouped things reusable.		Grouping functionality for geometries like found in very many rastergraphic, vectorgraphic and 3D-modelling programs that have a graphical user interface and mouse interaction is (beside holding things together against accidental breakup) supposed to make the grouped things reusable.

Apm: added Category:Programming

2023-07-11T11:00:00Z

added Category:Programming

← Older revision		Revision as of 13:00, 11 July 2023
Line 32:		Line 32:

	* [[Naive groupings as dumbed down functions]]		* [[Naive groupings as dumbed down functions]]

			[[Category:Programming]]

Apm: added link to yet unwritten page data compression

2022-01-26T09:21:34Z

added link to yet unwritten page data compression

← Older revision		Revision as of 11:21, 26 January 2022
Line 14:		Line 14:
	Groupings have a fixed set of parameters that all are implicitly hidden in most cases.		Groupings have a fixed set of parameters that all are implicitly hidden in most cases.
	Linear transformations: translation (insertion point), scaling, rotation, sometimes shearing.		Linear transformations: translation (insertion point), scaling, rotation, sometimes shearing.
	Other transformations (programmatic in general not only continuous nonlinear like swirls and such) are usually not possible. Even less if one wants nontrivial changes where the same object may even have completely different looks (good abstractions ~~ high levels of data compression).		Other transformations (programmatic in general not only continuous nonlinear like swirls and such) are usually not possible. Even less if one wants nontrivial changes where the same object may even have completely different looks (good abstractions ~~ high levels of [[data compression]]).

	== Broken inheritance ==		== Broken inheritance ==

Apm: added link to duplicate page: Naive groupings as dumbed down functions

2021-11-21T20:58:19Z

added link to duplicate page: Naive groupings as dumbed down functions

← Older revision		Revision as of 22:58, 21 November 2021
Line 28:		Line 28:
	that does not suffer from the "grouping"-problem. <br>		that does not suffer from the "grouping"-problem. <br>
	{{Todo\|More investigation is needed in the microcomponent-as-group-problem direction.}}		{{Todo\|More investigation is needed in the microcomponent-as-group-problem direction.}}

			== Related ==

			* [[Naive groupings as dumbed down functions]]