> > [...] > >> The reason that I wanted to point out the top coding was that I > >> thought it might be possible results that were equal, but had > >> different internal representations could be returned over the > >> interval (-1E-9, 1E-9), where the actual value is close to but less > >> than 1. This could effect computations involving the returned > >> values. I have not been able to demonstrate this (and suspect that > >> I may in fact be misreading the JLS on this issue - i.e., on method > >> return you have to map to the standard value set, so returned values > >> have to have the same internal representation), so I am fine leaving > >> out the reference to the cut point. > > Do you mean the numbers representation used inside the CPU? I think that > > this is beyond the scope of a Java library. > > It would be relevant if method return values were not required to be > among the standard value set (the JLS does not actually say this, > but I suspect it is true. Maybe someone who actually knows can > educate me). The spec allows JVMs to use extended value sets > internally. What is required is that equals works as an equivalence > relation over whatever value set is used internally, with > equivalence classes equal to the values in the standard value set, > with the one exception that -0, +0 are different values, but in the > same equivalence class (i.e. equal). If method return values were > not forced to be in the standard value set, it could happen that > values that were equivalent under equals (mapping to the same > standard value) but different in storage could be returned and > reused.
How can I look at these values? > That could result in subsequent computations using the > values diverging (in the non-top-coded case). I can't demonstrate > this in the present case, so either it does not happen or my > understanding of what is legal internally is incorrect (could well > be the case). > > When it comes to top-coding (especially around 0 and 1), I always > like to document when I do it in numerical algorithms, because > otherwise I am (as we are here) counting on categorical statements > about value sets / error propagation in every execution environment > that the code is expected to run under. Looks safe enough in this > case, and this discussion has gone on too long already, so I will > drop it. I think that the current contents of "Sinc.java" should be fine for everyone now. All the information is there, in one form or another. Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
