On Fri, Oct 28, 2011 at 07:20:34AM -0700, Phil Steitz wrote:
> >>>> [...]
> >>>> BoundedPoint. As I said, this is what I tend to do at the moment, but
> >>>> I have mixed feelings about this solution vs. passing 3 double[]. Any
> >>>> thoughts about this side question?
> >>> On the principle, you are right of course.
> >>> But I'm not sure that we gain much by adding this layer of data
> >>> encapsulation, because having a single array (instead of three) is not
> >>> enough to prevent a dimensionality error: indeed, the arrays dimension
> >>> must
> >>> match the expected argument of the function, and this possible mismatch
> >>> can
> >>> only be detected later, when the function is called (within the
> >>> "doOptimize"
> >>> method).
> >>>
> >> OK, that's a fair point.
> >>
> >>> To be completely safe, we would have to introduce an additional method
> >>> ("getDimension") in the "MultivariateFunction" interface. [But this has
> >>> the drawback that it reduces the generality of this interface.]
> >>>
> >> I'm certainly not claiming that such a method *should* be added, but
> >> may I ask why you think it reduces generality? I guess you are
> >> thinking of generic multivariate functions, with unspecified number of
> >> arguments (like sum(), product(), ...), but this could be handled by
> >> returning eg a negative value. Again, I'm not claiming anything, I'm
> >> just wondering (actually, wondering if what I did was wrong --or not
> >> so good--, in a project I'm working on at work...).
> > Both ways can be used and both are either good or bad depending on
> > context. We probably all have this kind of problems all the time. As
> > Apache Commons Math is a rather low level component in a complete
> > software stack, as many users are still used to non-object languages
> > (Fortran and C mostly), and as it is a library with many different users
> > and use cases, using very generic primitive arrays seems fair at this
> > level. For a dedicated application, using specific objects is better.
> >
> > One reason I prefer primitive objects for low level components is that
> > most of the time you already need to do some mapping from your
> > domain-specific objects. With primitive arrays, you may simply rely on
> > passing references to existing internal data structures and avoid
> > copying them back and forth all the time, which is cumbersome, adds
> > management code, and may impact performance in iterative algorithms.
>
> +1
>
> Phil
Just for the record, my proposal to stick with 3 arrays (instead of one of a
type like "BoundedPoint[]") is based solely on design consistency, not on
the assumption that it is more efficient, which it is not in fact.
Indeed, the arrays must be copied anyways for safety reasons. Thus, with
the proposed interface: 3 copies; whereas, with an immutable "BoundedPoint"
approach, only 1 copy would be necessary.
Additionally, the accessors, like "getStartPoint()", which are also used by
the subclass to access the data stored in its parent, are public. Thus for
the same safety reasons, they return a copy of the array: 3 more copies.
Hence, at the minimum (usage within an optimizer subclass), there will be 6
array copies for the "primitive" approach, but only 2 for the "BoundedPoint"
approach.
Regards,
Gilles
> > [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
