Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2006-04-16 19:33:41
|
It seems that are some request how to get some gnuplot internal variables
into the user space. For example, the current x and y ranges or the current
terminal name. Thus, the following could be helpful:
a = GPGET("terminal") => return "x11"
a = GPGET("termoptions") => return "enhanced noraise"
xmin = GPGET("xmin") => return min of xrange of the last plot
... GPGET("xmax"), "y2min", "cbmin", etc.
Only few variables, the most important, should be availabe now -- others
could be added on user's request any later, without poluting the user
space with new var/funcs.
That would solve this major problem (necessary before 4.2): Do you know
"gzoom" in Matlab/Octave? This command asks user to zoom-in the region of
interest. However, in gnuplot, you cannot access this range by
functions/variables -- it can only by printed to screen by "show xrange".
What do you think about GPGET("xmin") et al?
Or putting the plot ranges into XMIN, XMAX, etc?
---
PM
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-04-16 21:07:22
|
On Sunday 16 April 2006 12:33 pm, Petr Mikulik wrote:
> a = GPGET("terminal") => return "x11"
> a = GPGET("termoptions") => return "enhanced noraise"
> xmin = GPGET("xmin") => return min of xrange of the last plot
> ... GPGET("xmax"), "y2min", "cbmin", etc.
> Only few variables, the most important, should be availabe now -- others
> could be added on user's request any later, without poluting the user
> space with new var/funcs.
I'm not convinced that polluting the name space is a problem.
We could simply agree to use only variables beginning with
MOUSE_ or GPVAL_ or FIT_ or whatever, and document that users should
avoid creating private variables starting with these character strings.
Exporting a new internal variable as a user-visible one requires only
3 lines of code. Parsing for your proposed GPGET option would be more
cumbersome, I think, and would require making all exportable variables
global.
struct udvt_entry *name = add_udv_by_name("GPVAL_XMIN");
Ginteger(&name->udv_value, xmin);
name->udv_undef = FALSE;
>
> What do you think about GPGET("xmin") et al?
> Or putting the plot ranges into XMIN, XMAX, etc?
I think we should export internal values as user-visible variables
with a fixed naming scheme. See also feature request
#1117724 [fit] access to resulting chisquare
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Petr M. <mi...@ph...> - 2006-05-14 20:10:09
|
>> a = GPGET("terminal") => return "x11"
>> a = GPGET("termoptions") => return "enhanced noraise"
>> xmin = GPGET("xmin") => return min of xrange of the last plot
>> ... GPGET("xmax"), "y2min", "cbmin", etc.
>
>> Only few variables, the most important, should be availabe now -- others
>> could be added on user's request any later, without poluting the user
>> space with new var/funcs.
>
> I'm not convinced that polluting the name space is a problem.
> We could simply agree to use only variables beginning with
> MOUSE_ or GPVAL_ or FIT_ or whatever, and document that users should
> avoid creating private variables starting with these character strings.
>
> Exporting a new internal variable as a user-visible one requires only
> 3 lines of code. Parsing for your proposed GPGET option would be more
> cumbersome, I think, and would require making all exportable variables
> global.
I have implemented it as you've proposed, see SF patch
1488448 User-available GPVAL_ variables
This patch implements user-available GPVAL_ variables, like GPVAL_X_MIN,
GPVAL_X_MAX, GPVAL_Y_MIN, ...
Type
show var all
to display those variables related to the last plot.
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2006-05-16 20:01:24
|
On Sunday 14 May 2006 01:10 pm, Petr Mikulik wrote: > > I have implemented it as you've proposed, see SF patch > 1488448 User-available GPVAL_ variables > > Type > show var all > to display those variables related to the last plot. It looks basically reasonable to me. There are some rough edges though: %%%%%%% How to handle time data on axes? %%%%%%%%%%%%%%%%%% Terminal type set to 'wxt' gnuplot> load 'timedat.dem' Hit return to continue gnuplot> show xrange set xdata time set xrange [ "01/06/93\t0000" : "01/11/93\t0000" ] noreverse nowriteback gnuplot> print GPVAL_X_MIN -207792000.0 gnuplot> print GPVAL_X_MAX -194572800.0 %%%%%%% Something wrong in save/load code %%%%%%%%%%%%%%%%% Terminal type set to 'wxt' gnuplot> save 'yyy' gnuplot> load 'yyy' Segmentation fault I think these special variables should not be user-writable. That is, I think we want to return an error message like gnuplot> GPVAL_TERM_OPTIONS = "something or other" Cannot set internal variable GPVAL_* But this means it makes no sense to save these variables in the `save` command, because it will not be possible to read them back in on `load`. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Petr M. <mi...@ph...> - 2006-05-16 20:10:00
|
>> I have implemented it as you've proposed, see SF patch >> 1488448 User-available GPVAL_ variables > > It looks basically reasonable to me. > There are some rough edges though: > > %%%%%%% How to handle time data on axes? %%%%%%%%%%%%%%%%%% > > set xdata time > set xrange [ "01/06/93\t0000" : "01/11/93\t0000" ] noreverse nowriteback > > gnuplot> print GPVAL_X_MIN > -207792000.0 > gnuplot> print GPVAL_X_MAX > -194572800.0 Sorry, I have no idea about time values, I have never dealt with them. > %%%%%%% Something wrong in save/load code %%%%%%%%%%%%%%%%% > > Terminal type set to 'wxt' > gnuplot> save 'yyy' > gnuplot> load 'yyy' > Segmentation fault > > I think these special variables should not be user-writable. > That is, I think we want to return an error message like > > But this means it makes no sense to save these variables in > the `save` command, because it will not be possible to read > them back in on `load`. Yes, it is reasonable not to 'save' them, I will add this. > gnuplot> GPVAL_TERM_OPTIONS = "something or other" > Cannot set internal variable GPVAL_* Do you know where is code with the variable assignment? --- PM |
|
From: Petr M. <mi...@ph...> - 2006-05-17 14:32:23
|
> %%%%%%% Something wrong in save/load code %%%%%%%%%%%%%%%%%
> gnuplot> save 'yyy'
>
> gnuplot> GPVAL_TERM_OPTIONS = "something or other"
> Cannot set internal variable GPVAL_*
Both implemented, also for the MOUSE_ variables.
> SHOW_ALL_NL;
>- fputs("\n\tVariables:\n", stderr);
>+ int show_gpval = 0;
Fixed.
---
PM
|
|
From:
<br...@ph...> - 2006-05-18 16:36:10
|
Ethan Merritt wrote: > %%%%%%% How to handle time data on axes? %%%%%%%%%%%%%%%%%% > > Terminal type set to 'wxt' > gnuplot> load 'timedat.dem' > Hit return to continue > gnuplot> show xrange > > set xdata time > set xrange [ "01/06/93\t0000" : "01/11/93\t0000" ] noreverse nowriteback > > gnuplot> print GPVAL_X_MIN > -207792000.0 > gnuplot> print GPVAL_X_MAX > -194572800.0 That's to be expected. Time internally is kept in seconds since the millenium. I.e. there's nothing wrong with the above. |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-05-18 18:09:21
|
On Thursday 18 May 2006 09:35 am, Hans-Bernhard Br=F6ker wrote: > Ethan Merritt wrote: > > gnuplot> show xrange=20 > > > > set xdata time > > set xrange [ "01/06/93\t0000" : "01/11/93\t0000" ] noreverse > > nowriteback > > > > gnuplot> print GPVAL_X_MIN > > -207792000.0 > > gnuplot> print GPVAL_X_MAX > > -194572800.0 > > That's to be expected. Time internally is kept in seconds since the > millenium. I.e. there's nothing wrong with the above. I understand that the values are correct in some abstract sense (apart from being printed as negative numbers). But if the point of these GPVAL_* variables is to make the information available to a script, this format fails. We have no mechanism in place to use the value that is returned. =46or example, if you want to lock the x2 axis to agree with x1, the following seems the obvious way to do it: set x2range[ GPVAL_X_MIN : GPVAL_X_MAX ] But that won't work in the above case. =20 I admit to being very unfamiliar with the time/date code. I recently tried to use it for what I thought was a simple case, but got thoroughly tangled up. So I don't even have a suggestion as to how this *should* work, or what would need to be changed. Perhaps it would be sufficient to provide conversion routines? internal-time-in-seconds <=3D=3D> timefmt string Then (I think) it would work to say something like set x2range[ timestring(GPVAL_X_MIN) : timestring(GPVAL_X_MAX) ] =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
