How to entirely prevent rounding?

[Travis]

I've tried a few ways of approaching this, but in every case I get weird results. Here's a fiddle that demos a couple of them:

http://jsfiddle.net/GSpjW/2/

In both test cases, the rounding is in error. I'd like to be able to turn off rounding entirely, for any length of input. Is this possible?

[Kiril Nikolov]

Hi Travis,

The behavior that you observe is expected. It comes from the fact that the numbers in JavaScript are kept with exponential representation. The problem comes from the fact that when you convert from exponential representation you lose precision and this is what happens in your example.

A good idea is to have an option that will stop the rounding and use fixed representation and I have added this as a improvement/feature so we will see it implemented in an upcoming release. You can track the progress here:

https://github.com/telerik/kendo-ui-core/issues/132

Regards,
Kiril Nikolov
Telerik

 

 

[Travis]

Thanks Kiril. Just out of curiosity, wouldn't this kind of reporting earn Telerik points?

[Kiril Nikolov]

Hi Travis,

Please accept my apologies for not adding Telerik Points. I have just updated your balance.

Regards,
Kiril Nikolov
Telerik

 

 

[Travis]

Hello,

Just wanted to follow-up on this....

After discovering this issue, our team reverted back to standard HTML 'number' inputs. Subsequently, we've attempted to write a custom Kendo Validator rule for numeric/integer values, but ran into an additional problem. In some cases, using a type="number" will cause the browser to return an empty string for the input, if anything but a number is present. Because Kendo Validator assumes valid by default, if you don't specify the required attribute, such a field would be deemed valid (because the browser reports no value.)

Our workaround consists of using a type="text" input for these cases, so we can accurately validate. Sadly, this means that the user is not prevented from entering non-numeric values (a very nice feature of the Kendo widget), and the value spinner (up/down arrows in the field) does not appear in the input if focused/hovered (a very nice feature of both the Kendo widget, and in some cases, the browser itself.)

I'm wondering if the Kendo folks can suggest any alternative workarounds that might be better, and/or if there's any sense of when the rounding issue might be fixed. Thanks again!

[Georgi Krustev]

Hello Travis,

Unfortunately, the JavaScript Number object limits us up to 16 digits after the decimal point. This limitation is described in the Known limitation section. If the precision is kept up to 16 digits widget works just fine (demo for reference).

In order to provide support for bigger precision, then we will need to use a (custom) Number abstraction which internally persists the value in string format. Hence the widget will not return Number anymore, which will be breaking change. What I can suggest you is to open a UserVoice discussion/feature request for a widget which works with custom number abstraction.

Regards,
Georgi Krustev
Telerik

 

 

[Travis]

Thanks Georgi,

I can understand the 16 digit limitation. I can't understand why, in the fiddle I posted the URL for above (http://jsfiddle.net/GSpjW/2/), if you take the second example and paste it into the widget, upon blur the value gets mangled. In that example, the number of decimal places is 15, which should not cause a problem.

If the problem is in the widget instantiation, where decimals is specified as 20, I don't quite understand why that would cause the widget to generate non-zero decimal places. That seems like an actual bug. Can you help me to understand that? Thanks again!

[Travis]

Actually, updated the fiddle to demo a problem with even just 16 decimal places: http://jsfiddle.net/GSpjW/3/

Strange result when input third test value...

[Georgi Krustev]

Hello Travis,

The given demo uses a very old version of Kendo UI. Using the latest official one (demo for reference), the widget works as with decimals up to 16 digits. I noticed, however, that if the number has 6-7 digits and the last one is bigger or equal to 5 the value is incorrectly rounded. This is a bug, which will be fixed (you can follow the Github issue mentioned in this thread).

What causes this behavior?
NumericTextBox widget needs to round numbers based on the decimals option or format value. We use exponential calculation, which is the most accurate  found until now. This approach can, however, reach some of Number limitations and hence the value becomes incorrectly rounded. The real problem is related with the way how  the floating number is implemented in computing world.

Regards,
Georgi Krustev
Telerik