Native %pl

Paul - many thanks. yes, I saw your example was winop@ so realised (after posting) that it was just a mistype.

HTML standard is #rrggbb -- see https://www.w3schools.com/colors/default.asp for details.

Maybe I'm misunderstanding something, but the RGB@ documentation (in the FTN95 help file) has the arguments in the order RED GREEN BLUE. I supply values Red=127 Green=0 and Blue=0 which should give a dark red colour. The RGB@ function gives value 127 or Hex 00007F - which is dark blue. However if I supply Red=0 Green=0 Blue=127 which should give dark blue, the RGB@(0,0,127) = 8323072 = Hex 7F0000 = dark red.

Not sure what is going on here! Maybe generation of the Hex #rrggbb colour code should not just be using the Z6.6 format but should take each byte separately in the order R, G, B - probably easiest to do by avoiding RGB@ altogether but using the red, greem, and blue separately.

This works correctly:

      write(pltext,'(a,3z2.2,a)') '%pl[colour=#', ir,ig,ib, ']'
      call winop@(trim(pltext)) 

It's just that RGB@ gives the wrong order for this context so you have to use it in an unnatural way (i.e. we need a BGR@ function at this point).

Anyway, your approach is better.

Here is a simple demo of surface display using %pl, that Dan wanted to achieve. Using 4 arrays for different data value ranges, with different colours, small filled square symbols. Could generalise this, but stuck with limitation of 10 arrays - and messy coding as we need to hold the data in 10 separate sets of x,y arrays instead of a single set and a colour-code array.

This is what I would like to achieve (and I suspect a bit closer to what Dan wants), with an unlimited number of different colours.

For that, we would need to be able to supply x,y,rgb arrays to %pl, not just x,y[/img]

Silicondale, Paul did say in an earlier post that the limit on the number of plots (10) has been removed, so when the next DLL comes out you will be able to expand on your 1st 2-d plot. We'll also get grid lines then 😄

Thanks, Ken - I missed that one! That is good news.

What I shall need to do now is work out how to tidy up the coding - and add a colour palette to the side of the plot. Adding a general feature such as copying and pasting a graphics region on to the plot could allow that!

Fortunately for most of what I need, I don't have to go into the complexities of log-log plots, etc!

..... a little later .....

