Well, I didn't have any evil intentions, honestly.

I just wanted to, once again, say that the design of an API in the
form of several generators for a few pre-defined distributions seems
to me to be too specific to be really useful for a general user, but
not rigourous enough for mathematical applications.

It's just strange to see a library providing a "normally-distributed
random number" generator, but not an actual function to compute the
value of a gaussian bell in, i.g. that particular points where the
generator has produced some samples. An inverse value is extremely
often needed in statistical analysis.

Furthermore, a normal distribution spans all the real line from -inf
to inf. How does this work with Scheme numbers? I'm no expert, but I'd
expect an infinite amount of corner-cases in practice.

The (gsampling) function, e.g., produces a uniform combination of
distributions. What makes the uniform distribution a chosen one? What
about a function (ggsampling integer-generator . v-generator-list) ,
that generates a weight from a generator w-generator and the actual
value from a (seq-ref (integer-generator) v-generator-list). This
trivially generalizes to (gsampling).

Again, introducing a good and carefully designed (preferably, minimal)
statistical framework in such a scientific language as Scheme would be
extremely useful, but I just feel that this srfi is very likely to
cause frustration.

Again, this is just an opinion, I'm not familiar with full context.
Maybe there are some implementation-specific applications that may be
instantly made several times more portable after the introduction of
this srfi (which would be a perfect justification for me), but in its
present shape, I think it is not what I find aesthetically pleasing.
I'm sorry.

On Fri, 17 Jul 2020 at 11:00, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>
> On Thu, Jul 16, 2020 at 7:33 PM Vladimir Nikishkin <xxxxxx@gmail.com> wrote:
>>
>> The code would be just as well perfectly convenient for the user if
>> uploaded to Akku.SCM or snow-fort.
>> They are as portable as portability can be achieved in Scheme, and do
>> not require such a rigourous scrutiny as srfis do.
>
>
> One of the benefits of the SRFI process is that the ideas can get more rigorous scrutiny than a one-person project uploaded to Akku might get.  With the additional scrutiny, we hope that the resulting API will be better, and beyond that, simply more widely agreed upon.  One of the challenges of our field is that everyone wants to design their own API and write their own implementation, and lessons learned by one API and implementation are often missed by another.  SRFIs aren't perfect, but the process does help organize Scheme programmers to build cleaner, more practical code that is also more widely useful.
>
> In the case of this SRFI, in particular, I'm thrilled that we have mathematically sophisticated contributors who can take us far beyond where I, at least, would be able to get on my own.  I'm sure I'm not the only one who will benefit from that expert help.
>
> But thank you very much for bringing up this philosophical point.  Sometimes, it is hard to decide what is appropriate as a SRFI and what isn't, or how far a specific SRFI should go.

--
Yours sincerely, Vladimir Nikishkin