Native %pl

Maybe you just need [x_array].

Magic ! I was just trying to be too clever - replaced [x_array] by [independent], but actually need both.

Current work on %pl will allow you to send %pl output to a printer using the printer's high resolution. So if you can get your T-shirt into the printer, all well and good.

As for implanting numeric values easily into a string of other characters, maybe you could write a Fortran function to do that. There are no plans to make winop@ work like winio@ in the sense of taking additional arguments.

Paul,

So if you can get your T-shirt into the printer, all well and good.

Google with search terms: 'tee shirt transfer paper'

Eddie

Paul,

Could you define a derived type record structure, as an alternative subroutine input for format %pl. The record structure could have lots of fields, to cover all that have been discussed in this very long thread and there could be a PL_record_default parameter to set each series, something like:

TYPE PL_DATA_RECORD integer*4 :: num_points .... END TYPE PL_DATA_RECORD

type (PL_DATA_RECORD), parameter :: & PL_record_default = PL_DATA_RECORD(0,...)

type (PL_DATA_RECORD), allocatable :: All_PL_Options(:) real*8, allocatable :: PL_series_values(:,:)

allocate ( All_PL_Options(num_series) ) allocate ( PL_series_values(2,num_series,max_points) )

Perhaps a derived type record for the chart and another derived type for each series, as an allocatable array. Can we have real*8, allocatable :: x_values(:) in the derived type ?

It may need more work, but the parameter pl_record_default would be very useful for documentation, if it could be devised.

That would be a good project !!

A short video I made for some of my colleagues. Not the best video on YouTube, but it does show the native %pl in action.

https://www.youtube.com/watch?v=TcUP3f-ZUak&t=64s

John-Silver

On second thoughts, I could provide two or three variants of winop@ in order to make this easier. The variants would be like winop@ but would take a format string for just one option and then one extra argument for the value.

For example, it might look like this:

call winop_int@('%pl[symbol_size]', ival)

Have done some experimentation with multiple stacked data sets. It seems there is a maximum of 128 if you want to supply different symbol, symbol_size, link, and colour parameters for each.

Beyond 128 data sets, it seems to revert to a default setting which is black curved links.

I am using colour ramps with 256 distinct colours - this translates to 256 stacked data sets for plotting. From data sets 129 to 256, instead of coloured un-linked symbols I get black curved lines scribbling over the whole image.

This shows what happens ...

Each of these plots is produced from the same overall data set, split into roughly equal groups ordered by increasing value of a response variable, with colours selected in sequence from a colour-ramp array.

Quoted from PaulLaidler John-Silver

On second thoughts, I could provide two or three variants of winop@ in order to make this easier. The variants would be like winop@ but would take a format string for just one option and then one extra argument for the value.

For example, it might look like this:

call winop_int@('%pl[symbol_size]', ival)

Paul, That would be logical and convenient. Actually that is the only way I'd like to see that. Currently changing the ival dynamcally in symbol_size=ival requires 'internal write' to the character variable WRITE(symbol_sizeVar(33:35), '(i3)', err=43466) ival. Hell inconvenient.

John, the native PL can not make this nice looking picture like on your T-shirt yet. For that it will need an additional artistuc feature to paint everything under the curve to specific color, in this case white. Did I miss anything? On the topic of wrong centering again and again, clearly Paul complicated things to the extremes: centering has to use just the physical screen coordinates of axis start and end, two integer numbers, this is simple to stupidity why it is easy to miss. Instead looks like Paul translates them to plot value coordinates and then gets lost in the forest of exceptions and exclusions, positive Xs and negative Ys, external xmin's and ymax's...Look, the centering mechanism does not see negative curve numbers! Instead the plot positions on screen are always the same, plotted curve values though always change as you update the plot with new data. Happened to me all the time, we tend not to see simplicity 😃

Steve, plz post simple example. Besides simplifying things to Paul to reproduce the bugs, for all others seeing the picture of output and its source code is the best and fastest learning experience for native PL. Soon the manual for old and new PL will exceed the manuals for openGL 😃

Hi John-S -- some of the greeny colour disappears each time I add an extra colour because the data points are just being reclassified - so by the time we get to 256, half of the points are beyond the 128 so they plot as squibbly lines instead of neat coloured squares.

Y axis labelling looks like it does because it's all negative values. Not worried about that!

Dan - thanks for the suggestion, but easier said than done. This is just a small part of a long program, and I don't think I can demonstrate the problem properly with a small data set. But it's clear what the problem is !

I have increased this maximum to 255.

Hi Paul - and many thanks. That makes my life much easier 😄
I am generating software for an EU Horizon2020 project and this is exactly what I will need to keep the project officer in Brussels happy when he reviews the deliverables. No pressure - but will this go into the next CW+ library version?

%pl has its own legacy database and it is natural to keep its size within reasonable bounds.

