forums.silverfrost.com

Kenneth_Smith · Posted: Thu Oct 05, 2017 11:46 pm Post subject:

I have been experimenting with log_log scales.

Kenneth_Smith · Posted: Fri Oct 06, 2017 12:17 am Post subject:

The code above produces:-

Adding

Kenneth_Smith · Posted: Fri Oct 06, 2017 12:22 am Post subject:

NOTE, the two plots above were produced using DLL14 and 64 bit. When using 32 bit, the modified code for the second plot has a problem with the y-axis.

The label values at 10**-3 and 10**-4 appear as 0.

Kenneth_Smith · Posted: Fri Oct 06, 2017 11:27 am Post subject:

A slightly modified version of last night's code. By scanning the data arrays before the call to %pl in order to set the plot limits we can get it right first time for this type of data set.

Kenneth_Smith · Posted: Fri Oct 06, 2017 11:30 am Post subject:

cont

Kenneth_Smith · Posted: Fri Oct 06, 2017 11:31 am Post subject:

cont

Kenneth_Smith · Posted: Fri Oct 06, 2017 11:36 am Post subject:

cont

This works ok with DLL14 64 bit.

DanRRight · Posted: Fri Oct 06, 2017 4:05 pm Post subject:

Based on how much source text takes to plot similar graphs in Matlab or even older Simpleplot PL, i'd say that the glorious times of hacking returned back to this forum Smile

. Before this was with broken Simpleplot PL, now it's native PL.

After trying everything we still could not fix the LOG_LOG with older Simpleplot PL, it worked only if X values do not exceed 1. And it had no X_min, Y_min, or framed plotting, and was buggy, crashing at Y values > 1e22, crashing debugger, not working with 64bit etc.

But like Matlab, older Simpleplot PL had no big problems with the correct LOG tics or labels. And, like in Matlab, the whole source code for the similar plots like above take only one single source text line. If it would take more no one would use them. With Matlab even 3D plot is done with one line, clearly people at Matlab know human psychology very well.

Here is what older Simpleplot PL produced (though crashing inside with LOG_LOG and turning to LINEAR_LOG plotting instead) with just one-two lines of Fortran code if plotting data already exist and all the fonts were preliminary set up. No minimum/maximum beautifications were necessary, let alone using Y_min for the native PL fixing. This is one single 132 character Fortran line!

Kenneth_Smith · Posted: Sat Oct 07, 2017 10:51 am Post subject:

Dan's data combined with Friday's "hack" and I can replicate the performance of the old simple plot with the native %pl.

And it works for log_log scales.

Kenneth_Smith · Posted: Sat Oct 07, 2017 2:46 pm Post subject:

I was going to add grid lines to my log_log plots but unfortunately get_plot_point@ does not work with log scales as this example demonstrates.

DanRRight · Posted: Sat Oct 07, 2017 5:19 pm Post subject:

As everyone can see from comparison, even after the tricks and beautifications, even though the curves in native PL look better then in older PL, the unreasonable frame numbering, wrongly placed tic marks and other errors making the whole plot far from production quality.

Without the tricks (of setting X and Y axis min and max at exact orders of magnitude as Ken have done above) and beautifications (bullets, frames, font and lines sizes), here is what novice user will see for the first time in native PL as a default image when he will visualize with LOG_LINEAR and LOG_LOG the data above (even using more lines of Fortran code). For everyone raised on shiny covers of journals and flashy websites the cultural shock is guaranteed:

Kenneth_Smith · Posted: Sun Oct 08, 2017 11:46 am Post subject:

I do agree with you Dan, my perseverance and enthusiasm with native the %pl is beginning to falter somewhat. I have hoped to be able to generate a plot similar to the one below with grid lines, but it's not that straightforward. Even if I can decode the coordinates returned by get_plot_point@ with log graphs, there is an added complication of user selected margins to consider, which takes me back to the struggles I have with my own %gr based plotting routines.

Guess we all just have to wait on Paul and his colleagues having the time to look at these issues. A quick fix for get_plot_point@ with log scales would be a step in the right direction as I can live with having to select appropriate ranges for scales.

PaulLaidler · Posted: Thu Oct 12, 2017 7:03 am Post subject:

I don't know if it is a bug or if, like a number of these plots, it is a matter of choosing nice values for y_min, y_max, dx and dy. If and when I am able to do more work on this we will need to start off with some simple plots that illustrate the problems. But please don't post them now.

In the mean time one or two fixes have been made and...

a) the limit on number of plots (previously 10) has been removed. At the same time, an option [stacked] has been added which means that the y (and x) data for different plots is concatenated in order to avoid multiple winio@ arguments. The concatenation is equivalent to using a two dimensional array for the data but this 2D array can be "ragged".

b) an option [gridlines] has been added with the expected result.

Kenneth_Smith · Posted: Thu Oct 12, 2017 12:40 pm Post subject:

Paul,

The option external_ticks works well, but unfortunately it does not address the issue of cases where the data to be plotted obscures the scale numbers on the axis as shown bottom right below, perhaps you might consider an 'external_scales' option at some time in the future.

Apologies for raising this again, my intention is to provide positive suggestions which all users will benefit from rather than negative feedback.

The news that you have implemented grid lines is a big step forward. I look forward to being able to use that option.

Kenneth_Smith · Posted: Thu Oct 12, 2017 1:05 pm Post subject:

As for the issue with get_plot_point@ with log-log scales, I don't think this is related to the selection of y_min, y_max etc. I have experimented with lots of variations on this. My impression is that somewhere within %pl there is a coordinate transformation that is the root cause of all the problems we are collectively complaining about.