>
> I know nothing about the blocksworld problem, so I cannot help directly.
>> Indirectly, you can use (cog-report-counts) to monitor the number of atoms
>> in the atomspace -- I typically see an average of about 1KB or 2KB per
>> atom. So, a few GB is enough for millions of atoms, normally. This will
>> give you a hint of what might be going on there.
>>
>
Ok i did some tests.
Guile version is 2.2 (I'm on ubuntu and haven't figured out if Guile 3.0 is
available for me)
1) The first test tries to solve the BC with a goal corresponding to a
column of 3 distinct blocks. Execution time = a few seconds.
2) The second test (which is the one inside my repo) tries to solve the BC
with a goal corresponding to a column of 4 distinct blocks. Execution time
= infinite!
Running (cog-report-counts) I get these results :
1 test)
((ConceptNode . 8) (NumberNode . 2) (PredicateNode . 9) (SetLink . 5)
(ListLink . 30) (MemberLink . 7) (ContextLink . 5) (AndLink . 67) (NotLink
. 14) (PresentLink . 7) (VariableNode . 11) (VariableList . 6) (DefineLink
. 7) (BindLink . 7) (EvaluationLink . 44) (TypeNode . 6) (TypeChoice . 2)
(TypedVariableLink . 11) (EqualLink . 14) (ExecutionOutputLink . 7)
(SchemaNode . 2) (DefinedSchemaNode . 7) (GroundedSchemaNode . 6)
(InheritanceLink . 7) (ExecutionLink . 2))
2 test)
((ConceptNode . 8) (NumberNode . 2) (PredicateNode . 9) (SetLink . 4)
(ListLink . 11) (MemberLink . 7) (ContextLink . 5) (AndLink . 7) (NotLink .
17) (PresentLink . 7) (VariableNode . 16) (VariableList . 6) (DefineLink .
7) (BindLink . 7) (EvaluationLink . 25) (TypeNode . 6) (TypeChoice . 3)
(TypedVariableLink . 19) (EqualLink . 17) (ExecutionOutputLink . 7)
(SchemaNode . 2) (DefinedSchemaNode . 7) (GroundedSchemaNode . 6)
(InheritanceLink . 7) (ExecutionLink . 2))
(Obviously I think that the first test is solved so there are more atoms
than the second that cannot continue. Anyway they still seem very few to me)
In my BC, the fuzzy-conjunction-introduction-rule (changing types) is run
first to extract the atoms from an AndLink ( which is the goal = column of
blocks).
Next, the inference trees of the extracted atoms will be expanded and the
BC will end with the result.
The only difference between the two tests is that:
1) In the first test, the rule is executed with nary = 5 (2 EvaluationLink
for "A on B" and "B on C" + 3 NotLink to differentiate the three blocks)
2) While in the second one, the rule is performed with nary = 9 (3
EvaluationLink for "A on B" and "B on C" and "C on D" + 6 NotLink to
differentiate the four blocks)
Looking at the RAM occupation ("free -h" shows at the start 4.6 Giga
occupied out of 7.6 total):
1 test) RAM DOES NOT CHANGE.
2 test) I exceed 8 Giga and I start swapping. Only after half an hour, the
selection of the first rule (fuzzy-conjunction-introduction-rule) is
printed on the logger.
So it looks like it works fine (as it should) but is extremely
slow (i think due to my swap area is on external ssd, like for linux).
Summing up:
- I'm assuming it's RAM's fault
- in test 2, if I remove a single NotLink from the goal, and so the
fuzzy-conjunction-introduction-rule is executed with nary = 8 (instead of
9), it works! It takes a few seconds (but I lose a condition of
non-equality between 2 blocks).
It seems absurd to me that with 8 atoms it works and with 9 it doesn't ...
- Someone would be kind enough to try running test_pickup_stack.scm file
and share me the log file?
the repo is very light: https://github.com/raschild6/blocksworld_problem
and just use a command to load the file, as written in the readme.
In this way I could understand if it is a problem with my pc or with the
code. Sorry for the inconvenience and thanks in advance.
The only "problem" is that URE uses some temporary atomspaces; those are
>> not included in the count. The URE also mallocs structures that are not
>> part of the atomspace.
>>
>> There is a third but unlikely issue -- guile garbage collection not
>> running often enough. Take a look at (gc-stats) to get info, and (gc) to
>> manually run garbage collection. It's unlikely this is a problem, but there
>> were issues with older guile-- say, version 2.0. I'm hoping you are on
>> version 3.0, or at least version 2.2.
>>
>> Perhaps @Nil Geisweiller can help with URE ram issues.
>>
>> --linas
>>
>
- (gc-stats) before doing anything:
((gc-time-taken . 281744537) (heap-size . 6316032) (heap-free-size .
323584) (heap-total-allocated . 47119248) (heap-allocated-since-gc .
2700880) (protected-objects . 15) (gc-times . 19))
- (gc-stats) after 1 test:
((gc-time-taken . 305335411) (heap-size . 6316032) (heap-free-size .
372736) (heap-total-allocated . 50000112) (heap-allocated-since-gc .
2775904) (protected-objects . 15) (gc-times . 20))
- (gc-stats) in the 2 test when I ran out of RAM:
((gc-time-taken . 334108055) (heap-size . 6316032) (heap-free-size .
1228800) (heap-total-allocated . 54519584) (heap-allocated-since-gc .
1691024) (protected-objects . 16) (gc-times . 22))
I'm trying to understand their meaning. Do these numbers tell you something?
Thanks again for the help.
Michele
--
You received this message because you are subscribed to the Google Groups
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/opencog/e8d55639-fa5e-4d3d-96a8-feeb8a0eefcfn%40googlegroups.com.
