example15_get_input.zubr

An optimizer created by zubr communicates with the outer world via two methods:

• getInput
• execute

What is an optimizer? From our point of view the optimizer runs in a loop:

    while (loopIsRunning):
        getInput(...)
        ....
        execute(...)


In this example we tell zubr that the method getInput will be provided by us. The other one, "execute" will be a default one. We will provide an implementation of getInput which will enable the user to set one input variable at one of two values it may have.

// This is an example zubr specification.

package optimizer;

%option class MyOptimizer    // here we modify the target class name, it is optional
%option getinput own    // with this option we tell zubr we will provide our own implementation of the method getInput

// We can import Java packages here.
import javax.swing.JFrame;
import javax.swing.JOptionPane;
import java.awt.Dimension;

In the middle section we provide the Perkun code declaring one input variable, alpha, which may have one of the two values - FALSE or TRUE.

// here we put the Perkun code (values and variables)

values
{
    value FALSE, TRUE;
}

variables
{
    input variable alpha:{FALSE, TRUE};   
}

The method getInput looks as follows:
// this is the implementation of the method we promised to provide:
protected void getInput(Map<Variable, Value> m) {

    Object[] possibilities = {"FALSE", "TRUE"};
   
    String n = (String)JOptionPane.showInputDialog(frame, "Alpha=?", "Continue?", JOptionPane.PLAIN_MESSAGE,
         null, possibilities, "FALSE");
      if (n == null) {
        loopIsRunning = false; // here we tell the optimizer we want to break the loop
      }
      else
      if (n == "FALSE") {
         m.put(mapNameToVariable.get("alpha"), Value.FALSE);
      }
      else
      if (n == "TRUE") {
         m.put(mapNameToVariable.get("alpha"), Value.TRUE);
     
}
It is filling the map Map<Variable,Value> named "m" with values for all input variables, depending on the decision made by the user. We are free to use the map Map<String,Variable> named "mapNameToVariable" to access the variable "alpha". The Value is an enum created by zubr.

In more complex cases we will possibly have more input variables, then we will provide a different dialog.

When we run this example with zubr we will obtain a Java code:

zubr example15_get_input.zubr > MyOptimizer.java

After compiling and running it a dialog will be shown to set the variable "alpha" either with FALSE or TRUE. After you enter the alpha value twice (and press OK) an error will occur. Moreover - this error will not be reported, and we would like to have a Swing dialog shown when it happens. How to achieve this? We must provide an important error handling method, which will be discussed in the next example. The default version of this method does nothing, and the error should be handled otherwise.

example14_my_optimizer.zubr

Next example - example14_my_optimizer.zubr. In the declaration section we have the following code:


// This is an example zubr specification.

package optimizer;

%option class MyOptimizer    // here we modify the target class name, it is optional

// We can import Java packages here.
import javax.swing.JFrame;
import java.awt.Dimension;

The instruction %option class MyOptimizer is not a Java code, it is a zubr option. It tells zubr we want to change the default target class name. Nothing complicated. We must take it into account and modify the class OptimizerThread accordingly:


protected static class OptimizerThread extends Thread {
    private MyOptimizer optimizer;

    public void run() {
        optimizer = new MyOptimizer();
        optimizer.loop(1);
      }
}

Now it creates MyOptimizer rather than Optimizer. Also note that we added in the declaration section "package optimizer;" - this means that we have to place the result Java code in a package "optimizer" (you have to create the package). As usual we can execute this example with zubr:

zubr example14_my_optimizer.zubr > MyOptimizer.zubr

The result code should be compiled with a java compiler and executed. But it still only instantiates an optimizer and runs the loop without any means to communicate with the outer world. How to make the communication? Be patient, this will be covered in next examples.

For the Windows users - I have created an installer: http://www.pawelbiernacki.net/perkun.msi.

Download zubr from https://sourceforge.net/projects/perkun/.

example13_with_optimizer_thread.zubr

Next example from the "examples" folder of the perkun package. The definition section contains the code:

// the OptimizerThread class creates an instance of the Optimizer class (created by zubr)
// and runs the loop.

protected static class OptimizerThread extends Thread {
    private Optimizer optimizer;

    public void run() {
        optimizer = new Optimizer();
        optimizer.loop(1);
      }
}

public static void main(String[] args) {
    frame = new JFrame();
    frame.setTitle("Optimizer");
    frame.setSize(new Dimension(800, 600));
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.setVisible(true);
   
    OptimizerThread t = new OptimizerThread();
   
    t.start();
}
In short - we create a thread that creates an optimizer and calls its method "loop". In the loop the optimizer runs as long as the predefined boolean variable isLoopRunning equals true. This variable is defined by zubr, you do not need to define it, but you can access it in the Optimizer.

Try to execute the example with zubr:

zubr example13_with_optimizer_thread.zubr > Optimizer.java

That is all - it will create a Java class with the code shown above included. But the optimizer (although running) does not communicate with the outer world. It is no good for us. We need to define some optimizer's methods to do it. We will do it in next examples.

Download zubr from https://sourceforge.net/projects/perkun/.

example12_with_frame.zubr

This is another zubr example from the Perkun's "examples" folder. It merely demonstrates that we can open a Swing frame when running the program. There are still no Perkun values or variables. Also the optimizer class is not instantiated yet.


// This is an example zubr specification.

// We can import Java packages here.
import javax.swing.JFrame;
import java.awt.Dimension;

%%

// here we put the Perkun code (values and variables)

values {}
variables {}

%%

// here we put Java code to be included in the result class

private static JFrame frame;

public static void main(String[] args) {
    frame = new JFrame();
    frame.setTitle("Optimizer");
    frame.setSize(new Dimension(800, 600));
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.setVisible(true);   
}

Try to process the example file with zubr:

zubr example12_with_frame.zubr > Optimizer.java

Then compile Optimizer.java with your Java compiler and run it. It will open a frame. When you close the frame the program terminates. Not a big deal. The example just shows how to include Java into your zubr specification.

Download zubr from https://sourceforge.net/projects/perkun/.

example11_simple.zubr

I thought I would present the subsequent zubr examples from the "examples" folder in the package perkun. Let us begin with example11_simple.zubr:


// This is an example zubr specification.

%%

// here we put the Perkun code (values and variables)

values {}
variables {}

%%

// here we put Java code to be included in the result class

In the above example we have a legal zubr specification. We begin with a declaration section where we can place for example Java imports. Then we have a separator %% and a Perkun section follows, with two subsections - values and variables. Then we have another separator %% and definition section follows, where we can place the Java code to be included within the result class.

Let us run:
zubr example11_simple.zubr > Optimizer.java

This will produce a Java code. The code will contain an Optimizer class which needs to be instantiated. Then we can run the instance's "loop" method. 

This simple example does not contain any Perkun variables, its purpose is just to demonstrate the zubr concept. Next examples will generate Java code based on the Java Swing package.

Download the zubr tool with the package: https://sourceforge.net/projects/perkun/.

zubr - an optimizer generator tool producing Java code in Perkun 0.1.6

I made some improvements for zubr and wrote several examples. They can be found in the "examples" folder. Zubr comes as a companion tool in the Perkun package:

https://sourceforge.net/projects/perkun/

The examples are:

• example11_simple.zubr
• example12_with_frame.zubr 
• example13_with_optimizer_thread.zubr
• example14_my_optimizer.zubr
• example15_get_input.zubr
• example16_on_error_in_populate_belief_for_consequence.zubr
• example17_get_model_probability.zubr
• example18_simple_automaton.zubr
• example19_get_payoff.zubr
• example20_hidden_variables.zubr
• example21_set_apriori_belief.zubr

 They are ordered in the increasing complexity. I recommend running the Java code produced by them. In order to try out an example (say the last one) run:

zubr example21_set_apriori_belief.zubr > MyOptimizer.java

Then create a Java application project (for example in NetBeans), put the file MyOptimizer.java in the source folder (package "optimizer") and enjoy a simple optimizer generated by zubr!

I decided that only the Perkun values and variables are passed in the zubr specification - the apriori probabilities and the model probabilities are passed in pure Java (there is no special zubr syntax for them). It is better like that.

Perkun 0.1.5 released!

Perkun 0.1.5 has been released! It contains the "zubr" tool. In the folder examples there is an example zubr specification (example10_java.zubr). If you process the file with zubr you will get a Java code containing class MyOptimizer.

There is no manual for zubr yet, I will write it.

An idea: zubr - a Java code generator

I have an idea. I want to create a version of Perkun/Wlodkowic that works just like typical chess playing programs - i.e. without generating all the possible visible states. I want to use code that generates a game tree in runtime - based on the current state. In order to do that I will need a more powerful language than Perkun - I will need to write code in a general purpose programming language. One solution would be to embed an interpreter (like I did in Perkun2). Another one would be to enhance my own language. Another - the most interesting one - would be to create a code generator.

I mean a tool similar to yacc/bison with a specification that contains code in the target language. I choose the target language to be Java rather than C (for multiple reasons). The idea is to write a new tool (probably in C++) which would take a specification similar to this one:

//
// This is a zubr specification.
// When processed with zubr it generates Java code.
// The idea is based on yacc/bison generated parsers.

package optimizer;

%option class MyOptimizer
%option getinput own

import javax.swing.JFrame;
import javax.swing.JOptionPane;
import java.awt.Dimension;

%%

values
{
    value FALSE, TRUE;
}

variables
{
    input variable alpha:{FALSE, TRUE};
    hidden variable beta:{FALSE, TRUE};
    output variable chi:{FALSE, TRUE};
}

payoff
{
    set({alpha=>FALSE},0.0);
    set({alpha=>TRUE},100.0);
}

apriori
{
}

%%

// here we have remaining code (in Java) to be included in the optimizer class

 

I choose the tool to be named "zubr" which is derived from the Polish word "żubr" meaning a European bison.

As you can see I borrow quite a lot from the yacc/bison syntax. The middle part (between %% s) has Wlodkowic syntax, but the model generator will be written in Java.

The optimizer derived this way might be inherited or instantiated directly and used in your own Java program. The most important thing would be to achieve code based on Perkun specification with hundreds, maybe thousands of hidden variables. Current implementation of Perkun/Wlodkowic is not capable of doing that.

The tool "zubr" will be packaged in Perkun (hopefully in the version 0.1.5). In fact I already have a small prototype (based on Wlodkowic code).

IF THEN problems

In the ancient times we were imagining that Artificial Intelligence could easily be achieved just by using the IF THEN statement known from the programming languages like Pascal. We were wrong. Why? I think the reason is still not quite clear, even though we know algorithms like Q-learning or minimax. The problem with IF THEN is that it ignores the hidden variables. It is obviously based on the visible (input) variables only. Building complex logical expressions on them does not help. With IF THEN we concentrate on the visible variables ignoring the history.

The hidden variables are all about history. If we know how the world works (we know its "model" to say it in the Perkun/Wlodkowic terms) and we know the history then we can figure out what the hidden variables values look like - building the "belief", i.e. the probability distribution over the states.

Ignoring the hidden variables is not the only IF THEN problem. Simply mapping the input variables to actions does not explain the computer why these actions should be performed. It is much better to express it in terms of the payoff function (like in minimax or Perkun). Mapping game states to payoff function allows us to compare the game states (by comparing their "images" in the payoff function).

It is trivial to explain why hidden variables are necessary. Imagine an automaton which can perform a single action and it can see on input the values 0,0,1,1,0,0,1,1,... and so on. What is the 0's successor ? Either 0 or 1. With 50% probability. What is the 1's successor? Again either 0 or 1. Also with 50% probability. But if you introduce a hidden variable so that the state is denotes by both input variable and the hidden variable then you can present an automaton as follows:

Now the automaton has become deterministic, due to the introduced hidden variable! In Perkun you would describe it as follows:




values 

{ 
    value zero, one; 
}
variables
{
    input variable alpha:{zero,one};
    hidden variable beta:{zero,one};
    output variable action:{zero};
}
payoff {}
model
{
    set({alpha=>zero,beta=>zero},{action=>zero},{alpha=>one,beta=>zero},1.0);
    set({alpha=>one,beta=>zero},{action=>zero},{alpha=>one,beta=>one},1.0);
    set({alpha=>one,beta=>one},{action=>zero},{alpha=>zero,beta=>one},1.0);
    set({alpha=>zero,beta=>one},{action=>zero},{alpha=>zero,beta=>zero},1.0);
}

I have omitted the payoff function for convenience, anyway there is only one action possible. But the point is that by introducing hidden variables even non-deterministic automatons can become deterministic! Or at least less non-deterministic!

The conclusion is that IF THEN is not bad at all, but we deal with something much more complex, possibly with thousands of hidden variables there. And we have to take them into account, at least with probability, just like Perkun (or Wlodkowic) does.

You can download Perkun (and Wlodkowic) from https://sourceforge.net/projects/perkun/.