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 - Bug #101 (Minor) - Axis Captions Positioning
Goto page Previous  1, 2, 3  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: 1520
Location: Aerospace Valley

PostPosted: Thu Nov 15, 2018 10:58 pm    Post subject: Reply with quote

Paul, can you post the plot produced from the program after fixing please.
Ta
_________________
''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 Dec 04, 2018 11:42 pm    Post subject: Reply with quote

Paul, you obviously missed my previous comment/request.

Now that 8.4 is out could you generate the fixed plot please.

It's so that I can be sure a couple of other bugs ready to post are not already fixed, in which case I won't waste your time with them.

Ta.
_________________
''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: Sat May 25, 2019 8:47 pm    Post subject: Reply with quote

I finally got round to checking this reported bug had been fixed.

So, after installing v8.4 (Perso) I get ...


The Y-axis centreing is indeed now achieved .


The Y axis no longer TOUCHES the end of the tick label as it previously did !
Additional spacing has now been added.


The X-axis has now been positioned automatically (?) by the program at the bottom edge of the plot area.

Why was this done ? since it should really be optional.

The x-axis label and ticks numbering could/should be placed to the top of the axis could quite easily be achieved.


However, something odd has now happened to the scaling of the Y-axis.

The scaling is fixed in the program to be multiples of 1000 (as on originally generated plot at beginning of this post).

However, now the generated scales are can be seen positioned at 400, 1400, 2400, etc....
Odd. And obviously undesireable.

The same type of undesireable tick locations is, as before, evident on the X-axis also. 3e4, 6e4,9e4 is not exactly a 'useful selection' !
Where do those spacings originate - can't they be made 'regular spacing ?
The answer is obviously 'yes'.
At the moment they are clearlyunuseable !

Not also a couple of things I didn't mention on the original bug report, although they were pretty ovìbvious and I was hoping that they would have been picked up and treated/solved a s a matter of course.
They are still present.
These are:-

Y axis tick labels TOUCH the ends of the tick marks !
There should be spacing.

A +600 tick mark should exist and should be labelled
ùProbably also a '0' labelled tick markat the axes intersection.

What Happens When We Re-scale ?
Rescaling of the plot is still problematic (another not-as-yet-reported bug in relation to this bug post) when the window is re-sized. This type of behaviour has previously been reported - for different problems however, so it's not 'new'.

Strange re-adjustments and resulting overlaps/disappearances of axes captions and tick labels occurs depending on what exactly is attempted.u'll
Have a try and you'll see.

There ya go ... 'more work still needed' is the conclusion.
_________________
''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
PaulLaidler
Site Admin


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

PostPosted: Sun May 26, 2019 6:45 am    Post subject: Reply with quote

John

Can you provide a link to the source code for this sample.
Back to top
View user's profile Send private message AIM Address
DanRRight



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

PostPosted: Sun May 26, 2019 10:59 am    Post subject: Reply with quote

Paul, Source code is on previous page at the beginning of this thread.

I agree with John that numbers and tic marks have some space between. Including the same in LOG plots.

As to choosing good numbers as tic marks - this could be hard to implement. Currently plotter makes reasonable number of tic marks (not too many or too little) and teach it to choose additionally good looking for humans rounded numbers could be daunting task. This may need manual adjustment.

Here also my suggestions which could be easily implemented

1) I'd add also that "framed" part has to automatically take the same line width as other axis have. For it to be 1 pixel wide by default is not reasonable.

2) Can Y-axis numbering position be adjusted manually respect to ends of tick marks in case it is needed?
(I suppose the Y axis caption text will try to position itself centered automatically using available space till possible, but could be also adjusted manually)
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Mon May 27, 2019 5:55 am    Post subject: Reply with quote

Paul,
source code is at the top of this post, on p.1 .

John
_________________
''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: Mon May 27, 2019 6:24 am    Post subject: Reply with quote

Dan,

Paul did say to mention %pl bugs one at a time (which is why i started my personal way of numbering my native %pl bug reporting posts.
But in this case your comments are 100% valid as they're relevant to the curve in hand and could possibly be taken into account at the same time as resolving the ticks proximity issues.
They're also, for the most part, long-standing observations from past posts.

Quote:
1) I'd add also that "framed" part has to automatically take the same line width as other axis have. For it to be 1 pixel wide by default is not reasonable.


