Native %pl

A minor suggestion.

We have the subroutine get_plot_point@(x1,y1,xx1,yy1) which returns the pixel coordinates xx1, yy1, of the real world data x1, y1.

It would make programming interactively with mouse clicks etc on a %pl graphics area easier if there was a second subroutine which performed the reverse function, i.e. given pixel coordinates xx1, yy1, returns the real world coordinates x1, y1. I know this functionality can be achieved in otherways, but this complicates the programming.

Just a thought.

Ken

And another suggestion, maybe a way of detecting the first call to the %pl call back function via CLEARWIN_STRING@( STR )

Ken

Ken

The routine that you want is already included but perhaps not yet released.

The clearwin_info@('CALLBACK_REASON') for a %pl callback is 'PLOT_ADJUST'. I guess that the user's code could flag the first call.

Hi, John-S: 30 years ago I implemented an interactive graphics system that did exactly that, all in standard Fortran77. I'll see if I can find the low-level parts of the coding (should still have it somewhere). However, it won't fit easily with %pl because it overlapped a lot with the Simpleplot / %pl functionality. There seems to be a lot of reinventing of wheels, because mine was far from the only package that did the same job.

Paul,

I checked 8.30 with DLL23

Looks like for linear scale plots the placing of numbers on axis were fixed so that plot has now reasonable amount of numbers per axis and the numbers itself are not looking 'bad'.

The next would be great to fix bugs in LOG scale which are long overdue. The %pl then will be very useful tool. The examples of the bugs are described and pictured in detail in my last post on page 4 of this thread.

One more thing: a bug was introduced with the framed plot, you can see here that the thickness of the line of the frame is not the same:

   use clrwin 
   parameter (N=5) 
   real*8 X(N), Y(N) 
   Data X/1e1, 1e2, 1e3,  1e4, 1e5/ 
   Data Y/2.2, 66, 8333, 1111, 777/ 

   i=winio@('%sf%ts%bf%es&', 2d0) 
   call winop@('%pl[axes_pen=3,width=3,x_axis='X Axis Title',y_axis='Y Axis Title']')  

   i=winio@('%ww%pv%pl[native,framed,x_array,scale=log_log,N_GRAPHS=1]', 625,500, n, X, Y)  
   end

The option [frame_pen=dval] now provides the line width of the frame where dval is the width.

If you can post or send me the code for the bug then I will aim to look into it when time permits.

Thanks for new option. As to the codes they are here, cited from page 4 above

Quoted from DanRRight

1) use clrwin parameter (N=5) real*8 X(N), Y(N) Data X/1e1, 1e2, 1e3, 1e4, 1e5/ Data Y/2.2, 66, 8333, 1111, 777/

   i=winio@('%ww%pv%pl[framed,x_array,scale=log_log,N_GRAPHS=1]%es', 625,500, N, X, Y)  

   end

Problem: if you try to resize the plot just a tiny bit pulling window border or corner using mouse it abruptly displays Y correctly but X not.

2. The same code with 'beautifications' with just one-two more lines of code like here looks better. This kind of line widths and design actually have to be a default, and the code above has to be like this one below

   use clrwin
   parameter (N=5)
   real*8 X(N), Y(N)
   Data X/1e1, 1e2, 1e3,  1e4, 1e5/
   Data Y/2.2, 66, 8333, 1111, 777/
   
   i=winio@('%sf%ts%bf%es&', 2d0)
   call winop@('%pl[axes_pen=3,width=3,x_axis='X Axis Title',y_axis='Y Axis Title']')  
   
   i=winio@('%ww%pv%pl[native,framed,x_array,scale=log_log,N_GRAPHS=1]', 625,500, n, X, Y)  
   end
   

In other words, the lines for axis and curves with default width 1 pixel are unacceptable as a default. Such beautifications take a lot of time and always causes many recompilations. If Clearwin will make good looking plots it will be accepted like Matlab.

