Native %pl

Dan

You should get a error report if the symbol size is greater than 16. This limit can easily be increased. How big would you like it?

John

I am sorry that we are not providing the service that you expect. Unfortunately I do not anticipate further improvements to the native %pl in the short to medium term.

The delay from initial release until the release of the personal edition is normally about 2 months but it does depend on whether the initial release has proved to be successful.

Paul, Respect to symbol_size. Great that native PL now does not crash the code without diagnostics. That is very appreciated addition. But having restriction based on 16x16 pixel size is decision prone to permanent fixing in the future. It's ok for laptop screen, may be ok for 2k monitors, not enough for 4k and 5k monitors and is not acceptable for 8k.

What size has to be the maximum? I'd not restrict it till integer overflow where warning diagnostics should appear. If this will slow the graphics to total stall then 10x the screen dimensions have to be taken. Why so large? Some people may plot in virtual screens of extremely large dimensions.

Another is making one number for all plots which is fine for for first versions but besides making plotting less flexible is breaking the style of native %pl

Respect to some John's comments. I agree with him that the current shape of native PL needs urgent cosmetic fixing of few last often painful problems. That will take some extreme unsatisfaction with either bugs or missing features off the table. I'd go through this thread, make a list of what was asked for and what was done, reveal such screaming 'nails in the shoe' problems, and close this large old thread for good.

I'd like to echo John's words - very much appreciate Paul's responsiveness. What other compiler developer has such close and productive interaction with their user base?

Having said that, I also agree about the small proportion of users who actually participate in this forum. However, this is probably quite normal. I have been on the other side of the fence in the past, as an applications system developer supporting a large international user community, of whom fewer than 5% ever took part in any user forums and meetings (this was before the days of the Internet and we had to go globetrotting to meet the users in person).

Specifically on %pl - speaking from personal experience, I found SIMPLEPLOT didn't do everything i needed, and developed my own graphics library using %gr and the Salford primitives such as draw_line_between@. Fortunately made easier by adapting an existing library that I had used before in different software environments. But of course if everyone does that, the same wheels get reinvented many times. That's why I'd really like to see the native %pl expand to something that can replace my (and anyone else's) old clunky code!

John

The next general release of intermediate DLLs will probably have to wait until the personal edition of FTN95 catches up.

John

I don't have a simple answer to your questions. You will appreciate that the personal edition is free and is aimed at students learning Fortran who have no interest in the latest developments. All they need is a stable product.

I have a task which may or may not be implementable in native %pl. Sonar data consists of a set of N wavy lines which are separate. N is a large number which can vary from one plot to another. Each wavy line contains m points, where m can be different for each line.

This is what they should look like:

but the lines all get linked together in native %pl, like this:

Is there a way of suppressing the unwanted line segments?

Does each wavy line have its own y array?

Each wavy line is a set of x(i) y(i) pairs. All I need to do is separate the lines so that the last element of each wavy line isn't joined to the first element of the next one.

Can you post some code that illustrates how the y array or arrays are constructed?

The upper plot was generated using old coding: call draw_line_between@ (iu1,iv1,iu2,iv2,irgb) where each line segment is drawn separately by computing the pixel positions iu1,iv1 and iu2,iv2 for the ends of each line segment

The lower plot uses i=winio@('%`pl[x_array,link=lines,symbol=0]&', 1 iwvm,ihvm,NUMDAT,xval,yval,ighandle) where all of the wavy lines are held in the same xval,yval arrays - of necessity since it isn't practical to have umpteen separate arrays.

I am guessing that you get the join because to ask for it. Make sure that the end point of one wiggly line is not the start point of the next.

The first wiggly line ends at xval(n),yval(n) The second wiggly line starts at xval(n+1),yval(n+1) and goes on to xval(n+m),yval(n+m) ... and so on, for several wiggly lines. In the sample plots there are about 40 of them, but the exact number can vary.

So how, using %pl, do I suppress the line segments n to n+1 etc. so that the end point of one line is NOT the start point of the next?

Yes, I know you can set the number of graphs such as call winop@ ('%pl[N_GRAPHS=10]') but as N_GRAPHS gets bigger, the final i=winio@('%`pl.... call gets steadily longer because of all the arrays for the N_GRAPHS different data sets, and has to be coded separately for every possible different N_GRAPHS value.

Maybe I have missed the answer in this very long thread, but just how do you plot 40 separate wiggly lines using %pl ?

If you have the release that includes v8.20 of FTN95 then look at item 394 in the document cwplus.enh.

Sadly I just have v8.0. Can't afford to keep on buying new versions at full commercial price. I don't even qualify for an academic licence though all my work is now on EU research projects. Would be good if you could offer an annual maintenance contract for loyal customers, that provides updates as and when issued.

Sadly I just have v8.0. Can't afford to keep on buying new versions at full commercial price. I don't even qualify for an academic licence though all my work is now on EU research projects. Would be good if you could offer an annual maintenance contract for loyal customers, that provides updates as and when issued.

We do and have always provided exactly what you require.

Problem resolved. Many thanks to quick response from Silverfrost! Looking forward to installing v8.20 soonish.

I have updated the program but it's giving me a run-time error

call winop@ ('%pl[native,independent,stacked,n_graphs=39]')
call winop@ ('%pl[x_min=7500]')
call winop@ ('%pl[x_max=7710]')
call winop@ ('%pl[y_min=0]')
call winop@ ('%pl[y_max=130]')
call winop@ ('%pl[x_axis=X]')
call winop@ ('%pl[y_axis=SEQNUM]')
call winop@ ('%pl[color=black]')
call winop@ ('%pl[link=lines,symbol=0]')
i=winio@ ('%`pl&',iwvm,ihvm,numld,xval,yval,ighandle) 

where where iwvm = 500 ihvm = 500 numld is an integer array holding the number of points for each of the 39 graphs xval is a double precision array of all the x values for all graphs yval is a double precision array of all the y values for all graphs ighandle = 1

The error message is Argument No.7 of winio@ (continuation 1) should be a REAL*8

Definitely refers to this winio@ call - which has no continuation lines and is not over-length. Am I missing an argument somehow?

Silicondale, You are probably the first to try new feature 'stacked'. Post full demo

This was just a snippet out of a large program. In fact each winop@ call was constructed by a formatted write because the numeric values had to be inserted from variables. What I posted was just the set of resulting calls.