Sigh
I have no words.
I was trying to embed the fiddle but it wasn’t working .. whatever moving on… JavaScript can’t do math.
We spent over an hour trying to figure out why a Summary Row said “NaN” in a grid… It was because the numbers “added” up to a decimal that made javascript do the above… and eventually the number is so small that it goes into scientifc notation which the grids don’t appreciate.
I miss COBOL still to this day one of the very few languages without a floating point error
HA except in reality that number in Javascript is now represented as -4.4e-17 which absolutely blows the mind of any standard grid , component control.
Even with funky COMP-3 packed decimal storage. Nibble on that.
I’m sure it’d still run well - even with EFcore and in a Linux container
Cobol has floating point errors too. All languages do because of the nature of floating points. For those who dont know why that happens but are interested Floating-point arithmetic - Wikipedia explains it.
Also, the desktop version of Epicor did the same thing all the time, it was just handled better.
Javascript does the math fine, its just poorly done implementation that is breaking things. The grid should automatically round the values to “n” decimal places.
There is probably a Kendo grid setting you could set with some funky javascript to fix that.
Yes, it does. COMP-1 and COMP-2 numbers are floating point.
COMP is binary integers and COMP-3 is binary-coded-decimal (aka packed decimal) which stores individual numbers in four-bit (nybbles). COMP-3 is very accurate, and we used it for financial information. One still had to watch out for over and underflow but if the PIC was big enough for the workload, it worked great.