@friguzzi These would be perfect to provide baselines for an application of slipcover to ecological data that I am currently working on. Unfortunately, the example on cplint@SWISH throws exceptions:
In logistic regression, the goal example_log_r(100,Coeff) leads to procedure 'maplist(A,B,C,D,E,F)' does not exist,
while in linear regression, the goal example_lr(100,Coeff) leads to an instantiation error thrown by

mcintyre:mc_sample_arg_raw(noise(1,_1804,5),1,_1790,[_1810]) at /home/mlunife/.local/share/swi-prolog/pack/cplint/prolog/mcintyre.pl:2354

Good question. The compiled expansion of library(apply_macros) allows for maplist/N with arbitrary arity. It used to do its job whenever loaded. Now it depends on the flags optimise, optimise_apply and apply_macros_scope.

Now it gets a little hard. In my view, library(apply_macros) is a temporary crude alternative for inline and (thus) should not have any effect besides performance.

Of course, we can add a maplist/6, which seems to solve your problem. This too is not satisfying IMO (unless there is some agreement about an upper bound).

Also unsatisfactory, Iām tempted to say that the best solution, at least for now, is to add your own copy/pasted version of maplist/6 to your source.

If one is not limited by the sandbox such as with SWISH then adding maplist with more arguments is easy. In the case noted using SWISH, for me it seems that maplist/N with N upto 9 would be of value.

Thanks a lot!
A couple of points I noticed:
It seems as if the concrete way the matrix calculation is split up in the logistic regression iteration step can be unstable with cleaner input (for instance, setting noise to 1 leads to a zero-divisor error).
I forked a version at https://cplint.eu/p/my_logistic_regression.pl
that uses a different split and avoids that issue.

Also, I do get coefficient values widely different from [1,2,3], but I am not sure why that is.