From: Dmitry A. Kazakov on
On Sat, 5 Jun 2010 20:41:47 +0000 (UTC), tmoran(a)acm.org wrote:

>>> The word "model" is key. It is meaningless to talk about whether
>>> something, software or hardware, *is* stochastic - but one can observe
>>> whether a stochastic *model* of the system is helpful or not.
>>
>> Hmm, I think a physicist would strongly disagree with that. AFAIK, there is
>> no working deterministic models of quantum processes.
> A fair number of physicists have tried to find a hidden-variable
> deterministic version of quantum mechanics. In the meantime, engineers
> quite successfully used the probabilistic model to build working devices.

Yes, the modern understanding is that things are inherently random.

>> 1. Confidence has nothing to do with probability. It is an absolutely
>> different model of uncertainly. That returns us to the square one.
>> Confidences and probabilities are incomparable.
>>
>> 2. Your confidence describes you, it does not the program. It fact, it is
>> like - I give my word, it works. Fine, but why anybody should trust my
>> word?
> We fundamentally differ. I use statistical decision theory, which
> takes costs of outcomes and *estimated probabilities* of outcomes, to make
> decisions.

Ah, I thought you meant "confidence factors", but it seems that you did
"confidence intervals"?

> All I have is my best estimates, ie, confidence levels. I
> don't know the "absolute probability" of an event, and if you define that
> by frequency of occurrence, you really need to wait till the end of the
> universe to finally nail that down.

No problem, confidence interval is perfectly OK. The probability itself
tells nothing about next occurrence.

The problem is that to apply this theory to software you need maybe,
imaginary space of elementary outcomes (independent, complete etc). I don't
see any of that in the software. It is a fundamental issue. What is the
probability that the 100_000th decimal position of Pi is 5? 0.1? Rubbish,
it is not a random variable!

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on
On Sun, 06 Jun 2010 05:46:29 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Sat, 05 Jun 2010 21:59:58 +0200, Dmitry A. Kazakov
> <mailbox(a)dmitry-kazakov.de> a écrit:
>> BTW, this is my concern about software certification procedures. It fact,
>> they act quite as you suggested. They certify programmers, they don't the
>> software.
> What is this named “software certification” then ? Are you sure you are
> not talking about some non-glorious example only ? Or is it really common ?

I had talks with certification authority guys, and my overall impression is
what I said. But you better ask people who have more experience with that.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on
On Sat, 05 Jun 2010 21:14:53 +0100, (see below) wrote:

> I've never understood the objection to "all this instantiating every where".
> How much effort is a line or three of boilerplate code?

Geometrically exploding...

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Yannick Duchêne (Hibou57) on
Le Sun, 06 Jun 2010 09:25:59 +0200, Dmitry A. Kazakov
<mailbox(a)dmitry-kazakov.de> a écrit:
>> I've never understood the objection to "all this instantiating every
>> where".
>> How much effort is a line or three of boilerplate code?
>
> Geometrically exploding...
As this is about genericity, I would like to understand: what kind of
curve is one “Geometrically exploding” ? I could not find a simple
explanation on the web and don't have anything in my background about it..

I remember in the past (past year I think), we talked around generics
hierarchy and generic packages as formal parameters. You had warned about
possible complexity explosion in this area: is this about the same ?

--
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
-- i.e. forget about previous premises which leads to conclusion
-- and start with new conclusion as premise.
From: Dmitry A. Kazakov on
On Sat, 5 Jun 2010 14:16:42 -0700 (PDT), Maciej Sobczak wrote:

> On 5 Cze, 14:59, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
> wrote:
>
>> As for different types of the real and imaginary parts, it would make
>> little or no sense because you can "rotate" numbers by multiplying them to
>> exp(j*angle).
>
> Nobody said that such a "rotation" must make sense in every single
> application domain. If it does not make sense in a given domain, then
> it does not have to be supported.

No, in this case the domain is set, it the complex field.

> I can perfectly imagine a domain where only the addition/substraction
> operation for complex and multiplying/dividing complex by scalar are
> necessary.

Yes, that would be a different model of complex numbers. But the same
argument applies to any numerical type. There may be cases where
floating-point is unsuitable.

>> So the complex space must be isotropic
>
> So it does not have to be and Ada, as a language that promotes careful
> selection of types for the given purpose, would be more consistent by
> allowing separate base types for both components.

Polar representations were far more useful, or complex intervals
(rectangular, elliptic), to name some.

> Otherwise the model is simplified. Not necessarily bad, but certainly
> simplified.

You cannot have a model for each case. This is why I keep on arguing for a
better type system, where you could define your own models implementing
abstract classes like, in this case, complex field.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de