|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Thu Dec 03, 2020 4:04 pm Post subject: Failure of %pl[native] options frame, framed and etched |
|
|
Paul, one for you to look at when you have the chance. In this example, the specific combination of 11 data points with x values running from -10 to 0 causes the %pl option frame to fail. The left-hand vertical frame element is not drawn. This also happens with the alternative options framed and etched.
Code: | module example
use clrwin
implicit none
integer, parameter :: dp = kind(1.d0)
integer,parameter :: npts = 11
real(kind=dp) :: x(1:npts) = 0.d0, y(1:npts) = 0.d0, a(1:3) = (/0.d0,0.d0,1.d0/)
real(kind=dp) :: xmin = -10.d0, xmax = 0.d0
contains
integer function gui()
integer :: iw
iw = winio@('%mn[Exit]&','exit')
iw = winio@('%bg&',rgb@(250,250,250))
iw = winio@('%2.1ob&')
iw = winio@('%nl y = c*x^2 + b*x + a&')
iw = winio@('%2nlxmin%ta%`bg[white]%8rf%2nlxmax%ta%`bg[white]%8rf&',xmin,xmax)
iw = winio@('%2nla%ta%`bg[white]%8rf%2nlb%ta%`bg[white]%8rf%2nlc%ta%`bg[white]%8rf&',a(1),a(2),a(3))
iw = winio@('%2nl%cn%^bb[Update plot]%cb&',plot_cb)
call winop@('%pl[native,x_array,frame,link=curves,colour=blue,width=2,gridlines,symbol=13]')
iw = winio@('%pl&',600,400,npts,x,y)
iw = winio@('%cb')
gui = 2
end function gui
integer function plot_cb()
integer i
integer :: iw
real(kind=dp) inc
if (xmax .le. xmin) then ! ERROR
iw = winio@('XMAX must be greater than XMIN%2nl%cn%bb[OK]')
x = 0.d0 ; y = 0.d0 ; call SIMPLEPLOT_REDRAW@() ; plot_cb =2 ; return
else ! NORMAL
inc = (xmax - xmin)/dble(npts-1)
x(1) = xmin
do i = 2, npts, 1
x(i) = x(i-1) + inc
end do
do i = 1,npts, 1
y(i) = a(1) + x(i)*a(2) + x(i)*x(i)*a(3)
!! print*, i, x(i), y(i)
end do
call SIMPLEPLOT_REDRAW@()
end if
plot_cb = 2
end function plot_cb
end module example
program main
use example
i = gui()
end program main |
PS There are other combinations of XMIN, XMAX, and NPTS which have this issue. XMAX = 0 is common to all of these.
Quote: | NPTS = 2, XMIN = -10, XMAX = 0
NPTS = 3, XMIN = -10, XMAX = 0
NPTS = 5, XMIN = -10, XMAX = 0
NPTS = 6, XMIN = -10, XMAX = 0
NPTS = 9, XMIN = -10, XMAX = 0
NPTS = 11, XMIN = -10, XMAX = 0
NPTS = 17, XMIN = -10, XMAX = 0
NPTS = 21, XMIN = -10, XMAX = 0
NPTS = 2, XMIN = -10.1, XMAX = 0
NPTS = 3, XMIN = -10.1, XMAX = 0
NPTS = 19, XMIN = -10.1, XMAX = 0 |
Last edited by Kenneth_Smith on Fri Dec 04, 2020 1:24 am; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Thu Dec 03, 2020 4:57 pm Post subject: |
|
|
Ken
Thanks. I have noted this. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Fri Apr 09, 2021 12:04 pm Post subject: |
|
|
Ken
I have had a look at this. Changing the limits seems to work apart from the particular case xmin = -10 where the frame is not complete unless you reduce xmin a fraction.
I am not sure that I can safely make any changes that will improve this. |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Sat Apr 10, 2021 12:30 pm Post subject: |
|
|
Paul,
I had forgotten about this one, so I guess problematic data sets don't occur that often. The solution is straightforward, draw the frame via the %pl call back - I've been using that trick recently to enhance the appearance of the plot (different colours for the frame). |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Mon Apr 12, 2021 3:51 am Post subject: |
|
|
Paul, you wrote:
Changing the limits seems to work apart from the particular case xmin = -10 where the frame is not complete unless you reduce xmin a fraction
.. but Ken had failure cases where he did reduce xmin by 'a fraction' (-0.1 to be precise)
I'm not a fan of 'reducing numbers by 'a little bit' in order to make stuff run.
That 'little bit' might be different depending on the data set in use and one ends up repeatedly changing code (in different ways)depending on the input data defined !
wot the eck can possibly be causing this ? _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
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
|