@MSGID:
<37516061-91b6-4129-8221-4bdb0fa59f42n@googlegroups.com> 84514ed0
@REPLY: <m2r0njgghs.fsf@logic.at> 0426d38c
@REPLYADDR Mild Shock <bursejan@gmail.com>
@REPLYTO 2:5075/128 Mild Shock
@CHRS: CP866 2
@RFC: 1 0
@RFC-References:
<f4ad7701-cae3-4513-8b8e-a483415c6ad8@googlegroups.com> <977d5e9f-469f-4516-9260-26e917bbec2cn@googlegroups.com>
<142ae65f-61ad-403e-8450-caebfddf6d0an@googlegroups.com> <4e9bf208-0882-4f63-b243-b434f0a1392cn@googlegroups.com>
<3a23c78d-d4a1-472a-a460-776a5ca7d3een@googlegroups.com> <e945e9c8-e72f-41a2-bb06-473d275396c0n@googlegroups.com>
<030ed934-efa4-4a1e-96b4-96f9c5214a6en@googlegroups.com> <db4b30f2-2c33-42f6-9630-2828418aa146n@googlegroups.com>
<868d4f75-c293-4929-83b7-e319f4dba451n@googlegroups.com> <m2r0njgghs.fsf@logic.at>
@RFC-Message-ID:
<37516061-91b6-4129-8221-4bdb0fa59f42n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
One motivation to look at the problem, and to look at the
easier problem with 9 instead 42, is to elaborate a completely
new CLP(FD) solver, that is based on Chinese Remainder Theorem.

Actually I have already a prototype working, the timing was
also already published around 12 months ago. My system was much
faster than SWI-Prolog, since SWI-Prolog is slow with smallints and (^)/2:

Mostowski Collapse schrieb am Dienstag, 20. September 2022 um 20:28:33 UTC+2:
> /* Jekejeke Prolog 1.5.4 */
> ?- modular([15,16], X, Y, Z).
> X = 216, Y = 52, Z = 217;
> X = 52, Y = 216, Z = 217;
> fail.
>
> ?- time((modular([15,16], X, Y, Z), fail; true)).
> % Threads 594 ms, GC 5 ms, Up 591 ms (Current 09/20/22 20:21:30)
> true.
https://groups.google.com/g/comp.lang.prolog/c/mjpxkE3xVYk/m/cn0FICAQAAAJ

So these 594 ms are 10x times faster than the 5.117 seconds from
SWI-Prolog using ordinary CLP(FD). And around 100x times faster than 
the 41.658s from Scryer Prolog. But I didn`t yet publish this new 

CLP(FD) solver, maybe I did some blogging and also some code 
went into comp.lang.prolog here, but its not currently some officially 
released module somewhere. Its also a solver which isn`t based on 

attributed variables per se. It requires that the constraint store is 
re-evaluated with different moduli, so I envision something totally 
new, that drops attributed variables, but nevertheless has a constraint 

store. Attributed variables have become less important. The dis-
advantage of not having attributed variables would be that the 
constraints cannot be used on ordinary predicates. I have no solution 

for the later problem yet, but the figures in the former testing show, 
that the method can be much much faster than ordinary CLP(FD).

Markus Triska schrieb am Donnerstag, 31. August 2023 um 21:20:14 UTC+2:
> Mostowski Collapse <burs...@gmail.com> writes: 
> 
> > /* Scryer Prolog CLP(Z) */ 
 > > ?- time(([X,Y,Z] ins 0..239, X^3+Y^3+9 #= Z^3, label([X,Y,Z]),
fail; true)). 
> > % CPU time: 75.667s 
> > true. 
> >
> With the newly release Scryer Prolog version 0.9.2, I now get:
> ?- time(([X,Y,Z] ins 0..239, X^3+Y^3+9 #= Z^3, label([X,Y,Z]), fail; true)).
> % CPU time: 41.658s 
> true. 
> 
> On my machine, that`s within a factor of 6 of SWI. That`s quite 
> comparable to many other applications when it comes to time performance: 
> At the current state of Scryer Prolog development, its performance tends 
> to be within an order of magnitude of SWI`s. 
> 
> One neat feature of the Scryer Prolog toplevel is that we can press "a" 
> to obtain *all* solutions, one after the other. In this case: 
> 
> ?- time(([X,Y,Z] ins 0..239, X^3+Y^3+9 #= Z^3, label([X,Y,Z]))). 
> % CPU time: 16.080s
> X = 52, Y = 216, Z = 217
> ; % CPU time: 25.942s
> X = 216, Y = 52, Z = 217
> ; % CPU time: 0.250s 
> false. 
> 
> It`s often nice to get the Prolog system to enumerate all solutions 
> automatically. The GNU Prolog toplevel also has this feature, and I 
> highly recommend adding it in system where it is not yet available. 
> 
> All the best, 
> Markus 
> 
> -- 
> comp.lang.prolog FAQ: http://www.logic.at/prolog/faq/ 
> The Power of Prolog: https://www.metalevel.at/prolog
--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441