Native %pl

Great - thanks Paul. 😄

Both of us working on a Saturday - not to good. 😦

My observation is if, for example, scientist does not work on Saturdays - he does not work at all. 😃

Ken, Unless there was some specific purpose for that, copy_graphics_region was actually not needed to get 4 graphs together. Just placing these 4 %gr regions next to each other with ww[no_border] doing the same trick, is shorter and more convenient for run-time plotting. Here is the code example which running makes 4 different plots at the same time. It also crashes at the exit but the reason is probably different - program needs to exit cycling do loop first, which is probably easy to fix

winapp
use clrwin
common /RunContinueStop_/k_RunPauseContinueStop1234
common /Visual_/ k_visual, ixVis , iyVis, ihGrVis, ihGrVisGreen, lw_visWindow, ihGrRun, ihGrMain, icol
integer, external ::  Run

parameter (n=240) 
integer x(n),y(n)
common x,y

k_RunPauseContinueStop1234 = 1
k_visual	= 1
ixVis 		= 500
iyVis 		= 360

ihGrVis		= 4
ihGrVisGreen	= 3
ihGrRun		= 2
ihGrMain	= 1

do i=1,n
 x(i)=5*i
 y(i)=150 - 100 * sin(i/10.)
enddo

 i=winio@('%bg[gray]&')
! i=winio@('%^tt[Run  Code]&',Run)
 i=winio@('%^tt[E&xit]%ff%nl&','+','set',k_RunPauseContinueStop1234, 4,'exit')
 i = winio@('%ww[no_border]%pv%fr%lw',1200,800, ictrlFrame)
 i=winio@('%aw%ww[no_border]%pv%60.5cw',ictrlFrame, 0)
 jj=Run ()

end
!=====================================================
integer*4 function Run ()
use clrwin
common /RunContinueStop_/k_RunPauseContinueStop1234
common /Visual_/ k_visual, ixVis , iyVis, ihGrVis, ihGrVisGreen, lw_visWindow, ihGrRun, ihGrMain, icol

integer, external ::  Vis, Calc,  Interrupt 

j = Interrupt ()

 i=winio@('%ww[no_border]%ff&')
 i=winio@('%`gr[black]&',      ixVis, iyVis, ihGrMain)
 i=winio@('%`gr[blue]%ff&',    ixVis, iyVis, ihGrRun)
 i=winio@('%`gr[red]&',        ixVis, iyVis, ihGrVis )
 i=winio@('%`gr[green]',       ixVis, iyVis, ihGrVisGreen )

jj = Calc()

Run=1
end function

!================================================
integer*4 function Interrupt ()
use clrwin
common /RunContinueStop_/k_RunPauseContinueStop1234
common /Visual_/ k_visual, ixVis , iyVis, ihGrVis, ihGrVisGreen, lw_visWindow, ihGrRun, ihGrMain, icol
integer, external ::  Vis, Calc

 i=winio@('%^tt[Run]&',     'set',k_RunPauseContinueStop1234,1)
 i=winio@('%^tt[Pause]&',   'set', k_RunPauseContinueStop1234,2)
 i=winio@('%^tt[Continue]%ff&','set',k_RunPauseContinueStop1234,1)
 i=winio@('%^tt[StartVis]&','set',k_visual,1)
 i=winio@('%^tt[StopVis]&','set',k_visual,0)

 i=winio@('%^tt[E&xit]&', &
  '+', 'set',k_RunPauseContinueStop1234, 4, &
  '+', 'set',k_visual, 0, &
  '+', 'set',lw_visWindow, 0, &
       'set',iRunWindow,0) ! 'exit')

i=winio@('%lw&', iRunWindow)
Interrupt = 1
end function
!

!================================================
integer*4 function Vis ()
use clrwin
common /RunContinueStop_/k_RunPauseContinueStop1234 
common /Visual_/ k_visual, ixVis , iyVis, ihGrVis, ihGrVisGreen, lw_visWindow, ihGrRun, ihGrMain, icol
  i=winio@('%^tt[E&xit]&','set',lw_visWindow,0) ! 'exit')
  i=winio@('%lw',lw_visWindow)
  Vis = 1
end function
!=====================================================
integer*4 function Calc ()
use clrwin
common /RunContinueStop_/k_RunPauseContinueStop1234
common /Visual_/ k_visual, ixVis , iyVis, ihGrVis, ihGrVisGreen, lw_visWindow, ihGrRun, ihGrMain, icol
logical aa_log
integer, external :: plot
save 

a = 0.1
ixold = 0
iyold = 0

1	call temporary_yield@()	

if(k_RunPauseContinueStop1234.eq.1) then

  ir = random() * 255 
  ig = random() * 255 
  ib = random() * 255
  print*,'IR,IG,IB=',IR,IG,IB

  if(k_visual.eq.1) then

  icol = rgb@(ir,ig,ib)

