Proposal: Geometry Classes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposal: Geometry Classes

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

Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Geometry Classes

Karl Ramberg
+1

It's quite hard to get a grasp over how to draw stuff so this sound like a step in the right direction.

Best,
Karl


On Tue, Jan 22, 2019 at 6:32 PM <[hidden email]> wrote:
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.



Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Geometry Classes

Nicolas Cellier
I wonder if this is really for drawing?
For drawing, we might need some additional attributes, like a line width, a color, end drawing policy (rounded, square, arrow...)... unless all these attributes are held into/provided by  some graphics engine states?
Also a polygon might be a specification of outline or interior. If interior, different composition rules may apply if ever the edges intersect (like in bitblt or/xor/whatever...).
My understanding is that geometric objects would handle intersection, perimeter, area, and that we could provide generic affine transforms applying on these objects. They might serve as some sort of drawing spec, maybe via a visitor pattern driven by the effective drawer (which would thus hold the states) but it's not their primary responsibility.

Le mar. 22 janv. 2019 à 19:58, karl ramberg <[hidden email]> a écrit :
+1

It's quite hard to get a grasp over how to draw stuff so this sound like a step in the right direction.

Best,
Karl


On Tue, Jan 22, 2019 at 6:32 PM <[hidden email]> wrote:
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.




Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Geometry Classes

Kjell Godo
+1

On Tue, Jan 22, 2019 at 12:08 Nicolas Cellier <[hidden email]> wrote:
I wonder if this is really for drawing?
For drawing, we might need some additional attributes, like a line width, a color, end drawing policy (rounded, square, arrow...)... unless all these attributes are held into/provided by  some graphics engine states?
Also a polygon might be a specification of outline or interior. If interior, different composition rules may apply if ever the edges intersect (like in bitblt or/xor/whatever...).
My understanding is that geometric objects would handle intersection, perimeter, area, and that we could provide generic affine transforms applying on these objects. They might serve as some sort of drawing spec, maybe via a visitor pattern driven by the effective drawer (which would thus hold the states) but it's not their primary responsibility.

Le mar. 22 janv. 2019 à 19:58, karl ramberg <[hidden email]> a écrit :
+1

It's quite hard to get a grasp over how to draw stuff so this sound like a step in the right direction.

Best,
Karl


On Tue, Jan 22, 2019 at 6:32 PM <[hidden email]> wrote:
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.





Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Geometry Classes

Karl Ramberg
In reply to this post by Nicolas Cellier
You are right, of course :-)
But it will help with grasping the geometric classes, and much of that is used for drawing.

Best,
Karl



On Tue, Jan 22, 2019 at 9:08 PM Nicolas Cellier <[hidden email]> wrote:
I wonder if this is really for drawing?
For drawing, we might need some additional attributes, like a line width, a color, end drawing policy (rounded, square, arrow...)... unless all these attributes are held into/provided by  some graphics engine states?
Also a polygon might be a specification of outline or interior. If interior, different composition rules may apply if ever the edges intersect (like in bitblt or/xor/whatever...).
My understanding is that geometric objects would handle intersection, perimeter, area, and that we could provide generic affine transforms applying on these objects. They might serve as some sort of drawing spec, maybe via a visitor pattern driven by the effective drawer (which would thus hold the states) but it's not their primary responsibility.

Le mar. 22 janv. 2019 à 19:58, karl ramberg <[hidden email]> a écrit :
+1

It's quite hard to get a grasp over how to draw stuff so this sound like a step in the right direction.

Best,
Karl


On Tue, Jan 22, 2019 at 6:32 PM <[hidden email]> wrote:
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.





Reply | Threaded
Open this post in threaded view
|

About a new "Math" package ... (was: Proposal: Geometry Classes)

