Hi Axel,

sorry, I very much dislike your solution. I do understand your good intention, 
but the style just does not know anything about data types used by the axes. In 
that sense the addition in the style already is a mistake. The proper solution 
would be to move the addition into the axes. But this would be (at least) 
another function call slowing things down. Still, this would be the only 
solution to make the original code work unmodified without some ugly hacks.

We should overcome the temptation of such a hack by guessing too much things. 
The graph system already feels fancy, simple to break (partially due to bugs 
for sure) and it is certainly the wrong solution to make some more or less 
random guesses.

But as we identified the addition as the source of the problem, let me finally 
show you another solution: You can implement the correct addition within the 
data type. Works perfectly well.

    from pyx import *

    class dtuple(tuple):

        def __add__(self, other):
            return self[:-1] + (self[-1] + other,)

        def __sub__(self, other):
            return self[:-1] + (self[-1] - other,)

    g = graph.graphxy(width=8, y=graph.axis.split())
    g.plot(graph.data.points([(0.1, dtuple((0, 0.1)), 0.08),
                              (0.5, dtuple((0, 0.2)), 0.08),
                              (0.9, dtuple((0, 0.3)), 0.08),
                              (101, dtuple((1, 0.7)), 0.08),
                              (105, dtuple((1, 0.8)), 0.08),
                              (109, dtuple((1, 0.9)), 0.08)], x=1, y=2, dy=3),
           [graph.style.symbol(),graph.style.errorbar()])
    g.writePDFfile("minimal")


I do not claim this to be a nice solution (and this also always depends on the 
use case), but we can learn from that, that either the data types have to 
properly support addition and subtraction to use the delta-feature for 
calculating ranges in the graph or you should not use delta values at all. This 
is valid and comfortable standpoint. The alternative could only be to use the 
axes which knows how to properly deal with the axis data type, but I claim this 
to be just too much hassle for this very specific problem.

Best,


André


Am 25.01.2011 um 10:05 schrieb Axel Freyn:

> Hi André,
> 
> in order to correct the addition: I would propose to rewrite the
> adjustaxis - method: instead of "value+delta" one could use (with "from types 
> import TupleType")
> 
> if type(value) == TupleType:
>  point=map(lambda x:x[0]+x[1] , zip(value,data))
> else
>  point=value+data
> 
> or something in this direction. This would perform the correct addition
> for tuples, too.
> 
> Axel
> 
> 
> On Mon, Jan 24, 2011 at 10:36:16PM +0100, André Wobst wrote:
>> Dear Dave,
>> 
>> first of all thanks for sending this complete minimal example. You likely 
>> wouldn't have got an timely answer by me without it.
>> 
>> Tuples are the right way to specify the y values. It is nice to see that you 
>> basically already got the point. The problem comes from "value+delta" in the 
>> adjustaxis method of the range style (graph/style.py). Both value and delta 
>> are tuples like (0, 0.1) and (0, 0.08) and "+" adds them and creates a tuple 
>> (0, 0.1, 0, 0.08). Instead (0, 0.18) should have been created. I don't 
>> really know how to properly fix that. Probably the possibility to provide a 
>> delta is just not supported for split axes. (For the moment it clearly is, 
>> whether this is acceptable. For the moment I would say so.)
>> 
>> Anyway, as we identified the addition to be the problem, how about 
>> specifying the ymin and ymax value for the error bars? This runs fine, 
>> problem solved. Here is the code:
>> 
>>    from pyx import *
>> 
>>    g = graph.graphxy(width=8, y=graph.axis.split())
>>    g.plot(graph.data.points([(0.1, (0,0.1), (0,0.02), (0,0.18)),
>>                              (0.5, (0,0.2), (0,0.12), (0,0.28)),
>>                              (0.9, (0,0.3), (0,0.22), (0,0.38)),
>>                              (101, (1,0.7), (1,0.62), (1,0.78)),
>>                              (105, (1,0.8), (1,0.72), (1,0.88)),
>>                              (109, (1,0.9), (1,0.82), (1,0.98))], x=1, y=2, 
>> ymin=3, ymax=4),
>>           [graph.style.symbol(),graph.style.errorbar()])
>>    g.writePDFfile("minimal")
>> 
>> Best,
>> 
>> 
>> André
>> 
>> 
>> Am 22.01.2011 um 20:09 schrieb Dave Willmer:
>> 
>>> Hi everyone,
>>> 
>>> I'm having trouble getting error bars to appear on the y-axis when using a
>>> split y-axis, has anyone has any experience with this?
>>> Using the minimal example from the PyX website, I've got:
>>> 
>>> 
>>> from pyx import *
>>> 
>>> 
>>> g = graph.graphxy(width=8, y=graph.axis.split())
>>> 
>>> g.plot(graph.data.points([(0.1, (0,0.1), 0.08),
>>> 
>>>                         (0.5, (0,0.2), 0.08),
>>> 
>>>                         (0.9, (0,0.3), 0.08),
>>> 
>>>                         (101, (1,0.7), 0.08),
>>> 
>>>                         (105, (1,0.8), 0.08),
>>> 
>>>                         (109, (1,0.9), 0.08)], x=1, y=2, dy=3),
>>> 
>>> [graph.style.symbol(),graph.style.errorbar()])
>>> 
>>> g.writePDFfile("minimal")
>>> 
>>> 
>>> 
>>> which is just adding a third column to the data points, and assigning it to
>>> dy. This works if the x-axis is split (with y-errorbars), but doesn't work
>>> if the y-axis is split. Also, it doesn't generate any error message - the
>>> graph is created, it's just missing the errorbars.
>>> 
>>> 
>>> I've tried changing the third (dy) data column to be a tuple like the
>>> y-column, ie:
>>> 
>>> 
>>> g.plot(graph.data.points([(0.1, (0,0.1), (0,0.08)), ...
>>> 
>>> 
>>> however this throws the error
>>> 
>>> 
>>> File "/Library/Python/2.5/site-packages/pyx/graph/axis/axis.py", line 348,
>>> in adjustaxis
>>> 
>>>   assert len(value) == 2, "tuple of size two expected by bar axis '%s'" %
>>> errorname
>>> 
>>> AssertionError: tuple of size two expected by bar axis 'y'
>>> 
>>> 
>>> Sticking in a 'print type(value), value)' statement just before this assert,
>>> the data going in is:
>>> 
>>> 
>>> <type 'tuple'> (0, 0.10000000000000001)
>>> 
>>> <type 'tuple'> (0, 0.20000000000000001)
>>> 
>>> <type 'tuple'> (0, 0.29999999999999999)
>>> 
>>> <type 'tuple'> (1, 0.69999999999999996)
>>> 
>>> <type 'tuple'> (1, 0.80000000000000004)
>>> 
>>> <type 'tuple'> (1, 0.90000000000000002)
>>> 
>>> <type 'tuple'> (0, 0.10000000000000001, 0, 0.080000000000000002)
>>> 
>>> 
>>> so obviously this is cycling over the y-data, but then when it gets to the
>>> dy column, it still includes the y-data (or the dy has just been added to
>>> it).
>>> 
>>> 
>>> Anyone any ideas?
>>> 
>>> Do the dy values have to be assigned to the subcanvas individually?
>>> 
>>> 
>>> Any help is much appreciated!
>>> 
>>> Also, many thanks to Andre et al for a great piece of software!
>>> 
>>> 
>>> Cheers,
>>> 
>>> Dave.
> 
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> PyX-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/pyx-user

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   [email protected], http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Attachment: smime.p7s
Description: S/MIME cryptographic signature

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
PyX-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyx-user

Reply via email to