Problem with JavaToJson translation (com.isomorphic.js.JSTranslater)

[burkhard]

I'm using SmartClient_v110p_2016-07-08_Pro

Java Double values with many decimal digits (e.g. 3.0495475498449265) are translated to Strings by com.isomorphic.js.JSTranslater.
But 3.0495475498449265 is a correct JavaScript Number.

This is new in SmartClient V11. In V10 this was not the case

Thanks

Burkhard

[Isomorphic]

See dataSourceField.stringInBrowser - this is a behavior intended to preserve numbers that exceed JavaScript's Number range. You can turn it off if it doesn't apply.

However, it's strange that you report that 3.0495475498449265 is being converted to a String. What Java type are you using for that number - Double or BigDecimal?

[burkhard]

It's a Double value (java.lang.Double), not BigDecimal.

[alius]

Hello,

This behaviour is controlled by two settings:
dataSourceField.stringInBrowser (takes precedence) - for specific field
general config property "datasource.defaultStringInBrowser" (defaults to true if not set) - for all fields: number is converted to string if it has precision greater than 16.

As for your particular case: system behaves correctly (as programmed) - your provided number has 17 significant digits.
It just happened that your provided number was not converted. If you check number 3.0495475498449264 it will get rounded to 3.0495475498449265.

var d1 = 3.0495475498449265;
var d2 = 3.0495475498449264;

Print both numbers in javascript and you will see same result. Or you can compare it: (d1==d2) equals to true.

Actually in java you will get same results:

Double d1 = new Double("3.0495475498449265");
Double d2 = new Double("3.0495475498449264");
System.out.println(d1.toString());
System.out.println(d2.toString());
System.out.println(d1.equals(d2));

Output is:

3.0495475498449265
3.0495475498449265
true

You can not rely on java.lang.Double precision when dealing with big numbers or numbers with many digits after decimal point.

Regards,
Alius

[burkhard]

Hello,

The problem is: 3.0495475498449265 is a valid Java Double and it is a valid JavaScript Number.
But it is translated into a string and transfered as a string to the client. That should not happen.

If a number is converted to string if it has precision greater than 16, then, sorry, it is not correct if this number is a valid number in java and javascript.

Regards

Burkhard

[alius]

Hi,

As I've shown already - this number has more significant digits than java or javascript can handle without loosing precise value.
Here are some information how and why it happens:
Floating-Point Types, Formats, and Values in Java
IEEE Standard for Floating-Point Arithmetic (IEEE 754)

We have built "stringInBrowser" functionality to make sure that you do not loose exact value during data transfer.

If you do not want this functionality - you can turn it off either for specific field or for whole application by setting configuration values as described above.

Regards,
Alius

[burkhard]

Hi,

the precision of the number is not interesting in this case; it’s a question of data types.
3.0495475498449265 is represented in the same way in java and javascirpt, as you have shown in your examples. So there is no reason to convert this number to a string on client side.

JSTranslater is a part of the transport system between java server and javascript browser. If I send this number from the server, I expect to receive this number as a number on the client side, if representable as number in javascript. That’s what I want. And it was the behavior in SmartClient version 8, 9 and 10 - transferring numbers as expected.

Now the behavior changed and I think it is not necessarily better than before.
And in my opinion it’s not correct. Sorry.

You are the developer of this feature?
Will my number also translated to a string on server side if send from client? If so, is this also controled by "stringInBrowser"

Thanks

Burkhard

[Isomorphic]

We're considering whether to revise the feature for this case (sending numbers of precision which won't be representable in JavaScript, but which happen to be rounded to the same number anyway), however, for your additional questions, simply read the docs for dataSourceField.stringInBrowser.

[alius]

Hi,

I've just committed changes:
Now by default system will not convert Float and Double to String: you will have numbers on client side.

You can download changes with the next build.

Regards,
Alius