incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@apache.org>
Subject Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release
Date Fri, 25 Jan 2013 01:19:15 GMT
On 25.01.2013 01:50, Ted Dunning wrote:
> On Fri, Jan 25, 2013 at 7:37 AM, Branko Čibej <brane@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?

In cases like this one, it would seem reasonable for the source code to
refer to those models and computations, which presumably anyone can then
reproduce to their own satisfaction. This is unlike compiled code in
that compilation results are notoriously hard to reproduce exactly,
because they depend on many factors that are usually hard to document,
let alone reproduce. I'd expect a mathematical model, no matter how
large, does not suffer from such ambiguities (and shut up, Gödel).

However, that's beside the point, because ...

> 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?

... the issue is not about the exposing all the knowledge that goes into
writing the code, but to expose the code itself so that it can be
reviewed for, e.g., back-doors and other security issues. Neither of
your examples is relevant.

-- Brane


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message