OK, have now hit limit of N-GRAPHS (tried 16, doesn't work. 10 works). Have also added a colour ramp.

Just a couple of problems with this. (1) the y axis annotation doesn't appear. Since I can't see it anywhere (I tried a wider margin but that didn't help) I can't move it to somewhere visible. (2) I'd like to be able to put the colour ramp into one of the margins, so it will get saved in any exported jpg or png file - but can't find any way to do this.

btw - there has been some discussion on setting 'nice' limits. For what it's worth here's a very old subroutine (you can see from the fixed-format coding!) that I have used for decades to do exactly that job

      subroutine v_autsca (upr, alr)
      implicit double precision (a-h,o-z)
c
c ************************************************************
c * v_autsca  auto-scaling algorithm ... sets min and max    *
c *         values for plotting at round numbers which       *
c *         include the full data range. alr and upr on input*
c *         hold the raw values, on output hold the rounded  *
c *         values                                           *
c ************************************************************
c first make sure alr and upr are the right way round!
      if (upr.lt.alr) then
        t = upr
        upr = alr
        alr = t
      end if
c
      range = abs(upr - alr)
      if ( range.le.1.0e-6 ) go to 9000
      rl = alog10(range)
      lr = int(rl) - 1
      size = 10.0**lr
      up = upr/size
      al = alr/size
      up = (aint(up) + 1.0)*size
      al = (aint(al))*size
      upr = up
      alr = al
9000  return
      end 

Silicondale

I've seen this problem with the y axis label positioning as well. If the range of y axis data is positive, the label is positioned centred at ymax/2, which is fine for a range where ymin is zero, but results in the label being plotted off the graphics area for some data sets. In your case I would guess it has been centred at y = 204000.

A quick for now is to make the y_axis label a blank string using

call winop@('%pl[y_axis=@]')

(just in case it just creeps into your plot), and add the label using a call back function to draw the text on the graphics region. My post above (Thu Sep 28, 2017 12:49 am) shows the basic idea using a call to draw_characters@

If your colour ramp is drawn in a separate gr region, you could instead draw it to internal memory and then copy across to the pl region using COPY_GRAPHICS_REGION@ as part of the call back function.

Or if it exists as an external file by using IMPORT_IMAGE@, again as part of the call back.

Thanks for the suggestions, Ken!

I've only started playing with the new native %pl but I see you already have quite a few tricks of the trade!

-Steve

Silicondale, That's a good and simple scaling routine, but if you use it in the following code and run with 32 bit and 64 bit and compare the outputs you get a surprise as the return values are sufficiently different to cause problems with your 'nice' graph scales.

program main
real*8 upr, alr
upr = 3.1d0
alr = 0.0d0
call v_autsca (upr, alr) 
write(6,*) upr, alr
end

Change one line from size = 10.0lr to size = 10.d0lr and 32 bit and 64 bit will return the same values, and avoid surprises later.

Good suggestion! As I said, the routine is decades old. I wrote it originally in the 1970s when graphics meant Calcomp pen plotters! 64-bit coding wasn't something we even considered then. Double precision was used sparingly and only when absolutely necessary, because of memory constraints.

One more devilry. When I compile my or Ken's programs from previous pages 9-10 of this thread

real*8, dimension (5) :: X  = (/1.,    20.,  60., 200., 600./) 
real*8, dimension (5) :: Y1 = (/2.9e4, 300.,  3., 0.2,  0.0022/) 
real*8, dimension (5) :: Y2 = (/2.5e4, 500.,  2., 0.4,  0.042/) 
real*8, dimension (5) :: Y3 = (/2.2e4, 722.,  2., 0.5,  0.072/) 

        CALL DIAGLV (0)        
        CALL TEXTMN(0.4)      ! setting font size 
        CALL AXLBJS('*C','C')  ! centering tic labels 
        call thckmg('LINE',4.)  ! setting line width 
        call chset(-11)          ! setting fonts 

!... Case of two lines of Fortran source code 
i=winio@('%ww%pv%pl[title='STANDARD IEC IDMT CHARACTERISTICS', x_axis='Multiple of setting current',y_axis='Relay operating time& 
& [s]',  colour=red, colour=blue, colour=green, X_ARRAY, N_GRAPHS=3, SCALE=LOG_LOG]%es', 640, 480, 5, X, Y1, Y2, Y3) 

End

I get

0001) real*8, dimension (5) :: X  = (/1.,    20.,  60., 200., 600./) 
***  This statement contains an illegal character - ' '
0002) real*8, dimension (5) :: Y1 = (/2.9e4, 300.,  3., 0.2,  0.0022/) 
***  This statement contains an illegal character - ' '
0003) real*8, dimension (5) :: Y2 = (/2.5e4, 500.,  2., 0.4,  0.042/) 
***  This statement contains an illegal character - ' '
0004) real*8, dimension (5) :: Y3 = (/2.2e4, 722.,  2., 0.5,  0.072/) 
***  This statement contains an illegal character - ' '
0006)         CALL DIAGLV (0)        
***  This statement contains an illegal character - ' '
0007)         CALL TEXTMN(0.4)      ! setting font size 
***  This statement contains an illegal character - ' '
0008)         CALL AXLBJS('*C','C')  ! centering tic labels 
***  This statement contains an illegal character - ' '
0009)         call thckmg('LINE',4.)  ! setting line width 
***  This statement contains an illegal character - ' '
0010)         call chset(-11)          ! setting fonts 
***  This statement contains an illegal character - ' '
0010)         call chset(-11)          ! setting fonts 
*** Invalid character ' ' at start of line
*** Invalid character ' ' at start of line
    11 ERRORS  [<main program> FTN95 v8.10.0]
*** Compilation failed

Anyone can check why invisible character is inserted?

Dan,

I don't get these messages. Could the file be changed from ASCII Encoding ( see FILE > Advanced Save ) Compile with /lis and look at default compile options you are using

John

I have the same problem as Dan. Looking at the original source code I posted, and the results of copying/pasting from the forum, it seems that single spaces are fine, but every two consecutive spaces in the source file are replaced by one space and one non printing character in the forum text. There are more than 40 of these in Dan's post above. Definitely devilry at work!

Ken,

