which prolog implementation to use to avoid "out of stack" exceptions

Hi,

I'm doing a best first search in a very large space and have to keep
the list of possible solutions in memory. Since the search space is
huge I get "out of global stack" exceptions in SWI-prolog and in
Sicstus prolog.

Can anybody recomment me a prolog implementation which can use more
memory?

Thanks,
Gregor

On Wed, 13 Aug 2008 07:56:40 -0700 (PDT), Gregor Leban
<gleban@gmail.com> wrote:

>Hi,
>
>I'm doing a best first search in a very large space and have to keep
>the list of possible solutions in memory. Since the search space is
>huge I get "out of global stack" exceptions in SWI-prolog and in
>Sicstus prolog.
>
>Can anybody recomment me a prolog implementation which can use more
>memory?
>

No. This is not Prolog problem. This is problem with your program

A.L.

On Aug 13, 8:05*am, A.L. <alewa...@zanoza.com> wrote:
> On Wed, 13 Aug 2008 07:56:40 -0700 (PDT), Gregor Leban
>
> <gle...@gmail.com> wrote:
> >Hi,
>
> >I'm doing a best first search in a very large space and have to keep
> >the list of possible solutions in memory. Since the search space is
> >huge I get "out of global stack" exceptions in SWI-prolog and in
> >Sicstus prolog.
>
> >Can anybody recomment me a prolog implementation which can use more
> >memory?
>
> No. This is not Prolog problem. This is problem with your program
>
> A.L.

Hi A.L.,

I know that generally this means that there is a problem with the
program, but it is not true in my case (at least 99.99% sure).
I'm using Bratko's Hyper program for ILP. I was able to successfully
use it on several problems, but I now have a problem which has a lot
of background predicates and the hypothesis that I want to discover is
very long (in comparison with my previous problems).

I found an explanation on one of the groups that the "out of stack"
exception can happen because the SWI prolog (and I guess sicstus also)
uses some number of bytes for addressing, while other prolog
implementations can use higher number of bytes (but it didn't say
which prolog implementations that may be). What i need is to find
which are these implementations.

Thanks,
Gregor

On Wed, 13 Aug 2008 08:22:53 -0700, Gregor Leban wrote:

>
> I found an explanation on one of the groups that the "out of stack"
> exception can happen because the SWI prolog (and I guess sicstus also)
> uses some number of bytes for addressing,
bits, not bytes - for tagging, not for addressing

> while other prolog
> implementations can use higher number of bytes (but it didn't say which
> prolog implementations that may be). What i need is to find which are
> these implementations.

If you want more than a factor 2 or 4 of your current memory, you should
start using a 64-bit version (of SWI or Yap)

Cheers

Bart Demoen

On Wed, 13 Aug 2008 17:00:47 +0000 (UTC), bart demoen
<bmd@cs.kuleuven.be> wrote:

>On Wed, 13 Aug 2008 08:22:53 -0700, Gregor Leban wrote:
>
>>
>> I found an explanation on one of the groups that the "out of stack"
>> exception can happen because the SWI prolog (and I guess sicstus also)
>> uses some number of bytes for addressing,
>bits, not bytes - for tagging, not for addressing
>
>> while other prolog
>> implementations can use higher number of bytes (but it didn't say which
>> prolog implementations that may be). What i need is to find which are
>> these implementations.
>
>If you want more than a factor 2 or 4 of your current memory, you should
>start using a 64-bit version (of SWI or Yap)
>

... what down't emna that you can expand stack to infinity...

A.L.

On Wed, 13 Aug 2008 12:18:01 -0500, A.L. wrote:


##If you want more than a factor 2 or 4 of your current memory, you should
##start using a 64-bit version (of SWI or Yap)
# .. what down't emna that you can expand stack to infinity...
#
# A.L.

I don't understand that speak, but there is a huge leap from a factor 2
or 4 to infinity - 64-bit machines just make sure you have a stronghold
somewhere in between, which is what many people need. Of course, if you
think that anything you ever want to do should be possible in 32-bit
address space ... join the people who thought 16 bits was enough. They
were equally wrong.

And if you think that more memory doesn't increase your computational
power, read the book by Neil Jones.

Cheers

Bart Demoen

