search

anskarl / LoMRF

LoMRF is an open-source implementation of Markov Logic Networks
https://anskarl.github.io/LoMRF
Apache License 2.0
80 stars 20 forks source link

java.util.NoSuchElementException: reached iterator end #10

Closed ewerlopes closed 7 years ago

ewerlopes commented 7 years ago

HI,

On the current version, the following error would occur in case only one fluent is declared:

Exception in thread "main" java.util.NoSuchElementException: reached iterator end
    at scala.collection.immutable.VectorIterator.next(Vector.scala:674)
    at lomrf.util.Cartesian$CartesianIterator$$anonfun$apply$4.apply(Cartesian.scala:81)
    at lomrf.util.Cartesian$CartesianIterator$$anonfun$apply$4.apply(Cartesian.scala:77)
    at scala.collection.Iterator$class.foreach(Iterator.scala:893)
    at scala.collection.AbstractIterator.foreach(Iterator.scala:1336)
    at lomrf.util.Cartesian$CartesianIterator$.apply(Cartesian.scala:77)
    at lomrf.logic.PredicateCompletion$$anonfun$applyPCDecomposed$3.apply(PredicateCompletion.scala:350)
    at lomrf.logic.PredicateCompletion$$anonfun$applyPCDecomposed$3.apply(PredicateCompletion.scala:327)
    at scala.collection.TraversableLike$WithFilter$$anonfun$foreach$1.apply(TraversableLike.scala:733)
    at scala.collection.mutable.HashMap$$anonfun$foreach$1.apply(HashMap.scala:99)
    at scala.collection.mutable.HashMap$$anonfun$foreach$1.apply(HashMap.scala:99)
    at scala.collection.mutable.HashTable$class.foreachEntry(HashTable.scala:230)
    at scala.collection.mutable.HashMap.foreachEntry(HashMap.scala:40)
    at scala.collection.mutable.HashMap.foreach(HashMap.scala:99)
    at scala.collection.TraversableLike$WithFilter.foreach(TraversableLike.scala:732)
    at lomrf.logic.PredicateCompletion$.applyPCDecomposed(PredicateCompletion.scala:327)
    at lomrf.logic.PredicateCompletion$.apply(PredicateCompletion.scala:228)
    at lomrf.mln.model.MLN$.fromFile(MLN.scala:337)
    at lomrf.app.InferenceCLI$.delayedEndpoint$lomrf$app$InferenceCLI$1(InferenceCLI.scala:353)
    at lomrf.app.InferenceCLI$delayedInit$body.apply(InferenceCLI.scala:51)
    at scala.Function0$class.apply$mcV$sp(Function0.scala:34)
    at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
    at scala.App$$anonfun$main$1.apply(App.scala:76)
    at scala.App$$anonfun$main$1.apply(App.scala:76)
    at scala.collection.immutable.List.foreach(List.scala:381)
    at scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:35)
    at scala.App$class.main(App.scala:76)
    at lomrf.app.InferenceCLI$.main(InferenceCLI.scala:51)
    at lomrf.app.LoMRF$$anonfun$1.apply(LoMRF.scala:48)
    at lomrf.app.LoMRF$$anonfun$1.apply(LoMRF.scala:48)
    at auxlib.opt.MasterOptionParser$class.parse(MasterOptionParser.scala:54)
    at lomrf.app.LoMRF$.parse(LoMRF.scala:41)
    at lomrf.app.LoMRF$.delayedEndpoint$lomrf$app$LoMRF$1(LoMRF.scala:61)
    at lomrf.app.LoMRF$delayedInit$body.apply(LoMRF.scala:41)
    at scala.Function0$class.apply$mcV$sp(Function0.scala:34)
    at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
    at scala.App$$anonfun$main$1.apply(App.scala:76)
    at scala.App$$anonfun$main$1.apply(App.scala:76)
    at scala.collection.immutable.List.foreach(List.scala:381)
    at scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:35)
    at scala.App$class.main(App.scala:76)
    at lomrf.app.LoMRF$.main(LoMRF.scala:41)
    at lomrf.app.LoMRF.main(LoMRF.scala)
vagmcs commented 7 years ago

Hi @ewerlopes,

Can you please give more details of what exactly you run, as well as the KB and evidence?

ewerlopes commented 7 years ago

Hi @vagmcs,

This is a variant of the Yale Shooting Problem. 

fluent = {Loaded}
time = {0,...,13}

// Predicate schema
HoldsAt(fluent, time)
InitiatedAt(fluent, time)
TerminatedAt(fluent, time)
Happens(event, time)

// Event Calculus domain-independent axioms

InitiatedAt(f, t) => HoldsAt(f, t++).

TerminatedAt(f, t) => !HoldsAt(f, t++).

HoldsAt(f, t) ^ !TerminatedAt(f, t) => HoldsAt(f, t++).

!HoldsAt(f, t) ^ !InitiatedAt(f, t) => !HoldsAt(f, t++).

//Domain-dependent rules

// The gun becomes loaded if and only if the hunter loads the gun.
2 InitiatedAt(Loaded,t) :- Happens(Load,t)

// The gun stops from being loaded after a shot.
2 TerminatedAt(Loaded,t) :- Happens(Shoot,t) ^ HoldsAt(Loaded,t)

// Initial state

// Initially the gun is not loaded
!HoldsAt(Loaded, 0).

// Initially nothing is initiated
!InitiatedAt(f,0).

// Initially nothing is terminated
!TerminatedAt(f,0).

The evidence is the same of the original problem. The error seems to disappear when at least two fluent constants are declared. So, if you add: Alive, Dead to the fluent set, or even declare domain-dependent predicates, it will work.

ewerlopes commented 7 years ago

Additionally, the following code will also throw the same error in case fluents = {...} is not present and the assigned "set" has less then k+1 variables, where k is the number of fluents. 

// ----------------------------------------------------------------------------
// --- Domain definitions
//
// time: the domain of time-points
// fluent: the domain of fluent, that is composite events (CE)
// event: the domain of events, that is the input simple, derived events (SDE)
// id: domain entities, e.g. persons or objects
// ----------------------------------------------------------------------------

// The declaration of a fluent is necessary for avoiding misterious error (reported as issue on github).
// Besides the declaration, DUMMY_VAR is also needed to avoid the error.
fluent = {Blocking, Attacking, DUMMY_VAR}
tower = {T1,T2,T3,T4}
time = {0,...,20}

// Query Predicates:
HoldsAt(fluent, time)

// Template Predicates:
InitiatedAt(fluent, time)
TerminatedAt(fluent, time)

// Evidence Predicates (closed-world assumption):
Happens(event, time)
Next(time, time)
StartTime(time)

// Constraint predicate
CloseToRobot(time)
CloseToTower(tower,time)

// Function definitions for simple, derived events (SDE):
event Walking
event Running
event LocallyMoving
event Inactive
event Charging(tower)

// Function definitions for composite events (CE):
fluent Blocking
fluent Attacking(tower)

// ----------------------------------------------------------------------------
// --- Probabilistic Event Calculus (domain-independent axioms)
// ----------------------------------------------------------------------------

/**
 * Event Calculus domain-independent axioms
 */

// When a fluent holds:
InitiatedAt(f, t) => HoldsAt(f, t++).

// When a fluent does not hold:
TerminatedAt(f, t) => !HoldsAt(f, t++).

// The inertia of holdsAt, i.e. a fluent continues to hold unless it is terminated:
HoldsAt(f, t) ^ !TerminatedAt(f, t) => HoldsAt(f, t++).

// The inertia of !holdsAt, i.e. a fluent continues not to hold unless it is initiated:
!HoldsAt(f, t) ^ !InitiatedAt(f, t) => !HoldsAt(f, t++).

//
// High-Level Event: blocking 
//

#include "include/blocking.mln"

//
// High-Level Event: attacking
//

#include "include/attacking.mln"

// ----------------------------------------------------------------------------
// --- Other domain-dependent rules
// ----------------------------------------------------------------------------

/**
 * Initial state
 */

// Initially no fluent holds
!HoldsAt(f, 0).

// Initially nothing is initiated
!InitiatedAt(f,0).

// Initially nothing is terminated
!TerminatedAt(f,0).

Thank you for your help.

vagmcs commented 7 years ago

Hi @ewerlopes,

It seem that there is a small bug in the predicate completion component. I will try to fix it as soon as possible and let you now.

ewerlopes commented 7 years ago

Thank you very much! By the way, do you know wether it is possible to integrate RTEC with you library?

Thanks again!

On Thu, 22 Jun 2017 at 12:50, Evangelos Michelioudakis < notifications@github.com> wrote:

Hi @ewerlopes https://github.com/ewerlopes,

It seem that there is a small bug in the predicate completion component. I will try to fix it as soon as possible.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/anskarl/LoMRF/issues/10#issuecomment-310345668, or mute the thread https://github.com/notifications/unsubscribe-auth/ABdcny8-MCWbIvjJSb6Yii1dTBX8725-ks5sGkbygaJpZM4OA3eL .

-- -- Ewerton Lopes S. de Oliveira Mestrando em Ciências da Computação, PPGI-UFPB-CAMPUS I - www.ppgi.di.ufpb.br; Graduado em Lic. em Ciências da Computação - UFPB, Campus IV; Pesquisador em Inteligência Artificial e Informática Médica; Para [crescer] faça "poucas coisas", mas as faça bem! (S. F. Assis).

vagmcs commented 7 years ago

No its not possible, at least as an internal component because,

(a) RTEC is a crisp event recognition engine that works with logic programming and cannot handle noisy data or perform probabilistic inference, while LoMRF works with first-order logic (which is a superset of logic programming) and performs probabilistic reasoning. Therefore there are very different. For example RTEC does not understand weighted definitions.

(b) RTEC is written in prolog.

Of course you can learn something with LoMRF, then keep the best clauses, transform them into the RTEC language and perform event recognition.

vagmcs commented 7 years ago

Hello @ewerlopes

The issue has been solved. See commit https://github.com/anskarl/LoMRF/commit/8ea308b5dcdc95a9e2be81b6395757365fe82eac

ewerlopes commented 7 years ago

Great! Thank you very much for the support!

On Sun, 25 Jun 2017 at 14:31, Evangelos Michelioudakis < notifications@github.com> wrote:

Hello @ewerlopes https://github.com/ewerlopes

The issue has been solved. See commit 8ea308b https://github.com/anskarl/LoMRF/commit/8ea308b5dcdc95a9e2be81b6395757365fe82eac

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/anskarl/LoMRF/issues/10#issuecomment-310900065, or mute the thread https://github.com/notifications/unsubscribe-auth/ABdcn7iDYiFZ_E01z-DbMBoqQlFWPogwks5sHlM3gaJpZM4OA3eL .

-- -- Ewerton Lopes S. de Oliveira Mestrando em Ciências da Computação, PPGI-UFPB-CAMPUS I - www.ppgi.di.ufpb.br; Graduado em Lic. em Ciências da Computação - UFPB, Campus IV; Pesquisador em Inteligência Artificial e Informática Médica; Para [crescer] faça "poucas coisas", mas as faça bem! (S. F. Assis).

anskarl commented 7 years ago

The aforementioned issues have been resolved: