Thanks Paul. The simpleplot_update@ (though the name sounds irrelevant) now works. As I wrote the linear plotting looks almost ideal now, here how it looks in comparison with the leading scientific software OriginLab
Antialiasing makes curves look better then anything on the market now.
The only what needs fixing is numbering (Y scale has also problems, like number 1e22 instead of 100 or at least 1e2) and sometimes plotting gets out of plotting region (see the same below for LOG scales),
axis captions are better put centered by default -- and it is completely done

The source for this comparison is here. All may use own data or I can send mine for exact comparison (does this code work with you under last DLL7 ?)

And now LOG scale plots start to approach usable shape. Log scales are kind of more important to get fixed because without them 3/4 of all %pl cases (linear, log_linear, linear_log, log_log) will not work

Couple of problems with the DLLs7
1) small typo in the readme The source written there does not work because the line USE CLRWIN must go inside the module MODD
2) This code crash if use accelerator Ctrl+Z. Same for the code demo in the README (or see similar code below which crashes in my case)
3) The code for the linear Native pl Linear scale above works with DLLs6 but does not compile with DLLs7.

Last edited by DanRRight on Fri Apr 21, 2017 10:25 pm; edited 7 times in total

DLLs7 still crash my main code and SDBG64 in few circumstances so I still need to get back to older DLLs5. If this is not my problems and the users will also see the same crashing problems may be we will need to update the entire compiler. I may even give you to play my code so that the bugs will be found and fixed much faster not taking time of developers from more important things.

Now about LOG scale plotting. It looks now MUCH better, everyone can see that on this example I further modified from README file

Few defects are
1) plotting curves outside the box (symbols are plotted OK)
2) after clicking on Redraw 4-5 times it will switch on linear scale because I specifically made T numbers negative. Besides the fact that native %pl should not switch on linear scale as "y_min=100" condition is used this also wrecks chaos in linear plotting
3) somewhere in the ℅pl internals the real*4 numbers are still used because it is impossible to increase array size beyond N=30 which means exp(3*30)>1e38

Reason why I pay such attention to developing easy scientific graphics plotting utilities in Fortran is because I'm 100℅ convinced that without them Fortran is dead. It will be swallowed by MATLAB. Each student of technical universities now uses MATLAB. Adoption of Fortran is 1000x less. What is the reason for such crazy discrepancy? Both are simple, even similar in syntax and Fortran is even faster. The answer is that Matlab just made super easy professional graphics and math libraries, they are like ultimate easiest Lego blocks. Look at the MATLAB samples I cited few days back in another ℅pl thtead. Even the plot of 3D da

Last edited by DanRRight on Thu May 04, 2017 3:53 am; edited 1 time in total

Paul,
I'd experiment with these options first. If do not set y_min=positiveVal then I'd leave things as they are now, i.e. switching on linear scale plotting. Same with y_min was set as negativeVal or zero. If y_min was set as positiveVal then I'd treat negative y point as tiny positive number say 1d-200. That might help the algorithm to do smoothing better than just ignoring the negative point.

Formally 1d-200 is not even needed to be that small. Visually it will be hard to distunguush two plots one with 1d-200 and another with some number smaller then minimum plotted value by just 4-5 orders of magnutude. That may help smoothing algorithm even more.

By the way among all smoothing algorithms I like in Originlab software so called B-spline as the most stable and kind of universal due to that. It works much more reasonable than Bezier or Spline and almost never makes artifacts. I do not know how it works though, it always was no time to investigate. Ideal in this case would be to have variable degree of smoothing from straight lines to spline at your wish. May be someone here can develop such single universal function, I always wanted to have that.

After all that it would be good to add to pop-up window which informs about switching from logarithmic to linear scale that ℅pl[ y_min=Val ] can prevent the switching

Dan's idea of a 'warning' dialogue is a good idea.
In principal, if you're using log scales then there shouldn't be any of course, however catering for the unexpected is always a good approach.
if it finds any -ve y values it would be good to list them:
no. pt / x value °7 y-value
to aid in finding the erroneous value(s).
It's also worth noting that the check should also be for x-axis as well as y-axis shouldn't it ? Just to be complete and fool-proof.

