Dev - more minilang <calculate> rounding issues

[Si Chen-2]

David et al,

I've noticed another issue with minilang <calculate>, this time from the
convertUom service.  In the service, we have:

<calculate field-name="convertedValue" type="Double">

What is happening though is that the operation is done in BigDecimal and
then converted back to Double, thus effectively causing the Double to be
rounded to the BigDecimal's number of precision.

So what should we be doing when we don't want the same precision
rounding.  For example, I want to convert a currency value of a unit
cost, and the result needs to be high # of precision (no rounding).  
Should we expand convertUom to include a decimalsOfPrecision parameter?  
Should we change the type of the <calculate > to BigDecimal?

Also, I couldn't tell yet whether it is rounding the parameters of
<calculate > before it does the calculation or not.  Could you confirm
that either way?

Thanks,

Si

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Carl Sopchak]

Why doesn't <calculate> use the data type of it's parameters?????  This
discrepancy doesn't make sense to me, although I can see an issue with a
mixed data type calculation.  But, I would think that that problem has been
solved before - like in compilers, where the same issue exists.  A couple of
possible "simple" answers might be: (a) use the data type of the result; (b)
don't allow mixed data types; or (c) specify what data type to use in the
(interim) calculation as a parameter to <calculate> (defaulting to the
result's data type, perhaps).  All of these, however, do require <calculate>
to implement several data types internally for its calculations.

In any event, I'm currently making a mod to convertUom that adds an additional
(optional) parameter, so adding a decimalsOfPrecision parameter now is
something that could be added with this change that shouldn't have that great
of an impact on level of effort - with the exception of knowing how many
decimals to use on each call to convertUom.  But then again, the parameter
could be made optional, and used only when supplied, leaving that decision to
a later time.  If we're adding a decimalsOfPrecision parameter, we should
probably also add a typeOfRounding parameter, which would default to "round",
but could be "truncate".  Then, you can calculate, for example, the number of
whole pallets of a product (not to exceed the original quantity): pallets =
convertUom("boxes", "pallets", decimalsOfPrecision=0,
typeOfRounding="truncate").

Just "thinking out loud"...  

HTH,

Carl

On Friday, March 24, 2006 21:51, Si Chen wrote:

> David et al,
>
> I've noticed another issue with minilang <calculate>, this time from the
> convertUom service.  In the service, we have:
>
> <calculate field-name="convertedValue" type="Double">
>
> What is happening though is that the operation is done in BigDecimal and
> then converted back to Double, thus effectively causing the Double to be
> rounded to the BigDecimal's number of precision.
>
> So what should we be doing when we don't want the same precision
> rounding.  For example, I want to convert a currency value of a unit
> cost, and the result needs to be high # of precision (no rounding).
> Should we expand convertUom to include a decimalsOfPrecision parameter?
> Should we change the type of the <calculate > to BigDecimal?
>
> Also, I couldn't tell yet whether it is rounding the parameters of
> <calculate > before it does the calculation or not.  Could you confirm
> that either way?
>
> Thanks,
>
> Si
>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Carl Sopchak]

Now that I'm testing my changes to convertUom, I see the issue that Si is
talking about. Basically, before the "fix" to <calculate>, convertUom was
returning "arbitrary" precision values.  Now, it returns two decimals.  
Further, the intermediate calculations done within convertUom are being
rounded to two decimals.  For my product-based enhancement to convertUom,
this can make a BIG difference in the result!

The change also makes each step of a <calculate> <calcop> series round to two
decimals (which is where my rounding problem comes in).

This "fix" has the net result that EVERY STEP of EVERY CALCULATION will be
rounded to two decimals, unless the "decimal-scale" attribute is passed to
<calculate>.  This has the potential of "breaking" other calculations that
were previously relying on the fact that the results of a <calculate> was not
rounded.  (Two potential places that immediately come to mind might be
calculating shipping weight of an order and currency conversion.)

Because of the above, I think the change has the potential of breaking more
than it fixes.  In the immediate term, I'd strongly favor reverting to the
old version.  As for a long-term solution, I think each step should be
rounded (or not) based on data type of the target result (or attributes
decimal-scale and rounding-mode to <calculate>) of the current calculation.

As for my convertUomProduct method, I'll pass decimal-scale=9 to all of my
calculations for the time being, although this kind of defeats the purpose of
declaring my variables Double in the first place...

HTH,

Carl

On Saturday, March 25, 2006 09:40, Carl Sopchak wrote:

