Storing a number with 2 decimals is ok (at least it looks like that).
Formatting it on screen is ok too.
But when I click in a field the number shows like below. A few examples:
input: 0,96 (yes dutch locale formatted as ‘#,###,##0.00’)
when I enter the field again: 0,9599999785
input: 0,82
when I enter the field again: 0.8199999928
input 1.00
stored: 1
This is very annoying and gives a lack of convidence on the outcome of a calculation (with me and my customer)…
I noticed this myself, but eventhough it doesn’t seem harmfull, I do find it quite anoying to have this in the GUI. Making textfield of the numberfields seems quite a workaround, doesn’t it?
We found the issue, the default UI component uses: round-half-even, where a number is rounded to the nearest
digit, and if it is half-way between two values then it is
rounded to the nearest even digit. This method ensures that
rounding errors cancel out (on average), and is sometimes
called M-^SBankerM-^Rs roundingM-^T. For example, 12.345 rounded to
four digits is 12.34 and 12.355 rounded to four digits is
12.36.
we now use: round-half-up, where a number is rounded to the nearest digit,
and if it is half-way between two values then it is rounded to
the digit above. Here, 12.345 rounded to four digits is 12.35
and 12.355 rounded to four digits is 12.36.
round-half-up, where a number is rounded to the nearest digit,
and if it is half-way between two values then it is rounded to
the digit above. Here, 12.345 rounded to four digits is 12.35
and 12.355 rounded to four digits is 12.36.
HELP! this is not working anymore!
I have a aggregation.
with field format: #,####0.0000
it shows me: 23,2750
with field format: #,##0.00
it shows me: 23,27
I’m sorry…but I have to express my feelings (at least according to my therapist) .
But am I the only one that finds this kind of behaviour really unacceptable.
Different SQL-backend databases offers us a huge amount of possibilities concerning dataprovider types. Most of them we really don’t care about. Servoy has simplified (thank god) this into 5 usable dataprovider types.
BUT I really find it unacceptable that whenever I fill in 1,34 into a number field that the database invents 23 extra digits to generate an approximation of the value 1,34 when the value is entered manually and is exact (of course it’s acceptable when it IS an approximation due to a division).
You cannot explain to a client who is making an invoice that the values the client fill in are converted to an approximation. Furthermore you could have a scientific customer that really find it’s important what values are stored in the decimals and REALLY don’t want any approximations.
I’m convinced that for calculations the aprroximation will just work out fine. But the users who are filling in values into the databases…you cannot invent a good explanation for this. The users fill in a exact value…and that value should not be approximated.
We could all invent work-arounds for this, we could convert to strings or we could use 2 integers (before and after the comma) and then make a calculation showing everything correctly. But they are workarounds…and I hate workarounds…it reminds me too much of certain other products .
I don’t know if it’s possible or not…but it would really nice (and it would solve all the problems in my view) if we could fill in the amount of decimals in the dataprovider menu…for example: amount is a number with 2 decimals. weight is a number with 3 decimals.
We will check it out if we can improve that in the furhter. for now you just have to set a formatter: ###.## so that youre clients will always see just 2 digits..
And if you don’t want the database to store beyond 2 digits you could make the column youreself through a database manager (for now..)
numberfield numeric(3,2)
then the database will not store beyond 2 digits..