why is a 'fact object' address changing?

Help
Pyc Liph
2008-07-28
2013-04-25
  • Pyc Liph

    Pyc Liph - 2008-07-28

    It appears that the clips.FactList() returns a different address
    for the same fact every time when asked, as below:

    >>> clips.Assert("(duck)")
    <Fact 'f-1': fact object at 0x844f4e0>
    >>> clips.FactList()
    [<Fact 'f-0': fact object at 0x830da60>, <Fact 'f-1': fact object at 0x8300240>]
    >>> clips.FactList()
    [<Fact 'f-0': fact object at 0x8300380>, <Fact 'f-1': fact object at 0x844f5a0>]
    >>> clips.FactList()
    [<Fact 'f-0': fact object at 0x844f700>, <Fact 'f-1': fact object at 0x844f760>]
    >>>

    What is the meaning of a 'fact object' address?
    I presume it would be an address inside the CLIPS engine?
    Why a different 'fact object' address is returned every time?
    Thanks,
    Pyc.

     
    • Francesco Garosi

      Hi Pyc,

      This is not an issue, actually: the address that is shown is the one of the Python "wrapper" object, the one that contains a reference to the actual CLIPS fact. This is a shadow object, and does not correspond to the referenced CLIPS object... in other words, it cannot be used as an unique identifier for a fact. The only reason why I report it in the representation, is to remind that another Python object has been created, that is, more memory is consumed...

      In fact, you call clips.FactList(), that iterates through the facts in CLIPS working memory and builds a new list out of them. Even though the facts are the same across different calls, the corresponding Python objects are newly created and thus their addresses are different in Python working memory.

      This behaviour yields for the other "wrapper" objects too. This is a good question to be answered in the AQ!

      F.

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks