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 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: Thu Jul 18, 2019 6:42 pm    Post subject: Problems with %pl Reply with quote

These problems are well known but are not fixed for a long time probably because were not articulated by users clearly. To demonstrate them i made the program where slider just linearly increases value Y. The most important is the problem, or better say, the bug #1.

Code:
module mod1
use clrwin
integer, parameter:: N=30
Real*8 X(N),Y(N), Slider
contains
integer function cbSlider()
do i=1,N
  X(i) = i
  Y(i) = Slider*X(i)**3 * exp(-X(i)/3)
enddo
call simpleplot_redraw@
cbSlider=2
end function
end module
!.........................................................
winapp
use mod1

i=winio@('%ww%fn[Tahoma]%ts%bf&', 1.8d0)

i=winio@('%pv%pl[x_axis="Angle",y_axis="Intensity",native,framed,axes_pen=2,frame_pen=2,width=2,&
&n_graphs=1, x_array,scale=log_linear, Y_min=1.e-1]%ff&',740,540,N,X,Y)

i=winio@('%cn%50^sl&', Slider, 1d0, 20d0, cbSlider)

i=winio@('%lw%es',ilw)

i=cbSlider()

end


1) The displayed automatic Y axis maximum does not match the peak Y data value correctly

2) Y axis title centering mechanism is malfunctioning

3) Left Y axis minor ticks mark length is too small. Major tick mark length is adjustable by user but minor one is fixed. Here is better just to increase minor mark default length 50-70% which will fit most of users or even better also introduce the option for adjusting their length which will fit all 100% users

3a) Bottom X axis tic marks better do one sided (in this example better to be outside the box). Even better solution to fit all users would be to have the options of placing them In, Out or Both sides.

4) Left Y axis numbers are too close to axis tick marks.
If increase major ticks length the position of numbers does not change and they can hit each other. Minor increase of distance would solve the problem for most of users.

5) In case of LOG scale it is better to use homogeneous "scientific" numbering like this 10^-3, 10^-2, 10^-1, 10^0, 10^1, 10^2, 10^3. If Y does not go off humanly acceptable range 1/1000 to 1000 it is also possible to use "engineering" format 0.001, 0.01, 0.1, 1, 10, 100, 1000. Mixing them together possible but not particularly nice looking. Better though to introduce these engineering and scientific numbering options to chose from.

6) It is better to set the default values for all lines width to at least 2 (i even use 3 here, my monitor is 4K: axes_pen=3, frame_pen=3, width=3), not the current 1 pixel default. If there would be a need for 1 pixel widths (i doubt about that because it is aesthetically unacceptable) the masochistic users can change the defaults Smile - see comparison below. Bug #1 and mentioned minor defects are also clearly visible


Last edited by DanRRight on Fri Jul 19, 2019 2:56 pm; edited 8 times in total
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Fri Jul 19, 2019 11:21 am    Post subject: Reply with quote

Hi Dan,

Re: "humanly acceptable range 1/1000 to 1000" - nice one and good way to put it.

In my field, a parameter named 'hydraulic conductivity' (colloquially 'coefficient of permeability') may take values between 10^-1 and 10^-14 m/s or perhaps even less, which is probably the biggest log range anywhere.

Eddie
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Fri Jul 19, 2019 11:21 am    Post subject: Reply with quote

Hi Dan,

Re: "humanly acceptable range 1/1000 to 1000" - nice one and good way to put it.

In my field, a parameter named 'hydraulic conductivity' (colloquially 'coefficient of permeability') may take values between 10^-1 and 10^-14 m/s or perhaps even less, which is probably the biggest log range anywhere.

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



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Fri Jul 19, 2019 1:16 pm    Post subject: Reply with quote

Biggest range anywhere? Not so, if you consider electrical resistivity (in Ω·m):

Superconductors: Zero
Metals : 1E−8
Insulators : 1E+16
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Fri Jul 19, 2019 1:45 pm    Post subject: Reply with quote

When is a conductor not a conductor? When it's an insulator. Not the same thing.
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Sun Jul 21, 2019 2:23 am    Post subject: Reply with quote

Also can be added to Dan's list of niggly bugs:-
- the labels at the beginning/nd of the x-axis scales are missing
- the tick labels are not always centred on the tick marks !
_________________
''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 Jul 21, 2019 5:47 am    Post subject: Reply with quote

