soccer jersey forums.silverfrost.com :: View topic - %pl dx and dy values
forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

%pl dx and dy values

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
Kenneth_Smith



Joined: 18 May 2012
Posts: 709
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Fri Sep 01, 2023 12:12 pm    Post subject: %pl dx and dy values Reply with quote

Question, is there a way to interrogate the clearwin data to determine the currently applied %pl dx and dy values?

I think I already know the answer as I cannot see a documented function something like: GET_PLOT_DBL@(id, option, index, fval), but it may exist?

Ken
Back to top
View user's profile Send private message Visit poster's website
Kenneth_Smith



Joined: 18 May 2012
Posts: 709
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Fri Sep 01, 2023 3:24 pm    Post subject: Reply with quote

I am unable to remove my first post of today, something went horribly wrong. Perhaps the forum admin can do this?

The question above, stems from the code at the link below, which shows that the value returned by change_plot_dbl@ to adjust dx is always zero, even when the requested change is not made (maybe a silly value, or a value which would cause the text to overlap depending on the plot aspect ratio).

If a non-zero value was returned (as implied in the documentation), the code could detect this and "try again" with an alternative value. Consequently, the fortran code cannot keep track of the current dx value.

This means that if I use %pl without gridlines, if I then draw the grid lines within the %pl call back, the dx spacing may, or may not correspond to the value that was specified in the last call change_plot_dbl@ for dx.

At the moment, I cannot see a way to ensure that the %pl call back uses the correct dx value when drawing the vertical gridlines, i.e. aligned with the numbers on the x axis.

I was not initially looking at the return value from change_plot_dbl@ when I observed this occasionally occurring, and I thought the return value would provide a solution, but this does not appear to be the case.

Same issue can occur with the dy value.

Is this a possible bug in change_plot_dbl@ ?
https://www.dropbox.com/scl/fi/or7hmrqffpb2jpduhsjy3/dxproblem.f95?rlkey=rflboeyfatxygn50qbopqfdr9&dl=0
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK

PostPosted: Sat Sep 02, 2023 7:54 am    Post subject: Reply with quote

Ken

I have tested your sample program.

After clicking the CB4 button I get -521, -511, -501 on the x axis. The same for both 32 and 64 bits.

Am I missing the point?
Back to top
View user's profile Send private message AIM Address
Kenneth_Smith



Joined: 18 May 2012
Posts: 709
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Sat Sep 02, 2023 11:05 am    Post subject: Reply with quote

Paul,

I knew this would be difficult to explain.

You and I can, but the fortran code cannot view the graph, so how can the code keep track of the presently applied dx value after the last call to change_plot_dbl@, since this always returns zero?

Consider the sample program (which is rather artificial), where CB1 and CB5 are called in sequence.

When the window is formed, %pl is setting its own xmin, xmax, and dx.

After the call to CB1 Xmin, and xmax are changed to �nice� values i.e. � 520 and -500.

After the call to CB5 which fails to set the dx value to 20, the more complex / extended program logic thinks the values are:

Xmin = -520 Xmax = -500 dx = 20

But in reality they are:

Xmin = -520 Xmax = -500 dx = 10

Additional code, which now attempts to draw the vertical grid lines based on a dx value of 20 which it thinks has been applied, means that the grid line which is required in the actual grid produced (with dx =10) at Xmin + dx = -520 + 10 is omitted. The resulting graph is shown below:

https://www.dropbox.com/scl/fi/417081clejrz4lo9smgzo/missing_dx.JPG?rlkey=efqq4ybp4nk87yod2e01e8s88&dl=0


This is the issue which started me off looking at the return value from change_plot_dbl@.

Perhaps the solution to my problem is simply to prevent the case where dx = (xmax � xmin) ever occurring, but that may generate another problem when the x/y grid aspect ratio is low (x axis becomes cluttered). I will explore this further. (An even simpler solution, remove the option to redraw the grid lines and use the default %pl gridlines, but they become somewhat lost under all the other data in the graph.)

I�m now curious, under what circumstances does change_plot_dbl@ actually return a non-zero value?
Back to top
View user's profile Send private message Visit poster's website
Kenneth_Smith



Joined: 18 May 2012
Posts: 709
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Sat Sep 02, 2023 12:03 pm    Post subject: Reply with quote

This may better illustrate the issue.

Code:
program dxdy2
use clrwin
implicit none
integer iw, cb1, pl_cb ; external cb1, pl_cb
real*8 xmin, xmax, dx, ymin, ymax
common xmin, xmax, dx, ymin, ymax
  xmin = -520.d0 ;xmax = -500.d0 ; dx=20.d0 ; ymin = 230.d0 ; ymax = 250.d0
  iw = winio@('%mn[Exit]&','exit')
  call winop@('%pl[native,x_array,frame,etched,external_ticks,smoothing=5,axes_pen=2,link=user]')
  iw = winio@('%^pl&', 600,600,2,[xmin,xmax],[ymin,ymax], pl_cb)
  iw = winio@('%^bn[CB1]',cb1)
