<div dir="ltr"><div class="gmail_extra"><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">Going from 2 to 3 coordinates is a big change, we need<br>
a broad agreement before proceeding.<br></blockquote><div>Most definatively.<br>On the long term I think the best thing would be having<br>all algorithms that can work on generic spaces do so.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><br>
On Mon, Apr 08, 2013 at 05:50:24PM +0200, miniBill wrote:<br>
> I think the 3 coordinates system is the best one for<br>
> in memory representation, as it allows to write<br>
> algorithms with no needs for special cases.<br>
> On the other hand the .kig file format could<br>
> keep using 2 coordinates for non-infinity points.<br>
<br>
</div>yes... </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> Are you worried about reading "pre-projective" files<br>
> or how a "pre-projective" kig would read the new ones?<br>
<br>
</div>Mostly the first.  The second would mostly be ok if we stick<br>
to your assertion above, and anyway the scenario of an old<br>
kig that opens a new save file seems less worrying.<br></blockquote><div>Well, the file format already has a field for the file version.<br></div><div>We could simply keep the old reader for old files,<br>but make it produce the new in-memory data.<br>

</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> With regards to data size increase I don't really think<br>
> that would be an issue unless the drawing becomes<br>
> really complicated, and it would still "only" require<br>
> 50% more memory.<br>
<br>
</div>However, do not forget that *very complicated* constructions are<br>
possible using the "external" python scripting (pykig), like<br>
fractals and iterative geometric constructions.  We cannot<br>
just dismiss them.<br>
<span><font color="#888888"><br>
Maurizio<br></font></span></blockquote><div>Python script does indeed allow for more complicated objects,<br></div><div>but I think people using it should weigh in now.<br><br></div><div>One thing I've in doubt about is whether "projective" should be<br>

</div><div>the only way kig would work, or just a "coordinate system",<br></div><div>as there could be applications in which one want an euclidean<br>space instead of a full projective one.<br></div><div>One other thing that worries me is the concept of angles,<br>

</div><div>which from a theoretical point of view is proper to euclidean<br>spaces only (although one can easily imagine how it would<br>be extended even if one or two of the points are at infinity).<br></div></div></div>

</div>