Silverfrost Forums

Welcome to our forums

%pl[native] x/y label positions

10 Aug 2021 10:23 #28155

While I understand the existing algorithm used to determine the position of the x- and y-axis labels, for general purpose x/y plotting purposes it can result in very poor positioning of the x- and y-axis labels. The code below demonstrates the issue.

While this can be fixed by the programmer via a call back function to draw the labels after the %pl is drawn, a better approach (particularly for those starting to use %pl) would be an additional %pl option, with disables the default mechanism for label positioning and simply places the x-axis label centered on the centre line of the %pl frame and similarly for the y-axis label (similar to excel for example).

This would enhance the overall appeal of %pl for new users, and in my case, allow the simplification of new code.

This is the only remaining issue with the %pl[native] which I seem to run up against on a fairly regular basis.

Perhaps this proposed new option could be considered for a future update?

The direct link to the Clearwin+ enhancements file in the most recent version of Plato was a very good idea. I am finding that very useful.

module m
use clrwin
implicit none
real*8 :: x(2) = [-1.d0,1.d0],y(2) = [1.d0,-1.d0]
contains

  integer function gui()
  integer i
  i = winio@('%mn[Exit]&','Exit')
  i = winio@('Press Forward button 40 times observing position of x and y label&')
  call winop@('%pl[native,x_array,x_axis='x_data',y_axis='y_data', gridlines,frame,colour=blue,width=2]')
  i = winio@('%nl%fn[Consolas]%pl&',500,500,2,x,y)
  i = winio@('%sf%^bt[Forward]&',  forward)
  i = winio@('%^bt[Backward]&', backward)
  i = winio@(' ')
  gui = 2
  end function gui

  integer function forward()
    x(2) = x(2) - 0.05d0 + epsilon(1.0)
    y(2) = y(2) + 0.1d0  + epsilon(1.0)
    call simpleplot_redraw@()
    forward = 2
  end function forward

  integer function backward()
    x(2) = x(2) + 0.05d0 + epsilon(1.0)
    y(2) = y(2) - 0.1d0  + epsilon(1.0)
    call simpleplot_redraw@()
    backward = 2
  end function backward

end module m

program main
use m, only : gui
implicit none
integer i
i =gui()
end program main
11 Aug 2021 6:30 #28159

Ken

Thanks for the feedback. I think that this is simply a bug that needs fixing.

I have logged it for investigation.

12 Aug 2021 10:24 #28169

Ken

I now think that a new option is needed otherwise a change will adversely affect existing code.

In future a y-axis caption that starts with a tilde will be centred on the whole y range. The tilde will not be displayed. This will be experimental until you confirm that it works to your satisfaction.

12 Aug 2021 2:30 #28173

Thank you Paul, I shall lookout for the next intermediate dlls.
Have you included the x_axis? It is also sometimes poorly positioned, as shown in the example code, but not to the same extent as the y_axis. Ken

12 Aug 2021 3:38 #28174

Ken

I will add the same option for the x-axis caption.

12 Aug 2021 4:10 #28175

I do not think this will break any code because this was just the bug from the beginning. So i suggest not to use tilde. We are all early users of this option, there are just few of us, so we will adjust if needed. Adding tilde is counterintuitive and will break more code in the future

Besides, here is another example of bad placement of caption. It has also other defect you just fixed for the new release so ignore it (i guess, because did not have this new release yet), i just found this older demo as an example. My opinion the placement of caption has to be based on centering along the entire length of the visual axis line (i mean its visual (ix,iy) pixel position). Currently position seems decided by %PL based on data min and data max and if you change y_min manually like i did below the %PL does not see it

   module mod1
   use clrwin
   parameter (N=5)
   real*8 X(N), Y(N)
   Data X/1e1, 1e2, 1e3,  1e4, 4e5/
   Data Y/2.2, 66, 8333, 1111, 777/
   save
   contains

   INTEGER FUNCTION redraw ()
!    CALL simpleplot_redraw@()
    CALL        plot_redraw@()
    redraw = 2
    end function redraw
   end module
!................................
   Program bug333
   use mod1

   i=winio@('%fn[Tahoma]%bf%ts&',2.d0)
   CALL winop@('%pl[gridlines]')
   call winop@('%pl[axes_pen=2,frame_pen=2,width=2,x_axis='X Axis Title',y_axis='Y Axis Title']')
   i=winio@('%ww%pv%pl[native,framed,x_array,scale=log_log,N_GRAPHS=1,y_min=100.]%ff&', 925,700, n, X, Y)
   i=winio@('%sf%cn%^bt[Redraw]&', Redraw)
   i=winio@('%es')
   end
12 Aug 2021 6:05 #28176

Dan

The current default is to place the y-axis caption at the centre of the positive y-axis. For me, and perhaps the authors of many existing programs, this is best.

If I change this default then some users will be justifiably aggrieved.

Using a tilde seemed to me to be simpler than providing a new option but I am willing to be flexible on this.

12 Aug 2021 10:55 (Edited: 13 Aug 2021 6:54) #28177

This can be used but this placement of caption (in the center of positive part) is very vulnerable to being overwritten by the numbers or by the curve. Here is standard plot which i made out of Ken's example above: https://i.postimg.cc/Y9sjXYsm/Image10.jpg Good that positions and other settings could be adjusted if use Designer Mode, all this can done after plotting without programming, just clicking. I added into the source antialiasing and other things but this actually is not needed because can be done in Designer mode. For all other users who are interested this is the code and how plot captions could look after moving them using Designer mode: https://i.postimg.cc/GtSXVHnf/Image13.jpg

module m
use clrwin
implicit none
real*8 :: x(2) = [-1.d0,1.d0],y(2) = [1.d0,-1.d0]
contains

  integer function gui()
  integer i
  i = winio@('Press Forward button 40 times observing position of x and y label&')
  i=winio@('%ww%fn[Tahoma]&') 

  i =  winio@('%ts%bf&',1.d0) ! font size and bold-face
  i =  winio@('%`bg&',rgb@(245,250,255)) ! bluish background for plot
  call winop@('%pl[smoothing=4]') ! anti-aliasing for line smoothing 
  call winop@('%pl[file=zPlotDemo_DesignerMode.set]')	 
  call winop@ ('%pl[axes_pen=2.]') 
  call winop@('%pl[native,x_array,x_axis='x_data',y_axis='y_data', gridlines,colour=blue,width=2]')
  i =  winio@('%nl%pv%pl&',500,500,2,x,y)
  i =  winio@('%sf%^bt[Forward]&',  forward)
  i =  winio@('%^bt[Backward]&', backward)
  i =  winio@('%es')
  gui = 2
  end function gui

  integer function forward()
    x(2) = x(2) - 0.05d0 + epsilon(1.0)
    y(2) = y(2) + 0.1d0  + epsilon(1.0)
    call simpleplot_redraw@()
    forward = 2
  end function forward

  integer function backward()
    x(2) = x(2) + 0.05d0 + epsilon(1.0)
    y(2) = y(2) - 0.1d0  + epsilon(1.0)
    call simpleplot_redraw@()
    backward = 2
  end function backward

end module m

program main
use m, only : gui
implicit none
integer i
i =gui()
end program main

But in most cases more universal is to create the frame like Ken did and place the axis names in the middle of the X and Y entire frames. Here is an example: https://matplotlib.org/1.3.1/_images/tripcolor_demo_022.png Here you can click 40 times or 40000 times the result will look perfect. As another confirmation for that if you click on Ken's example Forward and Backward buttons the current placement in the middle of the positive part will look extremely ugly until it will be absolutely unacceptable aesthetically, permanently moving and at some point completely disappear: https://i.postimg.cc/rFwFSXrD/Image4.jpg

So if frame is used the placement of axis caption ideally has to be in the middle of the frame

13 Aug 2021 7:08 #28179

Dan

In response to your initial comment, I could add a new option [y-axis=caption] that uses a hyphen rather than the existing underscore. This would be instead of using a tilde.

13 Aug 2021 7:46 #28180

Dan,

I think the issue here is with older code – pre 64 bit %pl[native], i.e. 32 bit applications which used the simpleplot.dll

The %pl[native] has adopted the same convention as the earlier simpleplot.dll to avoid breaking code previously compiled as 32 bit applications which may now be recompiled as 64 bit code and consequently Paul does have to retain the current default placement however “illogical” you and I think it is.

Paul,

