[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 16:39:42
Message-ID: CAK6LAGFejhBx17pv6pUdAW_AhWZ-OXWe=e9S858BCAAAoEZL8g () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
2013/4/8 Maurizio Paolini <paolini@dmf.unicatt.it>
> Going from 2 to 3 coordinates is a big change, we need
> a broad agreement before proceeding.
>
Most definatively.
On the long term I think the best thing would be having
all algorithms that can work on generic spaces do so.
>
> On Mon, Apr 08, 2013 at 05:50:24PM +0200, miniBill wrote:
> > 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.
>
> yes...
> > Are you worried about reading "pre-projective" files
> > or how a "pre-projective" kig would read the new ones?
>
> Mostly the first. The second would mostly be ok if we stick
> to your assertion above, and anyway the scenario of an old
> kig that opens a new save file seems less worrying.
>
Well, the file format already has a field for the file version.
We could simply keep the old reader for old files,
but make it produce the new in-memory data.
> > 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.
>
> However, do not forget that *very complicated* constructions are
> possible using the "external" python scripting (pykig), like
> fractals and iterative geometric constructions. We cannot
> just dismiss them.
>
> Maurizio
>
Python script does indeed allow for more complicated objects,
but I think people using it should weigh in now.
One thing I've in doubt about is whether "projective" should be
the only way kig would work, or just a "coordinate system",
as there could be applications in which one want an euclidean
space instead of a full projective one.
One other thing that worries me is the concept of angles,
which from a theoretical point of view is proper to euclidean
spaces only (although one can easily imagine how it would
be extended even if one or two of the points are at infinity).
[Attachment #5 (text/html)]
<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>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic