[squeak-dev] About a new "Math" package ... (was: Proposal: Geometry Classes)

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Mar 10 10:22:03 UTC 2021


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 <marcel.taeumel at hpi.de> 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 <
> nicolas.cellier.aka.nice at gmail.com>:
> 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 patrick.rein at hpi.uni-potsdam.de :
> >
> > 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.
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210310/0bc201fc/attachment.html>


More information about the Squeak-dev mailing list