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 ... 23, 24, 25, 26, 27, 28  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
DanRRight



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

PostPosted: Sat Feb 03, 2018 4:45 pm    Post subject: Re: Reply with quote

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


At first glance there is no reason even for more then 4 digits for plotting with all the screens currently are less then 10000x10000 pixels. And the only need to get more then 4 is to have color depth around 8 bits per color for which single precision is enough. Right? Even my own 2D graphics libraries all were single precision by the way by these exact reasons.

OpenGL though from start allowed both single and double precisions I had no idea what for and with time most pros who write the games switched to double precision. When Nvidia started using double precision i scratched my head! The graphics and video were slow, cards expensive, image barely displayed on a tiny windows, and they were making it even slower. 20 years ago I was really surprised why the heck they waste precious resources, degrade speed and double memory requirements. But decades later...remember me and Agustin strongly complained few years back at older %PL design defect for not taking double precision values?

The answer why all graphics utilities must be double precision is universality to accept wider range of input data which unfortunately spreads wildly causing the same damn crashes I hate so much from using spurious large or small numbers and denormals not in the single precision range. The cause of games crashes in the past (remember kids angry yelling?) very often was due to single precision engines. Single precision range became too narrow for broader use of graphics utilities! The same idea was behind the Intel FP processors with their 80 digits -- universality -- because there could easily exist some numerical methods written by any teenager which go to 10^4096 numbers and beyond while still the final result being plotted on 640x480 screen in 2 bits color!

Intel scaled down somewhat from 80bits recently, but at least it improved single and double precision speed making both almost the same. And SilverFrost got down from real*10 to real*8 in 64bit compiler and I now need to rewrite some parts of my code to different methods I did not have yet invented. I'm not asking for 80 digits, this is really rare opulence, but the life demands these 64 bits at least. Universality gives you less headache and much less crashes. Clearly, it is the native %PL which has internally handle interaction with Microsoft 32 bit system by scaling down from more universal 64 bits and take care of potential problems preventing crashes
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Sun Feb 04, 2018 3:51 am    Post subject: Reply with quote

Silicondale wrote:
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.


Yes Steve I realised that, but it doesn't explain the space at the top (between the labelled axis and the first of the black squiggles turning from green to white !!! ??? ... here ....


Yes I) hadn't noticed it was all negative on the scale.
So that means the 'old' bug of centring of the axes subtitles over the whole of the axis range isn't corrected yet.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Sun Feb 04, 2018 4:25 am    Post subject: Reply with quote

Paul wrote:
Quote:
A lot of the information about the native %pl can be found in the cwplus.enh that goes with the v8.20 release.


Not seen that yet - eagerly awaiting Perso version to go v8.2 so I can !
Maybe you could post it for advanced viewing/better understanding ?

and also ...
Quote:
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.


Is there a warning given when this happens ? I assume it's detected when the input values are higher precision than that requested ?


and also ...
Quote:
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.


So as Dan says it's purely for consistency wth overall Clearwin philosophy then that double precision is specified.

I'll put some thought into the >7digits conundrum and get back to you :O)

I'm surprised that for x64 there's any reliance whatsoever on 'SimplePlot database'.
How does it work exactly native %pl and how does it rely exatly on simpleplot formulation ?
Doesn't that restrict it/put it 'at risk' for the future ?


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



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

PostPosted: Sun Feb 04, 2018 12:01 pm    Post subject: Reply with quote

John - I puzzled over the white space at the top in the 256-colours case, as well. But the explanation is quite simple. The plots represent x,y,value where the value is mapped to a colour. The data set is ordered by value, and mapped to colours so that there is (as far as possible) an equal number of points of each colour. In the 128-colour case all of the points are plotted as coloured squares. In the 256-colour case, the first half of the points map to colours 1 - 128. The second half of the points should map to colours 129 - 256 but in fact plot as black squiggles. Most of the high values are at the top of the plot. This plot shows sonar reflections and these are strongest at the top nearest to the sonar pinger. So what should plot as coloured squares near the top of the plot instead gets displayed as curved bezier lines all over the plot since the order of the x,y coordinates is completely arbitrary. You can see what happens in the 240-colour case where the higher values disappear and are replaced by curved lines.

Also showing the colour ramp - the only colours that ever get plotted are those in the left-hand half, blue to green.

I'm not sure why the lines in the 256 case don't go right to the top, but I guess by that stage the system has its knickers so twisted that the bezier curve fitting algorithm is itself struggling.

But why is the default setting black curved lines with no symbol ?
_________________
(Steve Henley)
Back to top
View user's profile Send private message Visit poster's website
DanRRight



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

PostPosted: Sun Feb 04, 2018 9:14 pm    Post subject: Reply with quote

Steve, Without demo I'm always puzzling what is done and what the problem is. Hopefully Paul gets that and will react. But if it looks like not many people are interested the solution may take longer time. In graphics typically always possible to make relatively small demo.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Sun Feb 04, 2018 9:16 pm    Post subject: Reply with quote

Thanks for the explanation Steve.

