%pl issue

The program below uses %pl to plot the Bessel function Y1(x) in the range 0 < x < 20

Obviously the first point in the x data arrays cannot be zero since Y1(0) is negative infinity.

We can also use the %pl option y_min to clip the large negative values (so effectively the line being plotted starts somewhere outside the %pl frame, and should appear where it crosses the lower horizontal edge of the frame.

Certain combinations of the starting x value (and hence starting y value) combined with the value specified for y_min run into problems. This can be seen in the second plot produced by this program. Here is a screenshot.

https://www.dropbox.com/scl/fi/fodkuemt1ykexr10v2vl2/Screenshot-2026-01-09-105813.jpg?rlkey=3u7gogu8lbem1xw52ejkbu9re&st=4ld4pjgp&dl=0

program test
use clrwin
implicit none
real*8 x_pl1(200), y1_pl1(200)
real*8 x_pl2(200), y1_pl2(200)
real*8 x_pl3(200), y1_pl3(200)
  integer i, iw
    x_pl1(1) = 0.0001d0   !Y0 of zero is - infinity so start a small distance away from zero
    do i = 2, 200
      x_pl1(i) = x_pl1(i-1) + 0.1d0
    end do
    y1_pl1=bessel_y1(x_pl1)
    print*, 'First point in first graph at : ', x_pl1(1), y1_pl1(1)
    call winop@('%pl[native,n_graphs=1,x_array,width=3]')
    call winop@('%pl[frame,etched,gridlines]')
    call winop@('%pl[link=lines, colour=blue]')
    call winop@('%pl[y_max=1,y_min=-1,x_max=20]')   ! Clip y-axis at -1
    iw = winio@('%pl&',500,400,200,x_pl1,y1_pl1)
    
    x_pl2(1) = 0.00001d0 ! Start closer to zero
    do i = 2, 200
      x_pl2(i) = x_pl2(i-1) + 0.1d0
    end do
    y1_pl2=bessel_y1(x_pl2)
    print*, 'First point in second graph at : ', x_pl2(1), y1_pl2(1)
    call winop@('%pl[native,n_graphs=1,x_array,width=3]')
    call winop@('%pl[frame,etched,gridlines]')
    call winop@('%pl[link=lines,colour=blue]')
    call winop@('%pl[y_max=1,y_min=-1,x_max=20]') ! Clip y-axis at -1
    iw = winio@('%pl&',500,400,200,x_pl2,y1_pl2)

    x_pl3(1) = 0.00001d0
    do i = 2, 200
      x_pl3(i) = x_pl3(i-1) + 0.1d0
    end do
    y1_pl3=bessel_y1(x_pl3)
    print*, 'First point in third graph at : ', x_pl3(1), y1_pl3(1)
    call winop@('%pl[native,n_graphs=1,x_array,width=3]')
    call winop@('%pl[frame,etched,gridlines]')
    call winop@('%pl[link=lines,colour=blue]')
    call winop@('%pl[y_max=1,y_min=-2,x_max=20]') ! Clip y-axis at -2
    iw = winio@('%pl',500,400,200,x_pl3,y1_pl3)
end program test

PS If i plot -Y1, i.e. the mirror image (reflected in the X axis) everthing is ok.

Thank you for this feedback. I will take a look at it.

Had a quick look and setting these values the same, removes the issue with the second plot:

x_pl1(1) = 0.0001d0 x_pl2(1) = 0.0001d0 x_pl3(1) = 0.0001d0

First point in first graph at : 1.000000000000E-04 -6366.19803646 First point in second graph at : 1.000000000000E-04 -6366.19803646 First point in third graph at : 1.000000000000E-04 -6366.19803646

Does this look correct?

Lester

Lester, the point Kenneth was making was 'It shouldn't have done it like this.'

I think we all have had moments like this, where what we did seems to violate some unknown limitation, so we programmed around it. Perfectly fine, yet the issue still remains.

Like my post a few days ago about property sheets locking up and crashing. Shouldn't happen, yet it does. So we do something different.

The folks at Silverfrost do a great job with this product, and knowing that there is something 'odd' is sometimes enough to get an even more robust product. If I dug back in my memory, I could give you at LEAST a half dozen workarounds in both MS Visual C++ and in Silverfrost. Only Silverfrost responded positively to my bug reports. And I learned a bunch of new things as a result of many of these encounters.

I hope that this is just one of those 'oh, goodness, look at this!' moments where things get corrected and more robust.