oh I forgot, in Dan's example above the 1e22 is very odd indeed, is there a specific reason why that has occurred becasu it's not even a number !

In addition while not being explicit requests for new capabilities at this moment in time (I took on board Paul's 'watch my lips - no more development at this time'), a few comments about the scales follow .....

A general comment is that the y-axis scale with all those zeros just doesn't look right.
I haven't delved into all the various settings yet (awaiting first resolution of these several points raised by Dan and Ken recently) but:

a) isn't it possible to more intelligently label not always using floating point numbers but also integers if the dividions are round numbers ?

b) what control is there over the number of divisions, or uis that uniquely automatic ?

In Dan's last example plot above for example, there are sub-divisions on the reference plot he is trying to duplicate !
On the x-axis I would personally choose:
12 - 22 on x-axis with at least divisions of 2 units
even better ..... 10 - 25 in divisions of 5 units, with 5 sub-divisions unlańbelled !

Which leads to the question, is there no scope for secondary divisions ? (automatic and/or user-defined)

On the Y-axis, similarly...
major divisions of 20 units with secondary of say 5 units, or even major of 50 units with subdivisions of say 5 or 10 units.

I'm just thinking off the cuff at what I would do in Excel for example.

Overall I just keep thinking - 'we're so near and yet so far' - not from an all-singing, all-dancing swish offering but just from the basics of a solid robust improved capability.
It's not been 100% easy I'm sure to knock together the undoubted improvements in the capability in such a short space of time but it should be left in a rock-solid state otherwise any new users trying to use it for the frst time will no doubt risk having the same reaction as we were getting with SimplePlot couple of years back.

The reason I delved into PLPLOT for example was not just for 3-D capabilities but also for rock-solid x-y plotting options with more user-control.

Ideal axis numbering is not easy matter. I tried this and I know myself. You will swear like hell doing it. My own codes (not %pl based but the ones I made myself) numbering currently choses 5-7 numbers per axis and looks not bad.

Also in my own graphics programs when i use %pv and decrease plot size (if axis is too small for used large fonts) then number of tics decreases eventually to zero. Native %pl is doing something similar

Ideally with native %pl of course is to scale fonts size together with plot size, but hopefully this can be easily done in the future when all defects will be fixed. There are also some other small suggestions for corrections like longer tic marks in LOG scale, better name for "width" of plotted lines in CALL winop@("%pl[width=2]") which better call "linewidth" etc

Among them could be also your good suggestion to use arbitrary step (in Originlab it is called increment), say, 5 for X axis like in the plot above. But you know why I call the current state of native %pl close to ideal? The blind choice of computer looks as better option because increment 5 leaves only two numbers on X axis 15 and 20 - aesthetically this would not be good, though in some cases necessary. I hope in the future Paul will implement user definable increment in axis numbering and user's choice of first and last axis numbers (From and To), as well as drawing minor tic marks, horizontal and vertical grid lines (see pic below), background from external files, different axis numbering options like in this plot for example ( with the comma, I never used but some may like it)

the error bars, text labels and may be more symbols like here

or eventually at some point even color scale and surface plotting like here

etc. I've done many these myself in my own graphics routines, they are easy to implement (much easier then to make good numbering!) and they look great. But the automatic choice of computer with latest native %pl right now for X axis looks acceptable. And also have you noticed that with the recent additions the axis drawing and text quality already looks more professional then for example in the two last plots?

The Y axis numbering does not look good with default settings. But I see new options x_sigfigs and y_sigfigs for user defined adjustments. Can you try them and post here to see how things look (use for example Postimage)? Will setting y_sigfigs to 2 fix y axis? I can not do that right now because my computers loaded multiple FTN95 programs so I can not overwrite DLLs or change FTN95 dir - I can not use latest DLL7s for my other programs, have crashes, do you too?

