From: Michael J G. <mic...@us...> - 2016-02-05 09:29:29
|
Currently, the length of the arrow as well as the size of the arrow head are scaled by the value of the "size" column, which can get out of hand quickly for vector field plots. Introduce an argument "arrowscale" (defaulting to 1) that makes the arrow head scale by a convex combination of "1" and the value of "size": 1 (default): scale by "size" as before 0: fixed size (as if the value of "size" were 1, just for the arrow head) Signed-off-by: Michael J Gruber <mic...@us...> --- I'll try and reply with two PNGs showing the output for arrowscale=0 (default) and arrowscale=1. Alternative to the RFC here, one could think about abstracting to graph.style.deco() with general decoargs and decokwargs arguments (defaulting to [arrowpos=0.5] and such). That would make it more complicated to specify a decorator which takes into account "size", though. pyx/graph/style.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/pyx/graph/style.py b/pyx/graph/style.py index 1d1e283..57cf2de 100644 --- a/pyx/graph/style.py +++ b/pyx/graph/style.py @@ -880,12 +880,13 @@ class arrow(_styleneedingpointpos): defaultlineattrs = [] defaultarrowattrs = [] - def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, epsilon=1e-5, decorator=deco.earrow): + def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, arrowscale=1, epsilon=1e-5, decorator=deco.earrow): self.linelength = linelength self.arrowsize = arrowsize self.lineattrs = lineattrs self.arrowattrs = arrowattrs self.arrowpos = arrowpos + self.arrowscale = arrowscale self.epsilon = epsilon self.decorator = decorator @@ -930,7 +931,7 @@ class arrow(_styleneedingpointpos): y2 = y_pt+(1-self.arrowpos)*dy*linelength_pt*size if self.decorator: privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), - privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*size)]) + privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*((1-self.arrowscale) + self.arrowscale*size))]) else: privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), privatedata.lineattrs) -- 2.7.0.341.gc1754cc |
From: Michael J G. <mic...@us...> - 2016-02-05 09:31:58
Attachments:
P-XIII-extra.png
P-XIII-extra-arrowscale.png
|
Michael J Gruber venit, vidit, dixit 05.02.2016 10:29: > I'll try and reply with two PNGs showing the output for arrowscale=0 (default) > and arrowscale=1. So let's see. |
From: André W. <wo...@us...> - 2016-02-05 15:35:54
Attachments:
smime.p7s
|
Hi Michael, Such a scaling should not be done within PyX, at least not within a pyx graph style. It is different from arrowsize, as arrowsize is a PyX length. It defined the length of the arrow for a length data value of 1. Preprocess the length data values has nothing to do with plotting. One could think about a transformation done in a separate step, similar to the 1d-graph for the colors in a 3d graph. Well, interesting idea (to my mind). It could create a scale plot with different arrow sizes and their data value "automatically". However, within the graph style an arrowscale to (smoothly) enable arrow length adjustment between no-adjustment at all (fixed size) and 1 (linear scaling according to the data value) is too specific. It is not the right thing to do, IMHO. Best, André Am 05.02.2016 um 10:29 schrieb Michael J Gruber <mic...@us...>: > Currently, the length of the arrow as well as the size of the arrow head > are scaled by the value of the "size" column, which can get out of hand > quickly for vector field plots. > > Introduce an argument "arrowscale" (defaulting to 1) that makes the > arrow head scale by a convex combination of "1" and the value of "size": > > 1 (default): scale by "size" as before > 0: fixed size (as if the value of "size" were 1, just for the arrow > head) > > Signed-off-by: Michael J Gruber <mic...@us...> > --- > I'll try and reply with two PNGs showing the output for arrowscale=0 (default) > and arrowscale=1. > > Alternative to the RFC here, one could think about abstracting to graph.style.deco() > with general decoargs and decokwargs arguments (defaulting to [arrowpos=0.5] and such). > That would make it more complicated to specify a decorator which takes into account "size", though. > > pyx/graph/style.py | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/pyx/graph/style.py b/pyx/graph/style.py > index 1d1e283..57cf2de 100644 > --- a/pyx/graph/style.py > +++ b/pyx/graph/style.py > @@ -880,12 +880,13 @@ class arrow(_styleneedingpointpos): > defaultlineattrs = [] > defaultarrowattrs = [] > > - def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, epsilon=1e-5, decorator=deco.earrow): > + def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, arrowscale=1, epsilon=1e-5, decorator=deco.earrow): > self.linelength = linelength > self.arrowsize = arrowsize > self.lineattrs = lineattrs > self.arrowattrs = arrowattrs > self.arrowpos = arrowpos > + self.arrowscale = arrowscale > self.epsilon = epsilon > self.decorator = decorator > > @@ -930,7 +931,7 @@ class arrow(_styleneedingpointpos): > y2 = y_pt+(1-self.arrowpos)*dy*linelength_pt*size > if self.decorator: > privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), > - privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*size)]) > + privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*((1-self.arrowscale) + self.arrowscale*size))]) > else: > privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), privatedata.lineattrs) > > -- > 2.7.0.341.gc1754cc > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > PyX-devel mailing list > PyX...@li... > https://lists.sourceforge.net/lists/listinfo/pyx-devel -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: André W. <wo...@us...> - 2016-02-05 15:46:53
Attachments:
smime.p7s
|
Hi again, I have to reply to myself. I just noticed, that by your change you can alter the length of the arrow (i.e. the line) independent from the size of the arrow cap. Now, this is something you need, and want. Ok. But wouldn't this mean, that we should have another input column, as an optional input column? Well, and yes, this maybe is again too complicated, as the arrow length (the line) and the size of the cap should depend on a single parameter only. Right. How about making linelength and arrowsize a callable (optionally) to enable insertion of non-linear dependance on the scaling. Still, this could maybe done on a translation step similar to the value-to-color conversion in a surface plot. Hmmm. I'm not yet done with getting myself to a final suggestion for a better implementation. Best, André Am 05.02.2016 um 16:35 schrieb André Wobst <wo...@us...>: > Hi Michael, > > Such a scaling should not be done within PyX, at least not within a pyx graph style. It is different from arrowsize, as arrowsize is a PyX length. It defined the length of the arrow for a length data value of 1. Preprocess the length data values has nothing to do with plotting. One could think about a transformation done in a separate step, similar to the 1d-graph for the colors in a 3d graph. Well, interesting idea (to my mind). It could create a scale plot with different arrow sizes and their data value "automatically". > > However, within the graph style an arrowscale to (smoothly) enable arrow length adjustment between no-adjustment at all (fixed size) and 1 (linear scaling according to the data value) is too specific. It is not the right thing to do, IMHO. > > Best, > > > André > > Am 05.02.2016 um 10:29 schrieb Michael J Gruber <mic...@us...>: > >> Currently, the length of the arrow as well as the size of the arrow head >> are scaled by the value of the "size" column, which can get out of hand >> quickly for vector field plots. >> >> Introduce an argument "arrowscale" (defaulting to 1) that makes the >> arrow head scale by a convex combination of "1" and the value of "size": >> >> 1 (default): scale by "size" as before >> 0: fixed size (as if the value of "size" were 1, just for the arrow >> head) >> >> Signed-off-by: Michael J Gruber <mic...@us...> >> --- >> I'll try and reply with two PNGs showing the output for arrowscale=0 (default) >> and arrowscale=1. >> >> Alternative to the RFC here, one could think about abstracting to graph.style.deco() >> with general decoargs and decokwargs arguments (defaulting to [arrowpos=0.5] and such). >> That would make it more complicated to specify a decorator which takes into account "size", though. >> >> pyx/graph/style.py | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/pyx/graph/style.py b/pyx/graph/style.py >> index 1d1e283..57cf2de 100644 >> --- a/pyx/graph/style.py >> +++ b/pyx/graph/style.py >> @@ -880,12 +880,13 @@ class arrow(_styleneedingpointpos): >> defaultlineattrs = [] >> defaultarrowattrs = [] >> >> - def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, epsilon=1e-5, decorator=deco.earrow): >> + def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, arrowscale=1, epsilon=1e-5, decorator=deco.earrow): >> self.linelength = linelength >> self.arrowsize = arrowsize >> self.lineattrs = lineattrs >> self.arrowattrs = arrowattrs >> self.arrowpos = arrowpos >> + self.arrowscale = arrowscale >> self.epsilon = epsilon >> self.decorator = decorator >> >> @@ -930,7 +931,7 @@ class arrow(_styleneedingpointpos): >> y2 = y_pt+(1-self.arrowpos)*dy*linelength_pt*size >> if self.decorator: >> privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), >> - privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*size)]) >> + privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*((1-self.arrowscale) + self.arrowscale*size))]) >> else: >> privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), privatedata.lineattrs) >> >> -- >> 2.7.0.341.gc1754cc >> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >> _______________________________________________ >> PyX-devel mailing list >> PyX...@li... >> https://lists.sourceforge.net/lists/listinfo/pyx-devel > > -- > by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim > / \ \ / ) wo...@us..., http://www.wobsta.de/ > / _ \ \/\/ / PyX - High quality PostScript and PDF figures > (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_______________________________________________ > PyX-devel mailing list > PyX...@li... > https://lists.sourceforge.net/lists/listinfo/pyx-devel -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Michael J G. <mic...@us...> - 2016-02-05 16:21:55
|
Hi, I think most people would be happy with arrow length proportional to the "size"-column and a choice for the head size: either proportional or fixed size. Maybe my convex combination was overdoing it a bit, but the same code gives the choice above (0 or 1). Alternatively, the arrow style could use an extra data column "head" whose value defaults to "$size" but could be set to "1" easily (everything still scaling with the same PyX base length that is currently used). Michael André Wobst venit, vidit, dixit 05.02.2016 16:46: > Hi again, > > I have to reply to myself. I just noticed, that by your change you can alter the length of the arrow (i.e. the line) independent from the size of the arrow cap. Now, this is something you need, and want. Ok. But wouldn't this mean, that we should have another input column, as an optional input column? Well, and yes, this maybe is again too complicated, as the arrow length (the line) and the size of the cap should depend on a single parameter only. Right. > > How about making linelength and arrowsize a callable (optionally) to enable insertion of non-linear dependance on the scaling. > > Still, this could maybe done on a translation step similar to the value-to-color conversion in a surface plot. Hmmm. I'm not yet done with getting myself to a final suggestion for a better implementation. > > Best, > > > André > > Am 05.02.2016 um 16:35 schrieb André Wobst <wo...@us...>: > >> Hi Michael, >> >> Such a scaling should not be done within PyX, at least not within a pyx graph style. It is different from arrowsize, as arrowsize is a PyX length. It defined the length of the arrow for a length data value of 1. Preprocess the length data values has nothing to do with plotting. One could think about a transformation done in a separate step, similar to the 1d-graph for the colors in a 3d graph. Well, interesting idea (to my mind). It could create a scale plot with different arrow sizes and their data value "automatically". >> >> However, within the graph style an arrowscale to (smoothly) enable arrow length adjustment between no-adjustment at all (fixed size) and 1 (linear scaling according to the data value) is too specific. It is not the right thing to do, IMHO. >> >> Best, >> >> >> André >> >> Am 05.02.2016 um 10:29 schrieb Michael J Gruber <mic...@us...>: >> >>> Currently, the length of the arrow as well as the size of the arrow head >>> are scaled by the value of the "size" column, which can get out of hand >>> quickly for vector field plots. >>> >>> Introduce an argument "arrowscale" (defaulting to 1) that makes the >>> arrow head scale by a convex combination of "1" and the value of "size": >>> >>> 1 (default): scale by "size" as before >>> 0: fixed size (as if the value of "size" were 1, just for the arrow >>> head) >>> >>> Signed-off-by: Michael J Gruber <mic...@us...> >>> --- >>> I'll try and reply with two PNGs showing the output for arrowscale=0 (default) >>> and arrowscale=1. >>> >>> Alternative to the RFC here, one could think about abstracting to graph.style.deco() >>> with general decoargs and decokwargs arguments (defaulting to [arrowpos=0.5] and such). >>> That would make it more complicated to specify a decorator which takes into account "size", though. >>> >>> pyx/graph/style.py | 5 +++-- >>> 1 file changed, 3 insertions(+), 2 deletions(-) >>> >>> diff --git a/pyx/graph/style.py b/pyx/graph/style.py >>> index 1d1e283..57cf2de 100644 >>> --- a/pyx/graph/style.py >>> +++ b/pyx/graph/style.py >>> @@ -880,12 +880,13 @@ class arrow(_styleneedingpointpos): >>> defaultlineattrs = [] >>> defaultarrowattrs = [] >>> >>> - def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, epsilon=1e-5, decorator=deco.earrow): >>> + def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, arrowscale=1, epsilon=1e-5, decorator=deco.earrow): >>> self.linelength = linelength >>> self.arrowsize = arrowsize >>> self.lineattrs = lineattrs >>> self.arrowattrs = arrowattrs >>> self.arrowpos = arrowpos >>> + self.arrowscale = arrowscale >>> self.epsilon = epsilon >>> self.decorator = decorator >>> >>> @@ -930,7 +931,7 @@ class arrow(_styleneedingpointpos): >>> y2 = y_pt+(1-self.arrowpos)*dy*linelength_pt*size >>> if self.decorator: >>> privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), >>> - privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*size)]) >>> + privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*((1-self.arrowscale) + self.arrowscale*size))]) >>> else: >>> privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), privatedata.lineattrs) >>> >>> -- >>> 2.7.0.341.gc1754cc >>> >>> >>> ------------------------------------------------------------------------------ >>> Site24x7 APM Insight: Get Deep Visibility into Application Performance >>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >>> Monitor end-to-end web transactions and take corrective actions now >>> Troubleshoot faster and improve end-user experience. Signup Now! >>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >>> _______________________________________________ >>> PyX-devel mailing list >>> PyX...@li... >>> https://lists.sourceforge.net/lists/listinfo/pyx-devel >> >> -- >> by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim >> / \ \ / ) wo...@us..., http://www.wobsta.de/ >> / _ \ \/\/ / PyX - High quality PostScript and PDF figures >> (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_______________________________________________ >> PyX-devel mailing list >> PyX...@li... >> https://lists.sourceforge.net/lists/listinfo/pyx-devel > |