pyx-devel — PyX development

[PyX-devel] $B$9$3$9$3!y(BNIGHT

[<in...@ha...>]

体験ブログ『ハメパン』
ハメれる！ヤれる！ハメまくれ！！
◆今回の体験者⇒マスオ◆

　http://hunter.deai-gogo.net/hamepan/old/bl_0822

今夜のおかずは『まさみちゃん』に決定！(*^▽^*)ノ
とりあえず簡単に結果報告します〜♪

この日は、HOTELではなく、なんとまさみチャンのお家へ。
ハメ撮りもOK?かと思いきやビックリすることに、
まさみチャンもビデオを撮りたいと。。。(￣△￣；)さらにエッ・・・ 
結果撮り合い？になりました。（悪用されませんように・・・）笑

　http://hunter.deai-gogo.net/hamepan/old/bl_0822

まさみチャンは、もっとエッチがうまくなりたいんだって。
月一でレッスンする事になりました。
∩(´∀｀∩) ワッショーイ！ワッショーイ ！(∩´∀｀)∩　

　http://hunter.deai-gogo.net/hamepan/old/bl_0822



配信拒否のかたは

　cha...@ya...

　




.

[PyX-devel] $BG3$($F$k%*%s%J$NL<C#$rAj<j$KJ3@o$@(B !!

[<in...@ju...>]

淫乱な女のコ達のエッチィなリクエストに答えようッ！！

魅惑の秋を制覇してホットな冬のリゾートへ準備せよ！！

　http://koikoi.deai-gogo.net/bo_navi.html

『新婚６ヶ月でほったらかし状態のマミです(→o←)ゞ
人妻になっちゃってもエロエロは治まりませんヾ(*´∀｀*)ノキャッキャ♪
イチャイチャ・・しながら・・たくさんHな事したいな。。
すごく敏感なチクビ・・凄く濡れやすいよ・・よろしくね(*^.^*)』

　http://koikoi.deai-gogo.net/bo_navi.html

『「ゆき」でぇす(*´ェ`*)
リードされるの大好き、いぢられるの大好き(￣∇￣*)ゞ
あ、いぢめる人だけはキライです。
元気だけど、寂しがりやなゆきに、いっぱいかまってくださいね！♪』

　http://koikoi.deai-gogo.net/bo_navi.html

問い合わせ＆配信拒否は下記までどうぞ

　hai...@ya...

[PyX-devel] $B<B$j$N=)(B!! $BFCA*%i%s%-%s%0$G7h$^$j(B!!

[<in...@ni...>]

　http://koikoi.deai-gogo.net/ainikite_bo.html

レジャーにグルメに実り多い秋にホットな
デートを決めろ!!　雑誌広告において売り出し中の
最新サイトを過激にピックアップしたぞっ!!

　http://koikoi.deai-gogo.net/ainikite_bo.html

↓女のコの一例。
『こんばんわぁ☆RuRuテ゛ス♪(*・ω・*)
Ruruは小さい頃からオナニストだったの(*ノノ)いつも
本気で感じて本気でイッちゃいます♪
(/ω＼*)何回もイッちゃうの…♪…。恥ずかしがり屋だけど大胆な所も…エヘヘ♪
Ruruと一緒にデートからはじめましょ♪

アナル星・うん地区在住です(∩∀`*)』

　http://koikoi.deai-gogo.net/ainikite_bo.html

大衝撃！濃厚エッチで下のおクチも息子も大満足確定！

　http://koikoi.deai-gogo.net/ainikite_bo.html

問い合わせ＆配信拒否は

　hai...@ya...






















.

[PyX-devel] IRL-GIRL

[<in...@ba...>]

 http://pure.pmp.to/girl-girl

◆◇◆◇ランキング＆オトナのブログ集◆◇◆◇

☆いま全国でもっとも人気のあるサイトTOP8☆

 http://pure.pmp.to/girl-girl

◆注目！！新着もご紹介（＾−＾）

 http://pure.pmp.to/girl-girl

おまけはかなり過激なオトナのブログ付♪

 http://pure.pmp.to/girl-girl

メールを拒否する方は

 toi...@ya...




.

Re: [PyX-devel] Re: [PyX-checkins] pyx/pyx normpath.py,1.10,1.11

[Andre W. <wo...@us...>]

Hi,

On 28.09.05, Michael Schindler wrote:
> A clear -1 from me for option 3. Just because of what you say:
> 
> > This also makes it impossible to build a normsubpath by
> > first creating an empty one and then filling it with normsubpathitems.
> > This might be unhandy.
> 
> Especially for deformers, ... where new normpaths are built. It is a
> very convenient feature of the normpaths that the can be built in a
> loop without always testing if it has been created already. This is
> what made the smoother e.g. unreadable.

Ok, the alternative would be to first just collect all
normsubpathitems and build the whole normsubpath in the end (when
there is at least one normsubpathitem). That's at least an option.
It would be clear from the very beginning. And doing it that way I
guess it wouldn't create unreadable code.

> On the level of normsubpaths, which are used internally I would like
> to keep the creation procedure with an emtpy normsubpath.
> On the level of normpaths, this could be different.
> What about forbidding to _add_ an empty normsubpath to a normpath?

Ok, that's interesting. We could even silently ignore to add it. I
think this would not create any problems for daily use. What do you
think about that? I kind of like the idea.

Overall I would also like to hear some other opinions (especially from
Jörg).


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] Re: [PyX-checkins] pyx/pyx normpath.py,1.10,1.11

[Michael S. <m-s...@us...>]

On 28.09.05, Andre Wobst wrote:
> Hi,
> 
> On 28.09.05, André Wobst wrote:
> > allow pathitem append on empty normpath
> > ...
> > !             if self.normsubpaths:
> > !                 context = path.context(*(self.normsubpaths[-1].atend_pt() +
> > !                                          self.normsubpaths[-1].atbegin_pt()))
> > !                 item.updatenormpath(self, context)
> > !             else:
> > !                 self.normsubpaths = item.createnormpath(self).normsubpaths
> 
> There is an interesting misfeature in the normpath: We can descripe a
> path without a currentpoint, which is not empty. This is done by an
> empty normsubpath (neither having any normsubpathitems nor a
> skippedline) used as the last normsubpath in a normpath. In PostScript
> you can't describe such a path. Only a completely empty path doesn't
> have a currentpoint.
> 
> There are several options here:
> 
> 1) We can ignore that. (But the code fragment shown above will fail
>    when adding a pathitem to such a normpath (=self).)
> 
> 2) We can forbid to have an empty normsubpath as the last normpath
>    except when we have only a single normsubpath, i.e. the path is
>    still completely empty.
> 
> 3) Any normsubpath should have a currentpoint (or a movetopoint or a
>    staringpoint or whatever you name it). We would not need the trick
>    with the zero-length skippedline for descriping a moveto anymore.

> I'm +1 for option 3. Note that this implies, that an empty path cannot
> contain any normsubpath anymore. Not even an empty one, since there
> are no real "empty" normsubpaths anymore, since they at least have
> a movetopoint.

A clear -1 from me for option 3. Just because of what you say:

> This also makes it impossible to build a normsubpath by
> first creating an empty one and then filling it with normsubpathitems.
> This might be unhandy.

Especially for deformers, ... where new normpaths are built. It is a
very convenient feature of the normpaths that the can be built in a
loop without always testing if it has been created already. This is
what made the smoother e.g. unreadable.

