Free conditional probability software for linux

Decision::Markov is a Perl module with markov models for decision analysis.

SYNOPSIS

use Decision::Markov;
$model = new Decision::Markov;
$state = $model->AddState("Name",$utility);
$error = $model->AddPath($state1,$state2,$probability);
$error = $model->Check
$model->Reset([$starting_state,[$number_of_patients]]);
$error = $model->StartingState($starting_state[,$number_of_patients]);
$model->DiscountRate($rate);
($utility,$cycles) = $model->EvalMC();
$state = $model->EvalMCStep($cycle);
($utility,$cycles) = $model->EvalCoh();
$patients_left = $model->EvalCohStep($cycle);
$model->PrintCycle($FH,$cycle);
$model->PrintMatrix($FH);

This module provides functions used to built and evaluate Markov models for use in decision analysis. A Markov model consists of a set of states, each with an associated utility, and links between states representing the probability of moving from one node to the next. Nodes typically include links to themselves. Utilities and probabilities may be fixed or may be functions of the time in cycles since the model began running.

Visual difference metrics can predict whether differences between two images are visible to the human observer or not. Such metrics are used for testing either visibility of information (whether we can see important visual information) or visibility of noise (to make sure we do not see any distortions in images, e.g. due to lossy compression).

The image below shows how two input images, a reference image (upper left) and a distorted image (lower left), are processed with the VDP to produce a probability of detection map (right). Such probability of detection map tells how likely we will notice a difference between two images for each part of an image.

Red color denotes high probability, green - low probability. Red color is mostly present in the areas where there is a snow covered path. Because of smooth texture of the snow, there is not much visual masking and distortions are easily visible.

Although there are dozens of visible difference metrics that serve a similar purpose, our Visual Difference Predictor for HDR images (HDR-VDP) has two unique advantages: firstly, our metric works with a full range of luminance values that can be meet in a real word (HDR images), and secondly, we offer a complete source code for free.

High Dynamic Range Visible Difference Predictor (HDR-VDP) can work within the complete range of luminance the human eye can see. An input to our metric is a high dynamic range (HDR) image, or an ordinary 8-bits-per-color image, converted to the actual luminance values. The proposed metric takes into account the aspects of high contrast vision, like scattering of the light in the optics (OTF), nonlinear response to light for the full range of luminance, and local adaptation.

VXL (the Vision-something-Libraries) is a collection of C++ libraries designed for computer vision research and implementation. The project was created from TargetJr and the IUE with the aim of making a light, fast and consistent system. VXL is written in ANSI/ISO C++ and is designed to be portable over many platforms.

The core libraries in VXL are:

vnl (numerics): Numerical containers and algorithms. e.g. matrices, vectors, decompositions, optimisers.
vil (imaging): Loading, saving and manipulating images in many common file formats, including very large images.
vgl (geometry): Geometry for points, curves and other elementary objects in 1, 2 or 3 dimensions.
vsl (streaming I/O), vbl (basic templates), vul (utilities): Miscellaneous platform-independent functionality.

As well as the core libraries, there are libraries covering numerical algorithms, image processing, co-ordinate systems, camera geometry, stereo, video manipulation, structure recovery from motion, probability modelling, GUI design, classification, robust estimation, feature tracking, topology, structure manipulation, 3d imaging, and much more.

Each core library is lightweight, and can be used without reference to the other core libraries. Similarly, the non-core libraries dont depend on more than absolutely necessary, so you can compile and link just the libraries you really need.

2E Programming Language (two es, as in ee, or expression evaluator) is a simple algebraic syntax language. It natively supports expressions (composed of operators and operands), and function definitions, and basically nothing else. Therefore, it can be fairly straight-forward to learn (assuming you are already familiar with general programming constructs).
The language itself is refered to as 2e, however the interpreter is called ee.
An operand can be a literal, such as a numeric value (integer or floating point), a quoted string, a single-quoted character, a variable or a function call. Operators consist of the standard algebraic operators (i.e., *, /, +, -), assignment ("="), logical operators (, =, ==), sub-expression join operator (";"), and a conditional operator pair ("? :") like in C. Also added, is an iterative conditional pair ("?? :").
Heres a couple of examples:
ee -p 2 + 3 * 7
23
In this case, when called with the "-p" flag, the next parameter is evaluated and the final result printed. The "-c" flag does the same thing, but doesnt print the final result (use this when the expression already contains output statements).
ee -c x = 7; y = 11; z = (x * y); print(z; "n")
77
The ";" operator isnt really a statement terminator, it is actually a join operator. It evaluates the left and right expressions, and returns the result of the right hand side. It has the lowest order of precedence, so in general use you can treat it like a statement terminator (however it can be used in the middle of a larger expression, such as within parentheses grouping). It also does double-duty as a function parameter delimeter, such as the print function in the previous example.
The way that the "?" (conditoinal) operator works is as follows:
result = expr_test ? expr_true : expr_false
If expr_test is true (non-zero), then expr_true is evaluated and returned, otherwise expr_false is evaluated and returned. This is just like the inline conditional in C.
Also supported, is the iterative conditional:
result = expr_test ?? expr_true : expr_false
This will evaluate expr_test repeatedly, and as long as it is true, will evaluate expr_true. Once expr_test becomes false, then the final expr_true value is returned as the result of the whole expression. However, if expr_test never was true to begin with, then and only then is expr_false evaluated and returned. Therefore, expr_false can be used for some error handling, for example.
If an operator of lower precedence than ? or ?? is encounterd such as the ";" (join) operator, then a default false target will automatically be assumed. Therefore,
result = expr_test ? expr_true : 0; ...
result = expr_test ? expr_true; ...
are both the same. Heres a more extensive example, highlighting a few more of the operands avaliable. This example also calls the interpreter using the unix "#!" syntax, same as what is used for other scripting languages.
#!/usr/local/bin/ee
# This is a comment
i = 0;
x = 0;
i < 10 ?? ( # Read this as "while i is less than 10"
j = 0;
j < 5 ?? ( # while j < 5
array[i][j] = x; # here we are assigning a value to a 2-dimentional array
j++;
x++
);
i++
)
This example uses the iterative conditional operator to initialize an array. Notice the missing ";" after x++ and i++. this is because they are not followed by an operand (instead, in this case are followed by a closing parenthese). The ";" operator is a binary operator, no different than +, -, *, /, etc. Therefore, it is only used between to operands or two sub-expressions.
Enhancements:
- This release adds a bunch of functions to round out the string handling capabilities of 2e.
- Also added are "anonymous" functions, bitwise operators, and a few code cleanups.

GNU Superoptimizer is a project that uses an approach to finding the shortest instruction sequence for a given function.
The superoptimizer is a function sequence generator that uses an exhaustive
generate-and-test approach to finding the shortest instruction sequence for
a given function. You have to tell the superoptimizer which function and
which CPU you want to generate code for, and how many instructions you can
accept.
The superoptimizer cant generate very long sequences, unless you have a
very fast computer or very much spare time. The time complexity of the used
algorithm is approximately
2n
O(m n )
where m is the number of available instructions on the architecture and n is
the shortest sequence for the goal function. The practical sequence length
limit depends on the target architecture and goal function arity; In most
cases it is about 5, but for a rich instruction set as the HPPA it is just
4. The longest sequence ever generated was for the MC68020 and 7
instructions long. It took several weeks to generate it...
The superoptimizer cant guarantee that it finds the best possible
instruction sequences for all possible goal functions. For example, it
doesnt even try to include immediate constants (other that -1, 0, +1, and
the smallest negative and biggest positive numbers) in the sequences.
Other reasons why not optimal sequences might be found is that not all
instructions are included, not even in their register-only form. Also, some
instructions included might not be correctly simulated. If you encounter
any of these problems, please report them to the address below.
WARNING! The generated sequences might be incorrect with a very small
probability. Always make sure a sequence is correct before using it. So
far, I have never encountered any incorrect sequences. If you find one,
please let me know about it!
Having said this, note that the superoptimizer practically always finds
optimal and correct sequences for functions that depend on registers only.
Enhancements:
- Delete unused variable tot_bits.
- Make state1 have char type.
- Use random() on alpha, since srand48 doesnt work there.
- Return small numbers with high probability.

IDS::Algorithm::MM is a Perl module created to learn or test using a first-order Markov Model (MM).

SYNOPSIS

A usage synopsis would go here. Since it is not here, read on.
In section 4.2 in Kruegel and Vignas paper, they ignored the probability information that the MM provided, and produced a binary result. In effect, they were using the constructed MM as a {N,D}FA.

Someday more will be here.

Ideally, we would be using the algorithm from stolcke94bestfirst. Constructing a DFA rather than a NFA in effect has performed most of the state merging that stolcke93hidden do.

Consider also a java or C/C++ implementaion: http://www.ghmm.org/ http://www.run.montefiore.ulg.ac.be/~francois/software/jahmm/

Useful information: http://www.cs.brown.edu/research/ai/dynamics/tutorial/Documents/HiddenMarkovModels.html http://www.comp.leeds.ac.uk/roger/HiddenMarkovModels/html_dev/main.html L R Rabiner and B H Juang, `An introduction to HMMs, IEEE ASSP Magazine, 3, 4-16.

printvcg

printvcg(filehandle)

Print in a form usable by VCG for printing the DFA.

If the filehandle is specified, print there; otherwise, print to STDOUT.
This code was stolen from DFA, and does not know about the probabilities.
load(filehandle)

Load a MM from a file; this is the inverse of "print", and the format we expect is that used in $self->print.

test(tokensref, string, instance)

Test the string of tokens and calculate the probability of the string being seen. At each stage, we get a p in [0,1]. The result is the product of these probabilities.
Note that if a transition cannot be made, we return a 0 probability.

add(tokensref, string, instance)

The collection of tokens (in the list referenced by tokensref) is a complete example of a list that should be accepted by the DFA.

string and instance are IDS::Test framework arguments that we ignore because we do not need them.

WE add the transition from the last token to the (ACCEPT) state.

add_transition(from, token)

Add a transition from one state to another when the specified token is received. It is not an error to try to add an existing transition. In that event, this function quietly returns. If no such transition exists, we look for a transition on the token; if so, we add an edge to the destination node for the existing edge. Finally, if there is no other choice, we create a new state and add the edge.

generalize()

Reduce the number of states in the model.

Our building a DFA rather than a NFA has in effect performed most of the state merging that would have occurred.

XXX We should still be doing some checks for additional merge possibilities.
XXX A proof that the DFA is effectively the NFA with merged states would be useful.

Video Disk Recorder (VDR) is a digital satellite receiver program using Linux and DVB technologies. Video Disk Recorder can record MPEG2 streams, as well as output the stream to TV. It also supports plugins for DVD, DivX, or MP3 playback and more.
Main features:
- Operation entirely via DVB cards On Screen Display and infrared control (LIRC/RCU) or keyboard
- Support for multiple DVB cards (up to four, at least one full featured card with video out required) and "conditional access" (CICAM)
- Channel groups
- EPG display by channel or by time ("Whats on now/next")
- Timers: Programming via EPG or manually, priority/lifetime model, single-shot or repeating timers which use EPG subtitle info as recordings title additionally
- Recording storage on disk: Automatically splitting of recording into files (<<less