Native %pl

1500 lines of code to produce this writing to a %gr region

At most 30 lines to present 95% of the same information with the new %pl 😄

Don't be disheartened by our grumblings Paul.

Ken

More complaints - better product - more users - happier developers.

But not for a long time, because more users - louder, more intense the outcry 😃

John

The place to look is in ftn95.chm under ClearWin+->SIMPLEPLOT->Native graph plotting.

Here is a quote about adjusting the position of the captions...

If ClearWin+ draws a title or axis caption at an inappropriate point then its position can be adjusted. For example [title=My Graph@(4.8)] using a decimal point, draws 'My Graph' at a point that is adjusted 4 pixels to the right and 8 pixels down from its default position.

Here is another quote...

using a decimal point, draws 'My Graph' at a point that is adjusted 4 pixels to the right and 8 pixels down from its default position.

Here is another quote...

[quote:714dd15257]The following routine can be called from within a %PL callback function in order to get the pixel coordinates of a particular point relative to the axes.

        SUBROUTINE GET_PLOT_POINT@(x,y,xpix,ypix)
        REAL*8 x,y           (input values)
        REAL*8 xpix,ypix     (output values) 

The function returns zero on success or a non-zero error code.

but it is not a SUBROUTINE. It is a FUNCTION returning an INTEGER.

Perhaps I am misunderstanding. GET_PLOT_POINT@(0.0d0,0.0d0,xp,yp) gives the origin for the axes. You also know the (x,y) values for a given tick mark so you can get the corresponding pixel co-ordinates.

Can we get pixel (or actual plotted X,Y) coordinates of the mouse like with usual %gr?

Dan

The native %pl uses a %gr region so you should be able get the mouse position in the same way. If not then please post a sample to show how it would be coded.

John

There is now an option (probably only in the next release) to set the margin so I am hoping that this will mean that you will be able to do what you want.

Quoted from PaulLaidler

Naturally it can't handle log y for negative y and to switch to a linear scale seems reasonable to me. Negative values of log y are more difficult to handle because the automatic y min can get very large but we can look into that.

If zero and negative numbers appear in the dataset and there exist restriction cutting off all the data below specific threshold like that

call winop@('%pl[Y_MIN=1.e0]')

then the native %PL should not switch from log to linear scale. Right now it sometimes switches to linear scale without any reason

Thanks Dan. When the next release comes out, if it is still wrong, perhaps you could send me an illustrative example.

%pl now does the log transformation of the raw data so it is bound to reject zero and negative values in the raw data. The next release is designed to allow zero and negative values in the transformed data.

Sounds good. Curious though how did you implement acceptance of zero values without mentioned above y_min=Val ? By allowing many additional orders of magnitude ?

I think that is what it amounts to. We will see what the end result is.

log10(1e-3) = -3

John, The problem is when the argument of LOG becomes a very small number or worse zero because the log10(0)=-inf. To plot such data in the LOG scale the %pl switches from LOG to LINEAR scale. My offer was not to switch on linear scale if condition is set in %pl not to plot anything below Y_min.

The way how to handle this could be to crash the code but that's bad idea. Another way is that %pl will still plot this very small or zero number as very small number (smaller then anything else on the graph by say 10-20 orders of magnitude). The user will immediately notice this huge drop and will somehow fix the problem with plotted data. I think Simpleplot was sometimes doing that, sometimes crashed. But Simpleplot also had the feature i mentioned above, so that if you explicitly tell it not to plot anything below some Y_min it plotted small data numbers as Y_min

Quoted from John-Silver A better option would be to simply not plot the points below a certain level

Yes, exactly. You set the Y_min and Y_max and anything below and above is ignored. That's how all usually do

A new version of the native %pl is available via the following download. There will probably still be some forms of data that it can't handle.

I am not going to do any further work on this for at least a few months so if you have feedback it would be better to keep it till later.

https://www.dropbox.com/s/xhk4ofgp5g5xcpn/newDLLs6.zip?dl=0

Paul,

Can you confirm the syntax for the specification of separate top, left, and bottom, margins?

The readme file says:-

%pl[margin=(left,top,right,bottom)] ... set the margins to left,top,right,bottom pixels

but my example below generates an error

... set the margins to left,top,right,bottom pixels

but my example below generates an error

