|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sun Nov 10, 2013 7:59 am Post subject: Variable Multiple X-Y Plots |
|
|
I'd like set up a routine to plot a user-defined subset of a series of columns of results (stored in an array) onto a single graph.
To do this I'd like to allow the user to select which data to plot by selecting associated 'labels' for the column data from :
either
a) a list in an input file
or
b) multiple selection from a scrollable list containing all the labels for all the columns of data
Are these 2 approaches both feasible ?
The re-draw of the graph needs to be either automatic in the case of using an input file for the selection and/or the result of a 'button push' by the user after selection from a list. |
|
Back to top |
|
|
stenlou
Joined: 24 Jun 2008 Posts: 30 Location: Germany and Denmark
|
Posted: Thu Nov 21, 2013 8:47 am Post subject: Re: Variable Multiple X-Y Plots |
|
|
John
You can do this both ways. I assume you are aware of Simpleplot.
In clearwin you setup a window with the list of you variables (I assume one list for X and another for Y) that the user can select.
Read the two variable into two one-dimensional arrays and then plot these using Simpleplot.
Sten
ps need more help? |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Mon Dec 09, 2013 7:13 am Post subject: |
|
|
No, no Stenlou, I think we are at cross purposes.
Imagine I have 20 columns of Y data (one column of X data).
These are all stored in arrays.
I want to plot maybe say any 5 user selected columns of data out of the 20. The list I mentioned being 'identifiers' of the columns.
I'll plot with CLEARWIN because it's more flexible/complete I think.
What I want is to allow to plot one set of 5 columns say, then let the user select a different set and the plot to automatically (?) update as a result of the new selection. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Mon Dec 09, 2013 8:56 am Post subject: |
|
|
If you are using %gr then you can probably call clear_screen@ and then draw everything that the user has selected. |
|
Back to top |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Mon Dec 09, 2013 12:17 pm Post subject: Variable Multiple X-Y Plots |
|
|
John,
I would read-in all data, then create a WINIO window containing e.g. at the top or at the left side a multiple selection box %ms to select the five columns to be displayed and may be some more switches and buttons to control the graphics. Add a callback function to remove the oldest selection when the user selects too many values.
Then place a (scalable) %gr graphics window at the right or bottom inside the same window.
Check the actual graphics size with
Code: | IXRESOL = CLEARWIN_INFO@ ('SCREEN_WIDTH')
IYRESOL = CLEARWIN_INFO@ ('SCREEN_DEPTH')
| Check the range of your data to be displayed and scale it down to pixel values.
Then you have e.g. the following functions available:
Code: | CALL Draw_Line_Between@ (iX1, iY1, iX2, iY2, nColor)
CALL Draw_Rectangle@ (iX1, iY1, iX2, iY2, nColor)
CALL Draw_Ellipse@ (iX1, iY1, iRA, iRB, nColor)
CALL POLYLINE@ (iXP, iYP, nPol, nColor)
CALL Rotate_Font@ (ROTA)
CALL Bold_Font@ (irb_ColorMode)
CALL Draw_Characters@ (Text(1:LTX), IX1, IY1, nColor)
CALL Draw_Point@ (iX, iY, nColor)
| Take care, that you pixel coordinates are inside [-32767, +32767]
I hope this will help a little.
Erwin |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Mon Dec 09, 2013 12:37 pm Post subject: |
|
|
Thanks Erwin for your suggestion, just a couple of clarifications:
1) what do you mean exactly by ' scale it down to pixel values' ? (and why)
ii) why limit to -32767, +32767 ? |
|
Back to top |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Mon Dec 09, 2013 12:59 pm Post subject: |
|
|
From my experience it has advantages to have all coordinates in pixel, e.g. when you add text or self-made symbols.
Find the largest and smallest X,Y values of the selected vectors, build the difference max-min and bring it in relation to your drawing window. this gives the scale factor.
Reduce your coordinates to the min-values and multiply it with the scale. Then all your drawing will fit to your %gr window.
The coordinates in the listed drawing functions are integer*2 values!
-32767 to +32767 is definitely enough for all available screens. Your drawing window might be only 1800 x 1100.
Erwin |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Mon Dec 09, 2013 7:59 pm Post subject: |
|
|
OK, now I see what you mean - scale your graphics to fit into the %gr window by scaling the max dimensions to the available pixels in that window. That's what I am doing anyway, thanks for the reminder though.
As an aside from your note about the Integer*2 limit, that means then that there's a limit to the size of the %gr created drawing surface then, and hence the number of graphics which could be written to a single file, by creating a 'huge' drawing surface', being approx. 32767 / (1200) i.e. about 25 ish screen sized graphics if ordered vertically ? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Tue Dec 10, 2013 8:41 am Post subject: |
|
|
Quote: | The coordinates in the listed drawing functions are integer*2 values! |
This was the case for DBOS graphics. So if the routines (e.g. draw_line@) are ported from DBOS then the arguments will be 16 bit integers. However, most of these routines have 32 bit alternatives (e.g. draw_line_between@) and these are the ones that are listed in ftn95.chm and online. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2818 Location: South Pole, Antarctica
|
Posted: Tue Dec 10, 2013 6:16 pm Post subject: |
|
|
draw_line@ looks better then draw_line_between@.
Is it possible just to make two equivalent and both 32bit? Who cares about DBOS now, and even few still care they will not notice 16-->32 bit change under the hood. Both functions use integer*4 parameters by the way and no one knows or cares what's inside of these functions if both work absolutely fine without slightest difference to outside world. In short, there is no reason to make draw_like@ obsolete |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Tue Dec 10, 2013 7:58 pm Post subject: |
|
|
Quote: | draw_line@ looks better then draw_line_between@. |
These two routines are the same internally. The same code just different integer types on entry. So the appearance ought to be identical. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2818 Location: South Pole, Antarctica
|
Posted: Wed Dec 11, 2013 2:18 am Post subject: |
|
|
I use draw_line@ exclusively for Win32 application with entry variables of integer*4. Is it different for draw_line_between@ ? |
|
Back to top |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Wed Dec 11, 2013 10:00 am Post subject: |
|
|
Dan,
as long as formal integer*2 parameters in functions are no arrays, they can be called as well with integer*4 values because of byte-shift. (I think)
Erwin |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Wed Dec 11, 2013 12:19 pm Post subject: |
|
|
The following code demonstrates that you can provide an I*4 variable to a routine expecting an I*2 or I*1 variable, as long as there is no overflow. If an integer*2 array is expected then this approach will not work.
The same approach can NOT be used when mixing REAL*8 and REAL*4, as the exponent is in a different location.
Code: | integer*8 ix, iy
real*8 rx, ry
!
ix = 1024
iy = 767
!
call draw_line_i4 (ix, iy)
call draw_line_i2 (ix, iy)
call draw_line_i1 (ix, iy)
!
rx = 1024
ry = 768
!
call draw_line_r8 (rx, ry)
call draw_line_r4 (rx, ry)
end
subroutine draw_line_i4 (ix, iy)
integer*4 ix(2), iy(2)
write (*,*) 'I4_x',ix
write (*,*) 'I4_y',iy
end
subroutine draw_line_i2 (ix, iy)
integer*2 ix(4), iy(4)
write (*,*) 'I2_x',ix
write (*,*) 'I2_y',iy
end
subroutine draw_line_i1 (ix, iy)
integer*1 ix(8), iy(8)
write (*,*) 'I1_x',ix
write (*,*) 'I1_y',iy
end
subroutine draw_line_r4 (rx, ry)
real*4 rx(2), ry(2)
write (*,*) 'R4_',rx,ry
end
subroutine draw_line_r8 (rx, ry)
real*8 rx, ry
write (*,*) 'R8_',rx,ry
end
|
Last edited by JohnCampbell on Thu Dec 12, 2013 12:27 am; edited 1 time in total |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2818 Location: South Pole, Antarctica
|
Posted: Wed Dec 11, 2013 5:19 pm Post subject: |
|
|
That means that draw_line@ if it is 16bit inside will still be useful till Gigapixel-scale (2^16 x 2^16) image sizes. This confirms that it is too early to retire it, it will serve for one-two more human generations fine.
I suppose that the only reason to keep draw_line@ as is not changing inside to integer*4 is due to FTN95 option which checks dummy and real argument mismatch. If this is not true, then changing its internals to I4 will not break any legacy codes and reinstate it as current. Did I miss something else? |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|