Proposal: Geometry Classes

> Hi Marcel,
> I see the POV of classification for understanding and teaching. But isn't
> there also the perspective of re-constructing a system from minimal
> core/kernel ?
> Also, is SmallInteger really related to Math? I do not see it as a
> specialization, but rather as providing some kernel operations (primitives)
> onto which we can build/generalize Integer math.
>
> Le mer. 10 mars 2021 ?? 09:48, Marcel Taeumel <[hidden email]> a
> ??crit :
>
> > Hi Nicolas,
> >
> > in the long term, we might want to re-design the entire "Kernel"
> > perspective to be specialized attachments to other packages. I would like
> > to see a clear separation of non-programming, high-level concepts and
> > technical, low-level optimizations.
> >
> > For example, "Integer" could be discoverable through "Math-Quantity" while
> > "SmallInteger" could reside in "MathExtras-Kernel" or similar. Eventually,
> > we would turn around the perspective from primarily technical to primarily
> > conceptual. Note that the inheritance tree would still look the same.
> >
> > Another example would consider RawBitsArray. "Rectangle" could reside in
> > "Math-Geometry" while "Float32Rectangle" could be a subclass of
> > "Float32Array" and hence reside in "MathExtras-Collections" or similar,
> > optimized for FFI.
> >
> > A similar example can be constructed for "Quanternion" and
> > "Float32Quaternion".
> >
> > Best,
> > Marcel
> >
> > Am 09.03.2021 18:49:55 schrieb Nicolas Cellier <
> > [hidden email]>:
> > Wow, high level of brainstorming, not sure I can catch up ;)
> >
> > I'm not sure whether Number subclasses should be put in Math, they are
> > so essential to the Kernel...
> >
> > What could obviously go in some extra Math-something is for example
> > all the function extensions (inverse trigonometry, hyperbolic, ...)
> > For trigonometry, not sure, it's essential to geometry.
> > Also the accelerated large integer arithmetic would find its place in
> > some extra package (not required in Kernel).
> > No problem if you want Quaternion in trunk, if it can be useful for 3D
> > geometry, then good.
> >
> > For RawBitArray, I'm not sure, it's more specific to programming than
> > math per se (the fact that we use bounded integers of some
> > byte-size...). RawBitsArray really shine when interacting with the
> > outside world (importing large data sets from some standard format
> > and/or passing them to FFI).
> >
> > Le mar. 9 mars 2021 ?? 14:28, Marcel Taeumel a ??crit :
> > >
> > > > non-ultimate partition
> > >
> > > The system evolves. Code changes. New insights will influence onward
> > refactorings. That's always the baseline. ;-)
> > >
> > > Best,
> > > Marcel
> > >
> > > Am 09.03.2021 14:27:06 schrieb Thiede, Christoph :
> > >
> > > From the perspective of "good old baby steps" and with the notion of
> > "Extras" as a non-ultimate partition in mind, this sounds very reasonable
> > ... :-)
> > >
> > >
> > > Best,
> > >
> > > Christoph
> > >
> > > ________________________________
> > > Von: Squeak-dev im Auftrag von Taeumel, Marcel
> > > Gesendet: Dienstag, 9. M??rz 2021 14:22:47
> > > An: squeak-dev
> > > Betreff: Re: [squeak-dev] About a new "Math" package ... (was: Proposal:
> > Geometry Classes)
> > >
> > > First step would be to assess whether something is "core or not". And
> > "SomethingExtras" or "SomethingExtension" is a familiar pattern for this.
> > Once a "MathExtras" package severely lacks cohesion, we can split it up
> > again.
> > >
> > > Best,
> > > Marcel
> > >
> > > Am 09.03.2021 14:18:39 schrieb Thiede, Christoph :
> > >
> > > Yeah, I see this point, but still ... "Extras" sounds kind of arbitrary
> > to me. If you cannot find a precise name for a package, how high can its
> > coherency be? :-)
> > >
> > >
> > > Best,
> > > Christoph
> > > ________________________________
> > > Von: Squeak-dev im Auftrag von Taeumel, Marcel
> > > Gesendet: Dienstag, 9. M??rz 2021 14:05:58
> > > An: squeak-dev
> > > Betreff: Re: [squeak-dev] About a new "Math" package ... (was: Proposal:
> > Geometry Classes)
> > >
> > > MathExtras might host low-level optimizations, as I exemplified:
> > >
> > > > And I would like to add that "number crunching" part around fancy
> > graphics (e.g. OpenGL through FFI) to "Math-Collections" or maybe
> > "MathExtras-Collections", looking at all the subclasses of RawBitsArray.
> > >
> > > :-) I assume that it may be beneficial to at least decide whether
> > something is "core" or "extra". I would like to have this for "Math" from
> > the beginning.
> > >
> > > Best,
> > > Marcel
> > >
> > > Am 09.03.2021 13:10:39 schrieb Thiede, Christoph :
> > >
> > > Referring to the MathExtras proposal ... What is your general idea of an
> > extra package? I know Morphic-Extras as a collection of non-necessary
> > tools, helpers, and demos, but the general idea sounds kind of vague to me.
> > >
> > >
> > > CollectionsExtras would be a place for Text enhancements such as
> > attributes (so actually, we could also call it simply "TextSupport" or
> > something like this), MathExtras would contain "math stuff that is not
> > necessary" ...
> > >
> > > Do you have any more precise idea of what classifies an extra package or
> > would "MathSmorgasbord" be a franker name for the package? If yes, this
> > would make me think about the coherency of such a package ... Just my 2
> > cents, of course. :)
> > >
> > >
> > > Best,
> > >
> > > Christoph
> > >
> > > ________________________________
> > > Von: Thiede, Christoph
> > > Gesendet: Dienstag, 9. M??rz 2021 12:56:04
> > > An: squeak-dev
> > > Betreff: AW: [squeak-dev] About a new "Math" package ... (was: Proposal:
> > Geometry Classes)
> > >
> > >
> > > Hi Marcel,
> > >
> > >
> > > sounds interesting! I have a few thoughts regarding package dependencies.
> > >
> > >
> > > As far as I understand, the dependency structure would look kind like
> > this:
> > >
> > >
> > > Kernel-Objects -> Math-Quantity (see senders of SmallInteger for
> > example), Math-Analysis (see senders of #asFloat for example)
> > >
> > > Math-Quantity -> Kernel (superclass), Math-Analysis (see senders of
> > #asFloat)
> > >
> > > Math-Analysis -> Kernel (superclass), Math-Quantity (maybe?)
> > >
> > > Math-Geometry -> Kernel (of course), Math-Quantity (senders of
> > SmallInteger), Math-Analysis (see senders of #asFloat)
> > >
> > > Math-Collections would probably depend on all other packages?
> > >
> > >
> > > The question is which of these dependencies can be eliminated and which
> > are a problem at all.
> > >
> > >
> > > What about Random? Do you want to keep it in Kernel, depending on Math?
> > >
> > >
> > > What is about dependencies from Number (Kernel-Objects) to Float
> > (Math-Analysis), for example, #asFloat, but also sophisticated things such
> > as #sin? Do we want to create a bunch of extension methods for this?
> > >
> > > In any case, I think the "math functions" protocol on Collection should
> > become an extension protocol ("*Math-Analysis" or
> > "*Math-Analysis-enumerating").
> > >
> > >
> > > Best,
> > > Christoph
> > > ________________________________
> > > Von: Squeak-dev im Auftrag von Taeumel, Marcel
> > > Gesendet: Dienstag, 9. M??rz 2021 10:50:09
> > > An: squeak-dev
> > > Betreff: [squeak-dev] About a new "Math" package ... (was: Proposal:
> > Geometry Classes)
> > >
> > > Hi all!
> > >
> > > I think that we would rather need a "Math" package with "Math-Geometry"
> > being one of multiple categories.
> > >
> > > Please take a look at the following proposed classification:
> > >
> > > Kernel-Objects (= not Kernel-Numbers)
> > > Magnitude
> > > Number
> > >
> > > Math-Quantity
> > > Integer (+ subclasses)
> > > Fraction
> > > ScaledDecimal
> > >
> > > Math-Analysis
> > > Complex
> > > Float (+ subclasses)
> > > Quaternion
> > >
> > > Math-Geometry
> > > Point
> > > Line
> > > Rectangle
> > > Polygon
> > > Path
> > >
> > > Math-Collections
> > > Vector2 (from 3DTransform, CroquetGL, etc.)
> > > Vector3
> > > Vector4
> > > Matrix2x3
> > > Matrix4x4
> > > VectorArray
> > > ...
> > >
> > > It would involve some effort, especially to untangle "ST80-Paths" from
> > graphics :-) Eventually, I would like to see Nicolas' efforts for "Complex"
> > and "Quaternion" in Trunk. And I would like to add that "number crunching"
> > part around fancy graphics (e.g. OpenGL through FFI) to "Math-Collections"
> > or maybe "MathExtras-Collections", looking at all the subclasses of
> > RawBitsArray.
> > >
> > > May I add "Math" and "MathExtras" packages so that we can slowly get
> > started? :-)
> > >
> > > Best,
> > > Marcel
> > >
> > > Am 22.01.2019 18:32:10 schrieb [hidden email] :
> > >
> > > Hi everyone,
> > >
> > > during some recent clean-up an issue with geometry objects came up. As a
> > result the following idea came up which I thereby would like to put out for
> > an initial discussion.
> > >
> > > In case we find that this might be useful, I would continue by
> > implementing a first prototype of the package as a foundation of a more
> > in-depth discussion later on.
> > >
> > > Bests
> > > Patrick
> > >
> > > # Squeak Change Proposal - Geometry Package
> > >
> > > ## Why?
> > > Squeak implements basic geometry logic in too many different places. For
> > example intersection of different kinds of geometric objects is implemented
> > all over Morphic, ST80, Balloon, Graphics, and Etoys. Such extensive
> > scattering across packages and classes impedes modularity, that is,
> > readability and extensibility. An example for this recently came up when we
> > discovered an issue with testing for graphical intersections between
> > PolygonMorph and RectangleMorph. It was not possible to compute that
> > overlapping area because the class Rectangle omits to provide an important
> > method. A quick fix would entail unnecessary dependencies (here: Morphic ->
> > Balloon) or duplicated code (see also
> > http://bugs.squeak.org/view.php?id=7872). Consequently, we might want to
> > modularize the geometry objects and operations. As a side effect, dependent
> > packages such as Morphic can be simplified a little bit (more).
> > >
> > > ## Scope
> > > The proposed package should cover basic 2D geometric objects and their
> > operations represented by the following classes:
> > > - Point
> > > - Line
> > > - LineSegment
> > > - Polygon
> > > - Rectangle (as an optimization as it could be represented as a special
> > Polygon already)
> > >
> > > Most classes could simply be moved from their previous packages.
> > Afterwards the interfaces would need to be made consistent with each other
> > to allow interoperability of all geometry classes within the new package.
> > >
> > > ### Affected classes:
> > > - All classes in ST80-Paths
> > > - LineSegement, Bezier2Segment, Bezier3Segment (Balloon-Geometry)
> > > - Rectangle, Quadrangle, Point (Graphics-Primitives)
> > > - LineIntersections, LineIntersectionSegment, LineIntersectionEvent
> > (Etoys-Squeakland-Graphics-Tools-Intersection)
> > >
> > > ## Open questions
> > > - Should this become a single new package or a subcategory in the
> > Graphics package?
> > > - Should the package contain an Ellipses class?
> > > - Should we model curved line segments as BezierLineSegments,
> > CurvedLineSegment, or Arc?
> > >
> > > ## Risks
> > > - This would potentially deprecate the existing ST80 geometry classes
> > (ST80-Paths)
> > > - Some of the new classes will cause name clashes with existing classes.
> > For example Line is currently in ST-80 and represents a line segment, and
> > the class LineSegment is a line segment but not in the geometric sense as
> > it also incorporates arcs. Both names might then be used by new classes
> > with different meanings. This might be mitigated by introducing a
> > pre-/postfix for the names of the new classes.
> > >
> > >
> >
> >
> >