Enterprise Client Community

Hi Captain,

can I modify the round behaviour of decimal output in FORMATTEDFIELD in a statical way? I want to change from default HALF_EVEN to HALF_UP (class RoundlingMode). (Background: The automatically opened tooltips in grid footers made it obvious ...)

Regards,
Joachim

Hi Joachim,
nice to hear from you! No, there is no possibility. - I do not understand yet, what you meant with tooltips and grid footer?
Regards, Björn

CaptainCasa wrote:

Hi Joachim,
nice to hear from you! No, there is no possibility. - I do not understand yet, what you meant with tooltips and grid footer?
Regards, Björn

Okay, I found that the tooltips part was my mistake.

Rounding half to even value is something, most people struggle with. Hopefully You will find a way to change that in the future.

So I must change my FORMATTEDFIELD to a (Text-) FIELD and use Java code for formatting.

Regards,
Joachim

Hi Joachim,
I just read the topic and wanted to share our experience there, maybe it helps.
In our case we have defined via annotations (namely @Digits) the integer and fractional part that a number field is allowed to have and with that information we write the appropriate value for the format, formatmask, regex, regexmode, minvalue, maxvalue attributes of the t:formattedfield associated to that number field.
Like that we avoid any roundings that are not under our control or values out of range.

Regards,

David

Just to make sure: the default rounding mode of FORMATTEDFIELD is the Math.round()-JavaScript function which does the normal rounding (0.5 => 1). Your post assumes that the default rouding mode was HALF_EVEN... The rounding modes you mention are Java rounding modes, which are unknown to JavaScript client processing.

Regards, Björn

CaptainCasa wrote:

Just to make sure: the default rounding mode of FORMATTEDFIELD is the Math.round()-JavaScript function which does the normal rounding (0.5 => 1). Your post assumes that the default rouding mode was HALF_EVEN... The rounding modes you mention are Java rounding modes, which are unknown to JavaScript client processing.

Regards, Björn

Ups! I was talking about Swing Client using formatmask '#.###'.

Regards,
Joachim

...ah! But also the swing client does not support EVEN rounding at all. the default rounding is normal UP-rounding...

Regards, Björn

CaptainCasa wrote:

...ah! But also the swing client does not support EVEN rounding at all. the default rounding is normal UP-rounding...

Regards, Björn

Yes, it is okay for FORMAT=double.

Handling FORMAT=float it becomes a little bit confusing. See the attachments.

Regards,
Jo

Hi,
for proper calculation float is always bad. ;-) If you input 2.55 for float, then internally there is something like 2.54999999999, because there is no accurate matching in the float system.
Using "bigdecimal" always will bring 200% correct results.

The Swing client follows in the client the datatypes that are defined in the format field. The RISC client always and only uses "big decimal" (in JavaScript there is no BigDecimal, but some equivalent to this...).

Regards, Björn

CaptainCasa wrote:

Hi,
for proper calculation float is always bad. ;-) If you input 2.55 for float, then internally there is something like 2.54999999999, because there is no accurate matching in the float system.
Using "bigdecimal" always will bring 200% correct results.

The Swing client follows in the client the datatypes that are defined in the format field. The RISC client always and only uses "big decimal" (in JavaScript there is no BigDecimal, but some equivalent to this...).

Regards, Björn

Okay ;-)

Float: 2.5499999523162841796875 = hex 0x40233333
Double: 2.54999999999999982236431605997E0 = hex 0x4004666666666666

Same issue. There is always a cut off. In both cases not representation of value 2.55 is available. But there should be a rules to assume a 1/5 1/50 ... 2.55 when 2.49 99999 was inputed.

I will check the Java DecimaFormat - implementation, if this is not the implementation in Swing client.

Regards,
Joachim

"But there should be a rules to assume a 1/5 1/50 ... 2.55 when 2.49 99999 was inputed"

Never ever! - CaptainCasa is not the one to treat float/doubles in a different way than Java does it. If you want to calculate seriously - use BigDecimal. This is the rule!

Regards, Björn

CaptainCasa wrote:

"But there should be a rules to assume a 1/5 1/50 ... 2.55 when 2.49 99999 was inputed"

Never ever! - CaptainCasa is not the one to treat float/doubles in a different way than Java does it. If you want to calculate seriously - use BigDecimal. This is the rule!

Regards, Björn

Of course! It is not the job of EC if it uses the Java API internal. The problem is design failure of Java's DecimalFormat class.

DecimalFormat's format() method doesn't overload with float parameter. The error is a result of passing float to format(double) with an implicit conversion.

So never ever use DecimalFormat with float.

Regards,
Joachim

"So never ever use DecimalFormat with float."
Yesssss!

And maybe even: never use float! ;-)

Thanks + Regards! Björn