On the level of normsubpaths, which are used internally I would like
to keep the creation procedure with an emtpy normsubpath.
On the level of normpaths, this could be different.
What about forbidding to _add_ an empty normsubpath to a normpath?

Then, the question
  if self.normsubpaths:

really does what you expect it to do.
The creation of a normpath reads then:
1. create an empty normpath
2. create the normsubpaths in a loop
2a add them if they are not empty

Alltoghether, this is a little weaker than your option 2
which gets a +1 from me.

4) Another possiblity would be a self.good() which tests each normsubpath for
   filling (-1 from me because it will be sloooooow)

> Last but not least we should take into account,
> that the epsilon is a feature of a normsubpath. In order to set the
> epsilon we would also need to set the starting point either by passing
> some normsubpathitems or by setting it explicitly (as a moveto would
> do it instead of using the skippedline-trick).

Michael.

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.

[PyX-devel] Re: [PyX-checkins] pyx/pyx normpath.py,1.10,1.11

[Andre W. <wo...@us...>]

Hi,

On 28.09.05, André Wobst wrote:
> allow pathitem append on empty normpath
> ...
> !             if self.normsubpaths:
> !                 context = path.context(*(self.normsubpaths[-1].atend_pt() +
> !                                          self.normsubpaths[-1].atbegin_pt()))
> !                 item.updatenormpath(self, context)
> !             else:
> !                 self.normsubpaths = item.createnormpath(self).normsubpaths

There is an interesting misfeature in the normpath: We can descripe a
path without a currentpoint, which is not empty. This is done by an
empty normsubpath (neither having any normsubpathitems nor a
skippedline) used as the last normsubpath in a normpath. In PostScript
you can't describe such a path. Only a completely empty path doesn't
have a currentpoint.

There are several options here:

1) We can ignore that. (But the code fragment shown above will fail
   when adding a pathitem to such a normpath (=self).)

2) We can forbid to have an empty normsubpath as the last normpath
   except when we have only a single normsubpath, i.e. the path is
   still completely empty.

3) Any normsubpath should have a currentpoint (or a movetopoint or a
   staringpoint or whatever you name it). We would not need the trick
   with the zero-length skippedline for descriping a moveto anymore.

I'm +1 for option 3. Note that this implies, that an empty path cannot
contain any normsubpath anymore. Not even an empty one, since there
are no real "empty" normsubpaths anymore, since they at least have
a movetopoint. This also makes it impossible to build a normsubpath by
first creating an empty one and then filling it with normsubpathitems.
This might be unhandy. Last but not least we should take into account,
that the epsilon is a feature of a normsubpath. In order to set the
epsilon we would also need to set the starting point either by passing
some normsubpathitems or by setting it explicitly (as a moveto would
do it instead of using the skippedline-trick).

Still, I'm in favor of option 3. Comments?


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

[PyX-devel] [ pyx-Bugs-1299096 ] OverflowError if input y data is constant

[SourceForge.net <no...@so...>]

Bugs item #1299096, was opened at 2005-09-22 22:19
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1299096&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: lszumel (lszumel)
Assigned to: Nobody/Anonymous (nobody)
Summary: OverflowError if input y data is constant

Initial Comment:
If min and max are not specified on an axis (I'm using
graph.axis.linear), and the y-data is constant,
parter.py gets an OverflowError when trying to compute
the range (log(max - min) == log(0) => math range
error). Feature or bug?

I'm using PyX 0.8. Here is the trace:


Traceback (most recent call last):
  File "./mycode.py", line 46, in ?
    c.writeEPSfile('somefile')
  File
"/usr/lib/python2.3/site-packages/pyx/canvas.py", line
326, in writeEPSfile
    document.document([document.page(self,
**kwargs)]).writeEPSfile(filename)
  File
"/usr/lib/python2.3/site-packages/pyx/document.py",
line 138, in writeEPSfile
    pswriter.epswriter(self, filename, *args, **kwargs)
  File
"/usr/lib/python2.3/site-packages/pyx/pswriter.py",
line 235, in __init__
    bbox = page.bbox()
  File
"/usr/lib/python2.3/site-packages/pyx/document.py",
line 78, in bbox
    bbox = self.canvas.bbox()
  File
"/usr/lib/python2.3/site-packages/pyx/canvas.py", line
161, in bbox
    abbox = cmd.bbox()
  File
"/usr/lib/python2.3/site-packages/pyx/graph/graph.py",
line 445, in bbox
    self.finish()
  File
"/usr/lib/python2.3/site-packages/pyx/graph/graph.py",
line 342, in finish
    self.domethods[0]()
  File
"/usr/lib/python2.3/site-packages/pyx/graph/graph.py",
line 275, in dolayout
    self.axes[key].create(self.texrunner)
  File
"/usr/lib/python2.3/site-packages/pyx/graph/axis/axis.py",
line 526, in create
    self.canvas = self.axis.create(self.data,
self.positioner, graphtexrunner, self.errorname)
  File
"/usr/lib/python2.3/site-packages/pyx/graph/axis/axis.py",
line 163, in create
    self.min is None, self.max is None)
  File
"/usr/lib/python2.3/site-packages/pyx/graph/axis/parter.py",
line 148, in partfunctions
    logmm = math.log(max - min) / math.log(10)
OverflowError: math range error


----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2005-09-23 07:22

Message:
Logged In: YES 
user_id=405853

I agree that the exception is bad, since it doesn't guide you to the source 
of the problem. I fixed it in the CVS head (i.e. for 0.9) some time ago 
already, where now a RuntimeError with the description "partitioning failed 
due to empty or invalid axis range" is raised instead. I hope this helps to 
clearify the situation. Beside that (and its not the first time we're 
discussing this issue) I just don't know how to proper handle this case, 
since I don't want some strange magic for such a case, where I just can't 
tell what the user really wants. I think an exception is the only option we 
have.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1299096&group_id=45430

[PyX-devel] [ pyx-Bugs-1299096 ] OverflowError if input y data is constant

[SourceForge.net <no...@so...>]

Bugs item #1299096, was opened at 2005-09-22 20:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1299096&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: lszumel (lszumel)
Assigned to: Nobody/Anonymous (nobody)
Summary: OverflowError if input y data is constant

Initial Comment:
If min and max are not specified on an axis (I'm using
graph.axis.linear), and the y-data is constant,
parter.py gets an OverflowError when trying to compute
the range (log(max - min) == log(0) => math range
error). Feature or bug?

I'm using PyX 0.8. Here is the trace:


Traceback (most recent call last):
  File "./mycode.py", line 46, in ?
    c.writeEPSfile('somefile')
  File
"/usr/lib/python2.3/site-packages/pyx/canvas.py", line
326, in writeEPSfile
    document.document([document.page(self,
**kwargs)]).writeEPSfile(filename)
  File
"/usr/lib/python2.3/site-packages/pyx/document.py",
line 138, in writeEPSfile
    pswriter.epswriter(self, filename, *args, **kwargs)
  File
"/usr/lib/python2.3/site-packages/pyx/pswriter.py",
line 235, in __init__
    bbox = page.bbox()
  File
"/usr/lib/python2.3/site-packages/pyx/document.py",
line 78, in bbox
    bbox = self.canvas.bbox()
  File
"/usr/lib/python2.3/site-packages/pyx/canvas.py", line
161, in bbox
    abbox = cmd.bbox()
  File
"/usr/lib/python2.3/site-packages/pyx/graph/graph.py",
line 445, in bbox
    self.finish()
  File