marcel.taeumel
In reply to this post by patrick.rein
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] <[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.



Reply | Threaded
Open this post in threaded view
|

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

Christoph Thiede

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 <[hidden email]> 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] <[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.



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

Christoph Thiede

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 <[hidden email]> 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] <[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.



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

marcel.taeumel
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 <[hidden email]>:

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 <[hidden email]> 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] <[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.



Reply | Threaded
Open this post in threaded view
|

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

Christoph Thiede

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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] <[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.



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

marcel.taeumel
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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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] <[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.



Reply | Threaded
Open this post in threaded view
|

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

Christoph Thiede

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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] <[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.



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

marcel.taeumel
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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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] <[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.



Reply | Threaded
Open this post in threaded view
|

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

Nicolas Cellier
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 <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]> 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] <[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.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

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



Reply | Threaded
Open this post in threaded view
|

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

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




Reply | Threaded
Open this post in threaded view
|

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

marcel.taeumel
That's right. I recall that Patrick's initial proposal was about reducing redundant implementations, most of them rather high-level.

(One reason why "Number" would remain in "Kernel" is that "Character" inherits from it. And "DateAndTime" is a "Magnitude". Hmmm...)

Hmm... so, if "Integer" would be in a "Math", would it make sense to keep "SmallInteger" in a "Kernel" package? I wouldn't have a problem with "eternally coupling" both Kernel and Math. Hmm....

For simplicity, let me focus on "SmallInteger" and "Float32Array" as two low-level optimizations. A minimal core needs minimal concepts, which should definitely include "Math" but maybe not "MathExtras"? After all, what value would a minimal core have if it cannot be used for anything meaningful? Then again, "anything meaningful" is so subjective ... Sigh. Mayber numbers aren't the best way to think about re-classification since most of them are used through literals and simple textual representations. Users do not bother with their classes.

Hmmm... back to "Geometry" again, I guess. :-) Point, Rectangle, Line, Polygon, ...

Best,
Marcel

Am 10.03.2021 11:22:23 schrieb Nicolas Cellier <[hidden email]>:

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




Reply | Threaded
Open this post in threaded view
|

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

marcel.taeumel
> (One reason why "Number" would remain in "Kernel" is that "Character" inherits from it. And "DateAndTime" is a "Magnitude". Hmmm...)

My bad. "Character" inherits from "Magnitude". Sorry for the confusion.

Best,
Marcel

Am 10.03.2021 11:45:13 schrieb Marcel Taeumel <[hidden email]>:

That's right. I recall that Patrick's initial proposal was about reducing redundant implementations, most of them rather high-level.

(One reason why "Number" would remain in "Kernel" is that "Character" inherits from it. And "DateAndTime" is a "Magnitude". Hmmm...)

Hmm... so, if "Integer" would be in a "Math", would it make sense to keep "SmallInteger" in a "Kernel" package? I wouldn't have a problem with "eternally coupling" both Kernel and Math. Hmm....

For simplicity, let me focus on "SmallInteger" and "Float32Array" as two low-level optimizations. A minimal core needs minimal concepts, which should definitely include "Math" but maybe not "MathExtras"? After all, what value would a minimal core have if it cannot be used for anything meaningful? Then again, "anything meaningful" is so subjective ... Sigh. Mayber numbers aren't the best way to think about re-classification since most of them are used through literals and simple textual representations. Users do not bother with their classes.

Hmmm... back to "Geometry" again, I guess. :-) Point, Rectangle, Line, Polygon, ...

Best,
Marcel

Am 10.03.2021 11:22:23 schrieb Nicolas Cellier <[hidden email]>:

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




Reply | Threaded
Open this post in threaded view
|

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

David Duke
In reply to this post by marcel.taeumel
Interesting discussion. Throws up issues that I and possibly others have had getting started with Smalltalk in general.
What are the criteria by which classes are arranged into categories? Leaving an element of subjective choice may be
helpful, but some guidelines might not go amiss.
Whilst the design choice of single inheritance for classes has been done to death. Is there any reason to restrict
classes to a single category. After all its primary use I believe is as an aid to navigating the classes via inspectors.
And there as been work on UIs for multi-dimensional data/hierarchies. Take 'Polygon' as an example
I might  expect to find it  under:
- graphics, where its primary uses are?
- 2D Primitives?
- geometry, as it supports geometric operations such as testing containment
- Collections, as its a collection of points, and one might want to enumerate/select.  etc