3. Additional problems: this nicer looking example shows the defects of absence of Scientific, Decimal etc numbering formatting options: the numbering does not look concise, in one style, it mixes different styles.

As to the numbering formats of LOG plots we here suggested to introduce few distinct user-definable formatting options: Scientific (numbers shown as 10^{0, 10}1, 10^{2, 10}3 etc) and Decimal (1, 10, 100, 1000...). All these ( and few other options like Engineering (1e0, 1e1, 1e2, 1e3) and Decimal with FP (1.0, 2.0, 3.0) ) are already there, they just need to be introduced into the user changeable settings.

With the LOG scale it is often possible for the code to choose these formats automatically: if the numbers are very small or very large and there are a lot of orders of magnitude to display then just the Scientific format has to be used

At the end here how this exact XY data is visualized by the professional scientific software using Scientific and Decimal formats. As you can compare the new %PL is already pretty close to the best of the best (the new PL can also do antialiasing for curves and in this example is even better doing data interpolation - compare how 8333 peak values are displayed)

Decimal format is of course the most difficult. If extend the plotted data to

0.01  0.011
0.1   0.044
1	   0.33
10	   2.2
100	   66
1000   8333
10000  1111
100000  777

the OriginLab plots it this way and if even more then 1e-3, 1e-4 ...

Item 1 has now been fixed. Improvements relating to item 3 might be possible later if time permits.

John,

1. There is no way to get not only production quality but any quality if axes_pen=1,width=1. But i agree my axes_pen=3, width=3 are probably too aggressive for anyone who uses less then 4K monitors. Try =2 and tell if that will look better (but take in mind that there is a bug with the frame width Paul just fixed)

So size=1 is too small for almost anyone but 3 are too large for anyone who use smaller resolutions. Of course with time all monitors will be 4K, 5K 8K, their prices dropped 10 times in last 3 years, i'v heard the first cell phone with 4k screen was just made. But the best solution which will fit everyone would be ( before it is too late and user base will be large) for Paul to consider the fp numbers for axes_pen and line width instead of integer numbers because antialiasing can allow any intermediate numbers like 1.4 and the plot automatically will look much better with line sizes larger then primitive 1 pixel