I seem to remember you mentioning this before.
IMO there should evntually be an option, either as is at moment or as you say all the same ... or indeed NONE on the top/rh sides ! Everyone has their own personal preference, for different reasons/applications.

Quote:
2) Can Y-axis numbering position be adjusted manually respect to ends of tick marks in case it is needed?


Good suggestion Dan.
This could easily be achieved by making the spacing a user-mofiable parameter. As could the spacing between labels and caption.

Quote:
(I suppose the Y axis caption text will try to position itself centered automatically using available space till possible, but could be also adjusted manually)

The Y axis caption position is already 'manually'-adjustable I believe.
Personally I'm no fan of 'adjustment' and prefer 'placement'.

I made a request a while back on a seperate post to have the possibility to know both: the length of tick marks, spacing between tick mark and label, the font and it's size used for tick marks (to be able to calculate the length of the labels, and the spacing between beginning of labels and the axis cqption.
I think it as put on the wish-list.
With these it would be possible for the user then to accurately 'adjust the position' of user-defined' captions (using DRAW_CHARACTERS after suppressing the automatic captions - as provided for a while ago now).
Which would have to be done 'dynamically' also to cater for window size changes if present.

Of course eventually as well as these spacings the font type and size for labels could be also made parametric.

I think the difficulty (well not difficulty bu more 'fastidiousness' of doing this could be getting it right for window size changing, which already has it's 'challenges' waiting to be ironed out.
'Fastidiousness' of course means time , and hence resources, of both types.
So I guess the wait might be undefineable.
_________________
''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 Mon May 27, 2019 3:22 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: Mon May 27, 2019 7:12 am    Post subject: Reply with quote

Regarding:

Quote:
As to choosing good numbers as tic marks - this could be hard to implement. Currently plotter makes reasonable number of tic marks (not too many or too little) and teach it to choose additionally good looking for humans rounded numbers could be daunting task. This may need manual adjustment.


It's not at all 'daunting, but once again fastidious.
We had a discussion I remember on one of the 'Native %pl' posts (there are 3 posts with exactly the same title) about auto-scaling.

This particular subject probably needs a seperate dedicated post for discussion in order not to divert the present one from it's particular bug-resolving topic. I'll see what I can do.

'Manual sdjustment' may be practical for an individual plot, but if you've got say a dozen , or even 100's to process it becomes impractical/unfeasible to adjust manually imo.

I guess the question for Paul is:
how much effot is required to 'attack' the question of scales ?
is it just a question of plugging in a relevant routine followed by a bit of tweaking ? or is it much more complicated than that ?
I guess what I'm asking: 'is it reasonable in terms of the resources available to you to ask you to consider knocking the scales selection into a more robust state ? ... and if yes, what sort of timescale would it imply ?
_________________
''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: Mon Jul 22, 2019 8:56 pm    Post subject: Reply with quote

I'm bumping up this post as the outstanding issues here are similar and complementary to those raised by DanRRight here:-
http://forums.silverfrost.com/viewtopic.php?t=4046
_________________
''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
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed Jul 24, 2019 8:15 am    Post subject: Reply with quote

Just out of interest, are these issues resolved withing SimDem? The examples seem to indicate that they are.

If so, (a) why not use it, (b) whoever's fixing %pl knows where to go for the answers !

If not, then ?

Eddie
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Jul 24, 2019 8:23 am    Post subject: Reply with quote

Eddie

At the moment there is no overlap in this sense. SimDem provides a set of routines that call into the ClearWin+ library.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed Jul 24, 2019 8:46 am    Post subject: Reply with quote

Hi Paul,

What I meant was that the algorithms might be there.

Alternatively, John & Dan could use it, perhaps by extracting the bits they need.

Eddie
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Thu Jul 25, 2019 6:29 pm    Post subject: Reply with quote

Paul wrote:-
Quote:
At the moment there is no overlap in this sense. SimDem provides a set of routines that call into the ClearWin+ library.


Just to clarify for Eddie's benefit, Simdem/Simfit is a completely seperate plotting code.
It makes no calls to %pl (of any flavour) .

It includes a 'ClearWin generated' front end (i.e. menus) and that's where the link to ClearWin which Paul refers to comes in.

Therein lies the problem in using it, when you call the simdem/Simfit routines you get the menus whether you want them or not.

It effectively creates a seperate SimDem/Fit graphics window with the options for realtime 'interactivity'.

It could suit some peoples needs but for others not.

Bill Bardsley, the SimFit guru deserves more credit than he gets I think just for maintaining it and trying to keep it 'modern and relevant'.

From the examples I've seen the answer to your question Eddie is no, the issues raised for %pl do not occur (because essentually the plotting routines are independently developed over a large number of years.
There could be the odd exception but it's pretty robust.


Of course it has a full panoply of plot types available too, not just 2-D X-Y.
It also has stacks of interpolation and curve fitting routines (it's original moticìvational raison d'etre).

The source code is there freely available for Silverfrost to develop, if the fancy takes one.
It just needs judicious filtering out of the ClearWin front end to leave just the plotting routines.
Morceau de gateau as the french say.

There is only bug fixing support to mere mortals, which is understandable being a Uni originated free-to-aair offering.

Then again SF are not mere mortals are they Smile

I believe there have been one or two organisations (e.g. Salamanca(?) Uni) who have already taken the source code nd developed it to their liking.

I got as far as listing out the subroutine tree for just one of the main plot routines. It's a bit of a redwood because the code is well structured and modulated in lots of subroutines.

Of course, one could end up in a penguin's paradise which would be ok if you use Linux I guess Wink
_________________
''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
PaulLaidler
Site Admin


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

PostPosted: Wed Apr 08, 2020 4:35 pm    Post subject: Reply with quote

The question at the start of this thread was raised in Sept 2018 and I have it on my list of things to look at when I get a moment to spare.

Well I don't really have a moment to spare but I want to get it off my list so here are my thoughts.

First of all, I don't want to get into a conversation on this issue so this will be my only response.

I agree that the native %pl does not respond well to the use of large fonts. However in this program the initial size of the graph is clearly too small for the given font. It is not surprising that %pl has failed to do anything reasonable with this font size in the initial graph size that the programmer has provided.

There are also two heavy demands in this code. 1) The data is not good and 2) a pivot (%pv) is provided.