end program dxdy2

integer function cb1()
use clrwin
implicit none
integer :: i(3)
real*8 xmin, xmax, dx, ymin, ymax
common xmin, xmax, dx, ymin, ymax
  i(1) = change_plot_dbl@(0,"x_min",   0,xmin)
  i(2) = change_plot_dbl@(0,"x_max",   0,xmax)
  i(3) = change_plot_dbl@(0,"dx",      0,dx)
  print*, i
  call simpleplot_redraw@()
  cb1 = 2
end function cb1

integer function pl_cb()
use clrwin
real*8 xmin, xmax, dx, ymin, ymax, x
common xmin, xmax, dx, ymin, ymax
logical, save :: first = .true.
  if (clearwin_string@('CALLBACK_REASON') .eq. 'PLOT_ADJUST') then
    if (first) then
      first = .false.
    else
      x = xmin                  ! Should really be x = xmin+dx
      call set_plot_mode@(1) ; call set_line_width@(3)
      do while (x .le. xmax)     ! Should really be x .lt. xmax
        call draw_line_betweenD@(x,ymin,x,ymax,rgb@(255,0,0))
        x = x + dx
      end do
      call set_line_width@(1) ; call set_plot_mode@(0)
      first = .false.
    end if
  end if
  pl_cb = 2
end function pl_cb
Back to top
View user's profile Send private message Visit poster's website
Kenneth_Smith



Joined: 18 May 2012
Posts: 709
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Sat Sep 02, 2023 2:05 pm    Post subject: Reply with quote

Issue now resolved by changing slightly the code that selects the desired xmin, xmax and dx values.

Examining the value returned by change_plot_dbl@ was the wrong path to follow, although it seemed logical on Thursday morning!

A very presentable contour plot:

https://www.dropbox.com/scl/fi/ybmjm965j7yghmdif8nve/dxdy_fixed.JPG?rlkey=necdjvj9h8gu7dykuxqzas2sp&dl=0
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK

PostPosted: Sat Sep 02, 2023 2:21 pm    Post subject: Reply with quote

It looks very impressive.
Back to top
View user's profile Send private message AIM Address
Kenneth_Smith



Joined: 18 May 2012
Posts: 709
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Thu Sep 07, 2023 8:56 pm    Post subject: Reply with quote

Paul,

I have looked at this a little more closely, as my "fix" fails in one test.

In the following code, the failure of change_plot_dbl@ to change the dy value is demonstrated.

There are three %pl regions which are created sequentially. In each case the pl graph frame is initially the unit square. The callback associated with the button CB, calls change_plot_dbl@ to change the following values:

x_min = -5, x_max = 5, dx = 5, y_min = -5, y_max = 5, and dy = 5

and thereafter calls simpleplot_redraw@.

The code works as expected for the first two cases, but fails in the final case where the plotted dy value is 2.5 rather than the requested 5.

The only difference is that the final case has the %pl margins explicitly specified via a call to winop. The presence of this margin specification appears to be the cause of the problem.
Code:

program p
use clrwin
implicit none
integer iw
integer cd ; external cb
  iw = winio@('%mn[Exit]&','exit')
  iw = winio@('%fn[Consolas]%ts%bf&',1.5d0)
  call winop@('%pl[native,x_array,frame,link=user]')
  iw = winio@('%pl&', 500,500,2,[0.d0,1.d0],[0.d0,1.d0])
  iw = winio@('%sf%^bn[CB]',cb)
 
  iw = winio@('%mn[Exit]&','exit')
  iw = winio@('%fn[Consolas]%ts%bf&',1.5d0)
  call winop@('%pl[native,x_array,frame,link=user]')
  iw = winio@('%pl&', 1344,876,2,[0.d0,1.d0],[0.d0,1.d0])
  iw = winio@('%sf%^bn[CB]',cb)

  iw = winio@('%mn[Exit]&','exit')
  iw = winio@('%fn[Consolas]%ts%bf&',1.5d0)
  call winop@('%pl[native,x_array,frame,link=user]')
  call winop@('%pl[margin=(294,60,294,60)]')
  iw = winio@('%pl&', 1344,876,2,[0.d0,1.d0],[0.d0,1.d0])
  iw = winio@('%sf%^bn[CB]',cb)
end program p

