Native %pl

Dan

Thank you for the bug report. I have fixed the 64 bit %PL so that it now accepts uppercase options.

The main thing to note is that you need to change the data supplied to %PL when using logarithmic scales. See the supplied notes on 64 bit %PL.

As you will have realised, the data does not lend itself to being joined by lines or curves. Best just to plot the points. y_max should be 30 (say).

Wow, so we have to take a LOG10 of X and Y data ourselves before supplying it to %pl in addition to call winop@('%pl[scale=LOG_LOG]) ?

Well, that's shocking to me. i'd say changing data this way is kind of very unusual and totally antiintuitive requirement no one will expect. No other software ever required that (even bad memory older Simpleplot). Why plotting software itself is not doing that internally leaving supplied data as is? The user always tries to see his data plotted this or that way, in linear, log-log, log-linear scales, and wants to do that just in one click. Why additional body movements are required for user to change the data for that? Is this temporal behavior of new %pl?

Another point, is the Bezier always used to make smooth curves why plotted curve may hiccup and plot something very different from the one based on points ?

Dan

I don't want to get into a long conversation on this.

64 bit %PL is just a quick stop gap aimed at getting existing 32 bit %PL code to draw something useful. I accept that it may not be very clever or generally useful at the moment.

I understand that this is first pancake which is always not as perfect. I just afraid bad initial development decisions which may stay forever

Quoted from PaulLaidler Dan As you will have realised, the data does not lend itself to being joined by lines or curves. Best just to plot the points. y_max should be 30 (say).

I sometimes can not use it even with the simplest LINEAR x_array plotting. Here is what I get with the data above and this code (just linear plotting even without any y_max)

USE clrwin 
 integer, parameter :: n_dim = 1153 
 real*8 xstart, X(n_dim), Y(n_dim) 

 OPEN (UNIT=275,FILE='A.dat',STATUS='old',err=990) 
 do i=1,10000 
   if(i.gt.n_dim) goto 100 
   read(275,*,err=995,end=100) X(i), Y(i) 
 enddo 
 100 close(275) 
 n_points=i-1 
 xstart=0 ! X(1) 
     
       i=winio@('%ww[no_border]%es%ca[Default Plot]%pv&') 
       i=winio@('%fn[Tahoma]&') 
       i=winio@('%ts&', 3.1d0) 
       i=winio@('%tc&',rgb@(0,0,0)) 
       i=winio@('%bf&') 
       i=winio@('%`bg&',rgb@(250,255,255)) 
!       CALL winop@('%pl[SCALE=log_log]')  
       CALL winop@('%pl[x_array]')  
       CALL winop@('%pl[n_graphs=1]')    
       CALL winop@('%pl[title='Sample plot']') 
       CALL winop@('%pl[x_axis=Wavelength A]') 
       CALL winop@('%pl[y_axis=Intensity@(-4.0)]') 
       CALL winop@('%pl[width=3]') 
!       CALL winop@('%pl[Y_max=30.]') 
       CALL winop@('%pl[smoothing=4]') ! anti-aliasing 
       CALL winop@('%pl[colour=black]')    
       CALL winop@('%pl[style=0,pen_style=0]')    

       i=winio@('%pl',1502,880,n_points,x,y) 


 goto 10000 

 !................. errors ...................... 
 990 Print*, 'Error opening file A.dat for read' 
 goto 10000 
 995 Print*, 'Error reading file A.dat' 
 goto 10000 
   
 10000 continue 
 end

• Do you see the same problem with the numbering for X axis tick marks?
• Do you see the same crazy curve (why I suspected that Bezier was used for smoothing)? With this is it possible just to offer linear approximation while connecting points?

Even if include rounded limit on X-min=12 the choice for tic numbers is not perfect

though this I think is fixable later. But the Log and Linear_Log is more important to fix first

I have added code to provide a better automatic x_min value but in the mean time you can set this in your code to 12.0 (say) or 10.0.

I have also corrected the code so that missing tick marks are now drawn.

I would use a smaller font (perhaps the default) and not bold. As I mentioned before, you can't realistically plot a curve for this data.

      i=winio@('%ww[no_border]%es%ca[Default Plot]%pv&') 
      i=winio@('%fn[Tahoma]&') 
      i=winio@('%`bg&',rgb@(250,255,255)) 
      CALL winop@('%pl[x_array]')  
      CALL winop@('%pl[title='Sample plot']') 
      CALL winop@('%pl[x_axis=Wavelength]') 
      CALL winop@('%pl[y_axis=Intensity]') 
      CALL winop@('%pl[x_min=12.]') 
      CALL winop@('%pl[symbol=9]')
      CALL winop@('%pl[link=none]')  
      i=winio@('%pl',1502,880,n_points,x,y) 

ps. I wonder if we are using the correct data.

Quoted from PaulLaidler ps. I wonder if we are using the correct data.

In the plots above I used small data file from previous page and large data I emailed to you (small or large here is not important, same problems I see in both cases). I also posted x_min=12 case probably at the same time as you posted your answer.

Right now new %pl is just for a fast draft data visualization not yet even reaching older Simpleplot %pl in some respects.

Missing are

• no bold fonts for numbering
• no settings for axis linewidth (right now it is 1 pixel no matter what plot size is).
• tic marks are wrong size and almost invisible and do not scale in length with the plot size.
• the amount of tic numbers is clearly excessive.

But these are minor details fixable easily. In short if you would be able to make this %pl approaching the look and feel of Ideal Plot #1 or #2 (I posted in other thread) and make the LOG data converted internally like in Simpleplot then this would be great and usable first version of new %pl !

In the future, in second version of %pl i'd add an option when you are scaling the plot size with the mouse all the fonts and line widths proportionally increase or decrease and make this style as universal scalable simplest default style, say, #100 so that you call it just in one single line

i=winio@('℅pv%pl[x_axis='Wavelength', y_axis='Intensity', n_graphs=1,style=100]',1502, 880, n_points, x, y)

and get exactly the perfect look of Ideal Plot #1 ready for any respectable publication. You will be increasing or decreasing its size with the mouse but the look will still be perfect. That will be great selling point and mass adoption of new %pl.

Future versions 3 will probably need to add 2D surface plotting or even 3D with OpenGL. I can send you my own 2D/3D plotting codes and examples if you need but I am sure you will be able to accomplish that much faster by themselves your way.

Dan

I can't do any more development on this for now. After the next full release we aim to revisit this subject and consider if there is a better way to get this kind of facility to the user.

Paul, Here are few other problems after I tried to plot in LOG-LINEAR scale. On top for comparison is the same data plotted in scientific graphics software OriginLab. In this software when you increase or decrease image using mouse it proportionally scales all elements making the whole plot perfect for all sizes even the thumbnail one. That is what I was advocating to implement in %pl. Hope you will soon find the time to return to %pl.

USE clrwin 
 integer, parameter :: n_dim = 1153 
 real*8 xstart, X(n_dim), Y(n_dim) 

 OPEN (UNIT=275,FILE='A.dat',STATUS='old',err=990) 
 do i=1,10000 
   if(i.gt.n_dim) goto 100 
   read(275,*,err=995,end=100) X(i), Y(i) 
 enddo 
 100 close(275) 
 n_points=i-1 
 do i=1, n_points
!  X(i) = alog10(X(i))
  Y(i) = alog10(Y(i))
 enddo 

 xstart=0 ! X(1) 
     
       i=winio@('%ww[no_border]%es%ca[Default Plot]%pv&') 
       i=winio@('%fn[Tahoma]&') 
       i=winio@('%ts&', 3.1d0) 
       i=winio@('%tc&',rgb@(0,0,0)) 
       i=winio@('%bf&') 
       i=winio@('%`bg&',rgb@(250,255,255)) 
!       CALL winop@('%pl[SCALE=log_log]')  
       CALL winop@('%pl[SCALE=log_linear]')  
       CALL winop@('%pl[x_array]')  
       CALL winop@('%pl[n_graphs=1]')    
       CALL winop@('%pl[title='Sample Log-Linear']') 
       CALL winop@('%pl[x_axis=Wavelength A]') 
       CALL winop@('%pl[y_axis=Intensity@(-4.0)]') 
       CALL winop@('%pl[width=3]') 
       CALL winop@('%pl[X_min=12.]') 
       CALL winop@('%pl[X_max=22.]') 
       CALL winop@('%pl[Y_min=0.1]') 
!      CALL winop@('%pl[Y_max=30.]') 
       CALL winop@('%pl[smoothing=4]') ! anti-aliasing 
       CALL winop@('%pl[colour=black]')    
       CALL winop@('%pl[style=0,pen_style=0]')    

       i=winio@('%pl',1502,880,n_points,x,y) 


 goto 10000 

 !................. errors ...................... 
 990 Print*, 'Error opening file A.dat for read' 
 goto 10000 
 995 Print*, 'Error reading file A.dat' 
 goto 10000 
   
 10000 continue 
 end

Thanks Dan.

As a good point one can note from these two pictures above that with its antialiasing FTN95 beats professional graphics software in line smoothness quality -- it produces MUCH less visible jaggedness.

Here is one more small defect with axis numbering. Plotted with different data set but this thing is pretty reproducible with almost any. Also, in this plot antialiasing is switched off so one can see the sharp edges of lines

Thanks Dan. For now you will probably need to use a smaller font size.

I do not know if this bug below should be fixed or we have to wait when the entire way of plotting LOG functions should be changed.

1. As i wrote that for example LOG_LINEAR way of plotting in new %pl is inconvenient as it requires LOG10 of all Y values. As the new %pl is in early development it would be easy to change things completely to the way older %pl doing same things. But may be it would be still a good idea to fix the current plotting way too. This simple annoying bug in tic numbering makes sometimes almost impossible to use %pl.

Here is the text for plotting of some simple function (i took y=x) where some y(i) take large values,like for example y(1)=1e20. In this case some tic marks here get crazy, like instead of 1e9 we see 1e909e7 etc

USE clrwin 
 integer, parameter :: n_dim = 5 
 real*8 X(n_dim), Y(n_dim), Z(n_dim)

 do i=1, n_dim
  A = i
  X(i) = A
  Y(i) = log10(A)
 enddo 

  Y(5) = log10(1e20)

     
  i=winio@('%ww[no_border]%es%ca[Default Plot]%pv&') 
  i=winio@('%pl[scale=log_linear,x_array,colour=black,colour=red,n_graphs=1]',600,400,n_points,x,y)! ,z)  

 end

