[GSoC]Idea

Maurizio Paolini paolini at dmf.unicatt.it
Mon Apr 8 15:42:33 UTC 2013


Speaking of kig internals, I see too different ways to proceed,
the most natural would be to use 3 coordinates instead of 2 for
points coordinates, the other would be to introduce some "special"
values of the present 2 coordinates (e.g. +infinity or -infinity
for the x coordinate and real numbers for the y coordinate).
The first approach would increase the overall data size of a
construction, but anyway it seems to me the way to go *if* we
decide to implement points at infinity.

I would like however to make a preliminar comment: compatibility
of kig with present save files (.kig files) is paramount and
we should be careful about this issue.

Maurizio

On Mon, Apr 08, 2013 at 03:15:44PM +0200, miniBill wrote:
> 2013/3/27 Maurizio Paolini <paolini at dmf.unicatt.it>
> 
> > I would like to mention that some of the internals of kig are already based
> > on projective type of data.  Most notably, almost all transformation (the
> > only
> > exception is circular inversion) are internally treated as a linear
> > transformation
> > of the projective plane (i.e. a 3x3 matrix defined up to a multiplication
> > by
> > a nonzero scalar).
> >
> > Maurizio
> >
> > That's good to know :) It will probably be easier to work on things then.
> 
> > Please, specify what kind of features are needed. It would great if
> > you can describe some use cases that work with concepts of
> > projective geometry.
> Mostly, adding support for points at infinity,
> and generalizing constructions with them.
> 
> For example generalizing construction and intersection would allow to
> use Kig to show theorems of projective geometry, whose graphic
> representation would then work even if some lines are parallel.
> (I'm thinking about Pascal's theorem, for example).
> 
> This would also be a step in decoupling the algorithms from the
> underlying field, which could open the road to nice things like:
> 1) 3D geometry
> 2) Projective complex spaces
> 3) Noneuclidean geometry (this would need checking the code
>    for euclidean assumptions!)
> 4) Maybe even finite fields, who knows
> 
> Points at infinity, in my opinion, could be either represented
> as points on the drawing frame border, or in a separate box.
> If going for the separate box, as P^2(R) is "R^2 plus P(R)",
> I'd represent points at infinity as a circle, with the point
> {^t}(x y 0) \in P^2(R) represented as a point
> with coordinates equal to his normalized form.
> 
> Leonardo Taglialegne

> _______________________________________________
> kde-edu mailing list
> kde-edu at mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-edu



More information about the kde-edu mailing list