giovi disanto Messages: 58 Registered: September 2011

Member

hi,
i've problem with a constraint in my model. I want to test in my state machine if the sum of probability (Real eattribuute) of all outgoingTransitions in any states is equal to 1. For do this i've write this ocl code:

outgoingTransition.transProb->iterate(p; res : Real = 0 | res+p) = 1.0

constraint work but the problem is in the approximation... if for example i test this rule in a state with 2 transition with 0.2 and 0.8 probability, i receive as result 1.0000000149011612, not 1.0. Where is problem?

This is a standard problem in almost every programming language.
Floating point calculations have finite precision and so you never get
exact answers. You must introduce a tolerance on your requirement.

Though you have only eight accurate digits, so I suspect you have an
algorithm problem too. Traditional Ecore OCL is using doubles, the new
code uses BigDecimal.

Regards

Ed Willink

On 02/11/2011 18:32, giovi wrote:
> hi,
> i've problem with a constraint in my model. I want to test in my state
> machine if the sum of probability (Real eattribuute) of all
> outgoingTransitions in any states is equal to 1. For do this i've
> write this ocl code:
>
> outgoingTransition.transProb->iterate(p; res : Real = 0 | res+p) = 1.0
>
> constraint work but the problem is in the approximation... if for
> example i test this rule in a state with 2 transition with 0.2 and 0.8
> probability, i receive as result 1.0000000149011612, not 1.0. Where is
> problem?

giovi disanto Messages: 58 Registered: September 2011

Member

Hi Edward and thanks for quickly response. Do you suggest me to use Double or BigDecimal type? as i know OCL support only Real type.... what you mean when you said there is an algorithm problem? it's a simple constraints in an ecore element...

I made two points. Firstly you will not achieve precise accuracy so you
must have a tolerance.

If you want more than 8 digit accuracy you must ensure that you are
using an algorithm that is not precision sensitive, and at least double
(i.e no floats). If you are using the default OCL going to BigDecimal is
not wise.

Just make sure
a) your input is double
b) your algorithm is sensible (i.e not 10.0e10 * (x - y)) where x and y
are almost equal
c) you do not expect exact answers

Regards

Ed Willink

On 03/11/2011 00:22, giovi wrote:
> Hi Edward and thanks for quickly response. Do you suggest me to use
> Double or BigDecimal type? as i know OCL support only Real type....
> what you mean when you said there is an algorithm problem? it's a
> simple constraints in an ecore element...