"/usr/lib/python2.3/site-packages/pyx/graph/graph.py",
line 342, in finish
    self.domethods[0]()
  File
"/usr/lib/python2.3/site-packages/pyx/graph/graph.py",
line 275, in dolayout
    self.axes[key].create(self.texrunner)
  File
"/usr/lib/python2.3/site-packages/pyx/graph/axis/axis.py",
line 526, in create
    self.canvas = self.axis.create(self.data,
self.positioner, graphtexrunner, self.errorname)
  File
"/usr/lib/python2.3/site-packages/pyx/graph/axis/axis.py",
line 163, in create
    self.min is None, self.max is None)
  File
"/usr/lib/python2.3/site-packages/pyx/graph/axis/parter.py",
line 148, in partfunctions
    logmm = math.log(max - min) / math.log(10)
OverflowError: math range error


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1299096&group_id=45430

Re: [PyX-devel] Re: [PyX-checkins] pyx/pyx trafo.py,1.53,1.54

[Andre W. <wo...@us...>]

Hi,

On 14.09.05, Joerg Lehmann wrote:
> > I'm aware that we need the epsilon in the constructor only, but still
> > I would do it very much like to keep it in the trafo as an instance
> > variable and inherit it to newly created trafos (like by rotated) ...
> 
> What do you want to do in the case of __mul__, when there are two
> trafos.

Hmmm. I don't know. We do have the same problem in normpath. In some
sense I would suggest the lower value for epsilon (and None, if one of
the epsilons is None). I don't think its a problem at the normsubpath,
that we increase the precision by that. What do you think?

(Yes, I would like to do the same in normsubpath and for the trafos.)

> > PS: I think we should set the default for trafo._epsilon to 1e-10 (or
> >     even lower!), since a determinate for a 2x2 matrix has the
> >     dimension of its items to the power of two. We should be able to
> >     scale by a factor of 0.001 without any problems.
> 
> Definitely, let's go for (1e-5)**2.

Ok. Just to remember, that epsilon in normpath is measured in pts. To
scale down a one in our default unit cm, the factor is:

    andre@pb:~/python/pyx$ python
    Python 2.3.3 (#1, Aug 23 2004, 20:06:57)
    [GCC 3.3 20030304 (Apple Computer, Inc. build 1640)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from pyx import normpath, unit
    >>> (normpath._epsilon/unit.topt(1))**2
    1.2445216049382721e-13
    >>>

I think 1e-10 is fine, but we should keep in mind, that this threshold
is still not yet generous. And I don't want to say, that the epsilon
in normpath and in trafo is directly related. But its fine as an
educated guess ... ;-)


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] Re: [PyX-checkins] pyx/pyx trafo.py,1.53,1.54

[Joerg L. <jo...@us...>]

On 14.09.05, Andre Wobst wrote:
> On 14.09.05, Jörg Lehmann wrote:
> > Log Message:
> > - introduce _epsilon for checking the singularity of a trafo
> > - only check for singularity in trafo constructor (this should catch
> >   all errors automatically)
> 
> Great. I like it. But I would also like to have a epsilon kwargs,
> which I can set to None. Use-case is to be able to define a trafo with
> determinate 0, which I'll not use for output. A stable epllise
> implementation could then be as short as:

Ok.

> class ellipse_pt(path):
> 
>     """ellipse with center (x_pt, y_pt) in pts,
>     the two axes (a_pt, b_pt) in pts,
>     and the angle angle of the first axis"""
> 
>     def __init__(self, x_pt, y_pt, a_pt, b_pt, angle, **kwargs):
>         t = trafo.scale(a_pt, b_pt, epsilon=None).rotated(angle).translated_pt(x_pt, y_pt)
>         return path.circle_pt(0, 0, 1, **kwargs).normpath(epsilon=None).transformed(t).path()
> 
> I'm aware that we need the epsilon in the constructor only, but still
> I would do it very much like to keep it in the trafo as an instance
> variable and inherit it to newly created trafos (like by rotated) ...

What do you want to do in the case of __mul__, when there are two
trafos.

> and at some point we might also want to have inplace modification (I
> certainly would like to have them) and for that we should need to keep
> and to check the trafo not just in the constructor. Any doubts left?

Ok, this sounds reasonable.

> André
> 
> PS: I think we should set the default for trafo._epsilon to 1e-10 (or
>     even lower!), since a determinate for a 2x2 matrix has the
>     dimension of its items to the power of two. We should be able to
>     scale by a factor of 0.001 without any problems. Currently we
>     have:

Definitely, let's go for (1e-5)**2.

        Jörg

Re: [PyX-devel] Curves with infinite curvature

[Andre W. <wo...@us...>]

Hi,

On 14.09.05, Joerg Lehmann wrote:
> > This means I have to compare with the _marker from the corresponding
> > module: normpath._marker in this case:
> 
> No, sorry, you misunderstood that. _marker is only used for determining
> whether someone passed a keyword argument or not. That's completely
> unrelated to the discussion on the undefined results. There, of course,
> we have to export the undefined instance. But again, it should not be
> contained in the helper module, but in the corresponding module (i.e.
> normpath) itself.
> 
> Btw, as you said yourself, <module>._marker would be bad anyway.

Right, those markers should be local only. I was trying to use a
single _marker all over the place for some other reason, which I'm now
convinced was a bad idea after the latest discussion on that list.

> But we
> already convinced André, so no need to discuss this again.

*smile*

I bag you pardon for mixing up the different issues. Orgininally I
thought it would be worth to thing about, but it's rejected.

To summarize it again: We should have local _markers and an global
helper._invalid. The later should (for the moment) be used as return
value in result lists of various normpath methods, which are able to
handle a handle/process/evaluate a list of points to mark errors.
There's no need for an trafo.invalid, since a trafo is either valid or
it raises an exception ...


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

[PyX-devel] Re: [PyX-checkins] pyx/pyx trafo.py,1.53,1.54

[Andre W. <wo...@us...>]

On 14.09.05, Jörg Lehmann wrote:
> Log Message:
> - introduce _epsilon for checking the singularity of a trafo
> - only check for singularity in trafo constructor (this should catch
>   all errors automatically)

Great. I like it. But I would also like to have a epsilon kwargs,
which I can set to None. Use-case is to be able to define a trafo with
determinate 0, which I'll not use for output. A stable epllise
implementation could then be as short as:

class ellipse_pt(path):

    """ellipse with center (x_pt, y_pt) in pts,
    the two axes (a_pt, b_pt) in pts,
    and the angle angle of the first axis"""

    def __init__(self, x_pt, y_pt, a_pt, b_pt, angle, **kwargs):
        t = trafo.scale(a_pt, b_pt, epsilon=None).rotated(angle).translated_pt(x_pt, y_pt)
        return path.circle_pt(0, 0, 1, **kwargs).normpath(epsilon=None).transformed(t).path()

I'm aware that we need the epsilon in the constructor only, but still
I would do it very much like to keep it in the trafo as an instance
variable and inherit it to newly created trafos (like by rotated) ...
and at some point we might also want to have inplace modification (I
certainly would like to have them) and for that we should need to keep
and to check the trafo not just in the constructor. Any doubts left?


André

