Native %pl

This is not an answer, Paul. This implies that compiler is fine and the program is wrong. But if program is wrong and it is wrong 100 times per day when you develop the code then it is the debugger which must tell me where the error is or at least give a hint. I'd like to but probably will never afford to hire you guys to substitute SDBG 😃. How I have to proceed to find the error of immediately crashing code with 'Access violation writing address 0x00007ff...........'? Just inspecting by hand each of a quarter of million lines of code will take me the same quarter of million years. The debugger crashes at the start of debugging. How come such error can crash both the EXE and the debugger? The 32bit code works by the way fine hence we can not use 32bit debugger to find this bug --> we are screwed.

I see few nice new features, i'd like to use it, the LINEAR scale %pl for example already approaching ideal beating for XY plots in quality MATLAB being equally simple,

https://www.mathworks.com/products/matlab/plot-gallery.html

the LOG one is almost done and just needs final fixes (still plots outside the allowed area etc), but this was very unstable build, totally unusable because of crashing on everything. Could it be that the new dlls are conflicting with the rest of the older 8.10 compiler ?

So before you interrupt with further development of native %pl (I thought you enjoyed this work and understand how important is to have top quality and simplicity graphics utilities natively in Fortran but in reality it appears that things were going exactly opposite) can you please fix these issues with LOG scale which are demonstrated with this code below so that %pl will not plot outside the allowed area and will not switch to linear scale automatically if y_min=val exists (the data plotted often fluctuates and zeros/negatives are inevitable). That could be hopefully easy fixes. Also, though this could be not related to %pl problem: by some reason the new %pl does not react on Redraw like the older %pl was doing (to see that action remove the line CALL winop@('%pl[native]' and compile under regular 32bit). This will make %pl finally at least usable in 64bits.

Module Modd
use clrwin
integer, parameter:: N=10
real*8 X(N), Y(N), Z(N), T(N)

Contains

integer function callb()
real(2) random 
do i=1,N
  X(i)=i
  Y(i)=exp(1.*i) * random() 
  Z(i)=exp(2.*i) * random()
  T(i)=exp(3.*i) * random()
enddo

call simpleplot_redraw@
callb =2
end function
End module
!.....................................
program hhh
use clrwin
use Modd

j=callb()

i=winio@('%ww&')
CALL winop@('%pl[native]')
i=winio@('%pl[x_array,scale=log_linear,N_GRAPHS=3,y_min=100.]%ff&', 600,400, N, X,Y,Z,T)  
i=winio@('%ac[Ctrl+Z]&',callb)
i=winio@('%cn%^bt[Redraw]%es',callb)
end

Thanks John. I only meant development work on the native %PL. Yes I aim to fix any native %PL 'bugs' but the tick mark values on the axes may not always be tidy and the behaviour for log scales and negative data values will not change (for me these are not 'bugs').

I am not sure what comes next. Maybe some of the requested missing Fortran standard features. Anyway I hope that I have learned my lesson. No more ventures like the native %PL.

John

The question about using negative data values and logarithmic transformations has gone on for so long now that I am beginning to doubt myself. If the user supplies a negative value of y then ClearWin+ can't calculate log(y) as a real value. I know that what is taught in physics can change but not mathematics surely. The issue about what happens with negative values of log(y) (e.g. log10(1e-3)) has been fixed.

As to the values shown at ticks marks, you can usually get good results particularly if you set (for example) the y_max and maybe the dy values.

John,

Apart from the issue with setting the margins independently the V6 DLLs are running fine for myself.

Ken

John, You are correct I've not tried the log scales - must try harder! However I have not had to go back one set of dlls. Ken

Paul,
Can you point me in the right direction and confirm the syntax for using the independent option. I am struggling to make the third %pl call in the code below work, where the two graphs with different x axis values are plotted together. Code below fails to draw anything in the third %pl region. I re-read the help file many times and tried various combinations with no success.

Thanks

Ken

program test
implicit none
include<windows.ins>
real(kind=2) x_array_1(10), x_array_2(10), y_array_1(10), y_array_2(10)
integer i

do i = 1, 10
  x_array_1(i) = i
  x_array_2(i) = i + 5
  y_array_1(i) = x_array_1(i)**0.75d0
  y_array_2(i) = x_array_2(i)**0.5d0
end do

i = winio@('%ww&')
i = winio@('%pl[native,x_array,n_graphs=1]&',300,300,10,x_array_1,y_array_1)
i = winio@('%pl[native,x_array,n_graphs=1]&',300,300,10,x_array_2,y_array_2)
i = winio@('%pl[native,x_array,n_graphs=2,independent]&',300,300,10,x_array_1,y_array_1,x_array_2,y_array_2)
i = winio@('%ff')

end program test

Ken

For two independent graphs together the number of points must be passed as an array. So in the third %pl, 10 becomes np with

integer np(2) np = 10

Thanks Paul.

Might be worthwhile changing the text in the help file

from:

In this case the number of data points and the optional x-start and x-increment data must be presented as variables (for one graph) or as arrays (for one or more graphs) where the array index corresponds to the order in which the graphs are coded.

to:-

In this case the number of data points and the optional x-start and x-increment data must be presented as variables (for one graph) or as an array (for one or more graphs) where the array index corresponds to the order in which the graphs are coded.

It was the plural 'arrays' which confused me.

Thanks

Ken

Thanks Ken. I have changed the text.