Though there might be people with low res monitors I strongly insist to not use 1 pixel for default, because no one in the world use that. Everyone who did all got out of business, just look at any packages of scientific graphics for Fortran over last 30 years supplied by such losers. While at the same time the Matlab for example almost killed all, taking lion part of the market share from Fortran. And when you will think why, you will find that the only what Matlab sells (having similar language with Fortran while Fortran is faster and more modern) all others missed is 1) ultimate simplicity 2) stellar graphics. Same was with Apple for example: ultimate simplicity, top parameters and stellar aesthetics. Same with Amazon: ultimate simplicity (one click orders), top convenience, good design. At the end anyone with very low res monitors can decrease line widths but for everyone else first look of the plot has to cause WOW effect (not the feelings that Fortran is the neanderthal's language like right now)

2. If i either decrease the plot size to zero by mouse resizing or minimize the plot it immediately crashes.

Paul, I hope you received on May 28 my email with demonstration of native PL crashing.

Dan

I think I did (too many balls in the air). If it concerned resizing then that bug has been fixed.

This was about sensitivity to the input data when native %pl crashed after simpleplot_redraw@ was used.

Dan

I have found your email, downloaded the archive and followed your instructions. The result is that I get 'Reference to undefined variable' at line 3199 of crashPL.for. The variable is E3864_log(1) which is indeed undefined, at least according to SDBG64.

Am I missing something?

Most probably my instructions how to get the crash were not clear. The problem you see is because the data needs to be loaded first but it was not loaded, please load it first.

For simplicity I made just 3 tabs. Click first 'Load Data', after data stops loading in couple seconds click 'Working Case' button where in new window there are options to create few XY plots, you then can click any radiobuttons and see all works OK.

Close it using ESC and finally click on 'Crashing Case' button, which is made programmatically similarly to the Working Case, and where you also will see few options to plot one or several XY graphs. You will see that initially all is plotted OK which tells that %PL is working OK but then clicking on any of radiobuttons causes crash because I suspect the simpleplot_redraw@ conflicts with something, most probably either being too sensitive to the data ranges or having a bug.

This whole demo was a simple case of using %PL when we have one set of X data and multiple sets of Y. The %PL makes one, two or several plots according to ON or OFF state of radiobuttons (multiplying specific Y(i) data on radiobutton state) and updating %PL with simpleplot_redraw@

Dan

I have spent an hour or so stepping through your program but at the moment I can't work out if there is anything wrong with %pl.

For me a failure occurs when I click on the 'Plot case 1' radio button (to reset it) and it fails because the y-data to be plotted at this point contains at least one invalid floating point value. It's not out of range but some kind of NAN.

ClearWin+ should report a runtime failure (and this needs fixing) but after that I can't work out where the data is coming from. So maybe your data is invalid or %pl is not processing the data correctly.

The only thing that I can suggest at the moment is that you print out the data that you are plotting at this point to see it looks like.

Thanks for the hunt of this devilry bug. I naively expected that since you have the source code of native PL the bug will be immediately catched in your own debug mode in your compiler where native PL was written. But I always forget that all developers prefer C++ and respect to debugging live even in pre-Anderthals era 😃

I will look again at all arrays but strongly suspect that the only way NaN can be generated is by native PL own bug. Because this small simple code can not generate such thing in /check /debug /undef mode after successfully plotting the same arrays when window starts (at start both rariobuttons are ON).

I spent more then a month to find the bug checking everything and extracting this demo from large code and together with my other 2 decades experience with plotters like my own, OpenGL and Simpleplot led me to wish the debug mode not only in Fortran (where FTN95 is the world champ among all existing compilers, most probably not just Fortran type) but in native PL plotter and then entire Clearwin+ too. For sure native PL must have it. User set some PLdebugkey=1 and native PL will inspect data before plotting and tell which array and where has the problem.

The same kind checking options for %ls and other Clearwin+ controls for example would reveal undefined parameter or out of range value. But this thing for Clearwin+ is definitely deeper in the wish list, for now I'm sure the native PL must have such checking options first to be user friendly. In my own graphics made using FTN95 and its graphics libraries I can immediately use /debug and find what crashes the code, the native PL also needs something like that because inside it is much more complex then draw_line_between@ or OpenGL plotting commands.

But having a crash if some problem without a human readable explanation is not acceptable for Fortran users, they are probably ok only for computer science geeks.

UPDATE

There is no way the data can have any NaNs. Before plotting all data is compared to be >1e-30 and if NaN happen at this stage the Fortran code would inform before invoking simpleplot_update@. So the error happens inside the native PL

Dan

I have an open mind as to where the fault lies.

If I put a print statement at line 3204...

      Do ion=1, n7348423
  	  Plot_ION_f_E(i,ion) = f_E_i_log (i,ion)/dE3864_log(i) * kP63457E(ion)
        print*, Plot_ION_f_E(i,ion)
      enddo 

then some zeros are printed but I have no idea if that is significant.

Paul,

These zeroes were taken care of in the next block of lines to make sure that the data will be free of zeroes before call of function cb_Replot which calls simpleplot_redraw@

Dan

When I run your program in 32 bit mode there is an integer overflow and then some undefined values that show up. I don't know if this has any impact on the data that you plot.

Dan

I am beginning to understand the problem but I am not sure how to fix it at the moment.

We probably need two versions of SIMPLEPLOT_REDRAW@.

When using log scales the current SIMPLEPLOT_REDRAW@ is for use when resizing, and when the data has not changed but needs to be restored to what it was before the log transformation. This is not what you want in your program where you call SIMPLEPLOT_REDRAW@ for logarithmic data that has been changed.

So at the moment SIMPLEPLOT_REDRAW@ is not doing what you want in this code and it is presumably restoring old data that is no longer valid.