Waste of EU money / bread and butter of statistics (Was: failure of formal verification [software.imdea.org])

Hi,
Spain is one of the main recipients of EU recovery funds,
with a total of 163 billion euros ($178 billion) earmarked
for the country, approximately half in grants and the rest
in loans. It has already received 37 billion euros.
Madrid and software.imdea.org is no exception. Probably
the same disaster as the Valencia floods. The money
is just siphoned into some crooks pockets. The biggest
crooks are at the moment ALP & friends,
just publishing a series of failure reports. Every
paper just reports some problems, never solutions.
Most recent cringe example:
BoostRLR: The beauty of Prolog for statistical
relational learning
https://www.informatik.uni-wuerzburg.de/fileadmin/10030600/2024/KI_2004_paper_174.pdf
What the fuck does this mean:
 > In SWI-Prolog, this can rely on an efficient specialised
 > implementation of aggregate_all(count,_,_), while we provide
 > a dedicated low-level XSB implementation in a count module
 > that we include with our program, courtesy of David S.
 > Warren (personal communication).
Why is change_arg/3 not common among Prolog systems.
Why do we deal with aggregates like we are still in
stone age. Aggregates are a well known discipline
of database technology.
Why only aggregate_all/2 and not also a memory savy
solutions of aggregate/3. Aggregates are the bread
and butter of statistics.
Bye
Mild Shock schrieb:> Results of a fuzzer comparison:
 >
 > library(nb_rbtrees) from 2014 in SWI-Prolog:
 >
 > /* SWI-Prolog 9.3.14 */
 > ?- L = [16,10,12,13,15,5,11,8,14,1,7,6,3,2,4,9], rb_new(T),
 >       (member(X,L), nb_rb_insert(T, X, true),
 >       fail; true), rb_display(T, 0).
 > $BLK 12-true
 >     $RED 5-true
 >        $BLK 2-true
 >           $BLK 1-true
 >              $NIL
 >              $NIL
 >           $BLK 3-true
 >              $NIL
 >              $RED 4-true
 >                 $NIL
 >                 $NIL
 >        $BLK 10-true
 >           $RED 7-true
 >              $BLK 6-true
 >                 $NIL
 >                 $NIL
 >              $BLK 8-true
 >                 $NIL
 >                 $RED 9-true
 >                    $NIL
 >                    $NIL
 >           $BLK 11-true
 >              $NIL
 >              $NIL
 >     $BLK 15-true
 >        $BLK 13-true
 >           $NIL
 >           $RED 14-true
 >              $NIL
 >              $NIL
 >        $BLK 16-true
 >           $NIL
 >           $NIL
 >
 > On the other hand the rules by Okasaki give a
 > different resulting tree, which is better balanced,
 > has less overall depth and doesn’t have a root 12,
 >
 > rather the root 8. Implementation based on change_arg/3:
 >
 > /* Dogelog Player 1.2.5 */
 > ?- L = [16,10,12,13,15,5,11,8,14,1,7,6,3,2,4,9], tree_new(T),
 >     (member(X,L), tree_set(T, X, true),
 >     fail; true), tree_display(T, 0).
 > $BLK 8-true
 >     $BLK 6-true
 >        $RED 3-true
 >           $BLK 1-true
 >              $NIL
 >              $RED 2-true
 >                 $NIL
 >                 $NIL
 >           $BLK 5-true
 >              $RED 4-true
 >                 $NIL
 >                 $NIL
 >              $NIL
 >        $BLK 7-true
 >           $NIL
 >           $NIL
 >     $BLK 12-true
 >        $BLK 10-true
 >           $RED 9-true
 >              $NIL
 >              $NIL
 >           $RED 11-true
 >              $NIL
 >              $NIL
 >        $RED 15-true
 >           $BLK 13-true
 >              $NIL
 >              $RED 14-true
 >                 $NIL
 >                 $NIL
 >           $BLK 16-true
 >              $NIL
 >              $NIL
 >
 > I think Okasaki is the more common red-black
 > trees implementation, if I am not mistaken Java’s
 > method fixAfterInsertion() from the class TreeMap,
 >
 > does also implement the Okasaki rules. Bug or
 > Feature that SWI-Prolog doesn’t use Okasaki?