I was happy with the prospect of adding a tilde to override the default placement, but thinking about this a little more yesterday evening after reading the later posts, an option like axis_placement=1 or 2 where 1 is equivalent to the original simpleplot.dll (and the default value where none is specified), and 2 is “centred on frame”, or using Dans’ terminology “universal” might be more straightforward from a programmer’s perspective. The selected axis_placement option would apply to both x and y.

In my case it would be an additional option to always specify once per %pl (much the same as gridlines and frame), and there is no need to worry about adding a tilde, while protecting older applications originally 32 bit when recompiled with the 64 bit compiler.

With this “option” approach you could also include a recommendation to use axis_placement=2 for new code in the help file, which would spare new users some of the “head scratching” Dan and I have experienced over the last few years (i.e where has the axis label gone to?, or why is the label poorly positioned?).

This approach would also avoid the potentially embarrassing/rework situation where the programmer’s test data produces a satisfactory graph with the tilde omitted but a third parties data (i.e. an end user) generates a less satisfactory plot in terms of axis label placement (i.e. tilde required).

While it may be slightly more difficult to implement within the Clearwin+ code (which means claiming a little more of your time - sorry) , I think this might be a more robust solution all round.

Ken

13 Aug 2021 9:04 #28181

Ken

It would be simpler, both for me to implement and perhaps also for the user, if I add new options [x-axis=name] and [y-axis=name] where the original underscore is replaced by a hyphen.

I will implement this approach on an experimental basis then you can test it and report back how you get on.

13 Aug 2021 10:02 #28184

Paul,

That's fine, I think I may be guilty of thinking about this a little too much.

Thanks

Ken

19 Oct 2021 10:17 #28364

New DLLs (and incidentally v8.81 of FTN95) are now available for download via the Support 'sticky' post https://forums.silverfrost.com/Forum/Topic/3780.

Contrary to the information above, the two new %pl options are [xaxis=<caption>] and [yaxis=<caption>]. These are like [x_axis=<caption>] and [y_axis=<caption>] but the captions are centred on the whole of the axis rather than the positive part.

20 Oct 2021 8:21 #28369

Paul, with which version this DLL will work? I can not use 8.80 because SDBG64 does not debug my files so i use previous version of compiler. I think older version of SDBG64 also does not work with 8.80

20 Oct 2021 11:44 #28370

Dan

The new DLLs might work with the FTN95 and SDBG64 that you are able to use but you should keep a backup of your current DLLs in case you have any problems.

But a better way forward would be for you to send a sample program that illustrates why the 8.80 release is not working for you.

21 Oct 2021 4:42 #28373

Paul, Scratching the head how to make a demo test when any small program runs OK and only large programs crash I found very good relatively known demo example, probably best of all: polyhedron dot com benchmarks.

You know, but many newcomers may not, that these benchmarks were made in 90th and everyone use them to optimize compiler run time speed. I remember well how these tests were selected and discussed on comp.lang.fortran at that time. I remember also how program calculating pi number was much fastest on FTN95 than any other Fortran. But then all other developers started to pay attention and optimized their compilers, specifically Intel and Absoft

FTN95 gas_dyn2.f90 /link /debug /64

When debugged this program immediately crashes the debugger. Same with mdbx.f90

21 Oct 2021 6:13 #28374

Dan

For me gas_dyn2.f90 runs OK for /64 /debug. It fails for /64 /checkmate but that might be due to an error in the code.

The same is true for mdbx.f90. It runs for /64 /debug but not /64 /checkmate.

Both run OK for /checkmate (i.e. 32 bits). I will make a note to investigate the failures but I have not been able to confirm your experience when using the current FTN95 and SDBG64.

21 Oct 2021 7:07 #28375

Yes, they run OK, but not debugged. Immediately crash after running via debugger

SDBG64 gas_dyn2.exe --> access violation inside debugger.

Same with all my large codes. Small demos all work OK

21 Oct 2021 7:56 #28376

Even more both polyhedron benchmarks and both my codes crash SDBG64 even with /nocheck /64 compilations. Robert mentioned about this that dynamic allocation was introduced for COMMON blocks. May be this is the reason?

21 Oct 2021 12:16 #28377

Dan

For me they run OK when using SDBG64 (for /64 /debug but not /64 /checkmate). I will check which version of SDBG64 I am running. I think that it will be the same as in the latest full release.

Please login to reply.