When talk about graphics it is always better to show what you want instead of saying, so I post INSTRUCTION FOR POSTING IMAGES FOR ALL WHO ARE INTERESTED
------------------------------------------------------------------------------
Use site Postimage.io where posting is easy as 2x2
- Chose "do not scale my image" (it is default now, so do not change it)
- Upload better png then jpg file by clicking on "Chose my image" and
- Highlight and Copy into clipboard using Ctrl+C second option Postiamage offers for posting in newsgroups called direct link.
- In FTN95 newsgroups place yourself this link between IMG and /IMG tags framed in the in square parentheses. Or look how forum offers to do that for you by clicking on IMG or URL buttons. Then press CTRL+V and click on IMG button again

Last edited by DanRRight on Tue Nov 07, 2017 11:35 am; edited 2 times in total

Ideal axis numbering is not easy matter. I tried this and I know myself. You will swear like hell doing it. My own codes (not %pl based but the ones I made myself) numbering currently choses 5-7 numbers per axis and looks not bad.

I'm sure it is. Not a trivial test but essential imo.
There are 2 aspects:
a) how far to go for the 'automatic' route (the quick-n-dirty if you like, but hopefully not too dirty
b) having enough parametrisation of the scales for the user to be able to be more sophisticated him/her self.

Quote:

Also in my own graphics programs when i use %pv and decrease plot size (if axis is too small for used large fonts) then number of tics decreases eventually to zero. Native %pl is doing something similar

This was something I was thinking too. Something to observe is how exactly the native%Pl behaves in a re-sizeable window, which it has to eventually cater for if the new kid on the block wants to be taken seriously.

Quote:

Ideally with native %pl of course is to scale fonts size together with plot size, but hopefully this can be easily done in the future when all defects will be fixed. There are also some other small suggestions for corrections like longer tic marks in LOG scale, better name for "width" of plotted lines in CALL winop@("%pl[width=2]") which better call "linewidth" etc

The big thing of course is 'when is the future'.
The problem at the moment is that even with a limited set of parameter options it's not yet 'rugged' as I see it.
It's important we get as many 'bugs' out of the trees for Paul to fix so that later on he has a sound working basis from which to restart from and think about further development.
I thought the length of tic marks could be specified ?

Quote:

Among them could be also your good suggestion to use arbitrary step (in Originlab it is called increment), say, 5 for X axis like in the plot above. But you know why I call the current state of native %pl close to ideal? The blind choice of computer looks as better option because increment 5 leaves only two numbers on X axis 15 and 20 - aesthetically this would not be good, though in some cases necessary

That's why instead of 12 to 22 scale a more inventive algorithm mith́́ght decide to logically extend the scales to between 10 and 25 !!!
as I actually said earlier....
"On the x-axis I would personally choose:
12 - 22 on x-axis with at least divisions of 2 units
even better ..... 10 - 25 in divisions of 5 units, with 5 sub-divisions unlabelled ! "

While I'm here, has anyone else noticed that the last numbers on both x and y scales are not printed !!!! This for me is a bug, although Paul might argue it's a limitation. I'm used to seeing scales numbered from start to finish

Quote:

I hope in the future Paul will implement user definable increment in axis numbering and user's choice of first and last axis numbers (From and To), as well as drawing minor tic marks, horizontal and vertical grid lines (see pic below), background from external files, different axis numbering options like in this plot for example ( with the comma, I never used but some may like it)

Exactly, although imo this should be sooner rather than later, with the automated scale calculation options for later.
I'd missed the lack of grid lines. In theory of course the user could add these themselves but only IF one knew where the tick marks were located.
I guess with the option available to find the pixel co-ords of any plotted point they could be deduced via that, but only if the actuyal scales were known in advance !!!!!! By the same measure one could also add extra minor tick marks I suppose too, but it seems like an awful lot of work for the user to have to put into the programming .... and of course it would also be complicated for any re-sizeable windows. We'd almost become as complicate

I hope in the future Paul will implement user definable increment in axis numbering and user's choice of first and last axis numbers (From and To), as well as drawing minor tic marks, horizontal and vertical grid lines (see pic below), background from external files, different axis numbering options like in this plot for example ( with the comma, I never used but some may like it)

