forums.silverfrost.com

PaulLaidler · Posted: Fri Jan 26, 2018 4:17 pm Post subject:

Maybe you just need [x_array].

silicondale · Posted: Fri Jan 26, 2018 5:04 pm Post subject:

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

PaulLaidler · Posted: Sat Jan 27, 2018 8:42 am Post subject:

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.

LitusSaxonicum · Posted: Sat Jan 27, 2018 10:11 am Post subject:

Paul,

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

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 !!

Kenneth_Smith · Posted: Sun Jan 28, 2018 9:05 pm Post subject:

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

PaulLaidler · Posted: Mon Jan 29, 2018 9:18 am Post subject:

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:

silicondale · Posted: Mon Jan 29, 2018 9:37 am Post subject:

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.
_________________
(Steve Henley)

DanRRight · Posted: Wed Jan 31, 2018 3:26 pm Post subject: Re:

silicondale · Posted: Wed Jan 31, 2018 7:10 pm Post subject:

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 !
_________________
(Steve Henley)

PaulLaidler · Posted: Wed Jan 31, 2018 7:24 pm Post subject:

I have increased this maximum to 255.

silicondale · Posted: Thu Feb 01, 2018 12:36 am Post subject:

Hi Paul - and many thanks. That makes my life much easier Very Happy

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?
_________________
(Steve Henley)

PaulLaidler · Posted: Thu Feb 01, 2018 12:22 pm Post subject:

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

silicondale · Posted: Sat Feb 03, 2018 11:59 am Post subject:

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.
_________________
(Steve Henley)

PaulLaidler · Posted: Sat Feb 03, 2018 1:24 pm Post subject:

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.