PS: I think we should set the default for trafo._epsilon to 1e-10 (or
    even lower!), since a determinate for a 2x2 matrix has the
    dimension of its items to the power of two. We should be able to
    scale by a factor of 0.001 without any problems. Currently we
    have:

        andre@pb:~/python/pyx$ python
        Python 2.3.3 (#1, Aug 23 2004, 20:06:57)
        [GCC 3.3 20030304 (Apple Computer, Inc. build 1640)] on darwin
        Type "help", "copyright", "credits" or "license" for more information.
        >>> from pyx import trafo
        >>> trafo.scale(0.001)
        Traceback (most recent call last):
          File "<stdin>", line 1, in ?
          File "/Users/andre/python/pyx/pyx/trafo.py", line 244, in __init__
            trafo.__init__(self, matrix=((sx,0), (0,sy)), vector=vector)
          File "/Users/andre/python/pyx/pyx/trafo.py", line 185, in __init__
            (unit.topt(vector[0]), unit.topt(vector[1])))
          File "/Users/andre/python/pyx/pyx/trafo.py", line 78, in __init__
            raise TrafoException("transformation matrix must not be singular")
        pyx.trafo.TrafoException: transformation matrix must not be singular
        >>> trafo.scale(0.01)
        <pyx.trafo.scale instance at 0x12afb48>
        >>>

    ;-(

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] Curves with infinite curvature

[Joerg L. <jo...@us...>]

Hello Michael,

