[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-edu
Subject:    Re: [GSoC]Idea
From:       miniBill <cmt.minibill () gmail ! com>
Date:       2013-04-08 13:15:44
Message-ID: CAK6LAGGRD_040RoZfCzWs-PcgzvA_Xm4Skn8t5JV8vDRycFUKQ () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


2013/3/27 Maurizio Paolini <paolini@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

[Attachment #5 (text/html)]

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

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 only<br>
exception is circular inversion) are internally treated as a linear \
transformation<br> of the projective plane (i.e. a 3x3 matrix defined up to a \
multiplication by<br> a nonzero scalar).<br>
<span class="HOEnZb"><font color="#888888"><br>
Maurizio<br>
</font></span><div class="HOEnZb"><div \
class="h5"><br></div></div></blockquote><div>That&#39;s good to know :) It will \
probably be easier to work on things then.<br><br></div><div class="h5">&gt; Please, \
specify what kind of features are needed. It would great if<br>

&gt; you can describe some use cases that work with concepts of<br>&gt; projective \
geometry.<br></div><div class="h5"> Mostly, adding support for points at \
infinity,<br>and generalizing constructions with them.<br><br></div>For example \
generalizing construction and intersection would allow to<br></div><div \
class="gmail_quote">use Kig to show theorems of projective geometry, whose \
graphic<br>

representation would then work even if some lines are parallel.<br>(I&#39;m thinking \
about Pascal&#39;s theorem, for example).<br><br></div><div class="gmail_quote">This \
would also be a step in decoupling the algorithms from the<br>

</div><div class="gmail_quote">underlying field, which could open the road to nice \
things like:<br></div><div class="gmail_quote">1) 3D geometry<br></div><div \
class="gmail_quote">2) Projective complex spaces<br></div><div class="gmail_quote">

3) Noneuclidean geometry (this would need checking the code<br>     for euclidean \
assumptions!)<br></div><div class="gmail_quote">4) Maybe even finite fields, who \
knows<br><br></div><div class="gmail_quote">Points at infinity, in my opinion, could \
be either represented<br>

as points on the drawing frame border, or in a separate box.<br></div><div \
class="gmail_quote">If going for the separate box, as P^2(R) is &quot;R^2 plus \
P(R)&quot;,<br>I&#39;d represent points at infinity as a circle, with the point<br>

</div><div class="gmail_quote">{^t}(x y 0) \in P^2(R) represented as a point<br>with \
coordinates equal to his normalized form.<br><br></div><div \
class="gmail_quote">Leonardo Taglialegne<br></div></div></div>



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


[prev in list] [next in list] [prev in thread] [next in thread]