Exactly, although imo this should be sooner rather than later, with the automated scale calculation options for later.
I'd missed the lack of grid lines. In theory of course the user could add these themselves but only IF one knew where the tick marks were located.
I guess with the option available to find the pixel co-ords of any plotted point they could be deduced via that, but only if the actuyal scales were known in advance !!!!!! By the same measure one could also add extra minor tick marks I suppose too, but it seems like an awful lot of work for the user to have to put into the programming .... and of course it would also be complicated for any re-sizeable windows. We'd almost become as complicated to plot as to start from scratch with points and lines !

Quote:

the error bars, text labels and may be more symbols like here

I'd agree you can never have enough symbols, and also more line_styles !!!
X-Y plots should be equally useable when printed in b&w !!!!!!!

Quote:

or eventually at some point even color scale and surface plotting like here etc.

Whoah boy !!!!
As I mentioned before this was another reason why I looked into PLPLOT too, for 3-D options. I don't imagine we're going to get that sort of capability directly integrated into Clearwin this decade !!!!
There is the option of using SimDem/SimFit , but the trouble is it isn't able to be integrated into a ClearWin window layout, it's doe via an independent window, and it overloads that window with buttons too. Fine for a stand-alone tool (which it was developed as of course so no criticism intended there) but not exactly fully integrateable into a complex %gr. I think.

Quote:

I've done many these myself in my own graphics routines, these are easy to implement (much easier then to make good numbering!) and they look great. But the automatic choice of computer with latest native %pl right now for X axis looks acceptable.

Debatable imo as to whether it looks acceptable. I guess the 'acceptability' or otherwise of the current capabilities will vary on a user-by-user basis and application-by-application of course.
Hopefully more of us will now start trying it and feedback any problems / comments.
I guess the 'acceptability' or otherwise of the current capabilities will vary on a user-by-user basis and application-by-application of course.

Quote:

And also have you noticed that with the recent additions the axis drawing and text quality already looks more professional then for example in the two last plots?

Yes, things have certainly come on from SimplePlot days I think we can all agree on that. It's just a question of whether we have a robust capability or not even for the limited capabilities which are currently baselined. Only time will tell of course.

I'm now going to bite the bullet and go and try to come up with a rigorous dataset keyed to my typical plotting needs and try it out.
It might take me a bit of time as I'm not as proficient as you experts and am a bit limited for time generally at the moment !

My gut feeling tells me that it'll come up short for my needs, but I'll try to put that out of my mind and see what it can (and can't) do to my requirements.

My first hurdle might actually besdorting out all the ENVIRONMENT variables sinc e I've just installed 8.1 in tandem with the 7.1 version which I already had there and I had problems setting them up for 1 version let alone 2 !!! Wish me luck.

While I'm here, has anyone else noticed that the last numbers on both x and y scales are not printed !!!! This for me is a bug, although Paul might argue it's a limitation. I'm used to seeing scales numbered from start to finish

John,
This specific thing is strictly saying not a bug because the data ends at 21.9674. Automatic axis numbering has to work in exact range of data. Though I agree with you and i myself in my own graphics programs numbering (written completely in FTN95 by the way) added small few percents search radius at the beginning and the end of X or Y axis to look if any 'good number' can be placed there like 0 or 1000 when data starts from 1.1 and ends at 996.9. My impression is that Paul have done something like this for automatic numbering of the beginning of axis number. Adding the same for the end of axis number would probably be beneficiary.

All things we discussed so far including not yet implemented surface plotting, color scales, 3D OpenGL plotting are often from few minutes to few hours, in worst case to few days (OpenGL) job. The numbering is a few weeks job. And the numbering in OpenGL I even not have done in decade (!, because not met on this planet anyone else who used with this specific Fortran such great thing like OpenGL to ask what i'm doing wrong why it does not work, and I do not RTFM)

Some things are very simple and look very attractive. Right now for example i can change the palettes of the color bar like in the figures above just with one click, this dramatically changes the plots. I can give the palette code if anyone wants though i am sure professional programmers can do that much more effectively