Gecode::Options Class Reference
[Commandline options for running scripts]
Options for scripts More...
#include <driver.hh>
Classes | |
| class | _I |
| Helper class storing Gist inspectors. More... | |
Public Member Functions | |
| Options (const char *s) | |
| Initialize options for script with name s. | |
Public Attributes | |
| class Gecode::Options::_I | inspect |
| Helper class storing Gist inspectors. | |
Model options | |
|
| |
| Driver::StringOption | _model |
| General model options. | |
| Driver::StringOption | _symmetry |
| General symmetry options. | |
| Driver::StringOption | _propagation |
| Propagation options. | |
| Driver::IplOption | _ipl |
| Integer propagation level. | |
| Driver::StringOption | _branching |
| Branching options. | |
| Driver::DoubleOption | _decay |
| Decay option. | |
| Driver::UnsignedIntOption | _seed |
| Seed option. | |
| Driver::DoubleOption | _step |
| Step option. | |
| void | model (int v) |
| Set default model value. | |
| void | model (int v, const char *o, const char *h=NULL) |
| Add model option value for value v, string o, and help h. | |
| int | model (void) const |
| Return model value. | |
| void | symmetry (int v) |
| Set default symmetry value. | |
| void | symmetry (int v, const char *o, const char *h=NULL) |
| Add symmetry option value for value v, string o, and help h. | |
| int | symmetry (void) const |
| Return symmetry value. | |
| void | propagation (int v) |
| Set default propagation value. | |
| void | propagation (int v, const char *o, const char *h=NULL) |
| Add propagation option value for value v, string o, and help h. | |
| int | propagation (void) const |
| Return propagation value. | |
| void | ipl (IntPropLevel i) |
| Set default integer propagation level. | |
| IntPropLevel | ipl (void) const |
| Return integer propagation level. | |
| void | branching (int v) |
| Set default branching value. | |
| void | branching (int v, const char *o, const char *h=NULL) |
| Add branching option value for value v, string o, and help h. | |
| int | branching (void) const |
| Return branching value. | |
| void | decay (double d) |
| Set default decay factor. | |
| double | decay (void) const |
| Return decay factor. | |
| void | seed (unsigned int s) |
| Set default seed value. | |
| unsigned int | seed (void) const |
| Return seed value. | |
| void | step (double s) |
| Set default step value. | |
| double | step (void) const |
| Return step value. | |
Search options | |
|
| |
| Driver::StringOption | _search |
| Search options. | |
| Driver::UnsignedIntOption | _solutions |
| How many solutions. | |
| Driver::DoubleOption | _threads |
| How many threads to use. | |
| Driver::UnsignedIntOption | _c_d |
| Copy recomputation distance. | |
| Driver::UnsignedIntOption | _a_d |
| Adaptive recomputation distance. | |
| Driver::UnsignedIntOption | _d_l |
| Discrepancy limit for LDS. | |
| Driver::UnsignedIntOption | _node |
| Cutoff for number of nodes. | |
| Driver::UnsignedIntOption | _fail |
| Cutoff for number of failures. | |
| Driver::UnsignedIntOption | _time |
| Cutoff for time. | |
| Driver::UnsignedIntOption | _assets |
| Number of assets in a portfolio. | |
| Driver::UnsignedIntOption | _slice |
| Size of a portfolio slice. | |
| Driver::StringOption | _restart |
| Restart method option. | |
| Driver::DoubleOption | _r_base |
| Restart base. | |
| Driver::UnsignedIntOption | _r_scale |
| Restart scale factor. | |
| Driver::BoolOption | _nogoods |
| Whether to use no-goods. | |
| Driver::UnsignedIntOption | _nogoods_limit |
| Limit for no-good extraction. | |
| Driver::DoubleOption | _relax |
| Probability to relax variable. | |
| Driver::BoolOption | _interrupt |
| Whether to catch SIGINT. | |
| void | search (int v) |
| Set default search value. | |
| void | search (int v, const char *o, const char *h=NULL) |
| Add search option value for value v, string o, and help h. | |
| int | search (void) const |
| Return search value. | |
| void | solutions (unsigned int n) |
| Set default number of solutions to search for. | |
| unsigned int | solutions (void) const |
| Return number of solutions to search for. | |
| void | threads (double n) |
| Set number of parallel threads. | |
| double | threads (void) const |
| Return number of parallel threads. | |
| void | c_d (unsigned int d) |
| Set default copy recomputation distance. | |
| unsigned int | c_d (void) const |
| Return copy recomputation distance. | |
| void | a_d (unsigned int d) |
| Set default adaptive recomputation distance. | |
| unsigned int | a_d (void) const |
| Return adaptive recomputation distance. | |
| void | d_l (unsigned int d) |
| Set default discrepancy limit for LDS. | |
| unsigned int | d_l (void) const |
| Return discrepancy limit for LDS. | |
| void | node (unsigned int n) |
| Set default node cutoff. | |
| unsigned int | node (void) const |
| Return node cutoff. | |
| void | fail (unsigned int n) |
| Set default failure cutoff. | |
| unsigned int | fail (void) const |
| Return failure cutoff. | |
| void | time (unsigned int t) |
| Set default time cutoff. | |
| unsigned int | time (void) const |
| Return time cutoff. | |
| void | assets (unsigned int n) |
| Set default number of assets in a portfolio. | |
| unsigned int | assets (void) const |
| Return slice size in a portfolio. | |
| void | slice (unsigned int n) |
| Set default slice size in a portfolio. | |
| unsigned int | slice (void) const |
| Return slice size in a portfolio. | |
| void | restart (RestartMode r) |
| Set default restart mode. | |
| RestartMode | restart (void) const |
| Return restart mode. | |
| void | restart_base (double base) |
| Set default restart base. | |
| double | restart_base (void) const |
| Return restart base. | |
| void | restart_scale (unsigned int scale) |
| Set default restart scale factor. | |
| unsigned int | restart_scale (void) const |
| Return restart scale factor. | |
| void | nogoods (bool b) |
| Set default nogoods posting behavior. | |
| bool | nogoods (void) const |
| Return whether nogoods are used. | |
| void | nogoods_limit (unsigned int l) |
| Set default nogoods depth limit. | |
| unsigned int | nogoods_limit (void) const |
| Return depth limit for nogoods. | |
| void | relax (double d) |
| Set default relax probability. | |
| double | relax (void) const |
| Return default relax probability. | |
| void | interrupt (bool b) |
| Set default interrupt behavior. | |
| bool | interrupt (void) const |
| Return interrupt behavior. | |
Execution options | |
|
| |
| Driver::StringOption | _mode |
| Script mode to run. | |
| Driver::UnsignedIntOption | _samples |
| How many samples. | |
| Driver::UnsignedIntOption | _iterations |
| How many iterations per sample. | |
| Driver::BoolOption | _print_last |
| Print only last solution found. | |
| Driver::StringValueOption | _out_file |
| Where to print solutions. | |
| Driver::StringValueOption | _log_file |
| Where to print statistics. | |
| Driver::TraceOption | _trace |
| Trace flags for tracing. | |
| Driver::IntOption | _profiler_id |
| Use this execution id for the CP-profiler. | |
| Driver::UnsignedIntOption | _profiler_port |
| Connect to this port. | |
| Driver::BoolOption | _profiler_info |
| Whether solution information should be sent to the CPProfiler. | |
| void | mode (ScriptMode em) |
| Set default mode. | |
| ScriptMode | mode (void) const |
| Return mode. | |
| void | samples (unsigned int s) |
| Set default number of samples. | |
| unsigned int | samples (void) const |
| Return number of samples. | |
| void | iterations (unsigned int i) |
| Set default number of iterations. | |
| unsigned int | iterations (void) const |
| Return number of iterations. | |
| void | print_last (bool p) |
| Set whether to print only last solution found. | |
| bool | print_last (void) const |
| Return whether to print only last solution found. | |
| void | out_file (const char *f) |
| Set default output file name for solutions. | |
| const char * | out_file (void) const |
| Get file name for solutions. | |
| void | log_file (const char *f) |
| Set default output file name for Gecode stats. | |
| const char * | log_file (void) const |
| Get file name for Gecode stats. | |
| void | trace (int f) |
| Set trace flags. | |
| int | trace (void) const |
| Return trace flags. | |
| void | profiler_id (int i) |
| Set profiler execution identifier. | |
| int | profiler_id (void) const |
| Return profiler execution id. | |
| void | profiler_port (unsigned int p) |
| Set profiler port. | |
| unsigned int | profiler_port (void) const |
| Return profiler execution id. | |
| void | profiler_info (bool b) |
| Whether solution info should be sent to profiler. | |
| bool | profiler_info (void) const |
| Return whether solution info should be sent to profiler. |
Detailed Description
Options for scripts
Definition at line 366 of file driver.hh.
Constructor & Destructor Documentation
| Gecode::Options::Options | ( | const char * | s | ) |
Initialize options for script with name s.
Definition at line 576 of file options.cpp.
Member Function Documentation
| void Gecode::Options::model | ( | int | v | ) | [inline] |
Set default model value.
Definition at line 177 of file options.hpp.
| void Gecode::Options::model | ( | int | v, | |
| const char * | o, | |||
| const char * | h = NULL | |||
| ) | [inline] |
Add model option value for value v, string o, and help h.
Definition at line 181 of file options.hpp.
| int Gecode::Options::model | ( | void | ) | const [inline] |
Return model value.
Definition at line 185 of file options.hpp.
| void Gecode::Options::symmetry | ( | int | v | ) | [inline] |
Set default symmetry value.
Definition at line 190 of file options.hpp.
| void Gecode::Options::symmetry | ( | int | v, | |
| const char * | o, | |||
| const char * | h = NULL | |||
| ) | [inline] |
Add symmetry option value for value v, string o, and help h.
Definition at line 194 of file options.hpp.
| int Gecode::Options::symmetry | ( | void | ) | const [inline] |
| void Gecode::Options::propagation | ( | int | v | ) | [inline] |
Set default propagation value.
Definition at line 203 of file options.hpp.
| void Gecode::Options::propagation | ( | int | v, | |
| const char * | o, | |||
| const char * | h = NULL | |||
| ) | [inline] |
Add propagation option value for value v, string o, and help h.
Definition at line 207 of file options.hpp.
| int Gecode::Options::propagation | ( | void | ) | const [inline] |
Return propagation value.
Definition at line 211 of file options.hpp.
| void Gecode::Options::ipl | ( | IntPropLevel | i | ) | [inline] |
Set default integer propagation level.
Definition at line 216 of file options.hpp.
| IntPropLevel Gecode::Options::ipl | ( | void | ) | const [inline] |
Return integer propagation level.
Definition at line 220 of file options.hpp.
| void Gecode::Options::branching | ( | int | v | ) | [inline] |
Set default branching value.
Definition at line 225 of file options.hpp.
| void Gecode::Options::branching | ( | int | v, | |
| const char * | o, | |||
| const char * | h = NULL | |||
| ) | [inline] |
Add branching option value for value v, string o, and help h.
Definition at line 229 of file options.hpp.
| int Gecode::Options::branching | ( | void | ) | const [inline] |
Return branching value.
Definition at line 233 of file options.hpp.
| void Gecode::Options::decay | ( | double | d | ) | [inline] |
Set default decay factor.
Definition at line 238 of file options.hpp.
| double Gecode::Options::decay | ( | void | ) | const [inline] |
Return decay factor.
Definition at line 242 of file options.hpp.
| void Gecode::Options::seed | ( | unsigned int | s | ) | [inline] |
Set default seed value.
Definition at line 247 of file options.hpp.
| unsigned int Gecode::Options::seed | ( | void | ) | const [inline] |
Return seed value.
Definition at line 251 of file options.hpp.
| void Gecode::Options::step | ( | double | s | ) | [inline] |
Set default step value.
Definition at line 256 of file options.hpp.
| double Gecode::Options::step | ( | void | ) | const [inline] |
Return step value.
Definition at line 260 of file options.hpp.
| void Gecode::Options::search | ( | int | v | ) | [inline] |
Set default search value.
Definition at line 270 of file options.hpp.
| void Gecode::Options::search | ( | int | v, | |
| const char * | o, | |||
| const char * | h = NULL | |||
| ) | [inline] |
Add search option value for value v, string o, and help h.
Definition at line 274 of file options.hpp.
| int Gecode::Options::search | ( | void | ) | const [inline] |
Return search value.
Definition at line 278 of file options.hpp.
| void Gecode::Options::solutions | ( | unsigned int | n | ) | [inline] |
Set default number of solutions to search for.
Definition at line 283 of file options.hpp.
| unsigned int Gecode::Options::solutions | ( | void | ) | const [inline] |
Return number of solutions to search for.
Definition at line 287 of file options.hpp.
| void Gecode::Options::threads | ( | double | n | ) | [inline] |
Set number of parallel threads.
Definition at line 292 of file options.hpp.
| double Gecode::Options::threads | ( | void | ) | const [inline] |
Return number of parallel threads.
Definition at line 296 of file options.hpp.
| void Gecode::Options::c_d | ( | unsigned int | d | ) | [inline] |
Set default copy recomputation distance.
Definition at line 301 of file options.hpp.
| unsigned int Gecode::Options::c_d | ( | void | ) | const [inline] |
Return copy recomputation distance.
Definition at line 305 of file options.hpp.
| void Gecode::Options::a_d | ( | unsigned int | d | ) | [inline] |
Set default adaptive recomputation distance.
Definition at line 310 of file options.hpp.
| unsigned int Gecode::Options::a_d | ( | void | ) | const [inline] |
Return adaptive recomputation distance.
Definition at line 314 of file options.hpp.
| void Gecode::Options::d_l | ( | unsigned int | d | ) | [inline] |
Set default discrepancy limit for LDS.
Definition at line 319 of file options.hpp.
| unsigned int Gecode::Options::d_l | ( | void | ) | const [inline] |
Return discrepancy limit for LDS.
Definition at line 323 of file options.hpp.
| void Gecode::Options::node | ( | unsigned int | n | ) | [inline] |
Set default node cutoff.
Definition at line 328 of file options.hpp.
| unsigned int Gecode::Options::node | ( | void | ) | const [inline] |
Return node cutoff.
Definition at line 332 of file options.hpp.
| void Gecode::Options::fail | ( | unsigned int | n | ) | [inline] |
Set default failure cutoff.
Definition at line 337 of file options.hpp.
| unsigned int Gecode::Options::fail | ( | void | ) | const [inline] |
Return failure cutoff.
Definition at line 341 of file options.hpp.
| void Gecode::Options::time | ( | unsigned int | t | ) | [inline] |
Set default time cutoff.
Definition at line 346 of file options.hpp.
| unsigned int Gecode::Options::time | ( | void | ) | const [inline] |
Return time cutoff.
Definition at line 350 of file options.hpp.
| void Gecode::Options::assets | ( | unsigned int | n | ) | [inline] |
Set default number of assets in a portfolio.
Definition at line 355 of file options.hpp.
| unsigned int Gecode::Options::assets | ( | void | ) | const [inline] |
Return slice size in a portfolio.
Definition at line 359 of file options.hpp.
| void Gecode::Options::slice | ( | unsigned int | n | ) | [inline] |
Set default slice size in a portfolio.
Definition at line 364 of file options.hpp.
| unsigned int Gecode::Options::slice | ( | void | ) | const [inline] |
Return slice size in a portfolio.
Definition at line 368 of file options.hpp.
| void Gecode::Options::restart | ( | RestartMode | r | ) | [inline] |
Set default restart mode.
Definition at line 373 of file options.hpp.
| RestartMode Gecode::Options::restart | ( | void | ) | const [inline] |
Return restart mode.
Definition at line 377 of file options.hpp.
| void Gecode::Options::restart_base | ( | double | base | ) | [inline] |
Set default restart base.
Definition at line 382 of file options.hpp.
| double Gecode::Options::restart_base | ( | void | ) | const [inline] |
Return restart base.
Definition at line 386 of file options.hpp.
| void Gecode::Options::restart_scale | ( | unsigned int | scale | ) | [inline] |
Set default restart scale factor.
Definition at line 391 of file options.hpp.
| unsigned int Gecode::Options::restart_scale | ( | void | ) | const [inline] |
Return restart scale factor.
Definition at line 395 of file options.hpp.
| void Gecode::Options::nogoods | ( | bool | b | ) | [inline] |
Set default nogoods posting behavior.
Definition at line 400 of file options.hpp.
| bool Gecode::Options::nogoods | ( | void | ) | const [inline] |
Return whether nogoods are used.
Definition at line 404 of file options.hpp.
| void Gecode::Options::nogoods_limit | ( | unsigned int | l | ) | [inline] |
Set default nogoods depth limit.
Definition at line 409 of file options.hpp.
| unsigned int Gecode::Options::nogoods_limit | ( | void | ) | const [inline] |
Return depth limit for nogoods.
Definition at line 413 of file options.hpp.
| void Gecode::Options::relax | ( | double | d | ) | [inline] |
Set default relax probability.
Definition at line 418 of file options.hpp.
| double Gecode::Options::relax | ( | void | ) | const [inline] |
Return default relax probability.
Definition at line 422 of file options.hpp.
| void Gecode::Options::interrupt | ( | bool | b | ) | [inline] |
Set default interrupt behavior.
Definition at line 429 of file options.hpp.
| bool Gecode::Options::interrupt | ( | void | ) | const [inline] |
Return interrupt behavior.
Definition at line 433 of file options.hpp.
| void Gecode::Options::mode | ( | ScriptMode | em | ) | [inline] |
Set default mode.
Definition at line 443 of file options.hpp.
| ScriptMode Gecode::Options::mode | ( | void | ) | const [inline] |
Return mode.
Definition at line 447 of file options.hpp.
| void Gecode::Options::samples | ( | unsigned int | s | ) | [inline] |
Set default number of samples.
Definition at line 452 of file options.hpp.
| unsigned int Gecode::Options::samples | ( | void | ) | const [inline] |
Return number of samples.
Definition at line 456 of file options.hpp.
| void Gecode::Options::iterations | ( | unsigned int | i | ) | [inline] |
Set default number of iterations.
Definition at line 461 of file options.hpp.
| unsigned int Gecode::Options::iterations | ( | void | ) | const [inline] |
Return number of iterations.
Definition at line 465 of file options.hpp.
| void Gecode::Options::print_last | ( | bool | p | ) | [inline] |
Set whether to print only last solution found.
Definition at line 470 of file options.hpp.
| bool Gecode::Options::print_last | ( | void | ) | const [inline] |
Return whether to print only last solution found.
Definition at line 474 of file options.hpp.
| void Gecode::Options::out_file | ( | const char * | f | ) | [inline] |
Set default output file name for solutions.
Definition at line 479 of file options.hpp.
| const char * Gecode::Options::out_file | ( | void | ) | const [inline] |
Get file name for solutions.
Definition at line 484 of file options.hpp.
| void Gecode::Options::log_file | ( | const char * | f | ) | [inline] |
Set default output file name for Gecode stats.
Definition at line 489 of file options.hpp.
| const char * Gecode::Options::log_file | ( | void | ) | const [inline] |
Get file name for Gecode stats.
Definition at line 494 of file options.hpp.
| void Gecode::Options::trace | ( | int | f | ) | [inline] |
Set trace flags.
Definition at line 499 of file options.hpp.
| int Gecode::Options::trace | ( | void | ) | const [inline] |
Return trace flags.
Definition at line 504 of file options.hpp.
| void Gecode::Options::profiler_id | ( | int | i | ) | [inline] |
Set profiler execution identifier.
Definition at line 515 of file options.hpp.
| int Gecode::Options::profiler_id | ( | void | ) | const [inline] |
Return profiler execution id.
Definition at line 519 of file options.hpp.
| void Gecode::Options::profiler_port | ( | unsigned int | p | ) | [inline] |
Set profiler port.
Definition at line 523 of file options.hpp.
| unsigned int Gecode::Options::profiler_port | ( | void | ) | const [inline] |
Return profiler execution id.
Definition at line 527 of file options.hpp.
| void Gecode::Options::profiler_info | ( | bool | b | ) | [inline] |
Whether solution info should be sent to profiler.
Definition at line 531 of file options.hpp.
| bool Gecode::Options::profiler_info | ( | void | ) | const [inline] |
Return whether solution info should be sent to profiler.
Definition at line 535 of file options.hpp.
Member Data Documentation
Driver::StringOption Gecode::Options::_model [protected] |
Driver::StringOption Gecode::Options::_symmetry [protected] |
Driver::StringOption Gecode::Options::_propagation [protected] |
Driver::IplOption Gecode::Options::_ipl [protected] |
Driver::StringOption Gecode::Options::_branching [protected] |
Driver::DoubleOption Gecode::Options::_decay [protected] |
Driver::UnsignedIntOption Gecode::Options::_seed [protected] |
Driver::DoubleOption Gecode::Options::_step [protected] |
Driver::StringOption Gecode::Options::_search [protected] |
Driver::UnsignedIntOption Gecode::Options::_solutions [protected] |
Driver::DoubleOption Gecode::Options::_threads [protected] |
Driver::UnsignedIntOption Gecode::Options::_c_d [protected] |
Driver::UnsignedIntOption Gecode::Options::_a_d [protected] |
Driver::UnsignedIntOption Gecode::Options::_d_l [protected] |
Driver::UnsignedIntOption Gecode::Options::_node [protected] |
Driver::UnsignedIntOption Gecode::Options::_fail [protected] |
Driver::UnsignedIntOption Gecode::Options::_time [protected] |
Driver::UnsignedIntOption Gecode::Options::_assets [protected] |
Driver::UnsignedIntOption Gecode::Options::_slice [protected] |
Driver::StringOption Gecode::Options::_restart [protected] |
Driver::DoubleOption Gecode::Options::_r_base [protected] |
Driver::UnsignedIntOption Gecode::Options::_r_scale [protected] |
Driver::BoolOption Gecode::Options::_nogoods [protected] |
Driver::DoubleOption Gecode::Options::_relax [protected] |
Driver::BoolOption Gecode::Options::_interrupt [protected] |
Driver::StringOption Gecode::Options::_mode [protected] |
Driver::UnsignedIntOption Gecode::Options::_samples [protected] |
Driver::BoolOption Gecode::Options::_print_last [protected] |
Driver::StringValueOption Gecode::Options::_out_file [protected] |
Driver::StringValueOption Gecode::Options::_log_file [protected] |
Driver::TraceOption Gecode::Options::_trace [protected] |
Driver::IntOption Gecode::Options::_profiler_id [protected] |
Driver::BoolOption Gecode::Options::_profiler_info [protected] |
Whether solution information should be sent to the CPProfiler.
Helper class storing Gist inspectors.
The documentation for this class was generated from the following files:
- gecode/driver.hh
- gecode/driver/options.cpp
- gecode/driver/options.hpp