if(ir.lt.64) then
 Print*,'<16 Run',icol 
 i16=select_graphics_object@(ihGrRun)
 if(i16.eq.0) goto 222
 call get_graphical_resolution@(ixVis,iyVis )

else if(ir.lt.128) then
  Print*,'<128 Main',icol 
  i32=select_graphics_object@(ihGrMain)
  if(i32.eq.0) goto 222
  call get_graphical_resolution@(ixVis,iyVis )
  ix   = random() * ixVis 
  iy   = random() * iyVis 
  call DRAW_filled_RECTANGLE@(IX,IY,IXold,IYold,ICOL)
  goto 222

else if(ir.lt.196) then
  Print*,'<196 red',icol 
  i48=select_graphics_object@(ihGrVis)
  if(i48.eq.0) goto 222
  call get_graphical_resolution@(ixVis,iyVis )
  ix   = random() * ixVis 
  iy   = random() * iyVis 
  call DRAW_RECTANGLE@(IX,IY,IXold,IYold,ICOL)

  goto 222

else
  Print*,'>196 green screen',icol
  i64=select_graphics_object@(ihGrVisGreen)
  if(i64.eq.0) goto 222
  call get_graphical_resolution@(ixVis,iyVis )
  jj = plot ()
  goto 222
 endif

  ix   = random() * ixVis 
  iy   = random() * iyVis 

  call temporary_yield@()	

  call draw_line@(ixold, iyold, ix,iy, icol)

222	  ixold = ix
	  iyold = iy
	endif

	endif

      do while(k_RunPauseContinueStop1234.eq.2)
	  call temporary_yield@()	
	  call sleep@(0.3)
          call sound@(8333,1)
      enddo

 if(k_RunPauseContinueStop1234.eq.4) goto 10000 ! stop run at exit button


  call sleep@(0.04)
  goto 1

10000	Calc = 1
end function
!........................................
integer function plot ()
use clrwin
parameter (n=240)
integer x(n),y(n)
common /Visual_/ k_visual, ixVis , iyVis, ihGrVis, ihGrVisGreen, lw_visWindow, ihGrRun, ihGrMain, icol
common x,y
save n_call, n1
data n_call/0/, n1/9/

	n_call = n_call + 1

	n1 = n_call
	if(n1.gt.n-1) then
	  n_call = 1
          call clear_screen@()
        endif

	icol=rgb@(255,0,0) 
	CALL set_line_width@(5)
	call draw_bezier@(x,y,n1,icol)

1000	plot = 1
	end

New DLLs are now available via the following link. The usual cautions apply. See the readme for new %pl options. Please report any bugs but not requests for additional features.

https://www.dropbox.com/s/ycd80m06hx9uxys/newDLLs5.zip?dl=0

Paul,

Thanks for that - no exception on program exit now.

However, the problem with the curve fitting has come back to haunt us.

Using newdlls4 there is no overshoot in the step responses:-

But with the newdlls5 there is :-

I'm not worried about the aspect ratio - that can be fixed with the new %pl[margin=n], n = 30 looks about right to me, and the %pl[etched] is a nice touch.

Hope this is an easy fix for you. The new %pl just about does everything I need it to do now.

Thanks

Ken

Dan,

Thanks for your sample code. It is always interesting to see other peoples approaches. I realise that I have much to learn having spent a few hours reading the Clearwin+ help pages after working my way through your code.

Generally my programs (some written 25 or more years ago) do a lot of number crunching and then spit out some results. My motivation for using Clearwin and FTN95 stems from the fact that younger engineers will not prepare a text file for input to a program, or accept a long file with many columns of data as an output. Since I started using Clearwin I have actually got some of our younger graduate engineers interested in writing Fortran rather than try to manipulate massive data sets in excel - which I think is a good thing. It's much easier to check some code than some of the complex spreadsheets I've seen created in my organisation. A good example is manipulation of harmonic impedance data for contingency analysis in power systems - this took an engineer 2 weeks in excel - 3000 lines of Fortran does the same job in 20 minutes - including generating all the required plots.

Thanks again

Ken

Ken, We all learn from each other here. I have question to you too - what settings in native %pl did you use in the last plots to get x and y axis linewidths more then 1 pixel wide? It clearly is not 'etched'

Dan, John,

The plots in the previous post did not use the new options in the latest dll from Paul (no 5)

Using these options with the new dll:-

      call winop@('%pl[smoothing=4]')
      call winop@('%pl[framed]')
      call winop@('%pl[margin=30]')
      call winop@('%pl[etched]')

Produced the following:-

The abscissa and ordinate are slightly thicker. The etched option does not accept a numerical value, so cannot make the lines thicker than this example.

John

Logarithmic scales are implemented in the latest DLLs.