> Why doesn't <calculate> use the data type of it's parameters?????  This
> discrepancy doesn't make sense to me, although I can see an issue with a
> mixed data type calculation.  But, I would think that that problem has been
> solved before - like in compilers, where the same issue exists.  A couple
> of possible "simple" answers might be: (a) use the data type of the result;
> (b) don't allow mixed data types; or (c) specify what data type to use in
> the (interim) calculation as a parameter to <calculate> (defaulting to the
> result's data type, perhaps).  All of these, however, do require
> <calculate> to implement several data types internally for its
> calculations.
>
> In any event, I'm currently making a mod to convertUom that adds an
> additional (optional) parameter, so adding a decimalsOfPrecision parameter
> now is something that could be added with this change that shouldn't have
> that great of an impact on level of effort - with the exception of knowing
> how many decimals to use on each call to convertUom.  But then again, the
> parameter could be made optional, and used only when supplied, leaving that
> decision to a later time.  If we're adding a decimalsOfPrecision parameter,
> we should probably also add a typeOfRounding parameter, which would default
> to "round", but could be "truncate".  Then, you can calculate, for example,
> the number of whole pallets of a product (not to exceed the original
> quantity): pallets = convertUom("boxes", "pallets", decimalsOfPrecision=0,
> typeOfRounding="truncate").
>
> Just "thinking out loud"...
>
> HTH,
>
> Carl
>
> On Friday, March 24, 2006 21:51, Si Chen wrote:
> > David et al,
> >
> > I've noticed another issue with minilang <calculate>, this time from the
> > convertUom service.  In the service, we have:
> >
> > <calculate field-name="convertedValue" type="Double">
> >
> > What is happening though is that the operation is done in BigDecimal and
> > then converted back to Double, thus effectively causing the Double to be
> > rounded to the BigDecimal's number of precision.
> >
> > So what should we be doing when we don't want the same precision
> > rounding.  For example, I want to convert a currency value of a unit
> > cost, and the result needs to be high # of precision (no rounding).
> > Should we expand convertUom to include a decimalsOfPrecision parameter?
> > Should we change the type of the <calculate > to BigDecimal?
> >
> > Also, I couldn't tell yet whether it is rounding the parameters of
> > <calculate > before it does the calculation or not.  Could you confirm
> > that either way?
> >
> > Thanks,
> >
> > Si
> >
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[BJ Freeman]

along these lines, I would like to suggest the there be a standard saved
value in the Database. Since each database handles the precision
differently, and the CPU also effects this, since most math packages
come from the CPU math package, that we take a page from cobol and store
all values as text, not rounded. then we have one math package that all
use, with compensation for the CPU and Database. Also they be stored as
whole numbers so no precision is required. the Math package would return
the proper type.

Carl Sopchak sent the following on 3/25/06 8:53 AM:

> Now that I'm testing my changes to convertUom, I see the issue that Si is
> talking about. Basically, before the "fix" to <calculate>, convertUom was
> returning "arbitrary" precision values.  Now, it returns two decimals.  
> Further, the intermediate calculations done within convertUom are being
> rounded to two decimals.  For my product-based enhancement to convertUom,
> this can make a BIG difference in the result!
>
> The change also makes each step of a <calculate> <calcop> series round to two
> decimals (which is where my rounding problem comes in).
>
> This "fix" has the net result that EVERY STEP of EVERY CALCULATION will be
> rounded to two decimals, unless the "decimal-scale" attribute is passed to
> <calculate>.  This has the potential of "breaking" other calculations that
> were previously relying on the fact that the results of a <calculate> was not
> rounded.  (Two potential places that immediately come to mind might be
> calculating shipping weight of an order and currency conversion.)
>
> Because of the above, I think the change has the potential of breaking more
> than it fixes.  In the immediate term, I'd strongly favor reverting to the
> old version.  As for a long-term solution, I think each step should be
> rounded (or not) based on data type of the target result (or attributes
> decimal-scale and rounding-mode to <calculate>) of the current calculation.
>
> As for my convertUomProduct method, I'll pass decimal-scale=9 to all of my
> calculations for the time being, although this kind of defeats the purpose of
> declaring my variables Double in the first place...
>
> HTH,
>
> Carl
>
> On Saturday, March 25, 2006 09:40, Carl Sopchak wrote:
>
>>Why doesn't <calculate> use the data type of it's parameters?????  This
>>discrepancy doesn't make sense to me, although I can see an issue with a
>>mixed data type calculation.  But, I would think that that problem has been
>>solved before - like in compilers, where the same issue exists.  A couple
>>of possible "simple" answers might be: (a) use the data type of the result;
>>(b) don't allow mixed data types; or (c) specify what data type to use in
>>the (interim) calculation as a parameter to <calculate> (defaulting to the
>>result's data type, perhaps).  All of these, however, do require
>><calculate> to implement several data types internally for its
>>calculations.
>>
>>In any event, I'm currently making a mod to convertUom that adds an
>>additional (optional) parameter, so adding a decimalsOfPrecision parameter
>>now is something that could be added with this change that shouldn't have
>>that great of an impact on level of effort - with the exception of knowing
>>how many decimals to use on each call to convertUom.  But then again, the
>>parameter could be made optional, and used only when supplied, leaving that
>>decision to a later time.  If we're adding a decimalsOfPrecision parameter,
>>we should probably also add a typeOfRounding parameter, which would default
>>to "round", but could be "truncate".  Then, you can calculate, for example,
>>the number of whole pallets of a product (not to exceed the original
>>quantity): pallets = convertUom("boxes", "pallets", decimalsOfPrecision=0,
>>typeOfRounding="truncate").
>>
>>Just "thinking out loud"...
>>
>>HTH,
>>
>>Carl
>>
>>On Friday, March 24, 2006 21:51, Si Chen wrote:
>>
>>>David et al,
>>>
>>>I've noticed another issue with minilang <calculate>, this time from the
>>>convertUom service.  In the service, we have:
>>>
>>><calculate field-name="convertedValue" type="Double">
>>>
>>>What is happening though is that the operation is done in BigDecimal and
>>>then converted back to Double, thus effectively causing the Double to be
>>>rounded to the BigDecimal's number of precision.
>>>
>>>So what should we be doing when we don't want the same precision
>>>rounding.  For example, I want to convert a currency value of a unit
>>>cost, and the result needs to be high # of precision (no rounding).
>>>Should we expand convertUom to include a decimalsOfPrecision parameter?
>>>Should we change the type of the <calculate > to BigDecimal?
>>>
>>>Also, I couldn't tell yet whether it is rounding the parameters of
>>><calculate > before it does the calculation or not.  Could you confirm
>>>that either way?
>>>
>>>Thanks,
>>>
>>>Si
>>>
>>>
>>>_______________________________________________
>>>Dev mailing list
>>>[hidden email]
>>>http://lists.ofbiz.org/mailman/listinfo/dev
>>
>>_______________________________________________
>>Dev mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev