On Tue, Jun 12, 2012 at 01:14:40PM +0200, Sébastien Brisard wrote:
> 2012/6/12 Gilles Sadowski <gil...@harfang.homelinux.org>:
> > Hello.
> >
> >> > [...]
> >> > I agree.
> >> >
> >> >>
> >> >> This does not solve the whole issue, however, because if the default
> >> >> entry is zero, its sign is lost, and {finite value} / {zero} is of
> >> >> undetermined sign. Any idea regarding this point?
> >> >
> >> > I guess that we could also keep a flag for the sign.
> >> >
> >> Do you mean that the default value would be +0 or -0, in some zero
> >> entries would be stored?
> >
> > I didn't get the end of the sentence.
> >
> Yes, something got lost in translation...
> In your solution, some zero entries would be stored, while others
> wouldn't. This is slightly inefficient memory-wise.
>
> > Anyways, what I meant is indeed to be able to specify that the default zero
> > is negative (so that "v / zero" has the correct sign).
> >
> >> Or do you mean to store the sign of each zero
> >> entry, which is slightly less efficient than the present
> >> implementation, but would work OK?
> >
> > No.
> >
> >> These signs could be stored in very
> >> compact form (as bits), as they need only seldom be retrieved.
> >
> > I strongly prefer a "boolean" unless you can devise a way to perform
> > calculations that strongly benefit from bit manipulation.
> >
> > Anyways, let's not try to re-invent the wheel...
> >
> I fully agree. We could also opt for a less correct, but more
> efficient solution: we do not store the sign of zero, and return NaN
> each time v / zero occurs. The result should be NaN anyway, because
> its sign is undecidable. This specificity would be clearly stated in
> the javadoc. What do you think?
We had this sort of discussion with the "Complex" class, where there are
such issues as "standard" vs "correct" vs "documented" etc. E.g. some
computations return "NaN" where it should be "infinity" (or vice-versa, I
don't remember exactly). See MATH-667:
https://issues.apache.org/jira/browse/MATH-667
Maybe that we must be guided with some use-cases for this class.
Maybe in actual uses, the problems discussed here do not appear, and any
additional check would destroy the usefulness of this class in such cases
(just a wild guess). Maybe that we should drop support for sparse vectors!
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