`specific cases is an orthogonal issue. Is it useful to view
rectangle/triangle etc a optimised forms of Polygon?

Now if you look elsewhere 
- Java allows classes to have implement  interfaces
- Haskell allows types to be instances of multiple type classes?

So why not allow classes to belong to multiple categories and/or categories to be connected
via different kinds of links along the lines of concepts in a semantic network...
 In ay event it would be helpful if there were some general published guidelines for
what membership of a category means any  criteria for putting classes into categories or not
and then for each category the defining characteristics of its classes?

Just some thoughts..

regards,
David.




On Wed, Mar 10, 2021 at 10:45 AM Marcel Taeumel <[hidden email]> wrote:
That's right. I recall that Patrick's initial proposal was about reducing redundant implementations, most of them rather high-level.

(One reason why "Number" would remain in "Kernel" is that "Character" inherits from it. And "DateAndTime" is a "Magnitude". Hmmm...)

Hmm... so, if "Integer" would be in a "Math", would it make sense to keep "SmallInteger" in a "Kernel" package? I wouldn't have a problem with "eternally coupling" both Kernel and Math. Hmm....

For simplicity, let me focus on "SmallInteger" and "Float32Array" as two low-level optimizations. A minimal core needs minimal concepts, which should definitely include "Math" but maybe not "MathExtras"? After all, what value would a minimal core have if it cannot be used for anything meaningful? Then again, "anything meaningful" is so subjective ... Sigh. Mayber numbers aren't the best way to think about re-classification since most of them are used through literals and simple textual representations. Users do not bother with their classes.

Hmmm... back to "Geometry" again, I guess. :-) Point, Rectangle, Line, Polygon, ...

Best,
Marcel

Am 10.03.2021 11:22:23 schrieb Nicolas Cellier <[hidden email]>:

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







Reply | Threaded
Open this post in threaded view
|

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

marcel.taeumel
Hi Dave.

Just a quick thought. :-)

> Is there any reason to restrict classes to a single category. After all its primary use I believe is as an aid to navigating the classes via inspectors.

Well, in this case, it matters big time whether one proposes something for the "Kernel" or just "MathExtras" package. One goal here is to level the path for such Trunk contributions. :-)

Best,
Marcel

Am 10.03.2021 12:19:27 schrieb David Duke <[hidden email]>:

Interesting discussion. Throws up issues that I and possibly others have had getting started with Smalltalk in general.
What are the criteria by which classes are arranged into categories? Leaving an element of subjective choice may be
helpful, but some guidelines might not go amiss.
Whilst the design choice of single inheritance for classes has been done to death. Is there any reason to restrict
classes to a single category. After all its primary use I believe is as an aid to navigating the classes via inspectors.
And there as been work on UIs for multi-dimensional data/hierarchies. Take 'Polygon' as an example
I might  expect to find it  under:
- graphics, where its primary uses are?
- 2D Primitives?
- geometry, as it supports geometric operations such as testing containment
- Collections, as its a collection of points, and one might want to enumerate/select.  etc

`specific cases is an orthogonal issue. Is it useful to view
rectangle/triangle etc a optimised forms of Polygon?

Now if you look elsewhere 
- Java allows classes to have implement  interfaces
- Haskell allows types to be instances of multiple type classes?

So why not allow classes to belong to multiple categories and/or categories to be connected
via different kinds of links along the lines of concepts in a semantic network...
 In ay event it would be helpful if there were some general published guidelines for
what membership of a category means any  criteria for putting classes into categories or not
and then for each category the defining characteristics of its classes?

Just some thoughts..

regards,
David.




On Wed, Mar 10, 2021 at 10:45 AM Marcel Taeumel <[hidden email]> wrote:
That's right. I recall that Patrick's initial proposal was about reducing redundant implementations, most of them rather high-level.

(One reason why "Number" would remain in "Kernel" is that "Character" inherits from it. And "DateAndTime" is a "Magnitude". Hmmm...)

Hmm... so, if "Integer" would be in a "Math", would it make sense to keep "SmallInteger" in a "Kernel" package? I wouldn't have a problem with "eternally coupling" both Kernel and Math. Hmm....

For simplicity, let me focus on "SmallInteger" and "Float32Array" as two low-level optimizations. A minimal core needs minimal concepts, which should definitely include "Math" but maybe not "MathExtras"? After all, what value would a minimal core have if it cannot be used for anything meaningful? Then again, "anything meaningful" is so subjective ... Sigh. Mayber numbers aren't the best way to think about re-classification since most of them are used through literals and simple textual representations. Users do not bother with their classes.

Hmmm... back to "Geometry" again, I guess. :-) Point, Rectangle, Line, Polygon, ...

Best,
Marcel

Am 10.03.2021 11:22:23 schrieb Nicolas Cellier <[hidden email]>:

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







12