Implementation of a function which calculates the empirical excess mass for given \eqn{\lambda} and given maximal number of modes (excessm()). Offering powerful plot features to visualize empirical excess mass (exmplot()). This includes the possibility of drawing several plots (with different maximal number of modes / cut off values) in a single graph.
| Version: | 1.0 |
| Suggests: | MASS |
| Published: | 2017-05-16 |
| Author: | Marc-Daniel Mildenberger |
| Maintainer: | Marc-Daniel Mildenberger <mildenberger.stat at web.de> |
| License: | LGPL-2 | LGPL-2.1 | LGPL-3 [expanded from: LGPL] |
| NeedsCompilation: | no |
| CRAN checks: | ExcessMass results |
| Reference manual: | ExcessMass.pdf |
| Package source: | ExcessMass_1.0.tar.gz |
| Windows binaries: | r-devel: ExcessMass_1.0.zip, r-release: ExcessMass_1.0.zip, r-oldrel: ExcessMass_1.0.zip |
| OS X binaries: | r-release: ExcessMass_1.0.tgz, r-oldrel: ExcessMass_1.0.tgz |
Please use the canonical form https://CRAN.R-project.org/package=ExcessMass to link to this page.


Dear [Customer Name],
We're pleased to confirm that your order for a more stylish sleep is now on its way.
Your items from order #9999 that have shipped include:
We'll send you a confirmation email when remaining items from your order ship.
Thank You! The [company name] team
If you have any questions, please email or call Customer Service at 1-800-555-5555.


