Re: Wrong plotting of csv data

Just to note I've just implemented an option which treats blank lines
in csv data files as data items, and automatically fills them with NaN
values. This should fix the problem above.

Jeremy

Re: [PATCH/RFC] Optional use of PyMinuit for fitting

On 21 December 2010 00:58, Benjamin K. Stuhl <bks24@...> wrote:

>  Here is a patch that optionally uses PyMinuit
> (http://code.google.com/p/pyminuit/) to do fitting rather than the
> current simple L-M routine. Minuit's great advantage is that it provides
> high-quality nonlinear error estimation as well as the more standard
> covariance matrix-based error estimates.
>
> The patch is probably a bit ugly right now, in that it might be worth
> wrapping most of the code that adapts to Minuit up in a utility module,
> but the larger reason this patch is an RFC is that PyMinuit is GPLv2 only.
> Veusz is GPL v2 or later, so the licenses are entirely compatible -- but
> using PyMinuit would mean that binary releases of Veusz would effectively
> be GPLv2 only.

Thanks for the patch. As long as it is optional, this should be fine.
I think the minuit fitting should be in its own function however - I
can have a look at that.

In the longer term I think the fitting probably belongs in its own
dialog box to make it easier to visualise the error bars, etc.

It might also be good to have an option to use scipy for the fitting
too, but I don't know how well that compares to pyminuit numerically
(the license is less strict of course).

Jeremy

[PATCH] support multi-line texts for plot keys

Hi all,
  Here's a patch which enhances the Key widget to do proper layout when
the key texts are longer than one line. The layout system tries to keep
the overall box as small as possible while still using as many columns
as the user requested. (IOW, it will stretch out the layout to fill the
last N columns even if everything could be fit into fewer. This is
important if, say, you have 4 items and you want 4 columns, even though
one of the items is two lines tall and so all four items would fit into
a 2x3 layout...) I also added a setting to control whether the key
symbol is aligned to the first line of the text, the center, or the last
line of the text.

The patch passes some manual torture testing, including a few pathological
orderings that I could think up. I've attached a sample file which shows
the new layout abilities.

I've attached the patch, since I don't trust my webmail to not mangle it.

Regards,
-- BKS

_______________________________________________
Veusz-discuss mailing list
Veusz-discuss@...
https://mail.gna.org/listinfo/veusz-discuss

Re: [PATCH] support multi-line texts for plot keys

And here's a version of the patch with the debugging prints removed...

Regards,
-- BKS

On Wed, January 12, 2011 13:10, Benjamin K. Stuhl wrote:
> Hi all,
>   Here's a patch which enhances the Key widget to do proper layout when
> the key texts are longer than one line. The layout system tries to keep
> the overall box as small as possible while still using as many columns
> as the user requested. (IOW, it will stretch out the layout to fill the
> last N columns even if everything could be fit into fewer. This is
> important if, say, you have 4 items and you want 4 columns, even though
> one of the items is two lines tall and so all four items would fit into
> a 2x3 layout...) I also added a setting to control whether the key
> symbol is aligned to the first line of the text, the center, or the last
> line of the text.
>
> The patch passes some manual torture testing, including a few pathological
> orderings that I could think up. I've attached a sample file which shows
> the new layout abilities.
>
> I've attached the patch, since I don't trust my webmail to not mangle it.
>
> Regards,
> -- BKS
>

[PATCH] bug fix: actually support \_ et al. in text strings

Hi all,
  It turns out that \_ and \^ do not render at all in veusz SVN; the
attached patch fixes that. It turned out to be simplest to modify the
render tree construction to execute symbol substitutions at the same
time as scripts and commands, since the two-pass substitution meant that
(originally escaped) carets or underscores tended to later get
re-interpreted as script commands... I also added another character,
\backslash, since there doesn't seem to be any way to currently put a
literal backslash in a text field. Manual testing seems to indicate that
the text rendering is now correct, including reasonably pathological
cases like "a\\\backslash\__\^^\dagger".

I've attached the patch, since I don't trust my webmail to not mangle it.

Regards,
-- BKS

_______________________________________________
Veusz-discuss mailing list
Veusz-discuss@...
https://mail.gna.org/listinfo/veusz-discuss

[PATCH/RFC] feature: add a picker (aka data reader) tool

Hi all,
  The attached patch implements a picker (aka "data reader" in
Origin-speak) tool. This is much deeper into the Veusz codebase than
I've gone before, so please look at it in some detail -- there may be
better or more idiomatic ways of doing things than what I've written.
  The patch implements data reading only for the PointPlotter, but it
should be easy to extend it to other widgets as well: they just need to
implement pickPoint(self, bounds, x0, y0, distance='radial') and
pickIndex(self, bounds, index). The first is used for mouse-picking, and
locates the closest point to (x0,y0), while the second is used for
keyboard navigation to provide an idea of 'next' and 'previous' points.
(It may be necessary at some point to make the index be entirely under
the control of the widget ala QAbstractItemModel rather than a simple
integer, but not yet...)
  In terms of testing, I've tested it on a bunch of the files in examples/
and used it in day-to-day use for a couple of days.

I've attached the patch, since I don't trust my webmail to not mangle it.

Regards,
-- BKS

_______________________________________________
Veusz-discuss mailing list
Veusz-discuss@...
https://mail.gna.org/listinfo/veusz-discuss

Re: [PATCH/RFC] feature: add a picker (aka data reader) tool

Thanks for the patch. I'm travelling on business at the moment so it
may be a little time before I can look at it.

Jeremy

Re: [PATCH/RFC] feature: add a picker (aka data reader) tool

On Thu, January 20, 2011 03:42, Jeremy Sanders wrote:
> Thanks for the patch. I'm travelling on business at the moment so it
> may be a little time before I can look at it.

That's fine; I've been looking at how to extend it to other widgets, and I
think some refactoring may be in order...

Regards,
-- BKS

Re: [PATCH/RFC] feature: add a picker (aka data reader) tool

Hi all,
  Here's a patch series with a, I think, cleaner implementation than the
previous version. I've extended it so that PointPlotters,
FunctionPlotters, Fits, NonOrthPoints, and NonOrthFunctions are all
usable with the tool, and without much code duplication.

The patch series is attached. (Hurrah for git-svn for making it easy to break
the patch into small enough pieces to hopefully be reviewable!)

Regards,
-- BKS

_______________________________________________
Veusz-discuss mailing list
Veusz-discuss@...
https://mail.gna.org/listinfo/veusz-discuss