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

Hi,
My experience with change_arg/3 so far,
one that is akin to nb_linkarg/3 from SWI-Prolog
is as follows:
- The lack of purity in that there is one
   more side effect, is compensated in that we
   don't need a FFI and dozen foreign function
   implemented gadgets, like this gadget,
   termed "dedicated low-level implementation".
 > 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).
- Instead of million different gadgets, there
   is only one gadget, which is change_arg/3 itself.
   One can integrate it with the Prolog garbage collection.
   I could demonstrated the same that change_arg/3
   can fully participate in minor and major garbage collections
   of the Prolog system using a write barrier.
- Having only this gadget, one can implement nb_XXX
   datastructures such as findall/3 bag. The big advantage
   since it will rely on Prolog garbage collection, is
   that no slow setup_call_cleanup/3 is needed. You can
   complemently forget about an infrastructure for this
   monster, its all superseeded by garbage collection,
   you also don't need to call some free()
- You can spin it further and implement more nb_XXX
   datastructures profiting from the same advantages
   again, this is ongoing work right now. Example
   datastrutures are library(util/hash) and the
   brand new library(util/tree).
- You can spin it even further to the ultimate goal.
   You can then use these nb_XXX datastructures to
   have memory savy aggregates. And thats one of the
   plateaus we want to reach. We want to compete
   with Pandas from Python and participate in Billion
   Row Challenges.
Bye
Mild Shock schrieb:

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?