forums.silverfrost.com

[PaulLaidler]

Thanks Ken. I hope to come back to this thread when things are a little quieter.

[Kenneth_Smith]

John,

My quick and dirty fix for get_plot_point@ for log_log scales with logs using base 10.

[Kenneth_Smith]

and the corresponding plot

[Kenneth_Smith]

John,
You can define the margins as integer variables and build up the pl string as follows before the final call to pl.

[silicondale]

Small change of subject. I have an idea how to plot full-colour area plots rather like Dan has asked for. The only thing that prevents this is that colours are defined by names. I need to be able to use RGB values (as obtained from function RGB@). This should really not be a major problem to implement ?

I would then divide the data set into multiple sets for different value ranges and plot each with a different colour. This would need more than the very limited set of named colours, to allow the use of a full colour palette.

Of course a much neater way to do this would be to allow a separate RGB value to be associated with each X,Y pair - i.e. each point would have its own colour, so we would have 3 arrays, X,Y, RGB. Any chance of doing this ?

[DanRRight]

Silicondale, I agree, that would be good addition to Paul's reported concatenation few days back, I do not know how it was done but suspect this way

%pl(X,Y)

where X(i,j) and Y(i,j) are 2D arrays and number of plots j can be very large.

In this case adding color

%pl(X,Y,iColor)

besides expanding functionality of usual X-Y plotting will automatically turn native %pl into 2D surface plotter. But suspect this stuff will be for the future, after our usual 1D X-Y plots will be made perfect

[DanRRight]

Ken,

I think silicondale got with your example problem with resizing.

To do resize just add %ww%pv to %pl'

[PaulLaidler]

Silicondale

I am not sure if this is what you need but you can set the colour via

call winopt@("%pl[colour=#bbggrr]")

where bb is the hex value for the blue component etc.

For example:

call winopt@("%pl[colour=#FF0000]")

for blue etc.

It's a little more tricky if the colour is "dynamic". For example if the colour has components R,G,B then you would need something like...

[silicondale]

Paul - many thanks for that. Certainly goes some of the way towards what we need, especially your 'dynamic colour' workaround. Ideally we should be able to attach a different colour to each individual point, but this is certainly a start. Could of course split the data into thousands of separate one-element arrays each with its own colour, but that wouldn't really be workable with %pl as it is!

By the way, I have been using winop@ but this is the first time I have seen winopt@ - can you point me to any documentation, please?

Odd that you use #bbggrr - the standard that I think is more commonly used (such as in HTML coding, for example) is #rrggbb

[PaulLaidler]

winopt@ was just my typing error. It should be winop@.
I am guessing that #bbggrr is somebody's standard. Is it not HTML?

[silicondale]

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:

[PaulLaidler]

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.

[silicondale]

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]

[Kenneth_Smith]

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

[silicondale]

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.