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? Sébastien > Regards, > Gilles > >> [...] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
