forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Native %pl
Goto page Previous  1, 2, 3 ... 22, 23, 24, 25, 26  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
John-Silver



Joined: 30 Jul 2013
Posts: 858

PostPosted: Sun Jan 28, 2018 11:23 pm    Post subject: Reply with quote

Paul:
Quote:
There are no plans to make winop@ work like winio@ in the sense of taking additional arguments.


not sure what you mean by 'additional arguments' I was talking about being able to write, for example ....

Quote:

max_x_value=7710
call winop@ ('%pl[x_max=max_x_value]')


which I think was silicondale's point.

Is that what you mean .... capability to parse variables as argument values ?
Is it actually implement for winio@ at present then for all arguments currently defined ?
I remember seeing the example in the manual which by its presence seemed to imply not, if I remember correctly, hence the need for formatted writes to generate the whole winio(/winop) statement.


Last edited by John-Silver on Sun Feb 04, 2018 3:52 am; edited 1 time in total
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 858

PostPosted: Sun Jan 28, 2018 11:42 pm    Post subject: Reply with quote

xcellent video Ken, even if the subject matter didn't turn yours truly on it is very professionally done.
Your trouble now is your colleagues will be asking for more !
I'm tempted to guess which part of Scotland your from based on the accent but I won't risk it ! Suffice to day it's not Glasgee ! LOL
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5438
Location: Salford, UK

PostPosted: Mon Jan 29, 2018 9:18 am    Post subject: Reply with quote

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:

Code:
call winop_int@("%pl[symbol_size]", ival)
Back to top
View user's profile Send private message
silicondale



Joined: 15 Mar 2007
Posts: 209
Location: Matlock, Derbyshire, UK

PostPosted: Mon Jan 29, 2018 9:37 am    Post subject: Reply with quote

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.
_________________
(just call me Steve)
Back to top
View user's profile Send private message Visit poster's website
John-Silver



Joined: 30 Jul 2013
Posts: 858

PostPosted: Wed Jan 31, 2018 11:17 am    Post subject: Reply with quote

Gosh ! that's impressive Steve.

What's interesting is that it's not 'cumulative' all this spyrographing is it.
It starts off so with the 129 and 130 cases but the 256 case has white space' at the top beteėween the labelled howėrizontal axis anfėd the etching.
... and there's not even the 'under-greens' of the first 128 plots either (you can still see there is green under the skqibblings though).
All very odd.

I also notice that the Y-axis label is oddly positioned too, right towqards the top. Maybe this is the axis label gremlin re-appearing again.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1864
Location: South Pole, Antarctica

PostPosted: Wed Jan 31, 2018 3:26 pm    Post subject: Re: Reply with quote

PaulLaidler wrote:
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:

Code:
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 Smile

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 Smile
Back to top
View user's profile Send private message
silicondale



Joined: 15 Mar 2007
Posts: 209
Location: Matlock, Derbyshire, UK

PostPosted: Wed Jan 31, 2018 7:10 pm    Post subject: Reply with quote

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 !
_________________
(just call me Steve)
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5438
Location: Salford, UK

PostPosted: Wed Jan 31, 2018 7:24 pm    Post subject: Reply with quote

I have increased this maximum to 255.
Back to top
View user's profile Send private message
silicondale



Joined: 15 Mar 2007
Posts: 209
Location: Matlock, Derbyshire, UK

PostPosted: Thu Feb 01, 2018 12:36 am    Post subject: Reply with quote

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?
_________________
(just call me Steve)
Back to top
View user's profile Send private message Visit poster's website
John-Silver



Joined: 30 Jul 2013
Posts: 858

PostPosted: Thu Feb 01, 2018 4:24 am    Post subject: Reply with quote

255 ?
not 256 ? .... in fact why not to say 1028 ?
I thought in a previous comment way back (when it was discovered the limit was about 10 I think) it was going to be limitless ? ... or was that for the number of points per curve ? I forget
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5438
Location: Salford, UK

PostPosted: Thu Feb 01, 2018 12:22 pm    Post subject: Reply with quote

