In PDL 2.3.3 this works:
$win->PDL::Graphics::PGPLOT::Window::env(1,-1,1,-1);
but it does not in PDL 2.4.0, in which the script
exits complaining about a division by zero. I use a
lot this feature of defining a reversed range (values
decreasing from left to right and/or from bottom to
top) because it is quite useful in my area of
research. Moreover, a simple definition like the one
above seems a sensible solution to this need.
As PDL 2.4.0 does not seem to have included an
alternative way to do this kind of definition, my
guess is that this is a bug and not an intended
'unfeature'.
Eduardo Unda-Sanzana
eundas@yahoo.com
N.B.: Although it would not be a real solution, I had
already tried to mix the OO functions and the
low-level ones in order to define ranges as needed.
It gets quite cumbersome and still it does not work
:-(
Logged In: YES
user_id=20200
Bug fixed in CVS.
Thanks for reporting the problem!
Logged In: YES
user_id=20200
This was an interesting bug to track down. It came from the
fact that 2.4.0 uses its own env calculations for more
flexibility,
whle 2.3.4 used PGPLOT's env function. Where the pitch of the
pixels is calculated, the greater of the calculated ideal X
and Y pitches
is used. This was a simple max( xpitch, ypitch ) operation, but
in the counting-down case the calculated pitches are negative.
The solution is to compare the absolute values but preserve
the original
sign; all the other calculations then stay valid.