On 14.09.05, Michael Schindler wrote:
> On 14.09.05, Joerg Lehmann wrote:
> > On 14.09.05, Andre Wobst wrote:
> > > On 14.09.05, Andre Wobst wrote:
> > > > > So, we could introduce something like trafo.invalid but we would also
> > > > > need a marker for the infinite curvature case. Alternatively, we could
> > > > > just live with a single notdefined marker.
> > > > 
> > > > I'm at least +0 for a generic notdefined marker. Which -- for the sake
> > > > of easy to use -- should raise exceptions on access like the old
> > > > invalidcurrentpoint did. It's just handy. And I would also like to
> > > > have a 
> > > 
> > > Sorry. I wanted to say, that I still think, that we could use this
> > > notdefined in keyword arguments as well. The point is, that we should
> > > never use this marker but only check by "... is notdefined". 
> > 
> > What means notdefined in the context of keyword arguments. Sounds
> > strange.
> > 
> > > Then
> > > we're back at the naming issue. For the use case in this thread
> > > "notdefined" seems appropriate. For the keyword arg "_marker" is more
> > > common. We might just create two instances for that. Fine. The last
> > > question I would than ask, whether we want it underscored or not (in
> > > the helper module). I would not underscore it, although this is would
> > > be different from "_marker". BTW did we reach a final decision whether
> > > to have a single _marker in helper or whether we should create such a
> > > class/instance/whatever in every module. I would like to have a single
> > > instance ...
> > 
> > Why? What's the advantage of
> > 
> >     from helper import _marker
> > 
> > as opposed to
> > 
> >     class _marker: pass
> > 
> > Not speaking of having to import an underscored name from a module.
> > 
> > A not-underscored version is out, because it would indicate that this is
> > an external interface, which it explicitely should not be. In other
> > words, no caller should be allowed to pass it as argument, simply
> > because he was never allowed to access it.
> > 
> > So, I see only one way (and that's anyway the standard way): we
> > use one _marker per module.
> 
> This means I have to compare with the _marker from the corresponding
> module: normpath._marker in this case:

No, sorry, you misunderstood that. _marker is only used for determining
whether someone passed a keyword argument or not. That's completely
unrelated to the discussion on the undefined results. There, of course,
we have to export the undefined instance. But again, it should not be
contained in the helper module, but in the corresponding module (i.e.
normpath) itself.

Btw, as you said yourself, <module>._marker would be bad anyway. But we
already convinced André, so no need to discuss this again.

        Jörg

Re: [PyX-devel] Curves with infinite curvature

[Michael S. <m-s...@us...>]

Hello Jörg,

On 14.09.05, Joerg Lehmann wrote:
> On 14.09.05, Andre Wobst wrote:
> > On 14.09.05, Andre Wobst wrote:
> > > > So, we could introduce something like trafo.invalid but we would also
> > > > need a marker for the infinite curvature case. Alternatively, we could
> > > > just live with a single notdefined marker.
> > > 
> > > I'm at least +0 for a generic notdefined marker. Which -- for the sake
> > > of easy to use -- should raise exceptions on access like the old
> > > invalidcurrentpoint did. It's just handy. And I would also like to
> > > have a 
> > 
> > Sorry. I wanted to say, that I still think, that we could use this
> > notdefined in keyword arguments as well. The point is, that we should
> > never use this marker but only check by "... is notdefined". 
> 
> What means notdefined in the context of keyword arguments. Sounds
> strange.
> 
> > Then
> > we're back at the naming issue. For the use case in this thread
> > "notdefined" seems appropriate. For the keyword arg "_marker" is more
> > common. We might just create two instances for that. Fine. The last
> > question I would than ask, whether we want it underscored or not (in
> > the helper module). I would not underscore it, although this is would
> > be different from "_marker". BTW did we reach a final decision whether
> > to have a single _marker in helper or whether we should create such a
> > class/instance/whatever in every module. I would like to have a single
> > instance ...
> 
> Why? What's the advantage of
> 
>     from helper import _marker
> 
> as opposed to
> 
>     class _marker: pass
> 
> Not speaking of having to import an underscored name from a module.
> 
> A not-underscored version is out, because it would indicate that this is
> an external interface, which it explicitely should not be. In other
> words, no caller should be allowed to pass it as argument, simply
> because he was never allowed to access it.
> 
> So, I see only one way (and that's anyway the standard way): we
> use one _marker per module.

This means I have to compare with the _marker from the corresponding
module: normpath._marker in this case:

[code in deformer.py]
curvatures = anormpath.curvature_pt(alist)
for curvature in curvatures:
    if curvature is normpath._marker:
        do fallback
    else:
        do real things


I cannot see the difference to saying helper._marker here.

Michael.

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.

Re: [PyX-devel] Curves with infinite curvature

[Andre W. <wo...@us...>]

Hi,

On 14.09.05, Joerg Lehmann wrote:
> So, I see only one way (and that's anyway the standard way): we
> use one _marker per module.

Ok, the arguments are overwhelming ... ;-)


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] Curves with infinite curvature

[Michael S. <m-s...@us...>]

On 14.09.05, Andre Wobst wrote:
> Hi,
> 
> On 14.09.05, Joerg Lehmann wrote:
> > You would access it like this
> > 
> >     try:
> >         curvatures = np.curvature_pt(somelist)
> >     except GeometricError, e:
> >         list_of_invalid_curvatures = e.invalid_indices
> > 
> > Or alternatively, we could generate a new list exception containing
> > the separate exceptions:
> > 
> >     try:
> >         curvatures = np.curvature_pt(somelist)
> >     except PathExceptionList, ies:
> >         for index, e in ies:
> >             # index is the index of the exception
> >             # e is the corresponding PathException
> 
> Ah ... you want to return a full set of invalid indices. That's at
> least better in terms of redoing calculations (especially when the
> fallback does something completely different, which might be likely in
> certain use-cases). I was thinking to return a single index for the
> first problematic point only ...
> 
> >    http://mail.python.org/pipermail/python-dev/2004-February/042421.html
> 
> I've seen the different behaviour of sqrt of negative values myself
> already (switching between Mac and Linux). You just have to get used
> to it.
> 
> > Btw, I just picked NaN because this is the thing which is most
> > resembling the marker thing. Inf would be less since from a mathematical
> > point of view, you could think of a compactified version of the real
> > numbers (in which -Inf doesn't fit, though), so Inf would be just a
> > number.
> > 
> > > When thinking of invalid transformations, this gets really reasonable.
> > > Why not introduce a
> > >   trafo.invalid
> > > class in the trafo module? 
> > 
> > Hmm. And what would you return for the curvatures?
> 
> I think we should have a generic invalid marker.
> 
> > > This could be returned without any
> > > problems, and it raises an error, as André suggests.
> > 
> > Would trafo.scale(0, 0).inverse() return trafo.invalid?
> 
> Hmmm. Maybe. Yes, I think so. I think its best to return invalid here
> too. Just fetch a ArithmeticError and that's it. Still, a plattform
> might not raise the ArithmeticError (ZeroDivisionError). Than we can't
> do much in this case ...
> 
> > > The next thing is that there was this invalid scaling in a recent
> > > PyX-user thread: trafo.scale(0, 0) looks like a perfect candidate for
> > > trafo.invalid. 
> > 
> > André would argument against this, I suppose. And me as well, for the
> > reason given by yourself:
> 
> Right. I'm against it. There are trafos which can't be inverted. But
> they are perfect affine trafos.

This is right, but inverting a trafo is still an open problem. In
trafo.py at the moment an exception is raised:

  raise UndefinedResultError, "transformation matrix must not be
  singular"

The comment "# shouldn't be zero, but" indicated that something is not
completely finished here.

> > > The only question here is -- as always -- the question
> > > of thresholds. Meybe there is a possibility to check this at least for
> > > normpaths, when writing them.

> > Coming back to the original question, you probably have in mind the
> > simplicity of the deformer implementation. If I understand you
> > correctly, you say that an exception-based system makes the code more
> > involved. This is certainly a point to take into account.

Yes.

> Right. We do want to handle the invalid case at the point we're
> accessing it. We should not have the burden to always have to
> prehandle that case. That's why an exception is not very useful.

Yes.

> > Initially, I
> > mainly objected to using None as a marker. Against some more specialized
> > marker, I would only mildly object, though. And certainly, your deformer
> > code represents a rather comprehensive use case for the path system.
> > 
> > So, we could introduce something like trafo.invalid but we would also
> > need a marker for the infinite curvature case. Alternatively, we could
> > just live with a single notdefined marker.

+0.5 for both: trafo.invalid (as a more specialized marker) and _marker
(or notdefined or helper.notdefined ...) for the curvature/radius
case.

> I'm at least +0 for a generic notdefined marker. Which -- for the sake
> of easy to use -- should raise exceptions on access like the old
> invalidcurrentpoint did. It's just handy. And I would also like to
> have a 
>
> Sorry. I wanted to say, that I still think, that we could use this
> notdefined in keyword arguments as well. The point is, that we should
> never use this marker but only check by "... is notdefined". Then
> we're back at the naming issue. For the use case in this thread
> "notdefined" seems appropriate. For the keyword arg "_marker" is more
> common. We might just create two instances for that. Fine. The last
> question I would than ask, whether we want it underscored or not (in
> the helper module). I would not underscore it, although this is would
> be different from "_marker". BTW did we reach a final decision whether
> to have a single _marker in helper or whether we should create such a
> class/instance/whatever in every module. I would like to have a single
> instance ...

An underscore would rather prevent users from using it. They should
not.

Michael.

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.

Re: [PyX-devel] Curves with infinite curvature

[Joerg L. <jo...@us...>]

Hi André,

[ sorry, forgot to CC the list, here we go ]

On 14.09.05, Andre Wobst wrote:
> On 14.09.05, Andre Wobst wrote:
> > > So, we could introduce something like trafo.invalid but we would also
> > > need a marker for the infinite curvature case. Alternatively, we could
> > > just live with a single notdefined marker.
> > 
> > I'm at least +0 for a generic notdefined marker. Which -- for the sake
> > of easy to use -- should raise exceptions on access like the old
> > invalidcurrentpoint did. It's just handy. And I would also like to
> > have a 
> 
> Sorry. I wanted to say, that I still think, that we could use this
> notdefined in keyword arguments as well. The point is, that we should
> never use this marker but only check by "... is notdefined". 

What means notdefined in the context of keyword arguments. Sounds
strange.

> Then
> we're back at the naming issue. For the use case in this thread
> "notdefined" seems appropriate. For the keyword arg "_marker" is more
> common. We might just create two instances for that. Fine. The last
> question I would than ask, whether we want it underscored or not (in
> the helper module). I would not underscore it, although this is would
> be different from "_marker". BTW did we reach a final decision whether
> to have a single _marker in helper or whether we should create such a
> class/instance/whatever in every module. I would like to have a single
> instance ...

Why? What's the advantage of

    from helper import _marker

as opposed to

    class _marker: pass

Not speaking of having to import an underscored name from a module.

A not-underscored version is out, because it would indicate that this is
an external interface, which it explicitely should not be. In other
words, no caller should be allowed to pass it as argument, simply
because he was never allowed to access it.

So, I see only one way (and that's anyway the standard way): we
use one _marker per module.

     Jörg

Re: [PyX-devel] Curves with infinite curvature

[Andre W. <wo...@us...>]

On 14.09.05, Andre Wobst wrote:
> > So, we could introduce something like trafo.invalid but we would also
> > need a marker for the infinite curvature case. Alternatively, we could
> > just live with a single notdefined marker.
> 
> I'm at least +0 for a generic notdefined marker. Which -- for the sake
> of easy to use -- should raise exceptions on access like the old
> invalidcurrentpoint did. It's just handy. And I would also like to
> have a 

Sorry. I wanted to say, that I still think, that we could use this
notdefined in keyword arguments as well. The point is, that we should
never use this marker but only check by "... is notdefined". Then
we're back at the naming issue. For the use case in this thread
"notdefined" seems appropriate. For the keyword arg "_marker" is more
common. We might just create two instances for that. Fine. The last
question I would than ask, whether we want it underscored or not (in
the helper module). I would not underscore it, although this is would
be different from "_marker". BTW did we reach a final decision whether
to have a single _marker in helper or whether we should create such a
class/instance/whatever in every module. I would like to have a single
instance ...


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] Curves with infinite curvature

[Andre W. <wo...@us...>]

Hi,

On 14.09.05, Joerg Lehmann wrote:
> You would access it like this
> 
>     try:
>         curvatures = np.curvature_pt(somelist)
>     except GeometricError, e:
>         list_of_invalid_curvatures = e.invalid_indices
> 
> Or alternatively, we could generate a new list exception containing
> the separate exceptions:
> 
>     try:
>         curvatures = np.curvature_pt(somelist)
>     except PathExceptionList, ies:
>         for index, e in ies:
>             # index is the index of the exception
>             # e is the corresponding PathException

Ah ... you want to return a full set of invalid indices. That's at
least better in terms of redoing calculations (especially when the
fallback does something completely different, which might be likely in
certain use-cases). I was thinking to return a single index for the
first problematic point only ...

>    http://mail.python.org/pipermail/python-dev/2004-February/042421.html

I've seen the different behaviour of sqrt of negative values myself
already (switching between Mac and Linux). You just have to get used
to it.

> Btw, I just picked NaN because this is the thing which is most
> resembling the marker thing. Inf would be less since from a mathematical
> point of view, you could think of a compactified version of the real
> numbers (in which -Inf doesn't fit, though), so Inf would be just a
> number.
> 
> > When thinking of invalid transformations, this gets really reasonable.
> > Why not introduce a
> >   trafo.invalid
> > class in the trafo module? 
> 
> Hmm. And what would you return for the curvatures?

I think we should have a generic invalid marker.

> > This could be returned without any
> > problems, and it raises an error, as André suggests.
> 
> Would trafo.scale(0, 0).inverse() return trafo.invalid?

Hmmm. Maybe. Yes, I think so. I think its best to return invalid here
too. Just fetch a ArithmeticError and that's it. Still, a plattform
might not raise the ArithmeticError (ZeroDivisionError). Than we can't
do much in this case ...

> > The next thing is that there was this invalid scaling in a recent
> > PyX-user thread: trafo.scale(0, 0) looks like a perfect candidate for
> > trafo.invalid. 
> 
> André would argument against this, I suppose. And me as well, for the
> reason given by yourself:

Right. I'm against it. There are trafos which can't be inverted. But
they are perfect affine trafos.

> > The only question here is -- as always -- the question
> > of thresholds. Meybe there is a possibility to check this at least for
> > normpaths, when writing them.
> 
> Coming back to the original question, you probably have in mind the
> simplicity of the deformer implementation. If I understand you
> correctly, you say that an exception-based system makes the code more
> involved. This is certainly a point to take into account.

Right. We do want to handle the invalid case at the point we're
accessing it. We should not have the burden to always have to
prehandle that case. That's why an exception is not very useful.

> Initially, I
> mainly objected to using None as a marker. Against some more specialized
> marker, I would only mildly object, though. And certainly, your deformer
> code represents a rather comprehensive use case for the path system.
> 
> So, we could introduce something like trafo.invalid but we would also
> need a marker for the infinite curvature case. Alternatively, we could
> just live with a single notdefined marker.

I'm at least +0 for a generic notdefined marker. Which -- for the sake
of easy to use -- should raise exceptions on access like the old
invalidcurrentpoint did. It's just handy. And I would also like to
have a 


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] Curves with infinite curvature

[Joerg L. <jo...@us...>]

Hi André,

parallelism...

On 14.09.05, Andre Wobst wrote:
> Hi,
> 
> On 14.09.05, Joerg Lehmann wrote:
> > > - We could raise an execption and mark it with further information.
> > >   Still, since we processed an list of values, the whole system is
> > >   complicated and inappropriate. We can raise only an single exception
> > >   and should provide all information we collected. In some sence, the
> > >   exception is a return value containing some results, which we were
> > >   able to get and some error information. It's a no win situation
> > >   compared to using a marker in the result.
> > 
> > In the framework of our present implementation it would be easy to put
> > the parameter value leading to the problem in the exception. This has
> > the drawback that when the caller has passed a list, he doesn't know the
> > index in the list, which is suboptimal. On the other hand, we could
> > capture the exception in the method decorator. There we still know the
> > list index, which we could use to generate a new exception containing
> > this information. Then the caller would get all the information he
> > needs. 
> 
> Right, but that's not the point. Whenever we pass parts of the list to
> normsubpathitems etc., we just also need to catch the exception and
> correct the list index where the error occur. This would be a clean
> and easy solution.
> 
> There are just to small issues here: The first is, that the we throw
> away solutions we just calculated. This is highly contra-productive,
> since we wanted the lists to be used to improve the performance. The
> second is, that it would be difficult for the caller to use. Whenever
> a problem occurs it must resolve the (local) issue before doing the
> (global) calculation.

Yep, that's a point against this.

> I expect that it'll be most easy to for the caller to use a single
> item list all the time. For that case we do not even need the index,
> but we would get it in the exception. The index will always be 0.

Yep.

> Ok, let's analyse the use-cases. We'll step into the problem for the
> curveradius, the rotation, the trafo and the tangent (and the
> curvature, once we'll introduce it) only. Usually the exception might
> not be catched at all, so it doesn't really matter. The only
> interesting point is, when we want to recover from such an situation.
> Any case outside of the parallel deformer, where we expect that to
> happen? Maybe we should just live with it. I'm not sure.

As I wrote in my previous mail, the defomer is a very comprehensive
use case, which we should take into account.

> > > - We could return a marker. This marker could be clever in that sence,
> > >   that it raises an exception as soon as it is accessed. (However you
> > >   could do a "x is _marker" check without an excpetion.) It would be
> > >   kind of a late evaluation exception raising similar to what we did
> > >   with the _invalidcurrentpoint in earlier versions of the path system
> > >   (cf.
> > >   http://cvs.sourceforge.net/viewcvs.py/pyx/pyx/pyx/path.py?rev=1.228&view=markup)
> > > 
> > 
> > I don't like this idea too much. The main thing which bothers me, that
> > we somehow mask an error, which actually has occured. In this sense,
> > this is totally different from the _invalidcurrentpoint example. There
> > is one argument in favour of it, namely the existence of NaN in many
> > floating point implementations. This would set a precedence for a
> > similar solution in PyX.
> 
> I didn't even thought about this point, but this more or less supports
> the idea instead of being against it. So why not?

Yes, it supports the marker idea (hey, I tried to find arguments for all
options).


> > > I think the second option is by far the most easiest one for our
> > > use-case of invalid curvatures/transformations etc. We could make it a
> > > general feature of the marker instance we're planing in favor of the
> > > existing helper.nodefault to raise an exception on access. That's by
> > > the way something such a marker is for ...
> > 
> > No. Internally, we should no how to deal with our markers. There is
> > really no need to protect us from ourselves.
> 
> Question is, whether _marker and _invalid is the same.

See my other mail. This has to be discussed.

> > All in all, I would still favour the first option, as long as there are
> > not more arguments against it. Alternatively, you can try to convince me
> > of the merits of the second solution :-)
> 
> My major concern is, that for cases where we want to recover from such
> an situation, the exception solution will lead to a typical useage
> scenario with a single item list. That would at least be strange. And
> that's also what Michael started the discussion with ...

Yep, Michael put forward some good arguments, so I would accept the
second option with marker != None.

        Jörg

Re: [PyX-devel] Curves with infinite curvature

[Joerg L. <jo...@us...>]

Hello,

On 14.09.05, Michael Schindler wrote:
> On 14.09.05, Joerg Lehmann wrote:
> > On 14.09.05, Andre Wobst wrote:
> > > On 12.09.05, Joerg Lehmann wrote:
> > > > > On 12.09.05, Michael Schindler wrote:
> > > > > > There is something else that judges against raising an exception, in
> > > > > > favour of the "arbitrary marker value": We calculate curvatures and
> > > > > > rotations ... always for a list of parameter values. If one of them
> > > > > > makes problems, you will never find out which one of them it was and
> > > > > > you cannot do anything against it. The outcome would be that the user
> > > > > > (or the module that uses this feature) has to ask for one
> > > > > > parameter value after the other in a try...except block.
> 
> > > Ok. I think we're in trouble here. An exception doesn't provide us
> > > with a proper recovery strategy. (It's a well known limitation of an
> > > exception system.) There are several ways out.
> > > 
> > > - We could raise an execption and mark it with further information.
> > >   Still, since we processed an list of values, the whole system is
> > >   complicated and inappropriate. We can raise only an single exception
> > >   and should provide all information we collected. In some sence, the
> > >   exception is a return value containing some results, which we were
> > >   able to get and some error information. It's a no win situation
> > >   compared to using a marker in the result.
> > 
> > In the framework of our present implementation it would be easy to put
> > the parameter value leading to the problem in the exception. This has
> > the drawback that when the caller has passed a list, he doesn't know the
> > index in the list, which is suboptimal. On the other hand, we could
> > capture the exception in the method decorator. There we still know the
> > list index, which we could use to generate a new exception containing
> > this information. Then the caller would get all the information he
> > needs. 
> 
> I do not really understand this suggestion.
> When doing parallel deformation, I have infinite curvatures (which is
> equivalent to a parameter "velocity" of zero) quite regularly. This is
> nothing the user should be bothered with, because the parallel
> deformer will know how to deal with it. My question is: How will this
> look in the code, when implementing that exception which tells me that
> there were errors processing a list?

You would access it like this

    try:
        curvatures = np.curvature_pt(somelist)
    except GeometricError, e:
        list_of_invalid_curvatures = e.invalid_indices

Or alternatively, we could generate a new list exception containing
the separate exceptions:

    try:
        curvatures = np.curvature_pt(somelist)
    except PathExceptionList, ies:
        for index, e in ies:
            # index is the index of the exception
            # e is the corresponding PathException

> > > - We could return a marker. This marker could be clever in that sence,
> > >   that it raises an exception as soon as it is accessed. (However you
> > >   could do a "x is _marker" check without an excpetion.) It would be
> > >   kind of a late evaluation exception raising similar to what we did
> > >   with the _invalidcurrentpoint in earlier versions of the path system
> > >   (cf.
> > >   http://cvs.sourceforge.net/viewcvs.py/pyx/pyx/pyx/path.py?rev=1.228&view=markup)
> > > 
> 
> > I don't like this idea too much. The main thing which bothers me, that
> > we somehow mask an error, which actually has occured. In this sense,
> > this is totally different from the _invalidcurrentpoint example. There
> > is one argument in favour of it, namely the existence of NaN in many
> > floating point implementations. This would set a precedence for a
> > similar solution in PyX.
> 
> I prefer this option -- not so much for the curvatures, because they
> are simply numbers (and we could use +"inf" or -"inf" which are easily
> produced by saying float("inf")

That's impossible since it is only existent on certain platforms. Python
doesn't guarantee the existence of NaN, inf, etc. See the standard
quoute on this topic by Tim Peters:

   http://mail.python.org/pipermail/python-dev/2004-February/042421.html

Note that this shows that in this case, even the Python
documentation/standard doesn't define whether to return something like a
marker (NaN) or to raise an exception (ValueError). Note also, that the
OP in the referenced thread expected Python to raise an exception when
math.sqrt(-1) is being called - an expectation which Tim Peters didn't
explicitely object to. Note finally that this means that the present PyX
code may already raise exceptions on other platforms when it doesn't do
so on Linux.

> -- this is much better than Nan,
> because we can divide by it).

Btw, I just picked NaN because this is the thing which is most
resembling the marker thing. Inf would be less since from a mathematical
point of view, you could think of a compactified version of the real
numbers (in which -Inf doesn't fit, though), so Inf would be just a
number.

> When thinking of invalid transformations, this gets really reasonable.
> Why not introduce a
>   trafo.invalid
> class in the trafo module? 

Hmm. And what would you return for the curvatures?

> This could be returned without any
> problems, and it raises an error, as André suggests.

Would trafo.scale(0, 0).inverse() return trafo.invalid?

> The next thing is that there was this invalid scaling in a recent
> PyX-user thread: trafo.scale(0, 0) looks like a perfect candidate for
> trafo.invalid. 

André would argument against this, I suppose. And me as well, for the
reason given by yourself:

> The only question here is -- as always -- the question
> of thresholds. Meybe there is a possibility to check this at least for
> normpaths, when writing them.

Coming back to the original question, you probably have in mind the
simplicity of the deformer implementation. If I understand you
correctly, you say that an exception-based system makes the code more
involved. This is certainly a point to take into account. Initially, I
mainly objected to using None as a marker. Against some more specialized
marker, I would only mildly object, though. And certainly, your deformer
code represents a rather comprehensive use case for the path system.

So, we could introduce something like trafo.invalid but we would also
need a marker for the infinite curvature case. Alternatively, we could
just live with a single notdefined marker.

        Jörg

Re: [PyX-devel] Curves with infinite curvature

[Andre W. <wo...@us...>]

Hi,

On 14.09.05, Joerg Lehmann wrote:
> > - We could raise an execption and mark it with further information.
> >   Still, since we processed an list of values, the whole system is
> >   complicated and inappropriate. We can raise only an single exception
> >   and should provide all information we collected. In some sence, the
> >   exception is a return value containing some results, which we were
> >   able to get and some error information. It's a no win situation
> >   compared to using a marker in the result.
> 
> In the framework of our present implementation it would be easy to put
> the parameter value leading to the problem in the exception. This has
> the drawback that when the caller has passed a list, he doesn't know the
> index in the list, which is suboptimal. On the other hand, we could
> capture the exception in the method decorator. There we still know the
> list index, which we could use to generate a new exception containing
> this information. Then the caller would get all the information he
> needs. 

Right, but that's not the point. Whenever we pass parts of the list to
normsubpathitems etc., we just also need to catch the exception and
correct the list index where the error occur. This would be a clean
and easy solution.

There are just to small issues here: The first is, that the we throw
away solutions we just calculated. This is highly contra-productive,
since we wanted the lists to be used to improve the performance. The
second is, that it would be difficult for the caller to use. Whenever
a problem occurs it must resolve the (local) issue before doing the
(global) calculation.

I expect that it'll be most easy to for the caller to use a single
item list all the time. For that case we do not even need the index,
but we would get it in the exception. The index will always be 0.

Ok, let's analyse the use-cases. We'll step into the problem for the
curveradius, the rotation, the trafo and the tangent (and the
curvature, once we'll introduce it) only. Usually the exception might
not be catched at all, so it doesn't really matter. The only
interesting point is, when we want to recover from such an situation.
Any case outside of the parallel deformer, where we expect that to
happen? Maybe we should just live with it. I'm not sure.

> > - We could return a marker. This marker could be clever in that sence,
> >   that it raises an exception as soon as it is accessed. (However you
> >   could do a "x is _marker" check without an excpetion.) It would be
> >   kind of a late evaluation exception raising similar to what we did
> >   with the _invalidcurrentpoint in earlier versions of the path system
> >   (cf.
> >   http://cvs.sourceforge.net/viewcvs.py/pyx/pyx/pyx/path.py?rev=1.228&view=markup)
> > 
> 
> I don't like this idea too much. The main thing which bothers me, that
> we somehow mask an error, which actually has occured. In this sense,
> this is totally different from the _invalidcurrentpoint example. There
> is one argument in favour of it, namely the existence of NaN in many
> floating point implementations. This would set a precedence for a
> similar solution in PyX.

I didn't even thought about this point, but this more or less supports
the idea instead of being against it. So why not?

> > - The third solution could be a callback function in case we step into
> >   an error. In other languages (list, smalltalk) a (more advanced)
> >   condition system is used in general in favour of excepts, but the
> >   question is, whether it's that easy to recover from an error by some
> >   callback/fallback/whatever.
> 
> This gets a definite -1 from me, as it strikes me as being totally
> unpythonic.

Sure. It was not under serious consideration by me either.

> > I think the second option is by far the most easiest one for our
> > use-case of invalid curvatures/transformations etc. We could make it a
> > general feature of the marker instance we're planing in favor of the
> > existing helper.nodefault to raise an exception on access. That's by
> > the way something such a marker is for ...
> 
> No. Internally, we should no how to deal with our markers. There is
> really no need to protect us from ourselves.

Question is, whether _marker and _invalid is the same.

> All in all, I would still favour the first option, as long as there are
> not more arguments against it. Alternatively, you can try to convince me
> of the merits of the second solution :-)

My major concern is, that for cases where we want to recover from such
an situation, the exception solution will lead to a typical useage
scenario with a single item list. That would at least be strange. And
that's also what Michael started the discussion with ...


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] Curves with infinite curvature

[Michael S. <m-s...@us...>]

Hello,

On 14.09.05, Joerg Lehmann wrote:
> On 14.09.05, Andre Wobst wrote:
> > On 12.09.05, Joerg Lehmann wrote:
> > > > On 12.09.05, Michael Schindler wrote:
> > > > > There is something else that judges against raising an exception, in
> > > > > favour of the "arbitrary marker value": We calculate curvatures and
> > > > > rotations ... always for a list of parameter values. If one of them
> > > > > makes problems, you will never find out which one of them it was and
> > > > > you cannot do anything against it. The outcome would be that the user
> > > > > (or the module that uses this feature) has to ask for one
> > > > > parameter value after the other in a try...except block.

> > Ok. I think we're in trouble here. An exception doesn't provide us
> > with a proper recovery strategy. (It's a well known limitation of an
> > exception system.) There are several ways out.
> > 
> > - We could raise an execption and mark it with further information.
> >   Still, since we processed an list of values, the whole system is
> >   complicated and inappropriate. We can raise only an single exception
> >   and should provide all information we collected. In some sence, the
> >   exception is a return value containing some results, which we were
> >   able to get and some error information. It's a no win situation
> >   compared to using a marker in the result.
> 
> In the framework of our present implementation it would be easy to put
> the parameter value leading to the problem in the exception. This has
> the drawback that when the caller has passed a list, he doesn't know the
> index in the list, which is suboptimal. On the other hand, we could
> capture the exception in the method decorator. There we still know the
> list index, which we could use to generate a new exception containing
> this information. Then the caller would get all the information he
> needs. 

I do not really understand this suggestion.
When doing parallel deformation, I have infinite curvatures (which is
equivalent to a parameter "velocity" of zero) quite regularly. This is
nothing the user should be bothered with, because the parallel
deformer will know how to deal with it. My question is: How will this
look in the code, when implementing that exception which tells me that
there were errors processing a list?
  try:
      curvatures = np.curvature_pt(somelist)
  except GeometricError:
      list_of_invalid_curvatures = ???

How do I access the return string/value of that GeometricException
here?

> > - We could return a marker. This marker could be clever in that sence,
> >   that it raises an exception as soon as it is accessed. (However you
> >   could do a "x is _marker" check without an excpetion.) It would be
> >   kind of a late evaluation exception raising similar to what we did
> >   with the _invalidcurrentpoint in earlier versions of the path system
> >   (cf.
> >   http://cvs.sourceforge.net/viewcvs.py/pyx/pyx/pyx/path.py?rev=1.228&view=markup)
> > 

> I don't like this idea too much. The main thing which bothers me, that
> we somehow mask an error, which actually has occured. In this sense,
> this is totally different from the _invalidcurrentpoint example. There
> is one argument in favour of it, namely the existence of NaN in many
> floating point implementations. This would set a precedence for a
> similar solution in PyX.

I prefer this option -- not so much for the curvatures, because they
are simply numbers (and we could use +"inf" or -"inf" which are easily
produced by saying float("inf") -- this is much better than Nan,
because we can divide by it).
When thinking of invalid transformations, this gets really reasonable.
Why not introduce a
  trafo.invalid
class in the trafo module? This could be returned without any
problems, and it raises an error, as André suggests.
The next thing is that there was this invalid scaling in a recent
PyX-user thread: trafo.scale(0, 0) looks like a perfect candidate for
trafo.invalid. The only question here is -- as always -- the question
of thresholds. Meybe there is a possibility to check this at least for
normpaths, when writing them.

> > - The third solution could be a callback function in case we step into
> >   an error. In other languages (list, smalltalk) a (more advanced)
> >   condition system is used in general in favour of excepts, but the
> >   question is, whether it's that easy to recover from an error by some
> >   callback/fallback/whatever.
> 
> This gets a definite -1 from me, as it strikes me as being totally
> unpythonic.

This sounds very complicated, again.

Michael.

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.

Re: [PyX-devel] Curves with infinite curvature

[Joerg L. <jo...@us...>]

Hi,

On 14.09.05, Andre Wobst wrote:
> On 12.09.05, Joerg Lehmann wrote:
> > On 12.09.05, Joerg Lehmann wrote:
> > > On 12.09.05, Michael Schindler wrote:
> > > > There is something else that judges against raising an exception, in
> > > > favour of the "arbitrary marker value": We calculate curvatures and
> > > > rotations ... always for a list of parameter values. If one of them
> > > > makes problems, you will never find out which one of them it was and
> > > > you cannot do anything against it. The outcome would be that the user
> > > > (or the module that uses this feature) has to ask for one
> > > > parameter value after the other in a try...except block.
> > > 
> > > I would say so. We could put this information in the exception instance
> > > and probably should do that anyway.
> > 
> > s/say/not say/
> 
> Ok. I think we're in trouble here. An exception doesn't provide us
> with a proper recovery strategy. (It's a well known limitation of an
> exception system.) There are several ways out.
> 
> - We could raise an execption and mark it with further information.
>   Still, since we processed an list of values, the whole system is
>   complicated and inappropriate. We can raise only an single exception
>   and should provide all information we collected. In some sence, the
>   exception is a return value containing some results, which we were
>   able to get and some error information. It's a no win situation
>   compared to using a marker in the result.

In the framework of our present implementation it would be easy to put
the parameter value leading to the problem in the exception. This has
the drawback that when the caller has passed a list, he doesn't know the
index in the list, which is suboptimal. On the other hand, we could
capture the exception in the method decorator. There we still know the
list index, which we could use to generate a new exception containing
this information. Then the caller would get all the information he
needs. 

> - We could return a marker. This marker could be clever in that sence,
>   that it raises an exception as soon as it is accessed. (However you
>   could do a "x is _marker" check without an excpetion.) It would be
>   kind of a late evaluation exception raising similar to what we did
>   with the _invalidcurrentpoint in earlier versions of the path system
>   (cf.
>   http://cvs.sourceforge.net/viewcvs.py/pyx/pyx/pyx/path.py?rev=1.228&view=markup)
> 

I don't like this idea too much. The main thing which bothers me, that
we somehow mask an error, which actually has occured. In this sense,
this is totally different from the _invalidcurrentpoint example. There
is one argument in favour of it, namely the existence of NaN in many
floating point implementations. This would set a precedence for a
similar solution in PyX.

> - The third solution could be a callback function in case we step into
>   an error. In other languages (list, smalltalk) a (more advanced)
>   condition system is used in general in favour of excepts, but the
>   question is, whether it's that easy to recover from an error by some
>   callback/fallback/whatever.

This gets a definite -1 from me, as it strikes me as being totally
unpythonic.

> I think the second option is by far the most easiest one for our
> use-case of invalid curvatures/transformations etc. We could make it a
> general feature of the marker instance we're planing in favor of the
> existing helper.nodefault to raise an exception on access. That's by
> the way something such a marker is for ...

No. Internally, we should no how to deal with our markers. There is
really no need to protect us from ourselves.

All in all, I would still favour the first option, as long as there are
not more arguments against it. Alternatively, you can try to convince me
of the merits of the second solution :-)

        Jörg