[GSoC]Idea

[miniBill]

I think the 3 coordinates system is the best one for
in memory representation, as it allows to write
algorithms with no needs for special cases.
On the other hand the .kig file format could
keep using 2 coordinates for non-infinity points.

Are you worried about reading "pre-projective" files
or how a "pre-projective" kig would read the new ones?

With regards to data size increase I don't really think
that would be an issue unless the drawing becomes
really complicated, and it would still "only" require
50% more memory.

A plus side of not having special values is that
algorithms would generalize better to non-euclidean,
non-planar or non-real geometries.


2013/4/8 Maurizio Paolini <paolini at dmf.unicatt.it>

> 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
>
> _______________________________________________
> kde-edu mailing list
> kde-edu at mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-edu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20130408/5503efaa/attachment.html>