Thanks a lot for your detailed bug report! Ideally you would create
github issues if each of these, but this is already greatly appreciated.
I'll have a careful look at them, already though regarding the slow down
due to cog-undefined-handle this is probably because it is getting
obsolete and I haven't removed it from all PLN rules (doing that now).
Nil
On 05/29/2017 02:50 AM,
rocketpwr.com wrote:
> Dear OpenCog Development Community,
>
> First, thank you for your hard work on this project.
>
> I found a few bugs that I have been able to work around that you might
> find helpful. Hopefully the below description of the problems and my
> work-arounds will help you or someone else who comes across the same
> problems.
>
> /*1) Really really long compile times on loading up the conceptnet4.scm
> test dataset in test-datasets/conceptnet/conceptnet4.scm*./ I left it
> to run overnight, and it still had not finished. Actually, I believe it
> was going to take 70+ hours to load and compile this 14.5 MB file. This
> seemed strange to me as smaller files loaded much faster. What I
> determined by experiment is that, for some unknown reason, the Guile
> Scheme compiler had a compile time that is proportional approximately
> n^2 of the number of rules. Here are some results on my test rig (a 4
> core 4 GB Ubuntu 16.04 setup):
>
> |
> Rulesloadtime rules/sec
>
> 259737.00
> 6343120.45
> 10007014.29
> 124911011.35
> |
>
>
> Because the Conceptnet4.scm file is about 60.5K I estimate that the
> compile time would be around 71 hours or 3 days. I am guessing this is
> a bug/feature in Guile Scheme which was not really meant as a database.
>
> My work-around: a) split the 60K rule file into 61 files of 1K rules
> each, and then compile them. Each file compiles in around 14 seconds,
> reducing the compile time to around 1.5 hours. Once compiled, the rules
> do not need to be compiled again. b) I wrote a small loader that loads
> all 61 files into Guile in a single command.
>
> */2) Really long execution time for (cog-bind
> deduction-inheritance-rule):/* I am experimenting with PLN, using the
> (define-public(cog-undefined-handle .X)'())
> |
>
> Note: I am not expert in Guile, Scheme, or Lisp. A poster on stack
> exchange said that by inserted the dot character in the argument list,
> it allows a Scheme function to take any number of arguments. This seems
> to work -- now the opencog.log is clean and the (cog-bind
> deduction-inheritance-rule) runs on the entire data set in only a few
> minutes.
> */
> /*
> */3) Hard coded gcc/g++ 4.8 compiler version in octool prevents
> installation on Ubuntu 16.04 LTS/*. I understand that the base Linux
> configuration for Opencog is still 14.04 LTS. However, that version is
> already 3 years old and I had just installed a 16.04 LTS image, and I
> did not want to reinstall after investing the time to set it up
> properly. To get octool to finish the compilation and subsequent
> installation, I did the following change:
>
> |
> $ diff octool octool~
> 843,844c843
> <#CXX=g++-4.8 cmake .. -DCMAKE_BUILD_TYPE=Release
> <CXX=g++cmake ..-DCMAKE_BUILD_TYPE=Release
> ---
>>CXX=g++-4.8cmake ..-DCMAKE_BUILD_TYPE=Release
> |
>
>
> A more clever programmer can ensure that the a version of g++ <= 4.8 is
> used by octool script.
>
> */4) Old python conceptnet converter.py doesn't match newer 5.5.0
> version of conceptnet. /* [NOTE: The following python code is likely
> deprecated in favor of newer c++ converter found here:
>
https://github.com/opencog/external-tools/tree/master/cnet_importer ]
>
> Earlier in the week, I tried to convert an English only
> conceptnet-assertions-5.5.0.csv file prepared by grep filtering out the
> non-English assertions. Unfortunately the Python converter.py that was
> downloaded (I believe by octool) does not work on this file. Note: this
> version of converter.py was installed in my
> ~/opencog/opencog/opencog/python/conceptnet/ directory. I further
> modified the conceptnet-assertions.5.5.0.csv file work by changing the
> column format to the same as the conceptnet4.csv file. This allowed the
> python converter script to run to the end of the file without
> terminating prematurely.
>
> -----------
>
> Overall I am still working to understand Opencog and its capabilities.
>
> Finally, if anyone has uploaded a recent dbpedia ruleset to Opencog, I
> would like to experiment with it as well. Please drop a line.
>
> Thank you again.
>
>
>
> --
> 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
opencog+u...@googlegroups.com
> <mailto:
opencog+u...@googlegroups.com>.
> To post to this group, send email to
ope...@googlegroups.com
> <mailto:
ope...@googlegroups.com>.
> Visit this group at
https://groups.google.com/group/opencog.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/opencog/608d7d27-f608-4eb9-a998-c607e4a4f34a%40googlegroups.com
> <
https://groups.google.com/d/msgid/opencog/608d7d27-f608-4eb9-a998-c607e4a4f34a%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit
https://groups.google.com/d/optout.