@MSGID:
<6c9c0d39-8658-47b8-8526-2fd11e08fc71n@googlegroups.com> f64fb5fd
@REPLY:
<37516061-91b6-4129-8221-4bdb0fa59f42n@googlegroups.com> 84514ed0
@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>
<37516061-91b6-4129-8221-4bdb0fa59f42n@googlegroups.com>
@RFC-Message-ID:
<6c9c0d39-8658-47b8-8526-2fd11e08fc71n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
Actually its not that dim, one could integrate the Chinese
Reminder Algorithm (CRA) strategy into a CLP(FD) constraint
solver via a labeling variant. The labeling would

include not only running through values inside the current
modulo M, i.e. choosing values in the range 0..M-1, but also
choosing different moduli M1, .., Mk. But the question is

whether one should do that. The problem is that the solution
is obtained by backtracking over all moduli. So when E is the
equation, then its basically a large conjunction:

E_M1, ..., E_Mk

Where each element of the conjunction produces some bits,
and these bits are then combined via CRA. Currently when
E_Mj is a predicate, the equation sits in this predicate,

and each element of the conjunctions runs instances of
the clauses of the predicate, thus has a copy of the equation
available. This copying of the equation makes me think

that attribute variables don`t work. But alternatively one
could also table the results of each E_Mj, and later do the
CRA combination. My current solution is not like that,

but this could have more affinity to attributed variables.

Mild Shock schrieb am Freitag, 1. September 2023 um 20:47:06 UTC+2:
> 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