The native %pl was never intended to be that clever.

I am generally pleased with what users have been able to do with the native %pl whilst at the same time recognising that it is bound to have its limitations.

So in short, I don't propose to make any adjustments based on this sample code.
Back to top
View user's profile Send private message AIM Address
DanRRight



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

PostPosted: Thu Apr 09, 2020 10:03 am    Post subject: Reply with quote

Yes, this data plotted with %pl such way is not looking good, see below again where I compare it one-to-one with Origin. But I propose better solution:

1) make a default not the link=curves like with this example, but link=lines. In this case Paul does not have to do anything today with this specific problem at all

This my suggestion comes from the fact of difficulty to find one universal smoothing solution for all cases, Paul is right here. To find coronavirus cure is easier. Hence if there will be no smoothing in %pl by default at least for a while people will understand that. Straight lines is the only stable method. It works OK for cases where you have many points, not just 3-5 changing wildly like in this example above. This example initially was constructed for using with LOG scales where it looks not that bad. I do not use smoothing in 99% of my plots made in %pl and they often are OK

2) Even more, I propose that Silverfrost to offer everyone to find the problem with the current smoothing algorithm and add any other methods people want

I tried this data set above to plot in ORIGIN plotting software and even this professional app failed with Spline creating total garbage. If also offers smoothing with 2-point Segment, 3-point Segment, B-Spline, Bezier, Step Horiz, Step Vert, Step Center, Straight Line. The Straight Line, Bezier and B-spline plotted something amicable, and last two even looking very nice but look how different they are from just the real data connected with the straight lines! First plot is %pl with default "link=curves", second is Origin:

So there are no universal solution for smoothing but I hope with time there will be offered additional options besides current two. I personally like B-Spline most, it always worked with much less problems than other algorithms if there are no large functional changes

3) Other problems mentioned in this post are purely small adjustments:
- increasing default tic length (specifically with minor tics in LOG scale which can not be increased with additional WINOP )
- add a tiny bit of distance between numbers and tics
- make consistent same width of the whole frame so that an additional WINOP to fix that will not be needed
- make default line widths not 1 but 2 pixels wide
- I do not see any problems with the large fonts here. Actually fonts often have to be like that for the conference presentations.
- The best solution for smoothing in the future when no one will complain is to make smoothing variable: you click on your plot and popping slider allows to adjust smoothing from Straight Lines to say B-spline. This way I do fitting for example. Very handy


Last edited by DanRRight on Thu Apr 09, 2020 10:50 pm; edited 3 times in total
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  Next
Page 2 of 3

 
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