<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>I think the 3 coordinates system is the best one for <br></div>in memory representation, as it allows to write<br></div>algorithms with no needs for special cases.<br>

</div>On the other hand the .kig file format could<br></div>keep using 2 coordinates for non-infinity points.<br><br></div>Are you worried about reading "pre-projective" files<br>or how a "pre-projective" kig would read the new ones?<br>

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

</div>A plus side of not having special values is that<br></div>algorithms would generalize better to non-euclidean,<br>non-planar or non-real geometries.<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

2013/4/8 Maurizio Paolini <span dir="ltr"><<a href="mailto:paolini@dmf.unicatt.it" target="_blank">paolini@dmf.unicatt.it</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Speaking of kig internals, I see too different ways to proceed,<br>
the most natural would be to use 3 coordinates instead of 2 for<br>
points coordinates, the other would be to introduce some "special"<br>
values of the present 2 coordinates (e.g. +infinity or -infinity<br>
for the x coordinate and real numbers for the y coordinate).<br>
The first approach would increase the overall data size of a<br>
construction, but anyway it seems to me the way to go *if* we<br>
decide to implement points at infinity.<br>
<br>
I would like however to make a preliminar comment: compatibility<br>
of kig with present save files (.kig files) is paramount and<br>
we should be careful about this issue.<br>
<span class="HOEnZb"><font color="#888888"><br>
Maurizio<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Mon, Apr 08, 2013 at 03:15:44PM +0200, miniBill wrote:<br>
> 2013/3/27 Maurizio Paolini <<a href="mailto:paolini@dmf.unicatt.it">paolini@dmf.unicatt.it</a>><br>
><br>
> > I would like to mention that some of the internals of kig are already based<br>
> > on projective type of data.  Most notably, almost all transformation (the<br>
> > only<br>
> > exception is circular inversion) are internally treated as a linear<br>
> > transformation<br>
> > of the projective plane (i.e. a 3x3 matrix defined up to a multiplication<br>
> > by<br>
> > a nonzero scalar).<br>
> ><br>
> > Maurizio<br>
> ><br>
> > That's good to know :) It will probably be easier to work on things then.<br>
><br>
> > Please, specify what kind of features are needed. It would great if<br>
> > you can describe some use cases that work with concepts of<br>
> > projective geometry.<br>
> Mostly, adding support for points at infinity,<br>
> and generalizing constructions with them.<br>
><br>
> For example generalizing construction and intersection would allow to<br>
> use Kig to show theorems of projective geometry, whose graphic<br>
> representation would then work even if some lines are parallel.<br>
> (I'm thinking about Pascal's theorem, for example).<br>
><br>
> This would also be a step in decoupling the algorithms from the<br>
> underlying field, which could open the road to nice things like:<br>
> 1) 3D geometry<br>
> 2) Projective complex spaces<br>
> 3) Noneuclidean geometry (this would need checking the code<br>
>    for euclidean assumptions!)<br>
> 4) Maybe even finite fields, who knows<br>
><br>
> Points at infinity, in my opinion, could be either represented<br>
> as points on the drawing frame border, or in a separate box.<br>
> If going for the separate box, as P^2(R) is "R^2 plus P(R)",<br>
> I'd represent points at infinity as a circle, with the point<br>
> {^t}(x y 0) \in P^2(R) represented as a point<br>
> with coordinates equal to his normalized form.<br>
><br>
> Leonardo Taglialegne<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> kde-edu mailing list<br>
> <a href="mailto:kde-edu@mail.kde.org">kde-edu@mail.kde.org</a><br>
> <a href="https://mail.kde.org/mailman/listinfo/kde-edu" target="_blank">https://mail.kde.org/mailman/listinfo/kde-edu</a><br>
<br>
_______________________________________________<br>
kde-edu mailing list<br>
<a href="mailto:kde-edu@mail.kde.org">kde-edu@mail.kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-edu" target="_blank">https://mail.kde.org/mailman/listinfo/kde-edu</a><br>
</div></div></blockquote></div><br></div>