Agree. Little bit not centered tics and numbers are sometimes visible on X axis with one and three digit numbers. On my example above they are i think OK. It may depend on the font used. Specifically with Y axis. So i did not include that till the better times when all will be more clear.

No number at the beginning could be not a bug and is actually dictated by the data (my X numbers in the example above start with 1). I see other plots now open on my screen, and they all have proper numbers at the beginning of X axis started with zero.

I think i included most of your other suggestions posted before over last year in the list above
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 6:55 am    Post subject: Reply with quote

Quote:
No number at the beginning could be not a bug and is actually dictated by the data (my X numbers in the example above start with 1).


Yes, and the maximum of data is 30.
BUT .... the scales themaelves go from 0 to 31 !!!
So, 0 should be marked at left end of scale.
In this particular case, imo the selected scale should go to 32 (little impact on graph 'white space'.

In fact, imo, there should be an option to a) either go EXACTLY to the extent of the data ( 1 to 30) or b) go to the 'next regular spacing (0 to 32).
Currently it appears the algorithm results in something inbetween (0 to 31) !

Dan, yes, I thnk you've got quie a few of past 'bugs'/less-than-optimal-design observations from previous discussions.

A couple of otable oversights include:
1) the completely irregular scales calculated when the range of the data doesn't fall on 'regular numbers' and the resulting tick spacings become somewhat 'arbitrary'.

The rule is simple - scales tick spacings should be only multiples of either 1,2,4,5, or 10 (*10^n ... where n depends on the overall range of the data).
Where the selection of the spacing distance (1,2,4,5,10) should be selected baased on having a sensibl optimal number of spacings, which again depends on the data range but also whether or not the scalig is specified to cover exactly the data range or 'the next nearest spacing' (which as mentioned above should be an option).
It tějust needs a clever algorithm to achieve this. All other plotting facilities I've come across seem to incorporate these fundamental design points.

Without knowing the ins and outs of exactly how it is currently coded of course it's difficult to assimilate how easy/hard this might be in the current scenario.

... also, there have been observed some significant buggy-behaviour relating to re-sizing of a %pl plot sindow where there appears to be a limited taking-int-consideration of margins/labels-to-ticks spacings, etc....

I'm sure Paul hasn't forgotten these and will dig them out (from the x3 Native %pl posts (see notes (1*), and others (e.g.see notes (2*))) as and when and if there is further work initiated.


*** CHANGES made 22/07/2019


Notes:
(1a) 'Native %pl' - http://forums.silverfrost.com/viewtopic.php?t=3357
(1b) 'Native %pl' - http://forums.silverfrost.com/viewtopic.php?t=3427
(1c) 'Native %pl' - http://forums.silverfrost.com/viewtopic.php?t=3619

(2a) 'Native %pl - Bug #101 (Minor) - Axis Captions Positioning'
http://forums.silverfrost.com/viewtopic.php?p=27303#27303

(2b) 'native %pl --> User-drawn Captions - Info. Reqd.'
http://forums.silverfrost.com/viewtopic.php?t=3747
(this even more applicable related with the new TEX capability
recently introduced
- to help corectly position user-drawn axis captions/labels)

(2c) 'Native %PL - User-spec. x-axis Ranges'
http://forums.silverfrost.com/viewtopic.php?t=3769

.... and there are others


_________________
''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 Jul 23, 2019 4:23 am    Post subject: Re: Reply with quote

John-Silver wrote:
BUT .... the scales themselves go from 0 to 31 !!!
So, 0 should be marked at left end of scale.


Looks like you are right. I added change to start X from zero
Code:
  X(i) = i-1

and added
Code:
link=lines
but X axis still did not start numbering with zero.

I understand this was design feature not a bug. To kill all birds with one stone. Because there exist situations when X and Y axis go in the middle of plotting surface and there will be no place for zero.

Agree that giving the user option to do numbering of end points would be reasonable design wish. At least no one would blame designers for that Smile

Would be nice if designers asked users for priorities what's most important to add or to fix, and what will go for an icing on the cake.
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 5:59 pm    Post subject: Reply with quote

Less than Optimal design choěce = bug ?

Not achieving an optimal design is not a crime, but not striving for it is.

Discuss.
_________________
''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: 7916
Location: Salford, UK

PostPosted: Fri Jul 26, 2019 7:58 am    Post subject: Reply with quote

Here at Silverfrost we have an ancient typing machine, salvaged from Bletchley Park. When you type in a bug it transfers the input to a "todo" list. If the input is not a bug, sometimes it transfers the input to a "wish" list, other times it just discards the input.

It saves me a lot of time and effort.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



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

PostPosted: Fri Jul 26, 2019 11:28 am    Post subject: Reply with quote

As a Bletchley Park enthusiast, I'd like to know does the machine have a keyboard (thus requiring repunching, which we all know is error-prone) or does it accept Hollerith cards or punched tape?

Apropos the latter two solutions and your admission re discarding, wouldn't it be more politic perhaps to have blamed a 'hanging chad' ? Or a punch card jam? After all the punch machines alone would be getting on for 80 years old.

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



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

PostPosted: Fri Jul 26, 2019 7:12 pm    Post subject: Reply with quote

Quote:
other times it just discards the input.


... that just means you have to replace those 'p' and 'l' keys Smile

that model is overall a bit of an enigma has it has an unexplained time shift key which drops stuff to the bottom of the todo list based on pre-programmed preferences.
It nearly lost us the war that defect on that model, you need to re-adjust the settings.
_________________
''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: Thu Oct 24, 2019 1:42 pm    Post subject: Reply with quote

More problems. After adding caption to %pl i found that axis numbers all got shifted to the left. Trying to corner this i found that possible reason is in simpleplot_update@ and made this demonstrator. Meantime also found other problems easily visible in this demo. This damn simpleplot_update@ is a source of subtle worms for entire 20 years i use it. Hope it will be finally fixed. To see the bug click on Redraw several times. Also this demo can demonstrate that moving gridline after i=winio@('%pl...') will cause problem with gridlines too.
Code:
   module mod1
   use clrwin
   parameter (N=5)
   real*8 X(N), Y(N)
   Data X/1e1, 1e2, 1e3,  1e4, 4e5/
   Data Y/2.2, 66, 8333, 1111, 777/
   save
   contains

   INTEGER FUNCTION redraw () 
    CALL simpleplot_redraw@()
    redraw = 2
    end function redraw
   end module
!................................
   Program bug333
   use mod1

   i=winio@('%fn[Tahoma]%bf%ts&',2.3d0)
   CALL winop@("%pl[gridlines]")
   call winop@("%pl[axes_pen=3,frame_pen=3,width=3,x_axis='X Axis Title',y_axis='Y Axis Title']")
   i=winio@('%ww%pv%pl[native,framed,x_array,scale=log_log,N_GRAPHS=1]%ff&', 925,700, n, X, Y)
   i=winio@('%sf%cn%^bt[Redraw]&', Redraw)
   i=winio@('%es')
   end
Back to top
View user's profile Send private message
Kenneth_Smith



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

PostPosted: Fri Oct 25, 2019 12:50 am    Post subject: Reply with quote

Ouch Dan, that is a major problem with x axis data. After redraw, the value that was previously stored in X is returned as log10(X).

Code:
   module mod1
   use clrwin
   parameter (N=5)
   real*8 X(N), Y(N)
   Data X/1e1, 1e2, 1e3,  1e4, 4e5/
   Data Y/2.2, 66, 8333, 1111, 777/
   save
   contains

   INTEGER FUNCTION redraw () 
   integer i
    write(6,*)
    write(6,*) "before redraw"
    write(6,*) "============="
    do i = 1, N
    write(6,*) i, x(i), log10(x(i))
    end do
    CALL simpleplot_redraw@()
   
!    do i = 1, N                ! Uncomment these three lines to "fix" the x data issue               
!      x(i) = 10.d0**x(i)       ! F77 style
!    end do

!    x = 10.d0**x               ! Or uncomment this single line, F90 style

    write(6,*) "after redraw"
    write(6,*) "============"
    do i = 1, N
    write(6,*) i, x(i), log10(x(i))
    end do
    redraw = 2
    end function redraw
   end module
!................................
   Program bug333
   use mod1

   i=winio@('%fn[Tahoma]%bf%ts&',2.3d0)
   CALL winop@("%pl[gridlines]")
   call winop@("%pl[axes_pen=3,frame_pen=3,width=3,x_axis='X Axis Title',y_axis='Y Axis Title']")
   i=winio@('%ww%pv%pl[native,framed,x_array,scale=log_log,N_GRAPHS=1]%ff&', 925,700, n, X, Y)
   i=winio@('%sf%cn%^bt[Redraw]&', Redraw)
   i=winio@('%es')
   end
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 -> Support All times are GMT + 1 Hour
Goto page 1, 2, 3, 4  Next
Page 1 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