Atebion Basics

Home
With Atebion You Can
About Us
Our Services
Pathology Costing
Support
Contact Information
Program fundamentals

Our perception of computer modelling

Under the term modelling, humans usually understand a set of techniques, which improve their comprehension of something by constructing a “cheap” miniature copy, or sketch that can be forced to pass different states or scenarios on some particular subject of interest.

Use of computers and software provides a viable approach to a task where:

The amount of data involved goes beyond the human brain’s capability to store.

The complexity of links between task data makes it difficult / impossible to make a qualified judgment.

Principles behind the program

When work started on Atebion we were fortunate that others had previously gone before us, so in many ways we could pick up what was seen as the best-established practices and approaches.  These created the following requirements for the initial program design:

Principles were based on:

  •  Program’s purpose is to build and calculate mathematical models.
  • An algebraic playground.  This means the models deal with real numbers masked by textual identifiers (i.e. algebraic variables) and the links between those numbers can be presented in the form of algebraic expressions constructed with the use of a fixed predefined set of algebraic operators/functions.
  • The model is a set of algebraic variables that are complying with a set of rules.  Any such rule itself is an algebraic equation/inequality. Algebraic equation/inequality consist of two arbitrary algebraic expressions joined by the comparison operator (i.e. “=”, “>”, “<”). The number of rules is not related to the number of variables.
  • Calculation of the mathematical model is an attempt to find such combination of values for the model’s variables under which
    1. Algebraic expressions on both sides of the comparison operator for every equation/inequality can be evaluated.
    2. The comparison itself presents a valid statement. 

 

NOTE: Calculation could fail due to different reasons (e.g. task has no solution, mathematical engine is incapable of finding an existing solution, mathematical engine will probably find a solution in a million years to come…). Some may think that it is an irresponsible/unprofessional approach to leave such flexibility in a model build-up that may not have a meaningful outcome.  Well, may be they are right but our honest belief is that it is better to build a model logically and consistently to your needs and afterwards think hard about what you can do for the sake of finding a solution (i.e. simplify/sacrifice some parts which are causing a problem…) than to scratch your head with the problem of how to overcome multiple restrictions even before work has actually started.

Program architecture:

  • The program consists of two components: 
    1.  Mathematical engine 
    2.  Integrated development environment (i.e. user interface) 
  •  Interactions between the mathematical engine and the user interface are fixed and their functionalities are not overlapped. 
  •  Mathematical engine must accept as an input a system of algebraic equations/inequalities.
  •  Mathematical engine outputs solutions it has found (if any) which are always supplemented by some kind of diagnostics.
  •  Diagnostics presents information about the way the math engine tried to find a solution, information about the “topology” of the system of equations/inequalities itself and math engine guesses where the actual/possible problems are (if any found).

 User interface:

  •  Generally the user interface should look familiar for most users (e.g. spreadsheet/file manager look-a-like).
  •  The user interface performs three main tasks:
    1. Creating/manipulating the entities used to create/modify the model.
    2.  Prepares “inputs” for the mathematical engine.
    3. Receives and shows outputs from the mathematical engine.
  •  User interface layout and terminology must not scare those who have bad memories of mathematics from their school days but at the same time should still have direct mirroring on principles/terminology of symbolic algebra.
  • The number of “bells and whistles” should be kept to a minimum in order to make it easier for the user to concentrate on the modelling itself.

Back to Our Services

COPYRIGHT ATEBIT LIMITED 1996 - 2007