%pl has its own legacy database and it is natural to keep its size within reasonable bounds.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 858

PostPosted: Sat Feb 03, 2018 10:24 am    Post subject: Reply with quote

Paul wrote:

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


ah ok Paul - I remember you commented previously that it's still got some 'links' to the original Simpleplot %pl then in some ways.

Let's hope for Steve that his client doesn't increase problem size requirements to 512 curves tomorrow then ! :O)

I guess this is a limit any user of native %pl needs just to be aware of.

I've spotted that there are in fact a number of fundamental omissions in the current documentation (at least in the on-line version) that maybe users need to be made aware of via some small changes:

1. the limit on the number of curves which can be plotted (N-GRAPHS option) is not documented at all - it should be added next to the description of the option N_GRAPH.

2. the limit on the number of points per curve which can be plotted is not documented anywhere (that I can find). In fact neither is the fact it has to be supplied ! (see 3. below)

3. The basic definition of the %pl format code is lacking : mention of N, the number of points, x and y (the vectors to be plotted) !!!!
One only finds it in examples but it should be included on the description of %pl no ?
The current mention in the description of the the option [X_ARRAY] is somewhat late in the proceedings , and somewhat confusing.

4. The fact that options have to be entered for each curve to be plotted is less than clearly documented imo. As well as the current mentions in the descriptions of options, and under some examples , it should be clearly stated under the main %pl format code description too.
For example it could be like:
"If multiple curves are to be plotted, any other options that are defined:
- if defined once will apply to ALL curves being plotted
- may be defined seperately and differently for each curve being plotted
by including the relevant option(s) definition(s) a number of times,
the order of their definition being in the order of the curves plotted

e.g. include here a comprehensive example>
"

Note - for sonsideration at a more 'startegic' documentation update point:
I personally still get confused by mention of ARRAY when in fact VECTOR is meant !
Similarly for 'graph(s'.
A graph is the entire graphical object, including frame, axes, labels and data plotted.
The lines which are plotted are for me better referred to as 'curves' (either straight line or curvy !).

Note:-
IMO the %pl format description should be more like:-

winio@('%pl[options, without X_ARRAY]', width, height,N,x_start,x_inc,Y_vector)

or , if X_ARRAY option, is used:

winio@('%pl[options, incl. X_ARRAY]', width, height,N,X_vector,Y_vector)

with the appropriate description of each argument and specification of types below each.


Last edited by John-Silver on Sat Feb 03, 2018 10:43 am; edited 1 time in total
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 858

PostPosted: Sat Feb 03, 2018 10:41 am    Post subject: Reply with quote

While perusing the %pl documentation I find ...
In the on-line documentation at least :-

%pl - SIMPLEPLOT Graphics Region
http://silverfrost.com/ftn95-help/clearwinp/formats/_pl.aspx
Data that is real must be passed as double precision values despite the fact that the SIMPLEPLOT library uses only single precision arithmetic.

then 'later' we see ...

A simple example
http://silverfrost.com/ftn95-help/clearwinp/simplepl/asimpleexample.aspx
Following the usual ClearWin+ convention, all real data is passed as DOUBLE PRECISION values. However, SIMPLEPLOT uses single precision, so data values should not exceed the single precision range.

So, if raw data is in double precision range does it have to be explicitly truncated first §?
And, what exactly happens if the data passed exceeds the single precision range then ? ...
Is it just truncated automatically, and if so is I assume a warning is produced?
or would it just cause a cacastrophic 'devilry' failure at runtime ?
Back to top
View user's profile Send private message
silicondale



Joined: 15 Mar 2007
Posts: 209
Location: Matlock, Derbyshire, UK

PostPosted: Sat Feb 03, 2018 11:59 am    Post subject: Reply with quote

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.
_________________
(just call me Steve)
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5438
Location: Salford, UK

PostPosted: Sat Feb 03, 2018 1:24 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page Previous  1, 2, 3 ... 22, 23, 24, 25, 26  Next
Page 23 of 26

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group