Kenneth

Can you check the effect of using [link=lines] against [link=curves]. They were implemented the wrong way round in some contexts. You need 'lines' to avoid overshoot with step like functions.

Apologies Paul, [link=lines] and [link=curves] is fine as this example shows:-

      program test
      implicit none
      include<windows.ins>
      real(kind=2) x(1:500), y(1:500), t, dt, tstart
      integer i
      tstart = 1.d0 ; t  = 0.d0 ;  dt = 0.01d0 ; x  = 0.d0 ; y  = 0.d0
      do i = 1, 500, 1
        x(i) = t
        if (t .ge. tstart) y(i) = 1.d0
        t = t + dt
        write(6,*) x(i), y(i)
      end do
      
      i = winio@('%ww&')
      call winop@('%pl[native]')
      call winop@('%pl[x_array]')
      call winop@('%pl[smoothing=4]')
      call winop@('%pl[framed]')
      call winop@('%pl[colour=blue]')
      call winop@('%pl[width=2]')
      call winop@('%pl[margin=30]')
      call winop@('%pl[etched]')
      call winop@('%pl[link=lines]')
      call winop@('%pl[title=Lines]')
      i = winio@('%pl&',300,250,500,x,y)

      call winop@('%pl[native]')
      call winop@('%pl[x_array]')
      call winop@('%pl[smoothing=4]')
      call winop@('%pl[framed]')
      call winop@('%pl[colour=blue]')
      call winop@('%pl[width=2]')
      call winop@('%pl[margin=30]')
      call winop@('%pl[etched]')
      call winop@('%pl[link=curves]')
      call winop@('%pl[title=Curves]')
      i = winio@('%pl',300,250,500,x,y)
      
      end test

Which produces

There's something else that's causing a problem in my longer/more complex code which I'll need to track down. Can you please confirm the format of the numerical values for x_min, y_max etc, i.e. what is correct:-

call winop@('%pl[y_max=1.2d0]')

or

call winop@('%pl[y_max=1.2]')

Thanks Ken

Ken, John, Then obviously the Ken's graphs look here better then they actually are. Because either posting service, or the browser, or the lose graphics JPG format was used, which scale the lines from their original 1 pixel size, or better say distort, doing that by antialiasing way. To see that i made PrintScreen and magnified plots above and my own plots. I used lossless PNG format. Compare axis Ken plotted at the left with my plot at the right below. In my plot axis width is not broadened by fake antialiasing, it is strictly 1 pixel.

By the way noticed the way Silverfrost realized 'etching' ? Left and bottom axis have approximately 1.5 pixel linewidth. If it is done by antialiasing (Clearwin is specifically good at that, better then most professional software, see the curves when smoother) then the linewidth could be not integer number 1,2,3 ... which is very crude but floating point number like 1.5, 2.3, 3.4 ... Would be very good if Silverfrost implemented axis linewidth parameter and have done that the way like the etching was done.

You should use 1.2, 1.2e0 or 1.2E0. In C, sscanf is called using %f.

Thanks Paul.

The code below replicates the problem I've observed in my much larger program. Originally I thought there was some dependency on the order in which the %pl options are assembled into the %pl string. In both cases below the %pl options are the same, only the order of the options is different. In both cases [link=lines].

      program test
      implicit none
      include<windows.ins>
      real(kind=2) x(1:500), y(1:500), t, dt, tstart
      integer plot1, plot2, plot3, plot4
      integer i
      tstart = 1.d0 ; t  = 0.d0 ;  dt = 0.01d0 ; x  = 0.d0 ; y  = 0.d0
      do i = 1, 500, 1
        x(i) = t
        if (t .ge. tstart) y(i) = 1.d0
        t = t + dt
        write(6,*) x(i), y(i)
      end do
     
      i = winio@('%ww&')
      call winop@('%pl[native]')
      call winop@('%pl[x_array]')
      call winop@('%pl[framed]')
      call winop@('%pl[colour=blue]')
      call winop@('%pl[width=2]')
      call winop@('%pl[link=lines]')
      i = winio@('%`pl&',300,250,500,x,y, plot2)

      call winop@('%pl[native]')
      call winop@('%pl[colour=blue]')
      call winop@('%pl[width=2]')
      call winop@('%pl[framed][link=lines]') !### comment out this line
!     call winop@('%pl[link=lines]')         !    and replace with this line
      call winop@('%pl[x_array]')
      i = winio@('%`pl',300,250,500,x,y, plot3)
      end test

which produces this plot, link=lines is not effective in the second plot

I then found that if you comment out call winop@('%pl[framed][link=lines]') in the second %pl sequence, and replace it with call winop@('%pl[link=lines]') , i.e. remove the reference to [framed], the second plot is correctly generated as shown below (but obviously there is now no frame).

