comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: Reverse engineering the new graphics PLOT() margin property?
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Reverse engineering the new graphics PLOT() margin property? [message #79874] Wed, 18 April 2012 14:15
Sean[1] is currently offline  Sean[1]
Messages: 11
Registered: July 2005
Junior Member
On Monday, 16 April 2012 19:54:42 UTC-6, Mark Piper wrote:
> On Thursday, April 12, 2012 11:37:45 AM UTC-6, Sean Davis wrote:
>> I was wondering if anyone has figured out how the default margins are determined in new graphics?
>>
>> On a related note, it is infuriating that there is no way to return the values of INIT properties like margin, position, etc. (unless I'm missing something!)
>>
>> What I'd really like to be able to do is the following --
>>
>> p = plot(findgen(20))
>>
>> print, p.margin
>
> Hi Sean,
>
> I agree, we should be able to get these plot properties that we can set on init. I'll enter a bug report.
>
> In the meantime, I think this works (though I haven't tested it thoroughly):
>
> IDL> p = plot(findgen(10)^2)
> IDL> r = transpose([[p.xrange], [p.yrange]])
> IDL> m = p.convertcoord(r, /data, /to_normal)
> IDL> print, m
> 0.13000000 0.13000000 0.00000000
> 0.92000000 0.89000000 0.00000000
>
> Check:
>
> IDL> print, p.convertcoord(m, /normal, /to_data)
> 8.8817842e-016 0.00000000 0.00000000
> 10.000000 100.00000 0.00000000
>
> mp

Mark,

Yup, that's the solution I came up with, but there are two complications that are currently undocumented (and will hopefully be fixed in 8.2!!!)

1. For log, axes, data coordinates are returned as the log of the value

;make a plot with a logarithmic y axis
IDL> p = plot(findgen(10), yrange=[1e3,10.], ylog=1)
% Loaded DLM: XML.
;try to return the normal coordinates of the lower left corner
IDL> print, p.convertcoord(0,1e3, /data,/to_normal)
0.13000000 -378.73000 0.0000000
;yikes, the y-value of the lower corner doesn't look right -- try feeding in the log10 of the lower corner
IDL> print, p.convertcoord(0,alog10(1e3), /data,/to_normal)
0.13000000 0.13000000 0.0000000
;that looks better!


2. For multiplots using the LAYOUT keyword, the margin values are not normal relative to the whole window, but just to the fraction of the window that is taken up by the given plot. This is kind of hard to explain, but here's an example:

IDL> p = plot(findgen(10), yrange=[1e3,10.], ylog=1, layout=[2,2,1],title='Margins not specified')


;Now get the lower left and upper right corners of the plot box
IDL> print, p.convertcoord(0,3, /data,/to_normal)
0.085000000 0.57000000 0.0000000
IDL> print, p.convertcoord(10,1, /data,/to_normal)
0.46000000 0.94500000 0.0000000

;Try to reproduce the first plot by feeding in the margins that are implied (assuming the layout keyword allots a box going from 0.-0.5 in x and 0.5-1.0 in y (normal coordinates)
IDL> p2 = plot(findgen(10), yrange=[1e3,10.], ylog=1, layout=[2,2,1],title='Margin = [.085,.07,.04,.055]',margin=[.085,.07,.04,.055])
;This doesn't work! Why? Because apparently the margins are interpreted as being normal coordinates relative to the plot region allotted by the layout keyword!

;Instead, since we know that the 2 x 2 layout gives a plot region that is half the size of the full window in both x- and y-directions, we multiply the margin by 2
IDL> p3 = plot(findgen(10), yrange=[1e3,10.], ylog=1, layout=[2,2,1],title='Margin = [.085,.07,.04,.055]*2',margin=[.085,.07,.04,.055]*2)
;Now we've created a plot that is the same as the original plot!

Sean
Re: Reverse engineering the new graphics PLOT() margin property? [message #79902 is a reply to message #79874] Mon, 16 April 2012 18:54 Go to previous message
Mark Piper is currently offline  Mark Piper
Messages: 198
Registered: December 2009
Senior Member
On Thursday, April 12, 2012 11:37:45 AM UTC-6, Sean Davis wrote:
> I was wondering if anyone has figured out how the default margins are determined in new graphics?
>
> On a related note, it is infuriating that there is no way to return the values of INIT properties like margin, position, etc. (unless I'm missing something!)
>
> What I'd really like to be able to do is the following --
>
> p = plot(findgen(20))
>
> print, p.margin

Hi Sean,

I agree, we should be able to get these plot properties that we can set on init. I'll enter a bug report.

In the meantime, I think this works (though I haven't tested it thoroughly):

IDL> p = plot(findgen(10)^2)
IDL> r = transpose([[p.xrange], [p.yrange]])
IDL> m = p.convertcoord(r, /data, /to_normal)
IDL> print, m
0.13000000 0.13000000 0.00000000
0.92000000 0.89000000 0.00000000

Check:

IDL> print, p.convertcoord(m, /normal, /to_data)
8.8817842e-016 0.00000000 0.00000000
10.000000 100.00000 0.00000000

mp
Re: Reverse engineering the new graphics PLOT() margin property? [message #79916 is a reply to message #79902] Sun, 15 April 2012 12:15 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
alx writes:

> What you guess makes sense.
> But I disagree with the view that the new graphics system would be too
> much complex to work. I am now using it extensively, in real
> scientific work, since several months. I learned a lot! I can quickly
> produce figures of publishable quality (faster and better than by
> using direct graphics); widget programming is oversimplified by using
> "widget_window"; I can easily build and use movies when I want to do
> some animated presentations; 3-D plotting is no longer a technical
> difficulty; and many other things that I did not discover yet.
> Of course, there are still some hard limitations, too much frequently
> encountered and really frustrating. But most often, when I get a
> problem with new graphics, I have no way to decide whether the problem
> comes from an actual bug or because I am misusing it ! An usable
> documentation would fix that and, by the way, would certainly help
> Exelis in getting more useful returns from users.

Well, Alain, why don't *you* write about it! :-)

You are probably one of the few users who understand it.
I'm happy to give you free reign to write as many articles
as you like and post them on my web page. I'd like to have
some positive articles about function graphics to balance
my own experience with them. (They don't lend themselves
to the type of scientific work I've been doing lately,
I guess.)

This offer goes to anyone who would like to write an article.
You can find an article template here:

http://www.idlcoyote.com/template.php

Cheers,

David


--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Reverse engineering the new graphics PLOT() margin property? [message #79917 is a reply to message #79916] Sun, 15 April 2012 10:49 Go to previous message
lecacheux.alain is currently offline  lecacheux.alain
Messages: 325
Registered: January 2008
Senior Member
> David Fanning writes:
> I don't have any special knowledge about this, but
> my guess is that the people who have enough knowledge
> about this system to document it properly are too busy
> trying to make it work correctly to write about it.
> Maybe a couple of years from now there will be time
> to do a better job of it.
>
What you guess makes sense.
But I disagree with the view that the new graphics system would be too
much complex to work. I am now using it extensively, in real
scientific work, since several months. I learned a lot! I can quickly
produce figures of publishable quality (faster and better than by
using direct graphics); widget programming is oversimplified by using
"widget_window"; I can easily build and use movies when I want to do
some animated presentations; 3-D plotting is no longer a technical
difficulty; and many other things that I did not discover yet.
Of course, there are still some hard limitations, too much frequently
encountered and really frustrating. But most often, when I get a
problem with new graphics, I have no way to decide whether the problem
comes from an actual bug or because I am misusing it ! An usable
documentation would fix that and, by the way, would certainly help
Exelis in getting more useful returns from users.
alx.
Re: Reverse engineering the new graphics PLOT() margin property? [message #79918 is a reply to message #79917] Sun, 15 April 2012 07:00 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
alx writes:

> Exelis should have produced a decent
> documentation too, with a precise description of the adopted
> conventions as well as the used principles. Only such a documentation
> would make any user really able to understand and efficiently use by
> himself the rich capabilities offered by the IDL object graphics.

I don't have any special knowledge about this, but
my guess is that the people who have enough knowledge
about this system to document it properly are too busy
trying to make it work correctly to write about it.
Maybe a couple of years from now there will be time
to do a better job of it.

The real problem with such a complex system, it seems
to me, is that "fixing" a problem often puts
two more problems into the work queue. It's no wonder
it can't be documented. It would be a thankless
and never-ending job! I can't imagine anyone signing
up for it. (Although, as Coyote reminds me, he has
done these kinds of jobs for years as our inadequately
paid webmaster, and, except for a persistent drinking
problem, he is doing great!)

Cheers,

David

--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Reverse engineering the new graphics PLOT() margin property? [message #79919 is a reply to message #79918] Sun, 15 April 2012 04:15 Go to previous message
lecacheux.alain is currently offline  lecacheux.alain
Messages: 325
Registered: January 2008
Senior Member
On 13 avr, 23:10, David Fanning <n...@idlcoyote.com> wrote:
> jimmyleependle...@gmail.com writes:
>> Set a breakpoint in the method, recompile, RETALL, then rerun with some valid input.
>
> By the way, I just point out that in Windows 7, you can
> set a breakpoint, recompile, etc., etc., but you will
> never stop at the breakpoint. The Windows 7 "permissions"
> don't allow you to write in the ITTVIS directories.
> (Although you will get no warning that this is the case
> or that anything is amiss.)
>
> To set a breakpoint in an IDL-supplied program, you have
> to copy the file to a directory you own and modify it
> there. It's just another way saying, "Don't do this!"
> without being too obvious about it. :-)
>
> Cheers,
>
> David
>
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming:http://www.idlcoyote.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
>
>

Debugging is not mandatory for trying to understand "graphics", nor
"itools" from which graphics is derived. Studying the *.pro files as
distributed in \lib\graphics and \lib\itools directories would be
enough, in principle. I acknowledge Exelis to have made this software
entirely open.
But such a hacking task cannot be reasonably requested from a
"normal" (and paying) user. Exelis should have produced a decent
documentation too, with a precise description of the adopted
conventions as well as the used principles. Only such a documentation
would make any user really able to understand and efficiently use by
himself the rich capabilities offered by the IDL object graphics. This
lack of documentation is a pity: while IDL might be one of the best
existing multipurpose scientific software, there is the risk that a
growing number of IDL users only "sub-use" IDL (and then question the
licence cost) or, even, leave IDL completely out (e.g. the "python"
effect, etc...).
alx.
Re: Reverse engineering the new graphics PLOT() margin property? [message #79923 is a reply to message #79919] Fri, 13 April 2012 14:10 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
jimmyleependleguy@gmail.com writes:

> Set a breakpoint in the method, recompile, RETALL, then rerun with some valid input.

By the way, I just point out that in Windows 7, you can
set a breakpoint, recompile, etc., etc., but you will
never stop at the breakpoint. The Windows 7 "permissions"
don't allow you to write in the ITTVIS directories.
(Although you will get no warning that this is the case
or that anything is amiss.)

To set a breakpoint in an IDL-supplied program, you have
to copy the file to a directory you own and modify it
there. It's just another way saying, "Don't do this!"
without being too obvious about it. :-)

Cheers,

David



--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Reverse engineering the new graphics PLOT() margin property? [message #79924 is a reply to message #79923] Fri, 13 April 2012 14:00 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
jimmyleependleguy@gmail.com writes:

> If you are fearless, don't mind rolling up your
> sleeves and perhaps your pantlegs, and enjoy the
> thought of diving deep (well, just 6 routines deep)
> into the "internal" .pro routines, it's pretty
> straightforward to answer the question "How?"

Thanks for explaining the innards of the function
graphics system. It's the first time I've ever heard
it explained with good humor instead of foul language,
and I can't tell you how grateful I am for that!

This may go down as one of those "classic" posts
of the IDL newsgroup. I hope so. :-)

Cheers,

David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Reverse engineering the new graphics PLOT() margin property? [message #79926 is a reply to message #79924] Fri, 13 April 2012 13:46 Go to previous message
Jim  Pendleton is currently offline  Jim Pendleton
Messages: 165
Registered: November 2011
Senior Member
On Thursday, April 12, 2012 11:37:45 AM UTC-6, Sean Davis wrote:
> I was wondering if anyone has figured out how the default margins are determined in new graphics?
>
> On a related note, it is infuriating that there is no way to return the values of INIT properties like margin, position, etc. (unless I'm missing something!)
>
> What I'd really like to be able to do is the following --
>
> p = plot(findgen(20))
>
> print, p.margin

If you are fearless, don't mind rolling up your sleeves and perhaps your pantlegs, and enjoy the thought of diving deep (well, just 6 routines deep) into the "internal" .pro routines, it's pretty straightforward to answer the question "How?"

If you have none of these qualities, remain ashore and read no further. Contact support@exelisvis.com with a feature request, and return to the safety of your home.

There's no reverse engineering since the .pro code is exposed. But there is hacking.

You have set sail to Terra Incognita, where a secret dialect is fluently spoken only by the natives known as The Second Floor*. Here there be undoc'ed IDL.

As a shortcut to getting to the crux of your question, execute the following slightly illegal statement from the Workbench

IDL> p = plot(/test, margin=[0,0,0], /debug)

This will cause IDL to stop on an error
% MARGIN must have 1 or 4 elements.

All the display geometry calculation is in an editor window showing the routine in which you've stopped.

Set a breakpoint in the method, recompile, RETALL, then rerun with some valid input.

If you have the mad IDL debugging skilz, you'll see that the MARGIN value is likely discarded when other values are derived from it. By itself it never appears to be stored as a property of your plot object, such as in an obvious member variable.

If you back your way slowly and carefully out of the call stack (Show no fear! New Graphics can smell fear!), you may be able to discern how the derived values are used in subsequent calculations.

Of course the harder questions to answer are, "How do I change this to do what I want?" and the more generic "Why was it implemented this way?" These are exercises left for the reader.

Jim P.

*I'm on the third floor. We don't get capitalization up here.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Map Function Question
Next Topic: Re: speed-up computation of kernel-based "statistics"

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 13:53:19 PDT 2025

Total time taken to generate the page: 0.00533 seconds