All good points, John! My 'client' is the project consortium, and 255 colours is fine. Fortunately for other requirements we won't need anything like 255 lines or point sets. Right now, can't do much, as sitting in a hotel bar in Ljubljana waiting to hear when a delayed flight is going to get me home. Heavy snow here.

A lot of the information about the native %pl can be found in the cwplus.enh that goes with the v8.20 release.

The original %pl SIMPLEPLOT DLL uses 32 bit reals. It just means that you only get about 7 significant figures from your 64 bit real input.

The native %pl uses 64 bit reals but even then it accesses the Microsoft GDI+ library and that uses 32 bit reals. However, when it comes to plotting graphs, is there any reason for having more than 7 significant figures in the data? If there is then %pl is not the thing to use.

Quoted from PaulLaidler However, when it comes to plotting graphs, is there any reason for having more than 7 significant figures in the data? If there is then %pl is not the thing to use.

At first glance there is no reason even for more then 4 digits for plotting with all the screens currently are less then 10000x10000 pixels. And the only need to get more then 4 is to have color depth around 8 bits per color for which single precision is enough. Right? Even my own 2D graphics libraries all were single precision by the way by these exact reasons.

OpenGL though from start allowed both single and double precisions I had no idea what for and with time most pros who write the games switched to double precision. When Nvidia started using double precision i scratched my head! The graphics and video were slow, cards expensive, image barely displayed on a tiny windows, and they were making it even slower. 20 years ago I was really surprised why the heck they waste precious resources, degrade speed and double memory requirements. But decades later...remember me and Agustin strongly complained few years back at older %PL design defect for not taking double precision values?

The answer why all graphics utilities must be double precision is universality to accept wider range of input data which unfortunately spreads wildly causing the same damn crashes I hate so much from using spurious large or small numbers and denormals not in the single precision range. The cause of games crashes in the past (remember kids angry yelling?) very often was due to single precision engines. Single precision range became too narrow for broader use of graphics utilities! The same idea was behind the Intel FP processors with their 80 digits -- universality -- because there could easily exist some numerical methods written by any teenager which go to 10^4096 numbers and beyond while still the final result being plotted on 640x480 screen in 2 bits color!

Intel scaled down somewhat from 80bits recently, but at least it improved single and double precision speed making both almost the same. And SilverFrost got down from real10 to real8 in 64bit compiler and I now need to rewrite some parts of my code to different methods I did not have yet invented. I'm not asking for 80 digits, this is really rare opulence, but the life demands these 64 bits at least. Universality gives you less headache and much less crashes. Clearly, it is the native %PL which has internally handle interaction with Microsoft 32 bit system by scaling down from more universal 64 bits and take care of potential problems preventing crashes

John - I puzzled over the white space at the top in the 256-colours case, as well. But the explanation is quite simple. The plots represent x,y,value where the value is mapped to a colour. The data set is ordered by value, and mapped to colours so that there is (as far as possible) an equal number of points of each colour. In the 128-colour case all of the points are plotted as coloured squares. In the 256-colour case, the first half of the points map to colours 1 - 128. The second half of the points should map to colours 129 - 256 but in fact plot as black squiggles. Most of the high values are at the top of the plot. This plot shows sonar reflections and these are strongest at the top nearest to the sonar pinger. So what should plot as coloured squares near the top of the plot instead gets displayed as curved bezier lines all over the plot since the order of the x,y coordinates is completely arbitrary. You can see what happens in the 240-colour case where the higher values disappear and are replaced by curved lines. Also showing the colour ramp - the only colours that ever get plotted are those in the left-hand half, blue to green.

I'm not sure why the lines in the 256 case don't go right to the top, but I guess by that stage the system has its knickers so twisted that the bezier curve fitting algorithm is itself struggling.

But why is the default setting black curved lines with no symbol ?

Steve, Without demo I'm always puzzling what is done and what the problem is. Hopefully Paul gets that and will react. But if it looks like not many people are interested the solution may take longer time. In graphics typically always possible to make relatively small demo.

John - we don't yet have the 255 limit version: I guess that will come with the next clrwin DLL release. I could do a 255 test but I think it will look very like the 256. Anyway, if I can use a 255-colour ramp instead of 256, not a basic problem. And I guess we have to accept Paul's statement that we are tied to some existing limitations in underlying code - at least for now. A matter of priorities, dependent on how many users want particular upgrades. It's the 'art of the possible' and from my own viewpoint I am quite happy for now that Paul has been very responsive and helpful.

Good point, John. And interesting results. It blows up ! Two plots from two runs of the same program, same parameters, both using 255 colours.

I ran the program several times. Got these two plots, but also two or three times it blew up or hung without producing any plot at all. I guess this is the sort of unpredictable behaviour you might expect when exceeding array limits. Would be helpful, however, to have some check within the %pl coding to prevent it, and instead give some proper error message.