Provide DecimalParameter element for Constant Parameters

[GoogleCodeExporter]

When dealing with cost parameters and calculations on those it would be good to 
represent them via BigDecimal rather than float/double. For this could add a 
DecimalParameter element to constant parameters:

<element name="DecimalParameter" substitutionGroup="ParameterValue">
        <complexType>
            <complexContent>
                <extension base="ConstantParameter">
                    <attribute name="value" type="decimal"/>
                </extension>
            </complexContent>
        </complexType>
    </element>

Thanks.

Original issue reported on code.google.com by tsurdilo...@gmail.com on 4 Sep 2012 at 3:28

[GoogleCodeExporter]

The reason that this one and double, long and other basic datatypes are not 
present in the first version is that we really did not see a case for them and 
we wanted to keep it simple. 

You can always internally load the floats as big decimal and use their enhanced 
precision and then re-output as a float. Would that work for you?

Original comment by sringue...@trisotech.com on 19 Oct 2012 at 12:46

[GoogleCodeExporter]

The way I read is that when working w/ Java the most correct way when dealing 
with cost values is to work with BigDecimal. If we start adding internal 
conversion as suggested, we will add possible issues with calculating precise 
cost values for users. 
Because of this I think we should use the best thing for cost values, which in 
Java is BigDecimal.

Original comment by tsurdilo...@gmail.com on 25 Oct 2012 at 12:32

[GoogleCodeExporter]

Decision 25 oct 2012 web meeting 

-Bigdecimal is a not primitive type but a class
-Bigdecimal is not supported in every programming languages. 
-The main purpose of this specification is successful interchange of simulation 
parametrization and simulation results.
-During interchange there is inherently a lost of precision.
-Whether the value is a float, double, of bigdecimal, its XML value in the 
interchanged file will be/look the same. 

It was decided this change would not be applied

Original comment by dga...@trisotech.com on 25 Oct 2012 at 4:33

• Changed state: WontFix