| Re: the sky is falling down again [message #52341] |
Wed, 31 January 2007 12:15  |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
On Wed, 31 Jan 2007 11:52:06 -0700, R.G. Stockwell wrote:
Bob C. offers a good case where this could actually get you. Imagine a
free form plotting widget which allows you to zoom in arbitrarily. Now
imagine a very irregular data set being plotting, with spacings along the
abscissa down at the 10^-7 range, and up to 10. Zooming in to very small
ranges will cause this bug to bite, if you simply replot the entire data
set without trimming.
a=(b=[indgen(10)*1D-7,5,6,10.])
window,xsize=800,ysize=300
plot,a,b,PSYM=-4,XRANGE=[0.,1.e-6]
I'm surprised they round trip the plotting code through device (integer)
coordinates in this way first, rather than sticking with double for
all plot layout calculations until the very last stage, at which point
they could detect and clip off floating numbers that are out of range in
device coordinates system. Seems like asking for trouble.
JD
|
|
|
|
|
|
| Re: the sky is falling down again [message #52346 is a reply to message #52345] |
Wed, 31 January 2007 11:37  |
news.qwest.net
Messages: 137
Registered: September 2005
|
Senior Member |
|
|
"Mike" <Michael.Miller5@gmail.com> wrote in message
news:1170269688.017732.248620@v45g2000cwv.googlegroups.com.. .
> The problem is that IDL apparently will happily create plots that show
> the incorrect relationship between data sets. This is a major problem
> for people who use graphics for exploratory data analysis. If the
> results of a plot depend on the shape of the display window, that is a
> huge bug.
I would agree. This case though calls for attempting to plot a point
that does not exist in the window, or graphics device.
I suppose the routine could check this and issue an error.
> You are right that reasonable analysis might lead a user to
> discover the problem, but this still calls into question the
> reliability of IDL's graphics.
I don't think so, I think plotting an axis from 1 to 10, then
trying to plot the point 10000000,10000000 is not a reasonable
request.
I can accept plotting a point not within the axis. But when it
is way way way off the page, it should not be handled properly.
It is like using the following command:
xyouts,0.5,1000000,'This is offscreen', /normal
Cheers,
bob
|
|
|
|
|
|
| Re: the sky is falling down again [message #52348 is a reply to message #52347] |
Wed, 31 January 2007 11:28 |
Bob[3]
Messages: 60
Registered: December 2006
|
Member |
|
|
On Jan 31, 1:52 pm, "R.G. Stockwell" <n...@email.please> wrote:
> I think this is the exact same thing as
> IDL> print, 10+2*10^(-7)
> 10
> and complaining that IDL is wrong.
I think it is. (the same thing, and wrong).
We both know why it's wrong - but thaty doesn't make it right.
> The rule is not to attempt to plot a point that is so far
> off the graph that 32 bit calculations do have the required
> precision.
Well as programmers we need to be aware of these limitations of the
underlying language (users cannot be expected to be).
> anyways, that is how i see it. i.e. as not a flaw in IDL, and
> not something they should fix in any priority over some of the
> other problems.
Well, in a case such as presented, either we (as programmers) need to
address it (via workarounds or by limiting users options) or ITTVIS
needs to.
>> Perhaps the plotting routine should first interpolate the line to the
>> extent or the plotted region first - or at least within the limit
>> posted by JD.
>
> I don't think we want the routine doing that sort of thing, nor
> do I want it to cook toast for me:actually, cook bread, the end
> result being toast of course :) .
Why not?
If done properly it'd at least present a correct plot - isn't that
what plot is supposed to do?
(besides plot is already frying the bacon and setting the table)
BTW I too have enjoyed the investigative nature of this thread, as
well as your perspective.
Bob.
|
|
|
|
| Re: the sky is falling down again [message #52349 is a reply to message #52348] |
Wed, 31 January 2007 11:04 |
Mike[2]
Messages: 99
Registered: December 2005
|
Member |
|
|
Has anyone submitted a bug report yet?
Mike
IDL> a=indgen(10)*1D-7
IDL> b=a
IDL> plot,a,b,psym=1, position=[0.1,0.1,0.3,0.8]
IDL> oplot,[0,10],[0,10]
IDL> plot,a,b,psym=1, position=[0.4,0.1,0.9,0.8], /noerase
IDL> oplot,[0,10],[0,10]
|
|
|
|
|
|
| Re: the sky is falling down again [message #52352 is a reply to message #52351] |
Wed, 31 January 2007 10:52 |
news.qwest.net
Messages: 137
Registered: September 2005
|
Senior Member |
|
|
"Bob Crawford" <Snowman42@gmail.com> wrote in message
news:1170268829.777687.8070@s48g2000cws.googlegroups.com...
> On Jan 31, 1:09 pm, "R.G. Stockwell" <n...@email.please> wrote:
>> Seriously??
>> Does anyone think this is really a problem?
>> I must be missing the point.
>>
>> Who in their right mind would plot a point on a graph
>> (or a line to a point) that is so very very off the axis?
>> That is user error, not a failing in the plot routine to only
>> use 32 bit numbers.
>
> It's certainly counter-intuitive for the line from (0,0) -> (10,10)
> not to pass thru the points.
> ... and it's pretty dangerous to label something like that as 'user
> error'.
I think this is the exact same thing as
IDL> print, 10+2*10^(-7)
10
and complaining that IDL is wrong.
Or,
IDL> for i = 0.0, 9.8 do ....
or
IDL> a = findgen(20)
IDL> print, a[8762938717]
The rule is not to attempt to plot a point that is so far
off the graph that 32 bit calculations do have the required
precision.
anyways, that is how i see it. i.e. as not a flaw in IDL, and
not something they should fix in any priority over some of the
other problems.
> Perhaps the plotting routine should first interpolate the line to the
> extent or the plotted region first - or at least within the limit
> posted by JD.
I don't think we want the routine doing that sort of thing, nor
do I want it to cook toast for me:actually, cook bread, the end
result being toast of course :) .
> Mightn't this be a problem when zooming on on details on a plot? As
> indicated above, it depends on the plot window size as to when this
> misrepresentation will occur.
How can anyone zoom in 8 orders of magnitude (and still have
10 points on the screen)? The length of the array would
probably start to have problems fitting into a 32bit memory address.
Like i said, to see that plot would require a screen 200 km wide.
Thanks for the comments,
Cheers,
bob
|
|
|
|
|
|
|
|
| Re: the sky is falling down again [message #52355 is a reply to message #52354] |
Wed, 31 January 2007 10:09 |
news.qwest.net
Messages: 137
Registered: September 2005
|
Senior Member |
|
|
"Reimar Bauer" <R.Bauer@fz-juelich.de> wrote in message
news:epq5vh$386t$1@zam602.zam.kfa-juelich.de...
...
> Thanks
>
> So may be there should be L64 used instead.
Seriously??
Does anyone think this is really a problem?
I must be missing the point.
Who in their right mind would plot a point on a graph
(or a line to a point) that is so very very off the axis?
That is user error, not a failing in the plot routine to only
use 32 bit numbers.
Look at it this way. If your plot is 10cm wide on your screen,
with the x range from 0 to 10^-7, then the plot you are adding
([10,10]) would be plotted 11,000 km away. That is a very large screen
required to place that point.
Or, if you were plotting time, and [a] was in seconds, then the
x-axis would span 10 seconds, then the plotted point [10,10] would
occur at the year 211. That is insane, when you have a plot of
0 to 10 seconds, and you decide to draw a line to the point
corresponding to year 211.
Cheers,
bob
PS great thread though, very interesting to see the
detective work going on to figure out where the problem
actually occurs, but unfortunately imho utterly irrelevant.
|
|
|
|
| Re: the sky is falling down again [message #52357 is a reply to message #52355] |
Wed, 31 January 2007 05:35 |
R.Bauer
Messages: 1424
Registered: November 1998
|
Senior Member |
|
|
JD Smith wrote:
> On Tue, 30 Jan 2007 16:01:31 +0100, Paolo Grigis wrote:
>
>
>>
>> Reimar Bauer wrote:
>>
>>> Hi all
>>>
>>> here is another example which is very funny if you see it the first time
>>>
>>> a=indgen(10)*1D-7
>>> b=a
>>> plot,a,b,psym=1
>>> oplot,[0,10],[0,10]
>>>
>>> because the coordination system is defined by plot it could be a bug too
>>> and not only a question about precisions
>>>
>>>
>>> Any idea what is happen here?
>>
>> I think that maybe plot tries to find out the pixel coordinates
>> corresponding to the far end of the line. If it uses long, signed
>> integers for that, then it will overflow around pixel 2^31, which
>> seems roughly where the line is supposed to be with your settings
>> (which should be something like 500 pixel times 10 divided by 1d-6).
>
>
> In fact this has to be the right explanation. If instead of a wide
> window, you create a tall one:
>
> window,xsize=600,YSIZE=800
>
> Then the line falls below the points. And if you make an exactly square
> plotting window:
>
> window,xsize=800,ysize=800
> a=indgen(10)*1D-7
> b=a
> plot,a,b, psym=1,xstyle=3,ystyle=3,POSITION=[.1,.1,.9,.9],/NORMAL
> oplot,[0,10],[0,10]
>
> Then it all lines up well. The direction with the largest pixel count per
> unit data value ends up "truncating" first: i.e. the longer dimension of
> the plotting window. You can see where it truncates by gradually altering
> the values until the line just starts deviating:
>
> for k=2.,5.,.1 do begin & print,k & oplot,[0,k],[0,k] & wait,1 & endfor
>
> At some point, both clip, and you get a min and max angle (the size of
> which is related to the aspect angle of your plotting window). The first
> deviation for me was near k=2.3. What's close to that number?
>
> IDL> print,!X.CRANGE[0]+((!X.CRANGE[1]-!X.CRANGE[0])/ $
> ((!X.WINDOW[1]-!X.WINDOW[0])*!D.X_SIZE)) * 2.^31
> 2.2700673
>
> Aha. This is precisely the data coordinate where the implied device
> pixel coordinate with this plotting range hits 2.^31, the limit for a
> signed long integer. At that point, it clips to this value, while the
> Y-axis, not having clipped yet, continues to move up, until it too
> clips. Your number may differ depending on your window size.
>
> JD
>
Thanks
So may be there should be L64 used instead.
cheers
Reimar
--
Reimar Bauer
Institut fuer Stratosphaerische Chemie (ICG-1)
Forschungszentrum Juelich
email: R.Bauer@fz-juelich.de
------------------------------------------------------------ -------
a IDL library at ForschungsZentrum Juelich
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro. html
============================================================ =======
|
|
|
|
| Re: the sky is falling down again [message #52359 is a reply to message #52357] |
Tue, 30 January 2007 06:11 |
Kenneth Bowman
Messages: 86
Registered: November 2006
|
Member |
|
|
In article <epngnc$f9fd$1@zam602.zam.kfa-juelich.de>,
Reimar Bauer <R.Bauer@fz-juelich.de> wrote:
> a=indgen(10)*1D-7
> b=a
> plot,a,b,psym=1
> oplot,[0,10],[0,10]
It's hard to say where in the graphics pipeline the problem occurs.
This works
oplot,[0.0D,1.0D-2],[0.0D,1.0D-2]
and in this case the problem is smaller than your example
oplot,[0.0D,1.0D-0],[0.0D,1.0D-0]
Perhaps it is happening at the stage where the coordinates are converted to device
coordinates (integers). Have you tried it with a different device, such as PS?
Ken
|
|
|
|
| Re: the sky is falling down again [message #52363 is a reply to message #52359] |
Tue, 30 January 2007 09:51 |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
On Tue, 30 Jan 2007 16:01:31 +0100, Paolo Grigis wrote:
>
>
> Reimar Bauer wrote:
>> Hi all
>>
>> here is another example which is very funny if you see it the first time
>>
>> a=indgen(10)*1D-7
>> b=a
>> plot,a,b,psym=1
>> oplot,[0,10],[0,10]
>>
>> because the coordination system is defined by plot it could be a bug too
>> and not only a question about precisions
>>
>>
>> Any idea what is happen here?
>
> I think that maybe plot tries to find out the pixel coordinates
> corresponding to the far end of the line. If it uses long, signed
> integers for that, then it will overflow around pixel 2^31, which
> seems roughly where the line is supposed to be with your settings
> (which should be something like 500 pixel times 10 divided by 1d-6).
In fact this has to be the right explanation. If instead of a wide
window, you create a tall one:
window,xsize=600,YSIZE=800
Then the line falls below the points. And if you make an exactly square
plotting window:
window,xsize=800,ysize=800
a=indgen(10)*1D-7
b=a
plot,a,b, psym=1,xstyle=3,ystyle=3,POSITION=[.1,.1,.9,.9],/NORMAL
oplot,[0,10],[0,10]
Then it all lines up well. The direction with the largest pixel count per
unit data value ends up "truncating" first: i.e. the longer dimension of
the plotting window. You can see where it truncates by gradually altering
the values until the line just starts deviating:
for k=2.,5.,.1 do begin & print,k & oplot,[0,k],[0,k] & wait,1 & endfor
At some point, both clip, and you get a min and max angle (the size of
which is related to the aspect angle of your plotting window). The first
deviation for me was near k=2.3. What's close to that number?
IDL> print,!X.CRANGE[0]+((!X.CRANGE[1]-!X.CRANGE[0])/ $
((!X.WINDOW[1]-!X.WINDOW[0])*!D.X_SIZE)) * 2.^31
2.2700673
Aha. This is precisely the data coordinate where the implied device
pixel coordinate with this plotting range hits 2.^31, the limit for a
signed long integer. At that point, it clips to this value, while the
Y-axis, not having clipped yet, continues to move up, until it too
clips. Your number may differ depending on your window size.
JD
|
|
|
|
| Re: the sky is falling down again [message #52365 is a reply to message #52359] |
Tue, 30 January 2007 09:01 |
Foldy Lajos
Messages: 268
Registered: October 2001
|
Senior Member |
|
|
On Tue, 30 Jan 2007, Reimar Bauer wrote:
> Hi all
>
> here is another example which is very funny if you see it the first time
>
> a=indgen(10)*1D-7
> b=a
> plot,a,b,psym=1
> oplot,[0,10],[0,10]
>
> because the coordination system is defined by plot it could be a bug too
> and not only a question about precisions
>
>
> Any idea what is happen here?
>
> Cheers
> Reimar
>
add after plot:
print, 'normal x coord:', !x.s[0]+!x.s[1]*10.
print, 'device x coord:', (!x.s[0]+!x.s[1]*10.)*!d.x_size
you will get:
normal x coord: 8781250.3
device x coord: 5.6200002e+09
The pixel value is greater than the max. value for a 32 bit integer,
so anything can happen.
regards,
lajos
|
|
|
|
| Re: the sky is falling down again [message #52367 is a reply to message #52359] |
Tue, 30 January 2007 08:28 |
news.qwest.net
Messages: 137
Registered: September 2005
|
Senior Member |
|
|
"Reimar Bauer" <R.Bauer@fz-juelich.de> wrote in message
news:epngnc$f9fd$1@zam602.zam.kfa-juelich.de...
> Hi all
>
> here is another example which is very funny if you see it the first time
>
> a=indgen(10)*1D-7
> b=a
> plot,a,b,psym=1
> oplot,[0,10],[0,10]
I am not sure what point you are going after, but this seems
that it is plotting indgen*10^(-7). Is that your intent?
Or are you pointing out that the line from 0, to 10 when plotted
on the scale 10^-7 is not colinear with the points.
I think the extrapolation necessary to plot from 0, 10
when your axis ranges from 0 to 9*10^(-7) is so huge
(in the plot coordinates) that some roundoff error will
occur, and hence the lines won't line up exactly.
I suggest:
oplot,[0d,10d^(-6)],[0d,10d^(-6)]
that puts the line correctly (i think)
Cheers,
bob
|
|
|
|
|
|
| Re: the sky is falling down again [message #52372 is a reply to message #52359] |
Tue, 30 January 2007 07:05 |
Vince Hradil
Messages: 574
Registered: December 1999
|
Senior Member |
|
|
Try this, too:
plot, a, b, psym=1, xstyle=2, ystyle=2
oplot, [0,10], [0,10]
!?!
On Jan 30, 7:20 am, Reimar Bauer <R.Ba...@fz-juelich.de> wrote:
> Hi all
>
> here is another example which is very funny if you see it the first time
>
> a=indgen(10)*1D-7
> b=a
> plot,a,b,psym=1
> oplot,[0,10],[0,10]
>
> because the coordination system is defined by plot it could be a bug too
> and not only a question about precisions
>
> Any idea what is happen here?
>
> Cheers
> Reimar
>
> --
> Reimar Bauer
>
> Institut fuer Stratosphaerische Chemie (ICG-I)
> Forschungszentrum Juelich
> email: R.Ba...@fz-juelich.de
> ------------------------------------------------------------ -------
> a IDL library at ForschungsZentrum Juelich
> http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro. html
> ============================================================ =======
|
|
|
|
| Re: the sky is falling down again [message #52373 is a reply to message #52359] |
Tue, 30 January 2007 07:01 |
Paolo Grigis
Messages: 171
Registered: December 2003
|
Senior Member |
|
|
Reimar Bauer wrote:
> Hi all
>
> here is another example which is very funny if you see it the first time
>
> a=indgen(10)*1D-7
> b=a
> plot,a,b,psym=1
> oplot,[0,10],[0,10]
>
> because the coordination system is defined by plot it could be a bug too
> and not only a question about precisions
>
>
> Any idea what is happen here?
I think that maybe plot tries to find out the pixel coordinates
corresponding to the far end of the line. If it uses long, signed
integers for that, then it will overflow around pixel 2^31, which
seems roughly where the line is supposed to be with your settings
(which should be something like 500 pixel times 10 divided by 1d-6).
Ciao,
Paolo
>
> Cheers
> Reimar
>
>
>
|
|
|
|
| Re: the sky is falling down again [message #52374 is a reply to message #52359] |
Tue, 30 January 2007 06:29 |
Haje Korth
Messages: 651
Registered: May 1997
|
Senior Member |
|
|
shouldn't your oplot line read "oplot,[0,10]*1d-7,[0,10]*1d-7" ?
"Reimar Bauer" <R.Bauer@fz-juelich.de> wrote in message
news:epngnc$f9fd$1@zam602.zam.kfa-juelich.de...
> Hi all
>
> here is another example which is very funny if you see it the first time
>
> a=indgen(10)*1D-7
> b=a
> plot,a,b,psym=1
> oplot,[0,10],[0,10]
>
> because the coordination system is defined by plot it could be a bug too
> and not only a question about precisions
>
>
> Any idea what is happen here?
>
> Cheers
> Reimar
>
>
>
> --
> Reimar Bauer
>
> Institut fuer Stratosphaerische Chemie (ICG-I)
> Forschungszentrum Juelich
> email: R.Bauer@fz-juelich.de
> ------------------------------------------------------------ -------
> a IDL library at ForschungsZentrum Juelich
> http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro. html
> ============================================================ =======
|
|
|
|
| Re: the sky is falling down again [message #52418 is a reply to message #52346] |
Thu, 01 February 2007 10:58 |
edward.s.meinel@aero.
Messages: 52
Registered: February 2005
|
Member |
|
|
On Jan 31, 2:37 pm, "R.G. Stockwell" <n...@email.please> wrote:
> "Mike" <Michael.Mill...@gmail.com> wrote in message
>
> news:1170269688.017732.248620@v45g2000cwv.googlegroups.com.. .
>
>> The problem is that IDL apparently will happily create plots that show
>> the incorrect relationship between data sets. This is a major problem
>> for people who use graphics for exploratory data analysis. If the
>> results of a plot depend on the shape of the display window, that is a
>> huge bug.
>
> I would agree. This case though calls for attempting to plot a point
> that does not exist in the window, or graphics device.
But in this case, all I did was change the x- and y-style on the plot:
a=indgen(10)*1D-7
b=a
plot,a,b,psym=1, xstyle=2, ystyle=3
No overplotting of relatively large values here. Why does that give me
a bad plot?
|
|
|
|
| Re: the sky is falling down again [message #52428 is a reply to message #52345] |
Thu, 01 February 2007 04:45 |
R.Bauer
Messages: 1424
Registered: November 1998
|
Senior Member |
|
|
David Fanning wrote:
> Mike writes:
>
>
>> Has anyone submitted a bug report yet?
>
>
> You think those people don't have anything better to do!?
as fixing bugs and get money for this?
Sometimes I wish they could spent some time for money to get actual
library versions used with idl, e.g. netCDF
A lot of my windows colleagues trapped to use idl 6.2 because of the
'useless' ;) 64 bit extension of 6.3 which does prevent using older dlms
on windows. They have used before always the netCDF 2.4 dlm which has
the same rules for variable name definition as an actual 3.6 netCDF version.
May be I have to look in a dictionary because I have a very different
mind of payed support ;)
cheers
Reimar
> Has anyone checked on 24-bit PostScript support lately?
> Or a TV command that works correctly? Or, ... oh never
> mind. I must be grumpy from a lack of sleep. How come
> no one is working on the problem of jet lag? That seems
> to me to be a problem worth spending some time on. :-(
>
> Cheers,
>
> David
--
Reimar Bauer
Institut fuer Stratosphaerische Chemie (ICG-1)
Forschungszentrum Juelich
email: R.Bauer@fz-juelich.de
------------------------------------------------------------ -------
a IDL library at ForschungsZentrum Juelich
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro. html
============================================================ =======
|
|
|
|
| Re: the sky is falling down again [message #52429 is a reply to message #52349] |
Thu, 01 February 2007 04:26 |
R.Bauer
Messages: 1424
Registered: November 1998
|
Senior Member |
|
|
Mike wrote:
> Has anyone submitted a bug report yet?
>
> Mike
>
>
> IDL> a=indgen(10)*1D-7
> IDL> b=a
> IDL> plot,a,b,psym=1, position=[0.1,0.1,0.3,0.8]
> IDL> oplot,[0,10],[0,10]
> IDL> plot,a,b,psym=1, position=[0.4,0.1,0.9,0.8], /noerase
> IDL> oplot,[0,10],[0,10]
>
We will submit a bugreport to creaso
cheers
Reimar
--
Reimar Bauer
Institut fuer Stratosphaerische Chemie (ICG-1)
Forschungszentrum Juelich
email: R.Bauer@fz-juelich.de
------------------------------------------------------------ -------
a IDL library at ForschungsZentrum Juelich
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro. html
============================================================ =======
|
|
|
|
| Re: the sky is falling down again [message #52440 is a reply to message #52354] |
Wed, 31 January 2007 12:17 |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
On Wed, 31 Jan 2007 11:30:57 -0700, David Fanning wrote:
> Where else can people go when they want
> to count angles on the head of a pin? :^)
I prefer counting them in radians, because !RADEG is single precision
floating point.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