Write a script that finds the lexicographically smallest and largest property in document, window and navigator objects


{% extends "../sub_base.html" %} {% block title %}Register Account{% endblock %} {% block sub_content %}
It's free and only takes a minute.
Please correct the following errors:
Already have an account?


Toggle navigation
DRØME
Issue One
About
Order Now
Issue NO. 1
Dichotomy, Character Play, and Haribo— dive into the world of Carly Mark.
$18


Getting {% if page.displayTitle %} {{ page.displayTitle }}... {% else %} {{ page.title }}... {% endif %}
Your download should begin automatically. If it doesn't, upgrade your browser.
Your download should begin automatically. If it doesn't, upgrade your browser.


Northern Territory
Come visit the beautiful Northern Territory, home of beautiful sites such as Uluru, and some deserts!
We are currently in the process of building a brand new resort (pictured right) in the heart of the NT.
It features a unique hotel at the peak of Uluru, with cycle paths following the circumferance of the great stone.
There are great views of the protestors from the pinacle of the building.


Course
Macro
Video
Media
Assessment
Widget
AMS
Button
Link
id:
Save changes
S C A L E Editor
Student-Centered Adaptive Learning Environment
Course editor


Welcome to my Bootstrap 4 website! Bootstrap is a free and open-source front-end library with HTML and CSS based designs.
Built with the latest version of HTML, HTML5.
Built with the latest version of Bootstap, Bootstrap 4.
Built with the latest version of CSS, CSS3.
The columns will automatically stack on top of each other when the screen is less than 576px wide.
Resize the browser window to see the effect. Responsive web design has become more important as the amount of mobile traffic now accounts for more than half of total internet traffic.
It can also display the web page diiferently depending on the screen size or viewing device.
We know that greatness in a disruptive era requires bold ambition, curious talent and a culture that believes we're smarter together.
We approach evry challenge holistically, with best-in-class expertise in data, creativity, media, technology, search, social and more. We call the Alchemy. It has the power to built our clients brands and transform their business. And while it may seem like magic, we've got it down to a science.