integer function cb()
use clrwin
integer i
   i = change_plot_dbl@(0,"x_min",0,-5.d0)
   i = change_plot_dbl@(0,"x_max",0, 5.d0)
   i = change_plot_dbl@(0,"dx",   0, 5.d0)
   i = change_plot_dbl@(0,"y_min",0,-5.d0)
   i = change_plot_dbl@(0,"y_max",0, 5.d0)
   i = change_plot_dbl@(0,"dy",   0, 5.d0)
   call simpleplot_redraw@()
  cb = 2
end function cb
Back to top
View user's profile Send private message Visit poster's website
Kenneth_Smith



Joined: 18 May 2012
Posts: 709
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Fri Sep 08, 2023 12:28 pm    Post subject: Reply with quote

The solution to the last problem is to ensure that the ratio of (top margin + bottom margin)/graphics_height is greater than 0.2
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK

PostPosted: Sat Sep 09, 2023 6:54 am    Post subject: Reply with quote

Thanks for the feedback Ken.

Here is some background information for the general reader.

The functions CHANGE_PLOT_INT@, CHANGE_PLOT_DBL@ and CHANGE_PLOT_CHR@ return the integer value zero on success. Other values indicate an error. These functions change the data but the user will need to call a routine like SIMPLEPLOT_REDRAW@ in order to redraw the graph. At that point the graph ought to be redrawn in the form that would appear if the new data had be used at the outset.
Back to top
View user's profile Send private message AIM Address
Kenneth_Smith



Joined: 18 May 2012
Posts: 709
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Wed Sep 13, 2023 11:02 am    Post subject: Reply with quote

This may help to identify the source of the problem.

The same issue can be replicated without calling CHANGE_PLOT_DBL@.

Code:
program p
use clrwin

! This example shows that specifying the dy value via winop@ before the window is
! formed fails to set dy to the required value i.e. 5 - when the margins are
! specified.  The plotted value is 2.5
! The correct dy value is obtained if the call to winop@ with the margin spec is
! commented out.

  iw = winio@('%mn[Exit]&','exit')
  iw = winio@('%fn[Consolas]%ts%bf&',1.5d0)
  call winop@('%pl[native,x_array,frame,link=user]')
  call winop@('%pl[x_min=-5, x_max=5, dx=5, y_min=-5, y_max=5, dy=5]')
  call winop@('%pl[margin=(294,60,294,60)]')    ! Comment out this line to get dy = 5
  iw = winio@('%pl', 1344, 876, 2, [0.d0,1.d0], [0.d0,1.d0])

! With the margin spec in place, the required dy value 5, is obtained if in the winop@ call dy = 9.

  iw = winio@('%mn[Exit]&','exit')
  iw = winio@('%fn[Consolas]%ts%bf&',1.5d0)
  call winop@('%pl[native,x_array,frame,link=user]')
  call winop@('%pl[x_min=-5, x_max=5, dx=5, y_min=-5, y_max=5, dy=9]')
  call winop@('%pl[margin=(294,60,294,60)]')
  iw = winio@('%pl', 1344, 876, 2, [0.d0,1.d0], [0.d0,1.d0])
     
end program p


PS In the first case, the %pl graph dy cannot be corrected at runtime by the addition of the option [params].
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK

PostPosted: Wed Sep 13, 2023 12:05 pm    Post subject: Reply with quote

Ken

I have logged this issue for investigation.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK

PostPosted: Thu Sep 14, 2023 8:22 am    Post subject: Reply with quote

Ken

I can see in the ClearWin+ code where this value is limited but a change might affect user's existing code.

I have added an option CLEARWIN_OPTION@("no_pl_dy_limit") that will allow you to experiment with this internal limit removed.

Our code changes are currently locked pending a full release so if I send you the update now it may be out of step with the next release.

I could send you updated DLLs on this understanding.
Back to top
View user's profile Send private message AIM Address
Kenneth_Smith



Joined: 18 May 2012
Posts: 709
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Thu Sep 14, 2023 11:23 am    Post subject: Reply with quote

Paul,

Yes, the "no_pl_dy_limit" is probably the solution I am looking for. I have tried, but failed to work out the functioning of that limit which I have long suspected is in the Clearwin code.

A "no_pl_dy_limit" would certainly provide a solution to an issue encountered previously. A common range in the electrical world for % voltage is y_min=97.5, y_max=102.5, and most power transformers have a 1.25% taps on the HV side, so dy = 1.25 and it is not possible to use these values in a %pl plot.

I am certain the dy increment value I am requesting is reasonable, but I guess what is reasonable, may be a moot point!

If you could provide a 64 bit dll, I can experiment with that. Issues with upcoming full release understood. Many thanks for taking the time to look at this.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
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