Menu
▾
▴
Re: [Xsb-development] FW: Re: XSB working in 64 bits on Macs
|
From: Terrance S. <ts...@cs...> - 2008-03-22 20:14:39
|
An alternate way of implementing arithmetical relations might be
to use a finite domain solver. Here is an example from CVS XSB:
------------------------
XSB Version 3.1 (Incognito) of August 10, 2007
[i386-apple-darwin8.9.1; mode: optimal; engine: slg-wam; gc: indirection;
sched\
uling: local]
| ?- [bounds].
[bounds loaded]
[clp_events loaded]
| ?- X in 1..10,Y in 1..10,sum([X,Y],#=,15),label([X,Y]).
X = 5
Y = 10;
X = 6
Y = 9;
X = 7
Y = 8;
X = 8
Y = 7;
X = 9
Y = 6;
X = 10
Y = 5;
no
------------------------
Now I agree that this interface isn't as simple as the one you
propose, but for your RA library you might be able to compile
into CLP(FD) and make it more to your taste. I'm not sure what
the efficiency of this solver is compared to what you propose.
This aproach extends naturally to subtraction, but not as easily
to multiplication or division since these operations do not
preserve closed intervals, which are used as a constraint
domain representation by many solvers -- bounds in particular.
Terry
PS: XSB's bounds.pl is based on the SWI paackage. bounds.pl is a simple
FD solver; recently SWI has started supporting a new solver -- I
haven't had time to look at it yet, but if its based on
attributed variables (and seems to be a good package), I'll port
it to XSB. Sicstus and GNU prolog also have FD solvers that (I
think) have hooks into their engines beyond attributed variables.
On Thu, 20 Mar 2008 pa...@du... wrote:
> We would like (would anyone else?) a more efficient encoding of the natural numbers so that unary arithmetic could be more efficiently and compactly implemented. Could we have an encoding of the difference list of the form {{{{{X}}}}}-X as a sequence of five 1's in a word of whatever size. I suppose this actually means encoding the {{{{{X}}}}} as the 5 true(1) bits with false(0) on either side within the 64 bit (or whatever size) word. It would be really nice if memory allocation were used to encode numbers beyond 64, up to whatever memory is available, say 64 billion.
One objective is improved program clarity and I don't believe any other prologs do this. Then, arithmetic goals such as the following could be more expressive:
---------
| ?- [naturals].
[naturals loaded]
yes
| ?- sum(X,Y,3).
X = 0
Y = 3;
X = 1
Y = 2;
X = 2
Y = 1;
X = 3
Y = 0;
---------
Assuming that the file 'naturals' is something like the following (simplified):
natural(0,X-Y) :- unify(X,Y).
natural(1,{X}-Y):- unify(X,Y).
natural(2,{{X}}-Y):- unify(X,Y).
natural(3,{{{X}}}-Y):- unify(X,Y).
natural(4,{{{{X}}}}-Y):- unify(X,Y).
natural(5,{{{{{X}}}}}-Y):- unify(X,Y).
natural(6,{{{{{{X}}}}}}-Y):- unify(X,Y).
natural(7,{{{{{{{X}}}}}}}-Y):- unify(X,Y).
natural(8,{{{{{{{{X}}}}}}}}-Y):- unify(X,Y).
natural(9,{{{{{{{{{X}}}}}}}}}-Y):- unify(X,Y).
sum(X,Y,Z) :-
natural(X,Xs-Ys),
natural(Y,Ys-Yn),
natural(Z,Xs-Yn).
The 'unify(X,Y)' is a unify with occur-check. I think this could lead to something quite interesting.
Paul
Terrance Swift wrote:
>
> I've gotten XSB to work fairly well on Macs when compiled with 64
> bits (it had already been working ok when compiled with 32 bits).
> The vast majority of our tests run, and apart from probems with
> 64-bit arithmetic, the port isn't that bad. Errors are:
>
> Sequential test:
>
> prolog_tests/test_precision differ!!! (probably a problem w. 64-bit
> arithmetic)
> prolog_tests/mf_test1 differ!!! (multifile ???)
> table_tests/concomp differ!!! (indexing problem???)
> table_tests/aggregs_test differ!!! (appears to be arithmetic problem)
> table_tests/float differ!!! (appears to be a float problem)
> neg_tests/q7 differ!!! (indexing problem???)
> delay_tests/residual1 differ!!! (appears to be a float problem)
> constraint_tests/clprtest differ!!! (float precision problems)
> sub_tests/decker differ!!! ???
> io_tests/fmt_io differ!!! (maybe problems w. numbers)
> regmatch_tests/perltest differ!!! not a problem: just can't find perl
>
>
> Mttest:
>
> prolog_tests/mutex_test differs!!! ???
> prolog_tests/cvartest_thread_make differs!!! (probably a problem w.
> config)
> prolog_tests/cregtest_thread_make differs!!! (probably a problem w.
> config)
> prolog_tests/cvartest_thread_make2 differs!!! (probably a problem w.
> config)
> prolog_tests/cregtest_thread_make2 differs!!! (probably a problem w.
> config)
>
> I'll try pecking away at the non-arithmetic problems. For the
> arithmetic problems, we need to wait until David decides what to
> do with GMP.
>
> Terry
>
> PS: David, you might just try again on 64-bit windows. Its
> probably optimistic, but it to*might* work now.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Xsb-development mailing list
> Xsb...@li...
> https://lists.sourceforge.net/lists/listinfo/xsb-development
>
>
|