Giter Club home page Giter Club logo

release-1.0's Introduction

Ariadne

License: GPL v3 Build Status codecov

This is the frozen 1.0 release of the Ariadne C++ library.

Installation

These installation instructions have been tested on Ubuntu 16.04 and macOS 10.12.

For the Ubuntu installation, we will refer to packages available on Aptitude. The macOS installation instead will assume you are using the Brew package manager.

The build system is CMake. The compiler we tested the library under Ubuntu is g++, while for macOS is clang. To build the library in a clean way, it is preferable that you set up a build subdirectory:

$ mkdir build
$ cd build

Dependencies

The library dependencies of Ariadne are the following:

Ubuntu

Aptitude packages required: git cmake libboost-system-dev libboost-serialization-dev libboost-thread-dev libgtk2.0-dev libcairo2-dev libbdd-dev

macOS

  1. Install the Command Line Developer Tools (will also be asked when installing Homebrew) from the Apple Store

  2. Install Homebrew from http://brew.sh/

    Homebrew packages required: cmake boost gtk cairo

  3. No Buddy package is offered, you need to compile the library from https://sourceforge.net/projects/buddy/

    Download and extract the Buddy package, then from the extracted directory:

$ ./configure $ make $ make install ```

Optionally, if you want to build the documentation, you need Doxygen and a working Latex distribution (including the Math packages).

Building

Then you can prepare the build environment:

$ cmake ..

At this point, if no error arises, you can build the library itself:

$ make

Optionally, you can also run the test suite for the library:

$ make test

where no error should appear.

If you want to build the documentation, you have to issue the following:

$ make doc

Installing globally

To install the library globally, you must do

$ make install

To find the installed library under Ubuntu, you may need to set the LD_LIBRARY_PATH variable in the .bashrc file:

export LD_LIBRARY_PATH=/usr/local/lib

To test the correct installation, you may build the tutorial/ example, which relies on Ariadne being present within system library and include directories.

release-1.0's People

Contributors

albertocasagrande avatar davide-univr avatar davidebreso avatar fonskuijk avatar ivan-zapreev avatar lgeretti avatar pietercollins avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar

release-1.0's Issues

Provide a list of warnings/errors for an automaton definition

Originally reported by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

In order to enable the checking of a file-type definition of an automaton, list the issues that may be possible when defining a single automaton. Organize them as warnings (non-blocking) and errors (blocking), also providing the scope of blocking in the second case (allows to check for multiple errors on different sections of the definition file, without generating at the same time a large amount of errors.

Identify the zi ratio on x0_critical/x0_far for different values of Tscan

Originally reported by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

For the laser example, provide the actual values of the ratio between the zi value on the critical x0 and the zi value on a point far for the edge, for different values of Tscan. This will prove that higher periods yield better ratios (i.e., closer to 1 instead of higher than 1) and are preferable.

dummy issue

filler issue created by bitbucket_issue_migration

Input/internal/output parameters

Originally reported by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

We should be able to support parameters which can be shared across automata. This is useful when a component is better represented compositionally, even if its parameters are present in more than one automaton. Otherwise, using the same parameter in different automata is prone to omissions when the value of the parameter is changed globally.

Input parameters would have no specified value and would need to be provided by an output parameter of another automaton. Internal parameters have automaton-wide scope and thus can be repeated within a system. Output parameters have system-wide scope and thus cannot be repeated. Substitution of parameters (as in parametric analysis) would still operate regardless of the visibility of the parameter.

Discretization issue on CMake vs Autotools

Originally reported by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

It appears that since we introduced CMake as a build system instead of Autotools, there is a reachability calculation issue that makes, for example, the watertank safety verification problem yield always true even if the setup is clearly unsafe.

The interested commit is 2564f1b , where both the build systems are available and it can be clearly seen that CMake has the issue while Autotools does not. The problem is present independently of the platform, and consequently the compiler.

Account for default reset values

Originally reported by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

Currently, providing an empty reset map results in a reduction of the target space to the empty space. Similarly, partial resets are handled incorrectly. An unspecified reset for a space variable instead should be interpreted as the identity function, as happens when we use the syntax for a new transition where no reset is specified.

TaylorModel::value() after reconditioning not working correctly

Originally reported by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

Thee reconditioning routine makes the value() method return 0.

For example, on ariadne, the code

#!c++
    Precision64 dp;
    ThresholdSweeper<Float64> swp(dp,1e-16);
    ValidatedTaylorModel<Float64> original({ {{0,0,0,0},4.}, {{1,0,0,0},1e-1}, {{0,1,0,0},1e-2} }, 1e-4, swp);
    Array<SizeType> discarded_variables(1);
    discarded_variables[0] = 1;
    ValidatedTaylorModel<Float64> reconditioned=recondition(original,discarded_variables,2,0);

returns the following original and reconditioned models:

#!c++

TM[4]( 4.0000000000000000 +0.1000000000000000*s0 +0.0100000000000000*s1+/-0.001)
TM[5]( 4.0000000000000000 +0.1000000000000000*s0 +0.0101000000000000*s3+/-0.000)

which are clearly correct.

Doing the same on the stable repository using the code

#!c++
    TaylorModel original=TaylorModel(Expansion<Float>(4,3, 0,0,0,0,4., 1,0,0,0,1e-1, 0,1,0,0,1e-2), 1e-4);
    Array<uint> discarded_variables(1);
    discarded_variables[0] = 1;
    TaylorModel reconditioned=recondition(original,discarded_variables,2,0);

Instead returns the following:

#!c++

(4.000000e+00+1.000000e-01*x0+1.000000e-02*x1+/-1.000000e-04)
(1.010000e-02*x3+4.000000e+00+1.000000e-01*x0+/-0.000000e+00)

which is still correct, but the x3 term is at the beginning. This may be a hint as to the source of the problem.

For practical purposes I attach the implementation of the recondition method for TaylorModel, in the two repositories. They appear the same to me.

Missed events when the step size is large

Originally reported by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

Using a very large step (i.e., 70), the painting example shows a problem: the guard for comes/leaves events is hit along with the switch_left or switch_right. Ultimately, two trajectories for the comes or switch_left/switch_right are produced. The first one has a large error and it may stop, the second one continues unabated. The ending result is a sequence of switch_left and switch_right events (in which the cover event is not even hit).

Input events acceptance influences the event source automaton

Originally reported by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

As it currently happens, if an automaton A1 fires an event E and an automaton A2 accepts that event in only a given location LE, the composed automaton accepts the event E only for a source location where A2 is in LE. This prevents the automaton A1 in the composition to evolve independently, by constraining it to fire the event only for a given location of A2.

Improve error absorption

Originally reported by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

It may be the case that error may be kept bound, thus allowing unlimited flight ability. The benchmark is still the circle-unbound example, which exhibits an alternated reduction of the widths of the two variables, if used in conjunction with the current absorption routine.
Will probably need to be paired with the adaptive integration step routine.

Review `Void Enclosure:: uniform_error_recondition()`

Originally reported by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

The implementation of uniform error reconditioning in geometry/enclosure.cc:1032 seems odd to me. I assume that it should work by collecting all the result indices for which a relatively large error is present in the model, then it modifies the models for those dimensions by creating a new parameter that encloses the error (which is then removed).

My doubts:

  1. The error_domains variable is assigned twice with no particular reason.
  2. The result dimensions chosen for moving the error into a new parameter do not match the dimensions for which the error is relatively large: we should apply the reconditioning to the large_error_indices[i] dimensions.
  3. The second error>MAXIMUM_ERROR seems redundant to me.

Analyze the possibility to perform mesh reachability analysis

Originally reported by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

To account for situations where a variable is defined in a space, we have to be able to analyze its behavior in such space. Being the space continuous, there would be R^n variables involved. Instead, we may work on intervals by splitting the space. Additionally, the number of variables may be adaptive, by updating only those that have a "fast" evolution; this solution could restrict the usability of the variable though.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.