[Kst] kdeextragear-2/kst/kst

[Barth Netterfield]

It is a very tricky problem!

I do not want to limit the dynamic range one can plot over unnecesarily, but, 
the label problem has to be fixed...

A good usage case to think about (one we face often) is - we are plotting 
time_t on the x axis, and are zoomed into a x range of 200ms.  So basically, 
the X axis as it is now is completely useless, though at least we can see the 
data.

One thing I saw somewhere for this situation was:
the value for Xmin is displayed to full precision at the left side of the 
plot, below the axis label line, then the relative offset from XMin is shown 
at each major tick mark.

+0		+0.05		+0.10		+0.15		+0.20
1064757578.752				(Time)

We could move to this notation automatically if we hit the dynamic range 
limit.

cbn

On August 4, 2004 05:29 pm, Andrew Walker wrote:
> The ideal solution would be to limit the zoom range to what can be
> encompassed by the labels. Most architectures have 14 signifincant figures
> for doubles, while the labels give (at best) 9 significant figures.  Thus,
> at first glance, limiting to 9 sig. figs. would seem appropriate.
>
> However, this zoom range would change depending on the value that we are
> zoomed around. Thus, if the user is zoomed in to the minimum range
> permitted near 0.0 this would then be less than the minimum zoom range near
> 10.0. So scrolling around would present problems, unless we dynamically
> change the zoom range as the user scrolls (probably not desirable).
>
> The current code is better than it was, but far from ideal. Suggestions are
> welcome.
>
> ---------- Original Message ----------------------------------
> From: George Staikos <staikos at kde.org>
> Date:  Wed, 4 Aug 2004 13:02:23 -0400
>
> >On Tuesday 03 August 2004 22:36, Andrew Walker wrote:
> >> CVS commit by arwalker:
> >> Fix for 86524.
> >>
> >> -#define X_MIN_DIFFERENCE 0.000001
> >> -#define Y_MIN_DIFFERENCE 0.000001
> >> +#define X_MIN_DIFFERENCE (MINDOUBLE*10.0)
> >> +#define Y_MIN_DIFFERENCE (MINDOUBLE*10.0)
> >
> >  I'm not sure that this can be correct anywhere except around 0.0. 
> > MINDOUBLE is defined to be the smallest value represented by double.
> >
> >  The zoom logic looks like this:
> >
> > if (ymax_in > ymin_in + Y_MIN_DIFFERENCE) { // only accept new range if
> > valid YMax = ymax_in;
> >    YMin = ymin_in;
> >    return true;
> >  }
> >
> >   However floats are not evenly distributed.  This means that while the
> >difference between 0 and [first_positive_neighbor_of_0] is MINDOUBLE,
> > further out it could be very many times MINDOUBLE.
> >
> >--
> >George Staikos
> >KDE Developer			http://www.kde.org/
> >Staikos Computing Services Inc.	http://www.staikos.net/
>
> ________________________________________________________________
> $0 Web Hosting with up to 120MB web space, 1000 MB Data Transfer
> 10 Personalized POP and Web E-mail Accounts, and much more.
> Get It Now At www.doteasy.com
>
>
>
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst