OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] chart:interpolation

On Mon, 2011-11-07 at 13:36 -0700, Patrick Durusau wrote:
> Andreas,
> On 11/03/2011 04:36 PM, Andreas J. Guelzow wrote:
> <snip>
> > I wasn't as confused as I thought.
> That's always a comfort. ;-)
> > A small bug in the current
> > development version of Gnumeric hid some of the interpolation methods
> > implemented there.
> >
> > So I will be proposing a few more methods:
> >
> >   * Cubic spline interpolation with parabolic limits.
> >   * Cubic spline interpolation with cubic limits.
> >   * Cubic spline interpolation with fixed derivatives at both ends.
> >
> > Rather than adding more attribute values to the chart:interpolation
> > attribute, I believe it would be cleaner (and more in the spirit of the
> > already existing chart:spline-* attribute) to use secondary attributes
> > chart:spline-limits, chart:spline-limits-start, chart:spline-limits-end
> > that would modify the cubic-spline interpolation already provided in ODF
> > 1.2.
> To confirm before you enter them in JIRA:
> chart:spline-limits
> chart:spline-limits-start
> chart:spline-limits-end
> Valuetype = ?

Until the proposal is finished, I don't think I am sure which value
types will be the most appropriate. chart:spline-limits-start/end are
probably going to be expressions that shall evaluate to a number.
chart-spline-limits will be some kind of enumeration. 
> What do we have to reference in current 20:26? (I know it is probably 
> obvious but we should not simply say: apply to 20:26 as appropriate.)

In 20.26 this would not affect the text for the step functions but it
will change the limit handling in the cubic splines.
> On prose for these attributes, let's avoid:
> > 20.51 If the chart:spline-resolution attribute has value 1 this
> > is identical to the chart:interpolation attribute value none.
> That is really awkward and I am not altogether sure it is necessary.

I am not sure why that sentence is preceded by "20.51" (that's the
section describing  "chart:spline-resolution".) The purpose of that
sentence is intended to provide a definition for b-spline (and
cubic-spline) in the case of the resolution 1. Of course one could omit
that sentence since in the case resolution == 1 the described method
yields the same result as using method none.

> Unless we mean to bind the value of chart:spline-resolution to 
> chart:interpolation? That is if chart:spline-resolution > 1 then 
> chart:interpolation *cannot* have the value of none?
> > Gnumeric also provides:
> > * Closed Bezier cubic spline interpolation.
> > Since this is not really a proper "interpolation" method, I am not sure
> > this would be appropriately added here unless other implementations
> > provided a similarly closed interpolation.
> >
> Other implementers? Anyone?

My comment wasn't quite correct. The description of the cubic-spline
method reflects the implementation in LibreOffice/OpenOffice: If the
first and last data point are the same then a closed cubic spline is
created otherwise an open one. In Gnumeric one would need to specify
whether one wants a closed or open cubic spline, there is no automatic
guessing of whether a closed or open spline is used. (Note that an
"open" spline with the first and last data point the same simply has a
corner at that point. This is something that may be expected by a user
and provides a continuous behaviour as the last and first data point
approach each other.)

So I will make a proposal that allows both behaviours to be specified.


Andreas J. Guelzow, PhD, FTICA
Concordia University College of Alberta

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]