commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: svn commit: r1179928 - in [...]
Date Sun, 09 Oct 2011 20:31:29 GMT
> > [...]
> >> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message