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 

Problems with %pl
Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
DanRRight



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

PostPosted: Fri Oct 25, 2019 5:59 am    Post subject: Reply with quote

Looks like you are right, Ken. Interesting that Y values are not changed...May be it is good to preserve X values just because SAVE was used above but i have no opinion at this point. Sometimes subroutines return completely destroyed initial data (like Gaussian solvers for example).

Good that this demo exposed additional problems but actually i was hunting different problem this demo does not exactly exposes: after few clicks on redraw the left Y axis numbering gets shifted to the left. This demo shows that but it could be caused by the different problem (like with this LOG scale of X values)

My initial problem i was tried to made reproducer for actually used linear scale! In this case there is no such devastating disaster like in the demo above. And the use of simpleplot_update@ i also used for different reason: to clear the surface for the new plot. May be i used it incorrectly. Is there specific function which can clear the plot ? Then at least one simple problem could be solved (we have few more though we will discuss later in the next messages).
In short:
1) CLEAR_WINDOW@(ihandleOfWindow) where handle is from %hw does not work
2) CLEAR_WINDOW@(ihandleOfPL) where handle is from %`pl does not work
3) CLEAR_SCREEN@ works but wipes out everything including axis etc leaving only the plotted curve and the legend.
The only which works is simpleplot_update@ but it moves axis numbering way to the left side if you use it
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Sun Oct 27, 2019 12:53 am    Post subject: Reply with quote

right back when native %pl was introduced I remember thayìt the user plot data was required to be input as the log of that data.
Paul quickly changd it.
Presumeably this bug is related to something which wasn't modified as a result of that U-turn.
native %pl needs a robust set of test examples to use as QA tests.
_________________
''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
DanRRight



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

PostPosted: Sun Oct 27, 2019 8:17 am    Post subject: Reply with quote

Best QA is a lot of users, the more the better. Are you guys using native PL ? If not yet i will be very angry at your stupidity which caused me a lot of lost time. Despite some minor problems it is already has great plotting capabilities. Soon you will see another top journal publication ("Nature") made with both MATLAB and Clearwin

Yes, most probably native PL modified internally X and Y values for log plot but by some reason did not recover the original Xs. Would be better if %pl was keeping the original X values intact.

Also does native PL provide the way to find the values of Xmin and Xmax it uses on the plot (and same for Y) ? This is important because it does not matter what start and end values of user's X are, the plot will use other, "good looking" numbers for the start and end. After that to place, say, a bullet on the axis user will not know its exact pixel (ix,iy) position on the screen because these values are taken only from "call get_plot_point@(Xmin, Ymin, ix, iy)", or i miss something ? I made a color bar near right Y axis but due to that effect this bar is permanently jumping little bit together with the plotted data overwriting sometimes the axis itself Smile
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Oct 28, 2019 11:37 am    Post subject: Reply with quote

Please see item 415 in cwplus.enh...

Quote:
415] A new routine PLOT_REDRAW@ has been added to the ClearWin+ library. This looks and works like SIMPLEPLOT_REDRAW@ but the
new routine must be used in place of SIMPLEPLOT_REDRAW@ when using logarithmic scales with the native %PL and where the plot
data has changed.


Also search for PLOT_REDRAW@ on this forum.
Back to top
View user's profile Send private message AIM Address
DanRRight



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

PostPosted: Tue Oct 29, 2019 8:23 am    Post subject: Reply with quote

Thanks, the plot_redraw@ makes the program do not crash.
Also it makes the clear %pl screen (for new update of the plot) even with linear plot, not just LOG like the 415 cwplus.enh tells which is good.

Unfortunately this did not help me to find the problem when i try to dynamically add/remove the legend on the top of the %pl plot for the second time (first appearance of the plot looks OK) causing the Y axis numbers to shift to the left (as well as X numbers a bit shift too).

On the smaller extracted demo all works fine though and i still can not find the bug. Seems my idea of integration everything into the large do-everything user-friendly and nice looking code for easier use of all the resources of the code is wrong. The debugging becomes living hell. I spend all my 24/7/365 time on debugging. All serving subroutines like plotting have to be independent (or very very primitive) despite the data to feed them will be very large. Lego blocks idea with elementary subprograms easily removable seems is the only way.
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Thu Nov 07, 2019 11:44 pm    Post subject: Reply with quote

Dan wrote ...
Quote:
causing the Y axis numbers to shift to the left (as well as X numbers a bit shift too).

can you post a coupe of plots before/after Dan so we can see what you mean

thanks JohnS
_________________
''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
DanRRight



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

PostPosted: Fri Nov 08, 2019 7:25 am    Post subject: Reply with quote

Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Fri Nov 08, 2019 4:19 pm    Post subject: Reply with quote

Something that struck my eye:

In both, the tick for 75 at the upper left corner is not quite aligned with the top frame line. This is in contrast with the other tick marks such as 60, 45, etc., which are nicely centered on the faint grid lines.

There is a small triangle at the origin. Does that have any significance?
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Fri Nov 08, 2019 7:33 pm    Post subject: Reply with quote

After i apply draw_characters@ which plots the text string "Before" or "After" on top of %pl plot the Y numbers and a bit X one too shift to the left

As to tiny triangle or sometimes square in the zero position of axis X and Y - this is small bug of %pl we pointed out few times before. This definitely has to be fixed by SFrost.

This so annoyed me that I extracted this part but the damn devilry thing disappeared and did not allow me to catch the problem so far. So what I often do is I create the %pl plot with shifted numbering, make a screenshot and photoshop the image moving numbers back as well as edit this tiny triangle or box in the corner. "Before" part of this plot above is exactly photoshopped part forgetting only to remove the triangle

My suggestion is to ask Paul to allow multiple title legends instead of just one. That will prevent us hacking with draw_characters@ when adding text on top is needed

By the way when I make the plot for the first time or close and reopen it again all looks OK. The shift appears when I add draw_characters@ text on top of already existing plot. I realize that %pl may not like dynamic updates in this case but it's so convenient to place numerous buttons and radiobuttons on the same window as %pl for adjusting the plot without closing it and plotting again. I already do that 1000 times per day

As to "In both, the tick for 75 at the upper left corner is not quite aligned with the top frame line" - this does not matter actually, it does not have to align. It may look a bit nicer in this specific case if it aligned though
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Tue Nov 12, 2019 12:55 am    Post subject: Reply with quote

Here is what ideal %pl should allow. Google public data plot. All dynamically changeable, plots, axis units, limits. All visually with the click. There are different types of plots, just click around.

Place the entire link into your browser, usual way of showing links does not work. Click on Switzerland or USA and watch magic. Do not worry for safety, this is Google, because if you do not trust Goggle then better do not use internet at all

https://www.google.com/publicdata/explore?ds=d5bncppjof8f9_&met_y=ny_gdp_pcap_cd&idim=country:AZE:GEO:TUR&hl=en&dl=en#!ctype=l&strail=false&bcs=d&nselm=h&met_y=ny_gdp_pcap_pp_kd&scale_y=lin&ind_y=false&rdim=region&idim=country:RUS:GRC:GBR:USA&ifdim=region&hl=en_US&dl=en&ind=false
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Tue Nov 12, 2019 8:10 pm    Post subject: Reply with quote

I think the 'mis-alignmnt' of the upper frame border with the '75 tick' is just a drop off in that the bottom of the line appears to be aligned with the centre of the tick mark whereas it should be centred on it.
Remember it's not an axis as such, it's a frame border.
(in this conteìxt it could be argued that it should have an option to change it's thickness/colour/style independent of the actual axes in order to distinguish it)
So, Maybe it's deliberate design intent in order not to obscure plotted curves which terminate at the maximum value? Only Paul knows.

The 'triangle' at the origin I see as an arrow because the short straight line also present is not the standard tick thickness.
Maybe it's something Paul included at some point because it appears to point neither to the centre of the Y-axis line nor the edge of it.
I'd guess it's 2 pixels wide (the y-axis) (?) and it points to the half of the line thickness which actually coresponds to the data x='0 (for a 2-pxel line it can't be centred on any particular data, obviously.
There may have been several of these used in Paul's debigging process and one was 'left in' by accident.

What is odd, and I've noticed this before I think on an example a long while back (trawl through the Native %pl posts) is that the first tick mark on the upper border is much longer (x2 ?) than the rest !!!!

Details, whih as Dan said 'don't really matter' ... except they do ... from an aesthetic and confidence point of view.

The fundamental problem (shift of axes labels on adding a DRAW-CHARACTERS user_title is befudddling indeed as to what could cause that.

My Conclusion: native %pl still in need of consolidation for these and several other glitches previously highlighted and which still need adresing (that SF enigma machine that Paul's mentioned previously not working to it's true potential ?)

Dan, there are indeed workarounds which have been introduced historically to resolve some similar glitches in an economic manner, like the offsets, but that's no real solution because if say you plot 10 plots of data you have no idea in advance if you need to hand-edit a number of them subsequently.
In any case Paul's often posted that they are intended for 'small' adjustments. I'd personally say the shifts you experience are not 'small', but it depends what the definition of 'small' is in the context of their design intention, and only Paul knows that.

You could, in theory, supress the tick labels (did Paul introduced an option for that as well as axis captions ? I can't remmìember) and then use user-defined DRAW_CHARACTERS calls to re-generate them .... except ..... all the parameters to correctly and accurately position them are not available. A point I raised in asking in a now long-ago post if it was possible to have access to the end-of-tick tick positions, tick label fonts & sizes, etc .... .
here's a link to that post:
http://forums.silverfrost.com/viewtopic.php?t=3747&postdays=0&postorder=asc&start=0
http://forums.silverfrost.com/viewtopic.php?t=3747&postdays=0&postorder=asc&start=0
Although Paul was clear back then though on that post that suggestions such as the fully interactive response of plots, which you mention above ith the google example, are way out of scope of his thinking ... at the time.
I imagine that the enigma machine didn't kick in then and hasn't since.
_________________
''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 "


Last edited by John-Silver on Tue Nov 12, 2019 10:29 pm; edited 1 time in total
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Tue Nov 12, 2019 8:20 pm    Post subject: Reply with quote

Dan,
I'd be interested to know what additional effect you get if you make the %pl window re-sizeable and re-size it)
This type of shift (in particular for the y-axis, but also for x-axis sometimes) occurs on re-sizing.
Maybe when the draw characters is used there is some re-sizing of the graphic area which results in this similar phenomenon, maybe of the same cause.
Do you notice any visible change in the size of the graphical (plot) area when the refresh for the user-defined characters takes place ?
i.e. is it the labels whcih move or is it the plot axes and frame ?
_________________
''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
John-Silver



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

PostPosted: Tue Nov 12, 2019 10:14 pm    Post subject: Reply with quote

Based on the plots you posted above you seem to have supressed the axes captions - if you include those are they affected in the same way as the tick labels ?
_________________
''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
DanRRight



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

PostPosted: Tue Nov 12, 2019 10:31 pm    Post subject: Reply with quote

John,
1) If you can make a small demo reproducing shift of numbering when you dynamically add and remove draw_character@ after you already created the plot -- that would be great

2) I initially did not understand your need with the additional functions to find exact position or tics etc. Now i see the reasons for that. The %pl for example sets initial or final value for X by its own way ignoring user defined numbers. This is good and right thing to do but we do not know in advance or after plot was done how to find these new X and Y limits values to define the correct scaling for user other needs. The tic marks for example will be impossible to do manually if you do not know initial and find values of X or Y.
The position of caption will be impossible to place in exact place of the plot etc

3) As i described it above the user has little control over exact numbers for start and finish of X and Y axis which sometimes is needed

4) I do not know if this is already done but in my version of software if you set the step of placing tic marks this has no effect.

But in general with the user adjustments, settings and manipulations i almost always succeed to make professionally looking plots. If SFrost would listen users more actively and communicate with them more often my wish of making pro plots from the first attempt with the minimal programming (ideally in one single line of Fortran source text) would be already realized.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sun Dec 22, 2019 6:17 am    Post subject: Reply with quote

New release is soon coming. Curious was this most annoying defect fixes already ? Or is there a workaround against of it ? You can not photoshop it after saving. Probably applying another bug mentioned above (placing characters on top) it is possible to move numbering to the left but i am not sure it always will work. In demo reproducer i was unable to repeat it

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 -> Support All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4  Next
Page 2 of 4

 
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