On Fri, Jan 25, 2013 at 7:37 AM, Branko Čibej <br...@apache.org> wrote:
> On 21.01.2013 21:08, Benson Margulies wrote: > ...>> > >> I am referring to this discussion http://s.apache.org/MUZ > > Well, that clear enough, even if it is a typical example of how our > > founders yell at us but we have no mechanism to channel those yells > > into concise, unambiguous, documentation. > > Per haps off-topic ... but I fail to see how "source release" is > ambiguous or not concise. > > Unless the Java world has a different definition of "source code" than > us stuck-in-the-mud plodders, and it's only considered binary once it's > been JIT-compiled. :) > It isn't necessarily ambiguous when applied to code, but there is a different case when applied to models or parameter settings. For instance, commons match has polynomial coefficients embedded in code that approximate certain functions. These are the results of computations done using other systems and the source code and the data used in those other computations are not included in the released code, only the parameter values are. This same sort of thing applies here except that the model in question has a much larger set of values and is being packaged in a binary, inspectable format. Would your opinion change if the model were expressed in a textual model? Would it matter that the textual model is too large and obtuse to usefully inspect? What about a hypothetical case where the model is derived from the explosion of a nuclear bomb? Would the release of the numbers require the inclusion of a suitable bomb design so that everybody could replicate the derivation?