Allows the user to convert PDF tables to formats more amenable to analysis ('.csv', '.xml', or '.xlsx') by wrapping the PDFTables API. In order to use the package, the user needs to sign up for an API account on the PDFTables website (<https://pdftables.com/pdf-to-excel-api>). The package works by taking a PDF file as input, uploading it to PDFTables, and returning a file with the extracted data.
| Version: | 0.1 |
| Imports: | httr, tools |
| Suggests: | knitr, rmarkdown |
| Published: | 2016-02-15 |
| Author: | Eric Persson [aut, cre] |
| Maintainer: | Eric Persson <expersso5 at gmail.com> |
| BugReports: | https://www.github.com/expersso/pdftables/issues |
| License: | CC0 |
| URL: | https://www.github.com/expersso/pdftables , https://pdftables.com |
| NeedsCompilation: | no |
| Materials: | README |
| In views: | WebTechnologies |
| CRAN checks: | pdftables results |
| Reference manual: | pdftables.pdf |
| Vignettes: |
Convert PDF Tables |
| Package source: | pdftables_0.1.tar.gz |
| Windows binaries: | r-devel: pdftables_0.1.zip, r-release: pdftables_0.1.zip, r-oldrel: pdftables_0.1.zip |
| OS X binaries: | r-release: pdftables_0.1.tgz, r-oldrel: pdftables_0.1.tgz |
Please use the canonical form https://CRAN.R-project.org/package=pdftables to link to this page.


Stan Lee
The man behind the heroes of our era
Stan Lee, was an American comic book writer, editor, publisher, and producer. He rose through the ranks of a family-run business to become Marvel Comics' primary creative leader for two decades, leading its expansion from a small division of a publishing house to a multimedia corporation that dominated the comics industry.
In collaboration with others at Marvel—particularly co-writer/artists Jack Kirby and Steve Ditko—he co-created numerous popular fictional characters, including superheroes Spider-Man, the X-Men, Iron Man, Thor, the Hulk, the Fantastic Four, Black Panther, Daredevil, Doctor Strange, Scarlet Witch and Ant-Man. In doing so, he pioneered a more naturalistic approach to writing superhero comics in the 1960s, and in the 1970s he challenged the restrictions of the Comics Code Authority, indirectly leading to changes in its policies. In the 1980s he pursued development of Marvel properties in other media, with mixed results. Following his retirement from Marvel in the 1990s, he remained a public figurehead for the company, and frequently made cameo appearances in films and television shows based on Marvel characters, on which he received an executive producer credit. Meanwhile, he continued independent creative ventures into his 90s, until his death in 2018.
Lee was inducted into the comic book industry's Will Eisner Award Hall of Fame in 1994 and the Jack Kirby Hall of Fame in 1995. He received the NEA's National Medal of Arts in 2008.


Pure Functional CSS
A typical card can look like this:
source:

Some Body
 @SomeBody - 55m

This is a really fancy tweet about something that will likely offend somebody.

This is great for composing some things from scratch but all the sudden you're repeating yourself, but you still want to use some immutable styles. Wat do?
Composing components
Not part of SASS or traditional CSS, through the magic of postCSS we're able to cobble together the functional css classes into more tradtional classes via the postCSS plugin apply-class.
.card {
@apply .bd(1), .bdrad(3), .bdc(gray-l1, .p(2), .d(f), .ai(t);
}
Which then is postCSS'd into:
.card {
border-style: solid;
border-width: 1px;
border-radius: 1rem;
padding: 0.5rem;
display: flex; }
Why not just write this CSS in the first place? When you consume the same composable classes and combine them into a component, you're just consuming all the patterns in a functional way and any changes to overall design goals like spacing or font weight changes are just automatically consumed.
Lets see how the component looks now
source:

Some Body
 @SomeBody - 55m

This is a really fancy tweet about something that will likely offend somebody.

reply

retweet

heart


--- layout: default title: Code file: code/index.html lang: en ---
azul is a 3D viewer for macOS 10.14 and higher. It is intended for viewing 3D city models in CityGML 1.0 and 2.0, CityJSON 1.0, IndoorGML, OBJ, OFF and POLY. It supports loading multiple files, selecting objects by clicking them or selecting them in the sidebar, toggling the visibility of individual items, and browsing their attributes. It is currently pre-release software, but it is pretty stable and most datasets already work without problems. It is available under the GPLv3 licence.
(planar partition repair) ensures that a set of polygons form a valid planar partition, made of valid polygons and having no gaps or overlaps.
Read more:
{% imbiber pubs/publications.bib one:12pfg noimg %}(polygon repair) takes a possibly invalid polygon, gives it a consistent interpretation and returns a valid polygon according to the OGC Simple Features and ISO 19107 rules.
Read more:
{% imbiber pubs/publications.bib one:14cg noimg %}tools to construct and manipulate higher-dimensional linear cell complexes, such as incremental and non-incremental construction and extrusion
Read more:
{% imbiber pubs/publications.bib one:15ijgis_extrusion noimg %} {% imbiber pubs/publications.bib one:14icaa noimg %}small Mac visualiser to debug triangle-based algorithms
converts BibTeX to HTML using PHP


COLOMBO (Reuters) - Sri Lankans trickled into polling centers early on Saturday to choose a new president for the island-nation still struggling to recover from Easter Sunday attacks on hotels and churches that have heavily weighed on its tourism-dependent economy.
Former defense secretary Gotabaya Rajapaksa, who oversaw the military defeat of Tamil separatists 10 years ago, and government minister Sajith Premadasa are locked in a close fight, politicians and analysts say.
Rajapaksa has vowed to overhaul national security, playing on the fears of the majority Sinhalese Buddhists following the April attacks claimed by Islamic State that killed more than 250 people.
Premadasa has sought to fire up the countryside with promises of free housing, school uniforms for students and sanitary pads for women - touching on a topic rarely discussed in public anywhere in south Asia but which has drawn women to his rallies.
Police said a group of unidentified men opened fire on buses carrying Muslims to a polling station in Anuradhapura district in central Sri Lanka. There were no injuries but witnesses said there were tires burning.
At a polling station in Colombo, M. Gunasekera, a 41-year-old homemaker, said the most important problem was widespread corruption and the lack of accountability of politicians.
About 16 million people are eligible to vote, with the ballot allowing voters to choose up to three candidates in order of preference.
Votes will be counted soon after polling stations close but the results are not expected before Sunday.
Muslims who make up nearly 10 percent of Sri Lanka’s 22 million population, say they have faced hostility ever since the April attacks.
That division has come on top of long-standing grievances of ethnic Tamils, who say they are still to get justice stemming from the human rights violations during a 26-war civil war with Tamil rebels that ended in 2009.


 You start with {{Budget|c}}. Make your choice accordingly from options below.
You are the Agency. You start with {{Budget|c}}. Make your choice accordingly from options below.


Get the user home directory with fallback to the system temp directory
Useful in cases where the home directory either isn't set or doesn't exist.
$ npm install --save home-or-tmp
var homeOrTmp = require('home-or-tmp');
console.log(homeOrTmp);
//=> '/Users/sindresorhus'
// and if there's no home directory:
console.log(homeOrTmp);
//=> '/var/folders/m3/5574nnhn0yj488ccryqr7tc80000gn/T'
MIT © Sindre Sorhus


This tutorial demonstrates how to work with symbols provided by the F# compiler. See also project wide analysis
for information on symbol references.
NOTE: The FSharp.Compiler.Service API is subject to change when later versions of the nuget package are published.
As usual we start by referencing FSharp.Compiler.Service.dll
, opening the relevant namespace and creating an instance
of FSharpChecker
:
1:
2:
3:
4:
5:
6:
7:
8:
9:
|
// Reference F# compiler API
#r "FSharp.Compiler.Service.dll"
open System
open System.IO
open Microsoft.FSharp.Compiler.SourceCodeServices
// Create an interactive checker instance
let checker = FSharpChecker.Create()
|
We now perform type checking on the specified input:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
|
let parseAndTypeCheckSingleFile (file, input) =
// Get context representing a stand-alone (script) file
let projOptions =
checker.GetProjectOptionsFromScript(file, input)
|> Async.RunSynchronously
let parseFileResults, checkFileResults =
checker.ParseAndCheckFileInProject(file, 0, input, projOptions)
|> Async.RunSynchronously
// Wait until type checking succeeds (or 100 attempts)
match checkFileResults with
| FSharpCheckFileAnswer.Succeeded(res) -> parseFileResults, res
| res -> failwithf "Parsing did not finish... (%A)" res
let file = "/home/user/Test.fsx"
|
After type checking a file, you can access the inferred signature of a project up to and including the
checking of the given file through the PartialAssemblySignature
property of the TypeCheckResults
.
The full signature information is available for modules, types, attributes, members, values, functions,
union cases, record types, units of measure and other F# language constructs.
The typed expression trees are also available, see typed tree tutorial.
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
|
let input2 =
"""
[<System.CLSCompliant(true)>]
let foo(x, y) =
let msg = String.Concat("Hello"," ","world")
if true then
printfn "x = %d, y = %d" x y
printfn "%s" msg
type C() =
member x.P = 1
"""
let parseFileResults, checkFileResults =
parseAndTypeCheckSingleFile(file, input2)
|
Now get the partial assembly signature for the code:
1:
2:
3:
4:
|
let partialAssemblySignature = checkFileResults.PartialAssemblySignature
partialAssemblySignature.Entities.Count = 1 // one entity
|
Now get the entity that corresponds to the module containing the code:
1:
2:
3:
|
let moduleEntity = partialAssemblySignature.Entities.[0]
moduleEntity.DisplayName = "Test"
|
Now get the entity that corresponds to the type definition in the code:
1:
|
let classEntity = moduleEntity.NestedEntities.[0]
|
Now get the value that corresponds to the function defined in the code:
1:
|
let fnVal = moduleEntity.MembersFunctionsAndValues.[0]
|
Now look around at the properties describing the function value. All fo the following evaluate to true
:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
|
fnVal.Attributes.Count = 1
fnVal.CurriedParameterGroups.Count // 1
fnVal.CurriedParameterGroups.[0].Count // 2
fnVal.CurriedParameterGroups.[0].[0].Name // "x"
fnVal.CurriedParameterGroups.[0].[1].Name // "y"
fnVal.DeclarationLocation.StartLine // 3
fnVal.DisplayName // "foo"
fnVal.EnclosingEntity.DisplayName // "Test"
fnVal.EnclosingEntity.DeclarationLocation.StartLine // 1
fnVal.GenericParameters.Count // 0
fnVal.InlineAnnotation // FSharpInlineAnnotation.OptionalInline
fnVal.IsActivePattern // false
fnVal.IsCompilerGenerated // false
fnVal.IsDispatchSlot // false
fnVal.IsExtensionMember // false
fnVal.IsPropertyGetterMethod // false
fnVal.IsImplicitConstructor // false
fnVal.IsInstanceMember // false
fnVal.IsMember // false
fnVal.IsModuleValueOrMember // true
fnVal.IsMutable // false
fnVal.IsPropertySetterMethod // false
fnVal.IsTypeFunction // false
|
Now look at the type of the function if used as a first class value. (Aside: the CurriedParameterGroups
property contains
more information like the names of the arguments.)
1:
2:
3:
4:
5:
6:
7:
|
fnVal.FullType // int * int -> unit
fnVal.FullType.IsFunctionType // int * int -> unit
fnVal.FullType.GenericArguments.[0] // int * int
fnVal.FullType.GenericArguments.[0].IsTupleType // int * int
let argTy1 = fnVal.FullType.GenericArguments.[0].GenericArguments.[0]
argTy1.TypeDefinition.DisplayName // int
|
OK, so we got an object representation of the type int * int -> unit
, and we have seen the first 'int'. We can find out more about the
type 'int' as follows, determining that it is a named type, which is an F# type abbreviation, type int = int32
:
1:
2:
|
argTy1.HasTypeDefinition
argTy1.TypeDefinition.IsFSharpAbbreviation // "int"
|
We can now look at the right-hand-side of the type abbreviation, which is the type int32
:
1:
2:
3:
|
let argTy1b = argTy1.TypeDefinition.AbbreviatedType
argTy1b.TypeDefinition.Namespace // Some "Microsoft.FSharp.Core"
argTy1b.TypeDefinition.CompiledName // "int32"
|
Again we can now look through the type abbreviation type int32 = System.Int32
to get the
full information about the type:
1:
2:
3:
|
let argTy1c = argTy1b.TypeDefinition.AbbreviatedType
argTy1c.TypeDefinition.Namespace // Some "SystemCore"
argTy1c.TypeDefinition.CompiledName // "Int32"
|
The type checking results for a file also contain information extracted from the project (or script) options
used in the compilation, called the ProjectContext
:
1:
2:
3:
4:
5:
6:
7:
|
let projectContext = checkFileResults.ProjectContext
for ass in projectContext.GetReferencedAssemblies() do
match ass.FileName with
| None -> printfn "compilation referenced an assembly without a file"
| Some s -> printfn "compilation references assembly '%s'" s
|
Notes:
- If incomplete code is present, some or all of the attirbutes may not be quite as expected.
-
If some assembly references are missing (which is actually very, very common), then 'IsUnresolved' may
be true on values, members and/or entites related to external assemblies. You should be sure to make your
code robust against IsUnresolved exceptions.
To check whole projects, create a checker, then call parseAndCheckScript
. In this case, we just check
the project for a single script. By specifying a different "projOptions" you can create
a specification of a larger project.
1:
2:
3:
4:
5:
6:
|
let parseAndCheckScript (file, input) =
let projOptions =
checker.GetProjectOptionsFromScript(file, input)
|> Async.RunSynchronously
checker.ParseAndCheckProject(projOptions) |> Async.RunSynchronously
|
Now do it for a particular input:
1:
2:
3:
4:
|
let tmpFile = Path.ChangeExtension(System.IO.Path.GetTempFileName() , "fs")
File.WriteAllText(tmpFile, input2)
let projectResults = parseAndCheckScript(tmpFile, input2)
|
Now look at the results:
1:
2:
3:
4:
5:
6:
7:
8:
|
let assemblySig = projectResults.AssemblySignature
assemblySig.Entities.Count = 1 // one entity
assemblySig.Entities.[0].Namespace // one entity
assemblySig.Entities.[0].DisplayName // "Tmp28D0"
assemblySig.Entities.[0].MembersFunctionsAndValues.Count // 1
assemblySig.Entities.[0].MembersFunctionsAndValues.[0].DisplayName // "foo"
|


See The Highest-Paid Football Managers In The World (Top 10)
by Enioluwa AdeniyiTottenham Hotspurs’ new manager, Jose Mourinho, has been declared as the second-highest-paid manager in football.
The former Manchester United boss signed a £15million-a-year contract with the North London side after the club sacked Mauricio Pochettino on Tuesday.
According to Tutto Mercato, his new deal with the English Premier League side has taken him to number two on the list.
The Portuguese coach is behind Manchester City’s Pep Guardiola, who signed a new two-year contract in 2018 worth £20m per season.
Atletico Madrid’s Diego Simeone is in third place and earns £13m-a-year.
TOP 10 HIGHEST-PAID MANAGERS
1. Pep Guardiola – Manchester City (£20m)
2. Jose Mourinho – Tottenham (£15m)
3. Diego Simeone – Atletico Madrid (£13m)
4. Rafa Benitez – Dalian Yifang (£11.5m)
5. Fabio Cannavaro – Guangzhou Evergrande (£10m)
5. Zinedine Zidane – Real Madrid (£10m)
7. Antonio Conte – Inter Milan (£9m)
8. Thomas Tuchel – PSG (£8m)
8. Ernesto Valverde – Barcelona (£8m)
10. Jurgen Klopp – Liverpool (£7m)


Below we present time series of 100 inter-beat intervals (a.k.a "RR") recorded in real time for three distinct clinical cases. Note the heart icon beats according to the RR intervals. It helps if you can imagine your own heart beating in synchrony with the heart icon: You may feel health/disorder.
Task: determine which one corresponds to the normal/healthy heart activity.
Advanced: what type of pathology of the heart is represented by the abnormal/unhealthy cases?
Extra points: in the Appendix the shown is the heart beating during some recreational activity. Hint: winter, Finland...
What recreational activity is represented by the following? (See also the Hints below)
The heart beat during staying in the cold air and/or ice-cold water (after sauna, see below).
The heart beat in the Finnish sauna (T around 100 °C or more!).


Update your Timings Below
Weekly Timings
Saturday:
Sunday:
Monday:
Tuesday:
Wednesday:
Thursday:
Friday:
Update Timings


The user's Role determines their ability to create, read, update and delete various items within Notary
Service. Role's are selected from the Preferences section of the user's profile page. A user can only
operate as one role at a time. If a user has multiple roles available to them, they can switch
between the available roles to accomplish different tasks.
Possible Roles:
-
Administrator
Full administrative rights over notary service deployment
- Can create, read, update, and delete templates
- Can create, read, update, and delete datasets
- Can create, read, update, and delete infrastructure
- Can create, read, update, and delete projects
- Can create, read, update, and delete workflows
-
Data Provider
Can create, read, update, and delete templates
Can create, read, update, and delete datasets
Per project association where dataset is used
- Can read templates
- Can read datasets
- Can read infrastructure
- Can read projects
- Can complete workflows
-
Infrastructure Provider
Can create, read, update, and delete infrastructure
Per project association where infrastructure is used
- Can read datasets
- Can read infrastructure
- Can read projects
- Can complete workflows
-
Institutional Governance
Per project association where institution/organization contains PI member
- Can create read datasets
- Can create read infrastructure
- Can create read projects
- Can create complete workflows
-
No Role
Access limited to About, FAQ and profile page
-
Project Member
Per project association that contains Project Member
- Can read datasets
- Can read infrastructure
- Can read projects
- Can complete workflows
-
Project PI
Per project association that contains Project PI
- Can read datasets
- Can read infrastructure
- Can read projects
- Can complete workflows
-
Project PI Admin
Can create, read, update, and delete projects
Can create, read, update, and delete workflows
Per project association that contains Project PI Admin
- Can read templates
- Can read datasets
- Can read infrastructure
- Can read projects
- Can complete workflows


Menu
PintaProject
Pinta
Pinta: Painting Made Simple
Pinta is a free, open source program for drawing and image
editing.
Its goal is to provide users with a simple yet powerful way to
draw and manipulate images on Linux, Mac, Windows, and
*BSD.
Download >>
Current Version: 1.6 -
Release Notes
Basic
Drawing Tools
Use easy drawing tools to draw
freehand, lines, rectangles, ellipses,
and more.
Adjustments and Effects
Pinta includes over 35 adjustments
and effects for tweaking your
images.
Multilingual
Use Pinta in your language. Pinta is
at least partially translated into over
55 languages.
Advanced Features
Full History
Don't be afraid to experiment, Pinta
tracks your full history so you can
always undo.
Multiple Layers
Use layers to help separate and
group elements of your image for
easy editing
Your Workspace
Like docked windows? No problem.
Floating windows? No problem. You
can even mix and match.
Resources
Download
Documentation
File Bugs
Make Suggestions
Ask Questions
Discuss Pinta
Contribute
Download
Documentation
File Bugs
Make Suggestions
Ask Questions
Discuss Pinta
Contribute
Download
PintaProject - 20175>


Minimizing and MaximazingMinimizing and maximizing events or issues at the same time. Sometimes we can minimize our achievements as if those achievements were not important. At the same time, we might maximize our mistakes believing that they are extreme or excessive.  Sometimes we can minimize our achievements as if those achievements were not important. At the same time, we might maximize our mistakes believing that they are extreme or excessive. We may have a general tendency to exaggerate the significance of negative information and experiences while trivializing the significance of the positive.


--- layout: page title: Registration hidden: false permalink: /registration/ tags: about weight: 3 headcss: /css/tito.css ---


Class DtwDistance
Calculates the distance between two vector sequences using Dynamic Time Warping
Inheritance
System.Object
DtwDistance
Implements
IDistance<System.Double[][]>
Namespace: SigStat.Common.Algorithms.Distances
Assembly: SigStat.Common.dll
Syntax
public class DtwDistance : object, IDistance<double[][]>
Remarks
Based on: Abdullah Mueen, Eamonn J. Keogh: Extracting Optimal Performance from Dynamic Time Warping.KDD 2016: 2129-2130
Constructors
| Improve this Doc View SourceDtwDistance(IDistance<Double[]>)
Initializes a new instance of the DtwDistance class with default settings
Declaration
public DtwDistance(IDistance<double[]> localDistance = null)
Parameters
| Type | Name | Description |
|---|---|---|
| IDistance<System.Double[]> | localDistance | The distance function used to calculate the distance between two individual points of the squences. Set the parameter to 'null' to use the default EuclideanDistance |
Properties
| Improve this Doc View SourceLocalDistance
The local distance function to use, when calculating the distance between two sueqence-points. Default is EuclideanDistance
Declaration
public IDistance<double[]> LocalDistance { get; set; }
Property Value
| Type | Description |
|---|---|
| IDistance<System.Double[]> |
Methods
| Improve this Doc View SourceCalculate(Double[][], Double[][])
Declaration
public double Calculate(double[][] p1, double[][] p2)
Parameters
| Type | Name | Description |
|---|---|---|
| System.Double[][] | p1 | |
| System.Double[][] | p2 |
Returns
| Type | Description |
|---|---|
| System.Double |


{% extends "header.html" %} {% block body %}
Welcome to part 4 of machine learning for forex and stock trading and analysis.
Now that we've seen our data, let's talk about our goals.
Generally, with machine learning, everything boils down to actually: Machine Classification.
With quant analysis, generally the first few things you are taught are "patterns" Head and shoulders, teacup, and whatever else.
So what is the theory behind these patterns? The idea is that the prices of stocks or various forex ratios are a direct reflection of the psychology of the people trading, ie: the traders (either people or computers) are making decisions, based on a bunch of variables. The theory is that, when those same variables present themselves again, we get a repeat of actions that creates a similar "pattern," then the outcome as well is likely to be similar, because the variables are almost the same.
So what we're going to do here is
1. Create a machine learned batch of what will end up being millions of patterns with their results, which can be used to predict future outcomes.
2. Test this.
You may have learned a few simple patterns, but everyone knows these. What if you could know every pattern in history? Pretty hard for you to remember them all, but not too hard for a computer.
Our entire system is really built on the inference of pattern recognition, so if patterns change due to new data, that's really built in and is done by programming that was done before results.
This allows backtesting to actually serve a very truthful and accurate purpose. If a machine learned live algo passes the back test, it is highly likely to continue performing well in the future, not because it passed a back test, but because our hypothesis and entire model passed the backtest... unlike finding the best algo at the time and backtesting for great results.
With that, what we will do is take a range of data in succession, and create a pattern with it. How we're going to do this is going to be with % change.
We want to have the data normalized as best we can, so it can be used no matter what the price was. We're just going to use a succession of % change for it.
To start, we'll do forward percent change, from starting point. This means, the longer the pattern, the more likely the END is to be less similar, but the actual direction of the pattern will be more similar. This can be useful, since some patterns might take more time to react than others, and we want the build up to be most accurate, but we might actually prefer the end to be more accurate in the future, so we could do reverse percent change. We can also do a point-to-point percent change as well. Trust me, when it comes to variables, we're gonna be very busy.
Now what that means is first we just need to store a bunch of patterns, in their percent change format.
Then, what we'll do to compare patterns is how similar the % changes are.
def percentChange(startPoint,currentPoint): return ((currentPoint-startPoint)/startPoint)*100.00


| Class and Description |
|---|
| Option
Class Option
|
| Server
Class Server
|
| ServerImage
Class ServerImage
|
| Class and Description |
|---|
| Option
Class Option
|
| Server
Class Server
|
| ServerImage
Class ServerImage
|
| Class and Description |
|---|
| BillingToken
Class BillingToken
|
| BillingToken.Builder |
| Customer
Class Customer
|
| Customer.Builder |
| Ip
Class Ip
|
| Ip.Builder |
| IpPortPair
Class IpPortPair
|
| IpPortPair.Builder |
| IpState |
| IpType |
| Job
Represents any job in GoGrid system
(jobs include server creation, stopping, etc)
|
| Job.Builder |
| JobProperties
State of a job.
|
| JobProperties.Builder |
| JobState |
| LoadBalancer
Class LoadBalancer
|
| LoadBalancer.Builder |
| LoadBalancerOs |
| LoadBalancerPersistenceType |
| LoadBalancerState |
| LoadBalancerType |
| ObjectType |
| Option
Class Option
|
| Option.Builder |
| PowerCommand
Server's state transition.
|
| Server
Class Server
|
| Server.Builder |
| ServerImage
Class ServerImage
|
| ServerImage.Builder |
| ServerImageState |
| ServerImageType |
| ServerState |
| Class and Description |
|---|
| Ip
Class Ip
|
| IpPortPair
Class IpPortPair
|
| Job
Represents any job in GoGrid system
(jobs include server creation, stopping, etc)
|
| LoadBalancer
Class LoadBalancer
|
| Option
Class Option
|
| PowerCommand
Server's state transition.
|
| Server
Class Server
|
| ServerImage
Class ServerImage
|
| Class and Description |
|---|
| Ip
Class Ip
|
| Job
Represents any job in GoGrid system
(jobs include server creation, stopping, etc)
|
| LoadBalancer
Class LoadBalancer
|
| Option
Class Option
|
| ServerImage
Class ServerImage
|
| Class and Description |
|---|
| IpState |
| JobState |
| LoadBalancerOs |
| LoadBalancerPersistenceType |
| LoadBalancerState |
| LoadBalancerType |
| ObjectType |
| ServerImageState |
| ServerImageType |
| ServerState |
| Class and Description |
|---|
| IpType |
| JobState |
| LoadBalancerPersistenceType |
| LoadBalancerType |
| ObjectType |
| ServerImageState |
| ServerImageType |
| Class and Description |
|---|
| LoadBalancer
Class LoadBalancer
|
| Server
Class Server
|
Copyright © 2009-2013 The Apache Software Foundation. All Rights Reserved.


--- layout: page title: About Me sidebar_link: false ---
I am currently a Research Scientist at the Cooperative Institute for Research in Environmental Sciences (CIRES), working in the Modeling and Data Assimilation Division of NOAA's Physical Sciences Lab in Boulder, Colorado. I am interested in advancing coupled data assimilation techniques for the next generation of weather forecasting systems. My main focus is in developing Machine Learning methods that can enable strongly coupled data assimilation, so that observations of the atmosphere can impact estimates of the ocean state, and vice versa, directly within the data assimilation framework.
Before joining PSL, I obtained my Ph.D. in Computational Science, Engineering, and Mathematics from the Oden Institute at UT Austin. My graduate work focused on quantifying uncertainties that are inherent to ocean models, and I implemented a generic, adjoint-based framework to propagate these uncertainties onto predictions from the MIT general circulation model. I used this framework to show how sparse observations of the ocean state reduce uncertainty in simulation-based estimates of ocean driven melting underneath the Pine Island ice shelf, which is fed by one of the fastest flowing glaciers in Antarctica. The results showed how valuable observations in this region are for constraining modeled quantities.
Broadly speaking, I am motivated to develop open source computational tools that help improve our weather forecasts and climate projections.
When I'm not working, I love to go rock climbing, skiing/snowboarding, trail running, and cycling in the beautiful Colorado outdoors.


CHAPTER 39
THE YEAR 1996
This was the year of change when this 'Group of Experts' had to realize that the JAIC was not really trying to find the truth but was fighting for a particular truth as already stated before.
39.1
Communication and Investigation up to March 1996In January some time was spent drafting the reply to Börje Stenström's letter of 22.12.95 which - finally - was agreed and sent by fax of 22.01.96 to Sweden. As the contents is of some importance the questions with answers shall be quoted below:
1. On top of pages 4 and 6 you say that von Tell submitted and B.V. approved load calculations for the locking devices. The only document we know about is the short telex from von Tell to B.V. informing that they had used LR rules for defining the strength of the locking devices and were somewhat high on shear stress (must presumably refer to the locking bolt). Have you seen any calculations?"
as to 1:
We have seen part of the telex exchange between von Tell-Hamburg and Gothenburg and also have seen some of their memos. From both it is revealed that there have been discussions (probably by telephone) between BV-Hamburg and von Tell-Gothenburg, and it has to be concluded that von Tell-Gothenburg have made calculations. This is also confirmed by the telex you have quoted and which is in your possession. To answer your question, we have not seen any of the von Tell calculations as we do not know where the files from von Tell-Gothenburg are, if they should still exist. We do conclude, however, from what we have read and heard from von Tell-Hamburg that such calculations have been made."2. On page 6 you further say that von Tell produced drawings sent to the yard for production. The von Tell drawings showed the von Tell deliveries and the complete assembly but not installation arrangements. Agree that the parts indicated by von Tell as "Werft Lieferung" are not clearly identified as information or as manufacturing guidance and we say in our text that this may have been misleading."
as to 2:
The parts marked "Werft Lieferung" in the von Tell drawings are generally according to scale respectively oversized in case they had to be made to fit for installation onboard. These parts are always drawn in such a way respectively the dimensions are stated in such detail that burning diagrams for the 1:10 shop could easily be made and/or the detail drawings were directly used for production. When questioning the yard workers having done the above-mentioned work in 1980 there was not the slightest indication that this "may have been misleading" - as you say in your report."3. On bottom of page 6 you say that the yard compared the von Tell design requirements with own results. Again, where are von Tell design requirements given?"
"as to 3:
When we say von Tell design requirements then we mean dimensions and form of the von Tell parts as could be taken from the drawings respectively from the information on the drawings supplied by von Tell. In other words, the yard obtained the load requirements which von Tell had based their dimensioning of the locking devices on by drawing conclusion from these dimensions and comparing the results with own calculations. In addition, this matter was certainly also discussed on the telephone, possibly personally."4. Page 7, item a), refers to welding tables instead of drawing information. The steel drawing for the visor does indeed contain very detailed welding information for welds which may be regarded as standard, such as butt joints between plates of different thickness. It is lacking, however, details of the non-standard welds, such as welding 60 mm thick plating. This seems to be contrary to your explanation."
as to 4:
The steel drawing does contain some welding information and we agree to your statement that butt joints between 2 plates of different thickness have to be regarded as standard. This, however, does not refer to shape of the respective steel plate edges. It is for this reason that at the lower right corner of drawing 1103 very detailed dimension sketches can be found. The same refers to other dimension sketches on other parts of this drawing. We assume that your missing welding information is for the 60 mm plate. This can be found in way of the visor arms (butt joints) as well as on the very detailed sketch of the welds of the cylinder lifting lugs. In both cases, however, the measurement information does not refer to the thickness of the welding seams but to the preparation for the welding seams. The thickness of the welds is only indicated by the thick-black coloured area. For comparison please look at the detail "visor arm/bushing", where you will not find any measurement. Consequently no welding preparation was required because a fillet weld was planned. The black-coloured area, however, indicates a rather thick weld and reference is made in this respect to page 8c, i.e. the thickness of the weld should be between 50% and 70% of the thickness of the structural member to be welded. Due to the very clearly and easily recognisable black-coloured area the welders could not understand why they should not have followed instructions."5. Page 8, item (b). the lugs of the bottom lock show clearly that the holes for the bushings were made by machine flame cutting. The lugs for the hinges show at several places a machine flame cutting pattern. (The coarse flame cutting pattern still being a question-mark.)"
as to 5:
We have to assume that the lugs for the bottom locks including the holes in the lugs for the bushings had been made by the 1:10 shop by means of machine flame cutting. The lugs for the hinges, however, have been definitely drilled. This is confirmed by the evidence of those who have done it in 1980, the respective drawings, photos and, last but not least, the remains of the hinges at KTH. In particular, the outer port hinge - showing only very minor burning marks at one location - demonstrates the original condition of the hinges at time of delivery, whilst at the stb. hinges due to the severe burning marks 10-15 mm material is missing. This is contrary to your previous statement when you said that the initial thickness would be still there.
In summary we agree that the holes in the lugs for the bushings of the Atlantic lock have probably been machine flame cut, although we have not yet found the respective drawing for the 1:10 shop (probably due to the use of "Diana II" drawings). As far as the holes for the hinge bushings are concerned, however, we emphasize that these were drilled, which we are able to prove and have done so already. We strongly suggest that you re-measure the hinge remains at KTH again and you will find out that at the stb. hinges there is 10-15 mm material less than at the port hinges. That leads to the conclusion that at the stb. hinges at least 10 mm material was missing (taken away by the burning) which at port side is still there. What effect that had on the alignment of the visor you may conclude yourself."6. Page 9, first para. We have not seen any von Tell drawings giving welding information to the yard."
as to 6:
The respective drawing will follow shortly."7. Page 11, last para. We understand that Viking Sally was on the contrary a few hundred tons lighter than originally estimated."
as to 7:
"Viking Sally" was not a few hundred tons lighter than originally estimated, but during the building phase the steel weight was continuously controlled very carefully in order to avoid overweight which would reduce the deadweight figure. As a matter of fact, AB Sally commenced arbitration proceedings against Meyer Werft claiming that the vessel was too heavy and thus could not carry the contracted deadweight, which, however, was not found by the arbitrators.
All this has nothing to do with the welding seams which, in total, correspond only to max. 2% of the steel weight.
Your assumption is probably based on the well known fact that Meyer Werft vessels have proved to be heavier and stronger than ordered for decades."8. Page 12, 4th para. We have no documentation showing that the bottom lock was installed to meet a design load of 132 tons. If available, please provide. Bottom of the same page, the safety factor is not so easily defined in a design where base material and welds carry the load simultaneously because the welds have some much lower ductility once the yielding strength is exceeded."
as to 8:
The 132 ts figure is based on 7.5 mm welds and on a permissible tension of 150 N/mm². (7.5 mm welds were initially applied.) The safety factor considered can be defined as the proportion between the nominal tension and the tension of the breaking tension of the basis material."9. Page 13, bottom. Was the extract from the von Tell drawing with the length of the side lug S70 released by the yard for production? If so, based on which calculations? As far as we can calculate, the strength of the side lug installation was somewhere around 100 tons when subjected to the combined pulling and bending force. This matches the actual tests carried out in Helsinki."
as to 9:
The lugs of the side locks were made according to von Tell drawing. The yard has made sure that the length was sufficient. The relatively low LCC of the side locks is not due to the too short lugs but due to the wrongly placed stiffeners at the bulkheads behind the lugs."10. Page 15, mid. The "Copenhagen Convention" you are referring to certainly does not put any obligations on classification societies but contains an agreement between the Nordic countries that classification societies may be authorised to perform certain functions under the jurisdiction of one country and agreement that such authorization will then be accepted also by the other administrations."
as to 10:
Name and application of this convention was given to us by the Finnish Board of Navigation as an explanation why they did not become active in SOLAS matters concerning vessel's structure."11. Further observations. I have looked back on ROV videos and have seen views of the bottom lock sensor mounting plate where the smaller holes for the magnetic sensors are clearly visible. Still no signs of the sensors themselves."
as to 11:
- We have also had more closer looks at the mounting plate in question and still did not find any sign of sensors, which, according to a member of the relief crew had been removed already several months before (due to damage sustained during the ice-winter 1994). In our opinion it is also clear from the videos that the cables for the sensors have been cut.
- The condition of the rubber packings we have discussed so many times and we have nothing to add to this.
- The visor was not flooded during sea trials (there were 4 people present, among them the BV surveyor Lohmann and the von Tell representative Todsen). At 22 kn speed and vessel pitching in head sea near Helgoland some water was leaking through the packing. After return to Emden they carried out the chalk-test and found that the packing at one location was not fitting tightly enough; a flat bar was welded in way, the packing fitted again, a high pressure hose test was carried out, and the visor was accepted as being weathertight by owners, BV, Yard and von Tell. (Signed acceptance or delivery certificate has been sent to you.)""Have also seen plenty of rubber packing on the forepeak deck in various state of separation from the flat bars. Understand the visor was flooded already during the sea trials. Do you have any information about how this was corrected."
"General:
You will recall that the quantity of water at sea inside the visor respectively the height of the water level has always been in dispute between us. Although there are very clear water marks inside visor and outside the (closed) ramp you would not accept this, which we could never understand until you gave us the explanation for your attitude. Your explanation was the gap at the lower port side in way of the securing bolt (which did or could not engage the mating pocket at the ramp side), i.e. there was a small opening of the bow ramp through which water would have penetrated the cardeck much earlier already with serious consequences, which it obviously did not do and therefore the water could not have been as high in the visor as we say. Upon my question where do you know this from, your answer was that the gap was caused by the severely twisted port outer hinges of the bow ramp, which had been stated in the working list several times for repairs but had not been repaired because it is a major item. We have thereafter looked a bit deeper into this and can see on the videos that the hinge was under repair. We have also found the explanation for water in the visor up to the visible marks, i.e. above the gap, and still no water on cardeck (at least not in dangerous quantities, i.e. crew members have plugged the gap each time bow ramp/visor were closed when they had to go down anyway to hammer the bolt of the Atlantic lock closed and at the same time plugged clothing, sheets, rags and the like into the bow ramp gap. You can still see these rags, etc. hanging respectively being pressed in way of the initial gap." The complete letter is attached as Enclosure 39.1.466 and its contents have never been disputed by the JAIC.On 8 January 58 pages of the index from the Swedish JAIC's register were received and carefully studied. The non-classified documents of interest, in particular the statements of the survivors, were ordered and subsequently copied and sent to Hamburg by members of the SEA relatives organisation. The statements and other documents arrived in bunches in the course of February and March and were very carefully studied, which took some time since they were in Swedish. Reference will be made to this further turning point in the investigation under the respective month. On the same day the Swedish JAIC plus the Sjöfartsverket observer Sten Andersson met again with S.C. Forsberg and Ulf Hobro from N&T who were accompanied by their lawyer. No details of the meeting are known.
February: In an internal meeting of this 'Group of Experts' it was decided to build a mock-up of the Atlantic lock with as-found welding seams, i.e. 3 mm, and have it pulled to destruction. The JAIC was informed accordingly and it was offered to have the break test performed by VTT or any other institute in the choice of the JAIC. After some time Klaus Rahka - the Finnish metallurgist expert - came back on behalf of the JAIC and declared that the JAIC was happy with the "Institute for Shipbuilding" (Institut für Schiffbau) of the University Hamburg to perform the break test, but that the JAIC would like to attend. The preparations for the tests, to which Klaus Rahka submitted own proposals, commenced and took several weeks. The JAIC Report was now scheduled to be published on 15.06.96. At the same time this 'Group of Experts' started the publication of a request to the Swedish people in the Swedish Text-TV for photos, slides, videos and other documentation/information about the condition and performance of the ESTONIA during her 20 months in service under this name. The request was repeated daily for 6 months and led to several slides, photos and videos, among them the so-called "passenger video" of 19.09.94 which shall be commented under "April" when it was received.
March: One of the highlights of the month was the publication of the book "Katastrofenkurs" (Catastrophe Course) by Anders Hellberg and Anders Jörle. Hellberg was working as journalist for DAGENS NYHETER and had proven on several occasions to have had confidential access to the classified files of the Swedish part of the JAIC while Anders Jörle was then working in the Stockholm office of "GÖTEBORG POSTEN"
The conclusion of the book written after more than one year of investigation was:
The sinking of the 'Estonia' had been caused by the failure of the visor hinges which were considerably pre-damaged by faulty and unqualified performed repairs. The catastrophe was programmed and could have had occurred practically at any time. Contributing factors were the facts that the master had not been on the bridge during the decisive last 15-20 minutes and further that the vessel departed from Tallinn with full port ballast water tanks but still had a starboard list.This was, more or less, a confirmation of the tentative casualty scenario and cause consideration of this 'Group of Experts' and in complete contradiction to the JAIC. Stenström said that he would not read the book, but his colleagues had done so.
39.2
The Break Tests and the FE Analysis of the VisorThe first break test of a mock-up of the Atlantic lock with 3-mm welds (as-found) between bushings and lugs was carried out by the Institute for Shipbuilding of the University Hamburg in the presence of Tuomo Karppinen and Klaus Rahka of the Finnish JAIC.
The result was the breaking of the big visor lug at a load of about 210 ts, a result which was in total contradiction to the calculations and findings of the JAIC and hectic phone calls between Karppinen/Rahka and Stenström followed. For details of this and the break tests performed subsequently reference is made to Subchapters 34.3 and 34.4. The result of this first break test meant that the break load of an intact Atlantic lock installation on the forepeak deck would have been in excess of 210 ts. As the lugs on the forepeak deck failed at the accident whilst the visor lug held, it follows that the lugs on the forepeak deck of ESTONIA must have had a holding power inferior even to a new lock with only 3 mm welding seams.
At this time the attention of the JAIC was also drawn to the results of an FE analysis of the visor and the loads on its locking devices which had been performed by the Technical University Hamburg-Harburg - see Subchapter 34.2. The result of this scientific analysis was that as long as the visor hinges were intact the load on the Atlantic lock was only in the range of 50-60 ts. - much less than on the side locks - and that the force direction was towards aft and upwards. Only after the visor hinges were broken the load on the Atlantic lock almost tripled and the force direction changed towards forward/upwards, i.e. the mode in which the lugs failed at the accident. All this was submitted in detail and in combination with the detailed break-test results to the JAIC, however without any obvious result. Upon request of the JAIC three further tests were prepared, i.e.- with a strengthened visor lug to find out the break load of the 3 lugs with 3 mm welds;
- with tag welds between lugs and bushings;
- without welds between lugs and bushings;Klaus Rahka attended at one further test and he even made written proposals - see Enclosure 39.2.466.1 - the others were left to the "Institute for Shipbuilding".
In any event, it had been established that an intact Atlantic lock installa-tion with 3-mm welds only failed at a load of 210 ts, and that the visor lug made of mild steel was the weakest point. It was further established by the FE analysis of the visor performed by the TU-Harburg that the load on the Atlantic lock was comparatively small, less than 1/3 of the break load, and that the force direction was aft/upwards as long as the visor hinges were intact. Since the lugs on the forepeak deck, however, broke in a forward/upwards mode at a load below 210 ts, it has to be concluded
(a) that the visor hinges were already broken when the Atlantic lock failed and, further,
(b) that the Atlantic lock installation was no more intact, a fact that was confirmed by the investigation of Prof. Dr. Hoffmeister. See Subchapter 34.8.All this in combination with the side lock break-tests results by VTT, Helsinki, indicated very clearly that the intact, i.e. as built, locking devices of the visor had by far not been as weak as the JAIC had outlined in their Part-Report and this 'Group of Experts' could correctly demand from the JAIC to correct their load assumptions and conclusions. This, however, was not done in spite of all the contradictory evidence, which could not be better demonstrated than by the fax that the Swedish JAIC administrator Gunnel Göransson did send to the 'STERN' representative in Stockholm in April 1996. It reads - office translated - as follows:
"I hope you received the DN article, Anders Hellberg, who wrote the article did follow up the commission work already from the beginning and did also write a book which has recently been published.Here are the answers to your questions:
1. Why does the Commission disregard the rumours concerning sabotage, dumping of narcotics, the master involved with the Russian Mafia? The damage scenario is so clear. The Commission has examined the visor and knows that all the locking devices, Atlantic lock and side locks were properly closed when the visor broke off. Therefore the rumours that the visor shall have been opened early and that then the locking devices could not have been properly locked again, cannot be true. Furthermore, if they would have had indeed the intention to dump cargo overboard it would have been much more suitable to do it by the stern ramps.
2. Did 'Estonia' comply with requirements for so-called 'short voyages'? The answer is yes. The law requires that if the vessel proceeds more than 20 nm from the nearest land, there has to be a radio operator onboard and there has to be provision in the lifeboats (food and water). 'Estonia' had this after she flew the Estonian flag and it was valid until the accident. Earlier when 'Estonia' traded between Stockholm and Turku she had an exemption.
3. Cause of the casualty?
The commission maintains its opinion as stated in the technical Part-Report, see page 31. a.)
The locking devices of the visor were constructed with less strength than required according to calculations. Extraordinary heavy weather. The ramp enclosed by the visor construction, etc. The report shall be ready later summer or early autumn. Regards, Gunnel"Subsequently Olof Forssberg was interviewed by "DER STERN" and the resulting article with the heading "Unqualified Rubbish Talks" published in STERN Nr. 18/96 shall be quoted in parts:
"STERN : Witnesses did reportedly hear already shortly after 20.00 hours starting noises on the car deck ... . What explanation does the commission have?
Forssberg : Of course all sorts of noises were heard. We have heard 135 witnesses (Note: actually they heard 5), however no one heard car noises or did see anything respectively. Furthermore the car deck was control-led by cameras and the pictures were transferred to monitors on the bridge and in the engine room .... . I do not understand that this is taken seriously in Germany.
STERN : Is it true that certain witnesses' statements have never been properly followed up and that they are now classified?
Forssberg : During the pending investigation not everything is public. However, when we present our Final Report all the statements will be put on the table.
STERN : How did the casualty develop according to the Commission?
Forssberg : ... The combination of weather, waves and speed explains why the visor was torn off. In addition, the construction of the vessel, the connection between visor and bow ramp was not very fortunate, and the locks were not strong enough to master the situation.
STERN : Is it true that divers were allowed to examine every-thing on the sunken ferry except for the car deck? Is there something hidden?
Forssberg : In order to be able to enter the car deck difficult burning work is necessary. There was no reason for this. It is irrelevant for our investigation whether there were drugs or cobalt onboard.
STERN : Isn't it wrong to bury the 'Estonia' under concrete in the light of these speculations before possible new evidence has been secured?
Forssberg : We have all the information we need. ..."The fax from Gunnel Göransson and the STERN article are attached as Enclosure 39.2.467.
The STERN questions were answered and the interview was made well after the results of the break tests in Hamburg and Helsinki were known to Forssberg.
It is also amazing to note that Forssberg states that the JAIC has all information they need while at the same time Stenström, Karppinen and Rahka are preparing a detailed ROV inspection of the vessel and Lethola even considered another wreck examination by Finnish divers. See Subchapter 39.5.
On 30 April a 90-second video was received which showed the closing of the visor looking down from the open deck 8. After the visor was closed the operator zoomed on the starboard visor hinge for quite a while and the result was shocking. The video showed very clearly and without doubt that the hinge was in an inoperable condition: The outer bushing stuck out, with its lower half missing and the securing plate was gone as well, just to mention a few of the very serious deficiencies demonstrated by this video. The video was taken by a Swedish passenger only 10 days before the last departure of the ESTONIA, i.e. on 17 September 1994. In order to secure this valuable evidence properly and to obtain the most reliable information from it the reconnaissance expert Bryan Roberts was instructed to evaluate the video tape by means of his acknowledged methods and summarize his findings in a report. For details see Subchapter 12.5 and Enclosure 12.5.180. Various images were made and one was sent by courier on 4 June to Börje Stenström together with the explanation of what this 'Group of Experts' could see on the images/tape, i.e.:
- there is a clear gap between the outer hinge plates vessel-/visor-sides which was obviously created by the steel bushing not sticking far enough through the bore, i.e. the larger part of the bushing is at the outer side of the visor hinge plate. - the outer securing plate is missing although 3 bolts can be seen.
- the lower part at the outer part of the bushing is apparently missing because you can see the end of the visor arm respectively the deck where the bushing respectively the securing plate should be.
- From the original of this photo, which is slightly clearer than the attached copy, you can also see that the hinge plates at vessel's side are not parallel to those from the visor.
- Furthermore, at the inner side there is a rust spot where subsequently the upper fracture occurred.Börje Stenström replied on 16 June as follows:
"1. Starboard side hinge. Have double checked together with Mikael Huss and Hans Öberg that the free ends of the hinge beam side plates are parallel, not converging as the video picture shows. This may influence the virtual position of the hinge bushing. Will look forward to a computer enhanced picture when available."
The Swedish JAIC showed the images sent to them to N&T for comments. The result is unknown.
In August, during a meeting in Hamburg with the representatives of the relatives' organisations DIS and SEA, Henning Witte and Lennart Berglund, the video tape was shown, without mentioning the date when it was made. After his return to Stockholm Witte informed the press which triggered off some interviews with JAIC members and N&T on which SVENSKA DAGBLADET reported on 31 August as follows:
"The video film was made by a Swedish passenger when 'Estonia' was in Tallinn harbour. Meyer Werft refuses to say by whom and on which date the film was made, but stated that it was "shortly before the casualty".
The film shows quite clearly, believes Meyer Werft, that the port hinges of the bow visor had been manipulated. The yard's conclusion is that carrying parts welded together in order that the hinges function better will lead to weakening of the load carrying capacity.
Shots from the video film are known to the International Commission for more than 1 month and they have received an offer to obtain a copy of the film. This shall be done shortly by the Finnish Commission members, said Olof Forssberg, Chairman of the Swedish part of the International Commission. He refused today to comment on the degree of importance of the picture material as evidence. This will, however, be determined before the substantially delayed Final Report will be published. ..........
On behalf of the owners N&T the technical manager, Sten-Christer Forsberg, rejected the last play-out of the German yard."
"This is nothing new or changed, not everything is as obvious as it seems. We have seen the shots from the video which the yard has sent to the Commission and we have replied that these pictures do not prove what the Germans are alleging", said S.C. Forsberg.
"The pictures are data enlargements and are of the same fantastic quality as the Germans are talking about their own behaviour. We base ourselves only on our own material which confirms that the vessel was 'in good condition' before the casualty", said S.C. Forsberg.
He also rejected the conclusion of Meyer Werft viz. that there should be no welding at load carrying parts in order to make the hinges of the visor function better.
"There have been no welding works at the visor hinges. This is furthermore another one in a line of allegations put forward by the Germans. Earlier they had already alleged that the bow visor was opened when the vessel was in Stockholm. But the visor is mainly not opened when the vessel is in Stockholm", said S.C. Forsberg, who characterised the acting of the German yard as "unethical".
The remarks of the N&T manager shall not be commented, however, the attention of the reader is drawn to the picture on page 292 of this report which shows the ESTONIA at her berth in Stockholm with open visor and open bow ramp.
On 5 September a copy of the video tape together with the Bryan Roberts report was handed over to the Finnish part of the JAIC in Helsinki. It was viewed jointly with Kari Lethola, Tuomo Karppinen, Klaus Rahka and Kari Larjo and everybody realised and recognised the deficiencies as explained in the report of Bryan Roberts. Subsequently the tape was sent to the Criminal Police Laboratory for examination whether it had been falsified, which it was not. Thereafter a copy was sent to Olof Forssberg of the Swedish JAIC, who informed prosecutor Tomas Lindstrand about the video.
By letter of 13 September, however, Forssberg sent the tape to the Military Intelligence Service (MUST) - see Enclosure 39.3.467 - and asked for data processing and contour strengthenings of certain sequences.
The MUST reply came on 20 September and is attached as Enclosure 39.3.468.
The "comments on the picture sequence" by MUST reads as follows:
"Mikael Huss mentioned a 'white line' at the bottom of the visor arm and the right part of the hinge. Upon studying the sequences picture by picture it is visible that this line is connected and sometimes looks broken. We have made 2 examples from each part picture which show these variations.
Such effect might occur with pictures if the distance between 2 objects is just few frames. Sometimes the objects are melting together and sometimes there appears to be a gap between them. This is due to the digital sensor of the video camera, respectively, how this sensor meets the shadow in each single picture."
The result is not negative and it is nowhere mentioned that the video tape is not reliable and cannot be interpreted correctly.
Nevertheless Stenström wrote on 20 September to this 'Group of Experts':
"Regarding the tourist video picture, we have of course studied the report of Dr. Robert with great interest. Unfortunately it does not come out from his report whether the analysis is based on a computer enhanced picture or purely from work with isolated pictures. Was a computer treated picture ever produced? We have looked at the video tape handed over to our Finnish colleagues two weeks ago and have done so on a screen where the pictures could be fed one by one with retained clarity. In this mode most of the details in the hinge area jump around quite a bit and the starboard hinge bushing is twisted clockwise almost as often as it is twisted anti-clockwise. We are attempting to get a computer processed picture from the copy we have and will study further the possibility of a pre-accident damage to the hinge arrangement."
On 28 September DAGENS NYHETER published under the heading "The Hinges of the Visor Were Sound" the comment of Olof Forssberg: "The pictures which allegedly show that the visor hinges were maltreated show instead that the hinges were 'completely sound'."
The article is attached as Enclosure 39.3.469.
On 21 October Anders Hellberg wrote in DAGENS NYHETER under the heading "Video Film Causes Controversies" and quoted the following comments:
"Olof Forssberg: "We do not believe that the pictures show anything new, none of them reveal that there was such a damage as alleged by the relatives."
Hellberg went on to say: "Börje Stenström pointed out that the loads during the casualty night affected the port and not the starboard hinges as the yard is now alleging."
Finally he quoted Sten-Christer Forsberg, the technical manager of N&T, who could find nothing serious in the report of the English expert:
"As far as I understand the judgements of the Swedish defence and the JAIC destroy the basis for the theory of the German yard."
The article is attached as Enclosure 39.3.470.
Börje Stenström wrote on 3 November to this 'Group of Experts':
"Have arranged for a copy of the data processed picture of the deck hinge to be sent to you. This picture is produced by superimposing in a computer program all the still pictures during a time period. In the 'average' picture so obtained the distorsions, which are numerous in any one still picture from a video camera, will be eliminated.
I am still not certain whether Dr. Robert has used such technique or not in his work. In this cleaned up picture we cannot see any signs of the distorsions that Dr. Roberts is reporting about.
Am trying to look into the listing of discrepancies you made in the fax but have very little evidence to by. Likewise we have no evidence of any contact accident with a berth of breakwater, certainly nothing that has been reported to the class."
The picture received showed the same as all the other images and the tape itself. It was nevertheless sent to Bryan Roberts for comments, which read as follows:
"Thank you for your letter of the 12 November and the enclosed print 0:05:17. This is within the bracket of frames I used in my Report. The complete range showing the starboard hinge assembly being 0:05:13 to 0:05:40. These were all used to arrive at the conclusions in my Report.
The frame 0:05:17 is one of this sequence and, with frame by frame re-examination I can see no reason to change the content of my Report in any way. The change of angle between the visor bolt (annotation 10) and the outer bushing (annotation 8) can be clearly seen on images in this sequence and equally well on frame 0:05:17, although the quality of the images I used were rather better than this print.
In assembling my Report I examined all frames on the video tape with any possible relevance to damage or distortion. These were viewed frame by frame on a Sony UP5200 printer/projector which allows visual examination of each frame and printout of selected frames at a chosen degree of enlargement. The ability to scan a sequence allows the comparison of one frame to another and any difference between components of an assembly to be seen."
Bryan Roberts' reply was sent to Stenström by fax of 15 November together with the following remarks:
"Since you have given your photo together with the report of Bryan Roberts obviously to the press - where else should they have got it from - and bearing in mind your and Olof Forssberg's remarks to Dagens Nyheter published on 21.10.96 (copy attached), we will now also give the comments of Bryan Roberts to Anders Hellberg and others."
Stenström's reply came two days later on 17 November:
"To clarify matters, the picture of the starboard hinge first appeared on Swedish TV in an interview with the lawyer Witte, obviously after he had had a meeting with you. Media naturally demanded comments from the commission and only then did we make our opinion public.
As to the technicalities, we have also looked at the pictures one by one and, as I have said before, there is considerable jumping around of the contours of the details. The average picture obtained by superimposing all pictures via a computer program then shows the correct shape, better than any isolated picture. Taking the contour of the bottom of the hinge beam as an example, the "mean picture" shows that it stops short of the hinge bolt locking plate. Many of the individual frames show the same thing. To comment only from an individual frame showing the opposite obviously becomes dubious.
We are at the moment not exploring this matter further."
In other words, the JAIC would completely disregard the evidence contained in this video and that's what they did. It was not mentioned at all in their Final Report. Hellberg, however, wrote again on 25 November, obviously after having spoken to Bryan Roberts:
"Hinges of 'Estonia' Were Damaged.
Dispute about video film, British photo expert rejects casualty investigation. By Anders Hellberg
The 'Estonia' Commission does not believe in the information that the starboard hinge was dangerously damaged when 'Estonia' left Tallinn on the evening of the 27th September 1994.
In case the Commission had taken another attitude a large part of the blame for the catastrophe would be with N&T, having been respon-sible for the operation of the vessel, and with the classification society Bureau Veritas, who performed the inspections.
The members and experts of the Commission, however, do not believe that it is possible to draw the same conclusions from the video, taken on board of 'Estonia' weeks before the catastrophe, as the English photo analysis expert did.
- "This is pure nonsense", said one of the members to DN during the meeting the Commission had in Stockholm last week.
- "The total arm holding the visor is winding like a snake in the film due to unevenness of the video - it is not possible to draw conclusions from such material", said one of the experts.
- "We do not trust the interpretation of the British photo expert who has been instructed by the German yard", said another member.
According to the Yard and the British photo interpretation expert Bryan Roberts the bolt, which holds the starboard hinge, is not there and the bushing through which the bolt should go is partly missing. Thereby the whole hinge should have been so dangerously weak-ened that it collapsed in the heavy weather and was also the cause for the visor to fall off. The Swedish experts of the intelligence Service, MUST, state in their short report that there are variations between different pictures of the film and that this should explain, among other things, why the bushing towards the bolt appears to be broken.
Bryan Roberts said he was astonished by such an attitude:
"It is obvious that on a number of picture details of the deck can be seen which should not be possible to be seen" - this is a fact which is difficult to get around. There can be no doubt that the bolt of the hinge is missing.
Roberts, who has long years of experience as a photo interpreter inside the British Military Intelligence Service, said he had used a number of pictures in video sequences and that his expert opinion therefore was not just based on one frame.
Although the angle to the bushing was changed, it could be seen on a large number of frames on the video. "I cannot understand", said Roberts, "how other experts can come to a conclusion other than mine. I would be pleased to meet them to discuss the matter."
But the Commission consequently cannot trust Roberts without changing their initial opinion stated in the Part-Report from 1st April 1995, viz. that at first the locking devices failed before the hinges broke. According to the opinion of the yard, at first the hinges collapsed due to having been weakened before the locking devices at the bottom of the visor broke."
Thereafter the video film was not mentioned again in the Swedish media but was brought back to the attention of the public by the Exhibitions held by this 'Group of Experts' in Stockholm in June and December 1997. See Subchapters 40.2 / 40.3.


---
layout: page
weight: 0
title: Event Notification URL
navigation:
show: true
---
{% anchor h2 %}
Retrieve
{% endanchor %}
| Parameter |
Required |
Requirements |
Description |
| task |
Yes |
Must be set to
get
|
This will allow you to retrieve the event
notification url for the specified customer |
| user |
Yes |
Customer must be registered under your
account |
The username of the customer |
| method |
Yes |
Must be set to
eventposturl
|
Allows you to access post event url
functionality |
{% apiexample get POST https://api.sendgrid.com/apiv2/reseller.manage<EMAIL_ADDRESS>%}
{% response json %}
{
"url": "http://www.SubUserPostUrlHere.com"
}
{% endresponse %}
{% response xml %}
http://www.SubUserPostUrlHere.com>
{% endresponse %}
{% endapiexample %}
{% anchor h2 %}
Update / Set URL
{% endanchor %}
| Parameter |
Required |
Requirements |
Description |
| task |
Yes |
Must be set to
set
|
This will allow you to retrieve the event
notification url for the specified customer |
| user |
Yes |
Customer must be registered under your
account |
The name of the customer |
| url |
Yes |
The notification URL |
This is the new event notification URL |
| method |
Yes |
Must be set to
eventposturl
|
Allows you to access post event url
functionality |
{% apiexample set POST https://api.sendgrid.com/apiv2/reseller.manage api_user=your_sendgrid_username&api_key=your_sendgrid_password&task=set&user=customer@example.com&url=http://www.SubUserPostUrlHere.com&method=eventposturl %}
{% response json %}
{
"message": "success"
}
{% endresponse %}
{% response xml %}
success
{% endresponse %}
{% endapiexample %}
{% anchor h2 %}
Delete
{% endanchor %}
| Parameter |
Required |
Requirements |
Description |
| task |
Yes |
Must be set to
delete
|
This will allow you to delete the event
notification url for the specified customer |
| user |
Yes |
Customer must be registered under your
account |
The name of the customer |
| method |
Yes |
Must be set to
eventposturl
|
Allows you to access post event url
functionality |
{% apiexample delete POST https://api.sendgrid.com/apiv2/reseller.manage<EMAIL_ADDRESS>%}
{% response json %}
{
"message": "success"
}
{% endresponse %}
{% response xml %}
success
{% endresponse %}
{% endapiexample %}


--- layout: default footerlogos: yes title: "Speaker" lang: en ---
Moritz works at the School of Data together with Helene and Knut. He gives workshops and supports NGOs in analysing and using data for their campaigning efforts. Moritz has studied European Studies and Public Policy and Human Development at Maastricht University and is also active at the Berlin Social Science Center.
Together with Helene Hahn and Knut Perseke Moritz will explain how the school of data team dove into 30.000 school datasets and discuss the plan for a project regarding the upcoming German federal election 2017. Furthermore, she will offer counseling on the first treatment of data at the data clinic.
Program for the second day


When you are feeling scared, your breath starts to grow faster and more shallow. This can cause you to become even more nervous. To stop this cycle, take control of your breathing! One popular excercise is to breathe in slowly and deeply for 5 seconds, then breathe out at the same pace for another 5 seconds. This process is normally repeated 10-15 times. Hover over the circle to begin. Close Explanation
#ibd-remote-working-tools-edition
By: Adarsh Vyas & Abhay Desai