So the problem seems to be related to the combination of [link=lines] and [framed].

Apologies for continuing to pester you with this.

Regards Ken

The syntax %pl[framed][link=lines] is incorrect it should be %pl[framed,link=lines].

ClearWin+ should have faulted this.

doh :evil: why is the blindingly obvious sometimes so difficult to see? Thanks for your perseverance Paul.

It's taken three weeks, but I got there. 😄 Thanks for all your help folks.

Regards

Ken

John

The logarithmic values don't need to be converted beforehand.

Given this and the extra options in the readme, the only documentation that is needed can be found in the latest ftn95.chm at ClearWin+->SIMPLEPLOT->Native graph plotting.

Paul,

Another one for you to take a look at when you have time. In an x-y plot, if all the y data is negative, pl may choose some strange range values for the y-axis and not display the x axis. The programmer needs to set y_min and y_max carefully, and y_max must be zero to ensure the x axis is displayed.

        program test
      implicit none
      include<windows.ins>
      real(kind=2) x(1:50), y1(1:50), t, dt
      integer i
      t  = 0.005d0 ;  dt = 0.005d0 ; x  = 0.d0
      do i = 1, 50, 1
        x(i) = t  ; y1(i) = log10(t) ; t = t + dt
      end do

      write(6,*) maxval(y1)
      write(6,*) minval(y1)
     
      i = winio@('%ww&')
      i = winio@('%tc&',rgb@(0,0,255))
      call winop@('%pl[native,x_array,n_graphs=1,width=2]')
      i = winio@('%pl&',300,250,50,x,y1)
      call winop@('%pl[native,x_array,n_graphs=1,width=2,framed]')
      i = winio@('%pl&',300,250,50,x,y1)
      i = winio@('%ff&')
      call winop@('%pl[native,x_array,n_graphs=1,width=2,y_min=-2.5,y_max=-0.5,framed]')
      i = winio@('%pl&',300,250,50,x,y1)
      call winop@('%pl[native,x_array,n_graphs=1,width=2,y_min=-2.5,y_max=0,framed]')
      i = winio@('%pl',300,250,50,x,y1)
      
      end program

Produces:-

Regards

Ken

1. And here are probably partially the same LOG_LOG, LOG_LINEAR problems like in the post above. The code below either does not display anything or complains that 'Y contain zero or negative numbers' and automatically switches to LINEAR scale. The Y values as one can see do not contain zero or negative numbers

Displayed Y axis numbers in all scales including LINEAR have problem too.

2. In log scale it also does not like call winop@('%pl[Y_min=1e-8]') or call winop@('%pl[Y_max=1e-5]') and making numbers like 1d-5, 1d-8 immediately gets new %pl on strike 😃

3. As a suggestion if there exist CALL Winop@('%pl[Y_min=1e-8]') and zero/negative numbers in the data indeed are present the native %pl should not switch to linear scale but should keep going with LOG scale and just ignore and do not plot anything below Y_min

   winapp use clrwin real*8 X(11), Y(11)

   X(1)=6.9; Y(1)=1.0d-8 X(2)=10.; Y(2)= 6.d-8 X(3)=20.; Y(3)= 5.5d-7 X(4)=50.; Y(4)= 3.5d-6 X(5)=100.; Y(5)=7.8d-6 X(6)=200.; Y(6)=1.3d-5 X(7)=500.; Y(7)=1.8d-5 X(8)=1000.; Y(8)= 2.0d-5 X(9)=2000.; Y(9)= 1.95d-5 X(10)=4000.; Y(10)= 1.8d-5 X(11)=10000.; Y(11)= 1.7d-5

   iwid=800; iheig=600

   i=winio@('%ww&') i=winio@('%fn[Tahoma]&') i=winio@('%ts&',1.6d0) i=winio@('%tc&',rgb@(0,0,0)) i=winio@('%bf&') CALL winop@('%pl[x_array,N_GRAPHS=1]') CALL winop@('%pl[native]') call winop@('%pl[framed]') call winop@('%pl[SCALE=log_log]') ! LOG_LINEAR, LINEAR

   i=winio@('%pv%pl[x_axis='E [keV]',y_axis='Value Y',title='LOG_LOG Problem',& & colour=black]&', iwid, iheig, 11, X, Y)

   i=winio@('%ac[Esc]','exit')

   end

I guess that users will always be able to find data that the native %pl can't handle. It is after all a quick fix for the missing 64 bit SIMPLEPLOT which is a non-trivial product.

Naturally it can't handle log y for negative y and to switch to a linear scale seems reasonable to me. Negative values of log y are more difficult to handle because the automatic y min can get very large but we can look into that.

The good news is that users can always draw their own by using %gr or %pl with a callback to draw extra things on the graph. There is a subroutine that gives you the origin for the axes and the x and y pixel scaling.