[quote:0036daed78]Runtime error from program:g:\motor\problem.exe Run-time Error Invalid margin value in %PL specification

00401000 main [+01d2]

winapp
program test
implicit none
include <windows.ins>

real(kind=2) :: ns = 3600.d0
real(kind=2) :: slope = -200.d0
real(kind=2), dimension(1:1000) :: speed, po_pr
real(kind = 2) po
integer i

po = 0.d0
do i = 1, 1000, 1
  speed(i) = ns + slope*po
  po_pr(i) = po
  po       = po + 0.001d0
end do

      i = winio@('%fn[Tahoma]&')
      i = winio@('%mn[Close ]&','EXIT')
      i = winio@('%bg&',rgb@(250,250,250))
      i = winio@('%tc&',rgb@(0,0,0))
      i = winio@('%`bg&',rgb@(255,255,255))

call winop@('%pl[native]')

!call winop@('%pl[margin=60]')                !THIS WORKS
call winop@('%pl[margin=(60,60,60,60)]')      !THIS DOES NOT WORK

i = winio@('%pl[x_array,N_GRAPHS=1,COLOUR=BLACK]',400, 300, 1000, po_pr, speed)

end program test

I can see that I am picking up the new dlls since the default %pl[x_sigfigs] and %pl[y_sigfigs] have changed in another test I ran.

Thanks

That is what was intended and I thought that I had tested it but you are right it doesn't work.

Not very stable DLLs, or some other conflicts there. My codes freeze immediately with access violation like that (if this tells you anything):

Within file CLEARWIN64.DLL In _fdebug_printf at address 17C In _send_text_message at address 3B3 In _yield_program_control at address 234 In _sleep_at at address 5A Within file PPP.exe in ANGULARBREMMS at address 590b

Can not start the code in the debug mode to see what's wrong. Also crashes at start with /optimize mode. With /nocheck code may start OK but is now sensitive and crashes often, seems it does not like something. For example the code freezes when i use %ac and works ok if the same callback is called via clicking on a button %bt.

Ones code worked with such tricks and i succeeded to run the new %pl i found that it still does not like something in the data and switches to linear scale from LOG. Is there a way to push it not do that ? As we discussed before it should not switch to linear scale when zero or negative data is present if condition y_min=val is used -- there is no reason to switch (and i do not see any zero/negative data and it still switches to linear). **I see the work on that is almost done, %pl plots minimum of axis at y_min if you set it like this %pl[y_min=100.] but it still plots curves below this minimum threshold line and switches to linear if data has zeroes ** (or it suspects that)

New feature - the axis thickness works fine and looks good CALL winop@('%pl[axes_pen=3]')

The new way of axis numbering when it switches the styles is probably not good idea. Example of some my real axis numbering: 0, 20, 40, 60, 80, 1e2, 1.2e2, 1.4e2 does not look good. For reasonably small numbers it should be 0, 20, 40, 60, 80, 100, 120, 140. The numbers as large as 1.2e5, 1e12 are probably OK represented like that but when axis is plotted they all should be in the same style

Dan

I suggest that you just go back to a stable set of DLLs. I am not able to do any more work on this for the time being.

Paul, Of course i will go to older dlls, but i'm curious if this is only my compiler state/settings issue. One simple case which crashes i already found. This demo code works in usual 32 bit mode

ftn95 name.f95 /link

and if you switch to 64

ftn95 name.f95 /64 /link

it crashes if you push DRAW or hit Ctrl+Z set in %ac

use clrwin
integer, external :: callb

  i=winio@('%ww%gr%ff&', 600,400) 
  i=winio@('%ac[Ctrl+Z]&',callb)
  i=winio@('%cn%^bt[DRAW]%es',callb)
end

integer function callb()
use clrwin
ipos = random()*555 
call draw_line@(1,1,ipos,111,rgb@(255,1,1))
callb =2
end function

use clrwin 
integer, external :: callb 

  i=winio@('%ww%gr%ff&', 600,400) 
  i=winio@('%ac[Ctrl+Z]&',callb) 
  i=winio@('%cn%^bt[DRAW]%es',callb) 
end 

integer function callb() 
use clrwin 
real(2) random
ipos = random()*555 
call draw_line_between@(1,1,ipos,111,rgb@(255,1,1)) 
callb =2 
end function