2. Another problem is visible too but we discussed that already. /* Trying to make smooth line we get the plot distorted in the area x = 3.8 - 4. Offering an option of having just the simpler linear interpolation between points should be in many cases OK i think

Dan

In the next release I have taken logarithmic scales out of the native %PL until I get more time to work on this.

This bug looks easy fixable, may be it is worth for now just to fix it?

Also the question: why it was chosen to define the line width this way which is harder to change dynamically

CALL winop@('%pl[width=3]') 

instead of doing that usual way

i=winio@('%XX&', LineWidth) 

??

Unfortunately I don't have time to do anything more on this at the moment.

Paul,

I am using a recent download of libraries date stamped 5/11/2016 10:29am (I am not sure if this is the file date stamp, or the download date.) I think I got it from this thread.

When I run my graphics program I get the message: ' Argument number 2 of WINIO@ (continuation 113) should be an INTEGER(7) at address 1c007ee9'

The traceback gives: In scc_lib_version at address C4 In clearwin_error at address 14E In _set_edit_delay at address 1361 In _set_edit_delay at address 209B In _winop at address 501B In _winio at address 87E In WINDOW_PRINTF$$ at address 15A Within file saplot.exe in TEST at address 514

This has me a bit stumped, as I have checked all WINIO@ arguments and can not find the problem. I have used INTEGER(7) for all handles or previously INTEGER*8. (continuation 113) is not easy to locate !

Ver 8.05.00 (17/06/2016) does not produce this problem. Could the problem be in something else, say a function call ?

My 64 bit attempt to get the date stamp of the .dll is:

      subroutine echo_dll_version
!
      include <clearwin.ins>
      C_EXTERNAL SCC_LIB_VERSION@       '_scc_lib_version' :INTEGER*4
!      C_EXTERNAL INITLIBRARYFILEINFO@   '_InitLibraryFileInfo'():INTEGER*4
!      C_EXTERNAL GETLIBRARYVERSIONINFO@ '_GetLibraryVersionInfo'():STRING
!      C_EXTERNAL GETLIBRARYPATH@        '_GetLibraryPath'():STRING
!      C_EXTERNAL GETLIBRARYDATEINFO@    '_GetLibraryDateInfo'():STRING
!
      integer   dll_version
!      character str_dll_version_info*256
      character dos_date*9, dll_date*9, ftn95_ver*80
      external  dos_date
!
         include <ftn95_ver.ins>
!         ftn95_ver   = '[FTN95/Win32 Ver. 8.00 beta.14]'
         dll_version = scc_lib_version@ ()
         dll_date    = dos_date (ints(dll_version))
!
         WRITE ( *,1001) trim(ftn95_ver), dll_date, dll_version
         WRITE (98,1001) trim(ftn95_ver), dll_date, dll_version
!
      write ( *,1000) ' '
      write (98,1000) ' '
 1000 FORMAT (a,a)
 1001 FORMAT (a/' Salford DLL code : ',a,i11)
!
      RETURN
!
      END

Is this a possibility ? scc_lib_version@ () actually returns dll_version =17002 > 10-Mar-13 which looks wrong.

John

John

I think that there was a point where the beta DLLs got out of step with the last full release of FTN95. You may need to use the DLLs downloaded via a link in the current thread about %PL. If you can wait a little while, a full release is expected soon when hopefully everything will be sorted out.

John-Silver, I am sure Paul knows himself many these defects even without our mentioning. This new %pl is just in beta state, or, better say, even pre-beta. Just first attempts.

I will tell you based on my experience with 2D graphics, that it is actually not easy to make this graphics stuff look perfect from first attempts. It took me many years just to make it look not like utter ugly cr#p. And based on the same experience i may say even more: there were may be just couple run-time graphics packages which you can embed into your running codes in the entire history of computing which make regular XY plots look not like a cr#p.

I just hope to shorten potentially long try and fail attempts if we will show the best examples to follow and warn to avoid dangerous minefields. One of these fields is to use pixels as plot units. And i afraid this already took place with first version of new %pl. The plot design must be based on the entire X and Y dimensions of the plot and everything else must be based on percentage from these X and Y sizes (besides may be axis and line sizes which good to measure in pixels). That will allow to create scalable size graphs where the plots will look perfect with any magnification