How are you copying from the post ? I am copying from Win 7-Internet Explorer V11 to Notepad and saving (ctlC ctlV). I do not get any strange characters. The following is a scan of the file I get. [List Ver 1.61 8-Jun-16] file name: dan_post.txt /control selected Opening file dan_post.txt iostat = 0 [63] real8, dimension (5) :: X = (/1., 20., 60., 200., 600./) <CR><LF> [65] real8, dimension (5) :: Y1 = (/2.9e4, 300., 3., 0.2, 0.0022/) <CR><LF> [64] real8, dimension (5) :: Y2 = (/2.5e4, 500., 2., 0.4, 0.042/) <CR><LF> [64] real8, dimension (5) :: Y3 = (/2.2e4, 722., 2., 0.5, 0.072/) <CR><LF> [ 0] <CR><LF> [31] CALL DIAGLV (0) <CR><LF> [50] CALL TEXTMN(0.4) ! setting font size <CR><LF> [54] CALL AXLBJS('*C','C') ! centering tic labels <CR><LF> [53] call thckmg('LINE',4.) ! setting line width <CR><LF> [49] call chset(-11) ! setting fonts <CR><LF> [ 0] <CR><LF> [46] !... Case of two lines of Fortran source code <CR><LF> [130] i=winio@('%ww%pv%pl[title='STANDARD IEC IDMT CHARACTERISTICS', x_axis='Multiple of setting current',y_axis='Relay operating time& <CR><LF> [117] & [s]', colour=red, colour=blue, colour=green, X_ARRAY, N_GRAPHS=3, SCALE=LOG_LOG]%es', 640, 480, 5, X, Y1, Y2, Y3) <CR><LF> [ 0] <CR><LF> [ 3] End

Count of active characters in file dan_post.txt
            16 lines identified if text file
           820 characters read from file dan_post.txt
 Number of <lf>   characters =          15                   30
 Number of <cr>   characters =          15                   30
 Number of <ht>   characters =           0
 Number of ctrl   characters =           0                    0
 Number of blank  characters =         179
 Number of number characters =         105
 Number of alfa   characters =         505                  789
 Number of other  characters =           0                    0
 Number of lines identified  =          16
 Maximum line length found   =         130
 DOS format lines identified

The following link is the scan_file.f95 program I used to produce the report. https://www.dropbox.com/s/trk4k3acmj4gz9e/scan_file.f95?dl=0

It appears that only some of you are possessed !!

John

John, Confirmed there's no problem using Internet Explorer, but if you switch to Microsoft Edge which became the default on my main machine following a recent Windows 10 update the problem occurs. Ken

Good catch, Ken. Google Chrome has no problems too.

It was always very bad thing to be among first testers of Microsoft bugware. The only reason MS is still not bankrupt is that it was chosen not by computer revolution or free competition but exclusively by organized finances to make it a monopoly.

Many thanks for those tests, John! - and the code update. Of course I should have said that the main purpose of the original coding was geographic plots where we never had either negative coordinate values or logarithmic transforms! National Grid and UTM coordinates are always positive. Yes, one of my colleagues did write a version of this routine which allows specification of the orders of magnitude to use, but I no longer have a copy of that. As for transformed data, not just logarithmic but also probability scales, which we did use for geochemical data, we either took the easy way out and hard-coded the limits or we applied this scaling on log values after conversion. For the probability scale, this is always from 0 to 1 - but since (like with logarithms) both ends go off to infinity, we used a standard range of 0.0001 to 0.9999

BTW, I prefer this single line shortcuts for y_min and y_max which are used in

call winop@('%pl[y_min=Axis_min']')

when the plotted data has minimum and maximum values y0min and y0max

Axis_min = 10.d0**(int(log10(max(1d-30,y0min))))
Axis_max = 10.d0**(int(log10(max(1d-30,y0max))))

If there is a consensus on the best algorithm to provide nice limits then I could add a new option to apply it.

Paul - not sure you'll get consensus on this - or even if setting 'nice' limits is something that should be done within %pl. However, there are two things that I think would be much more useful (for me at least!) -

(1) when plotting points, allow each point to have its own symbol, size, and colour - so instead of just x,y arrays we have x,y,sym,size,RGB arrays. Maybe there's already a way to do this, but I haven't found it yet. Could even add an array with the link values, but since this controls the linkage between points it isn't a property that refers to just one point, unless you make it a property defining the link from the previous point in the list.

(2) to allow multiple over-plotting of sets of points and lines on the same graph. For example, coastlines of a set of islands with points (as in (1) above) scattered over each island. Actually N_GRAPHS may already do what we need, so perhaps this is already available. Limit needs to be increased to something much bigger than 10 ! The problem with N_GRAPHS is that the argument list for the %pl call can get very long if you have a lot of different x,y arrays, and you need to know in advance exactly how many - it can't easily (or maybe not at all) be changed at run time.

If (1) is implemented, there is much less of a requirement for (2).

Just my two-penn'orth 😃