I think I was thrown by my own (il)logical assumption from the 129 and 130 cases being black lines progressively incrementing from the top and would progressively increase to the bottom.)
The 240 case shows that not to be true

Just thinking about it, Paul has increased to 255 (not 256) so maybe the hint lies therein.
Does 255 plot at the top for example ?

Black curved lines with no symbols is I think the overall default at the start.
A case of <REW> <NO_SAVE>. %pl must be based on betamax technology Wink [this is a joke Paul]
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
silicondale



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

PostPosted: Sun Feb 04, 2018 10:25 pm    Post subject: Reply with quote

John - we don't yet have the 255 limit version: I guess that will come with the next clrwin DLL release. I could do a 255 test but I think it will look very like the 256. Anyway, if I can use a 255-colour ramp instead of 256, not a basic problem. And I guess we have to accept Paul's statement that we are tied to some existing limitations in underlying code - at least for now. A matter of priorities, dependent on how many users want particular upgrades. It's the "art of the possible" and from my own viewpoint I am quite happy for now that Paul has been very responsive and helpful.
_________________
(Steve Henley)
Back to top
View user's profile Send private message Visit poster's website
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Tue Feb 06, 2018 3:53 am    Post subject: Reply with quote

I meant running it with the current version.
My logic being to see if something just 'flipped' the plotting when it turned to 256th curve for some reason. I just picked up on it being 256. Mybe the storgage array indices go from 0 to 255 and not 1to256, something like that, and it was flipping back to 0 which contains ... well I don't know what it would contain.
I seem to remember that's what fortran does when it runs out of arrya , it goes back to the start and carries on reading/writing no ?
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
silicondale



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

PostPosted: Tue Feb 06, 2018 10:00 am    Post subject: Reply with quote

Good point, John. And interesting results. It blows up ! Two plots from two runs of the same program, same parameters, both using 255 colours.



I ran the program several times. Got these two plots, but also two or three times it blew up or hung without producing any plot at all. I guess this is the sort of unpredictable behaviour you might expect when exceeding array limits. Would be helpful, however, to have some check within the %pl coding to prevent it, and instead give some proper error message.
_________________
(Steve Henley)
Back to top
View user's profile Send private message Visit poster's website
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Tue Feb 06, 2018 5:10 pm    Post subject: Reply with quote

Grief ! I wouldn't have expected that !
Good point about the error messages, if any parameter at all is out of it's bounds I'd expect a fatal error (obviously saying which parameter, it's value and the limit value !) and the run to stop.
Might not be so easy with the Simpleplot legacy factor though.

Thanks for taking the time to re-run the code.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Mon Feb 19, 2018 1:41 pm    Post subject: Reply with quote

A minor suggestion.

We have the subroutine get_plot_point@(x1,y1,xx1,yy1) which returns the pixel coordinates xx1, yy1, of the real world data x1, y1.

It would make programming interactively with mouse clicks etc on a %pl graphics area easier if there was a second subroutine which performed the reverse function, i.e. given pixel coordinates xx1, yy1, returns the real world coordinates x1, y1. I know this functionality can be achieved in otherways, but this complicates the programming.

Just a thought.

Ken
Back to top
View user's profile Send private message Visit poster's website
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Mon Feb 19, 2018 2:48 pm    Post subject: Reply with quote

And another suggestion, maybe a way of detecting the first call to the %pl call back function via CLEARWIN_STRING@( STR )

Ken
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Mon Feb 19, 2018 5:10 pm    Post subject: Reply with quote

Ken

The routine that you want is already included but perhaps not yet released.

The clearwin_info@("CALLBACK_REASON") for a %pl callback is "PLOT_ADJUST". I guess that the user's code could flag the first call.
Back to top
View user's profile Send private message AIM Address
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Wed Feb 21, 2018 5:25 am    Post subject: Reply with quote

this 'reverse function has limited useage doesn't it ?
by definition there is rounding involved in any reverse lookup so thre would always be some error.
I'm strìuggling to imagine a practical application of it, although I'm sur there must be one.
Of course if co-ordinate-pairs could be tagged to a particular pixel (or small area around a picìxel) a-la-excel that would be what Ken probably means. i.e. a click on or near an actual data point would give the real co-ordinates)

Of more interest to me would be knowing the co-ordinates of the positions of the extents of the edges of the tick labels, so that user-programmed defined axes titles could be placed without the hit-n-miss of having possibly overlay of title with lables.
I think I mentioned this quite a while back but it got lost amongst all the other to-ings and fro-ings.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
silicondale



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

PostPosted: Wed Feb 21, 2018 11:01 am    Post subject: Reply with quote

Hi, John-S: 30 years ago I implemented an interactive graphics system that did exactly that, all in standard Fortran77. I'll see if I can find the low-level parts of the coding (should still have it somewhere). However, it won't fit easily with %pl because it overlapped a lot with the Simpleplot / %pl functionality. There seems to be a lot of reinventing of wheels, because mine was far from the only package that did the same job.
_________________
(Steve Henley)
Back to top
View user's profile Send private message Visit poster's website
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 ... 23, 24, 25, 26, 27, 28  Next
Page 24 of 28

 
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