On Wed, 13 Aug 2008 17:39:19 +0000 (UTC), bart demoen
<bmd@cs.kuleuven.be> wrote:

>On Wed, 13 Aug 2008 12:18:01 -0500, A.L. wrote:
>
>
>##If you want more than a factor 2 or 4 of your current memory, you should
>##start using a 64-bit version (of SWI or Yap)
># .. what down't emna that you can expand stack to infinity...
>#
># A.L.
>
>I don't understand that speak, but there is a huge leap from a factor 2
>or 4 to infinity - 64-bit machines just make sure you have a stronghold
>somewhere in between, which is what many people need. Of course, if you
>think that anything you ever want to do should be possible in 32-bit
>address space ... join the people who thought 16 bits was enough. They
>were equally wrong.
>
>And if you think that more memory doesn't increase your computational
>power, read the book by Neil Jones.

What book by Neil Jones?...

Whatever is the amount of memory we have, whatever is the version of
prolog, whatever is the oparating system - memory is limited.
Therefore, sooner or later we will have program that will not work
because of memory limitations. The only problen is where is teh limit

Theer are 2 solutions:

1. Increase the limit,
2. Program in a way that with current available memory program will be
working correctly when solving large problems.

A.L.

On Wed, 13 Aug 2008 17:39:19 +0000 (UTC), bart demoen
<bmd@cs.kuleuven.be> wrote:

>On Wed, 13 Aug 2008 12:18:01 -0500, A.L. wrote:
>
>
>##If you want more than a factor 2 or 4 of your current memory, you should
>##start using a 64-bit version (of SWI or Yap)
># .. what down't emna that you can expand stack to infinity...
>#
># A.L.
>
>I don't understand that speak,

Sorry, I was writing from my phone. Keyboard and screen are to
small... Should be

"what doesn't mean that you can expand stack to infinity..."

A.L.

On Wed, 13 Aug 2008 15:04:08 -0500, A.L. wrote:


> What book by Neil Jones?...

THE book by THE Neil D. Jones :-)
Find his home page and you will see - can be downloaded freely these days.

>
> Whatever is the amount of memory we have, whatever is the version of
> prolog, whatever is the oparating system - memory is limited. Therefore,
> sooner or later we will have program that will not work because of
> memory limitations. The only problen is where is teh limit
>
> Theer are 2 solutions:
>
> 1. Increase the limit,
> 2. Program in a way that with current available memory program will be
> working correctly when solving large problems.

Have a look at the swimming at the olympics these days and wonder why the
swimmers are not trying to break the records with the swimming suit of
50 years ago.

Cheers

Bart Demoen

On Wed, 13 Aug 2008 20:13:16 +0000 (UTC), bart demoen
<bmd@cs.kuleuven.be> wrote:

>On Wed, 13 Aug 2008 15:04:08 -0500, A.L. wrote:
>
>
>> What book by Neil Jones?...
>
>THE book by THE Neil D. Jones :-)
>Find his home page and you will see - can be downloaded freely these days.
>

There are very small number of people/things that are THE for me

What specifically you want me to read in this book? Especially in the
context of memory limitations?

>>
>> Whatever is the amount of memory we have, whatever is the version of
>> prolog, whatever is the oparating system - memory is limited. Therefore,
>> sooner or later we will have program that will not work because of
>> memory limitations. The only problen is where is teh limit
>>
>> Theer are 2 solutions:
>>
>> 1. Increase the limit,
>> 2. Program in a way that with current available memory program will be
>> working correctly when solving large problems.
>
>Have a look at the swimming at the olympics these days and wonder why the
>swimmers are not trying to break the records with the swimming suit of
>50 years ago.

What do you want to say? That SICStus or SWI are obsolete? WinXP
cannot handle more than 3 GM memory, therefore you cannot solve
problem that doesn't fit into this memory. But sometimes you have to,
and it takes some work to redesign the algorithm and to rethink the
approach.

I cannot tell the customer to switch to UNIX if they are not using
UNIX - and in industry UNIX is not used except for database servers.

The Original Poster wants to save all nodes visited during search -
sorry - this is THE nonsense. The other nonsense is not seeing THE
difference between academic example and real stuff

A.L.