Storing and showing numbers

[IT2Be]

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)...

OS X 10.3, Java 10.4.1, Servoy R1.2...

[pbakker]

This is DB behavior. Somewhere on the forum Jan Aleman wrote something about it months ago.

From what I remember there is no problem in calculation.

Paul

[Harjo]

here it is:
http://forum.servoy.com/viewtopic.php?t ... ght=number

[IT2Be]

OK guys thanks! I was afraid since I noticed that Aqua Data Studio shows the correct value...

[pbakker]

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?

Paul

[Harjo]

I agree, one of my customers asked me already too, about this issue.
mabey Jan B. or Johan C. can fix it. (At least in GUI?)

[IT2Be]

And the winner is....

Nobody! I still have an issue.Imagine this:

column 1 value 25,05
column 2 value 00,00
column 3 value 10,00%
column 4 = column 2 * (1 - column 3) = 22,54

I have 6 rows, only row 2 has the above value, the rest is 0,00.

The sum of column 4 gives:..... 22,55.....

And, in fact the aggregation is correct. 25,05 * 10,00% = 22,545...

So I have two issues (or just plain problems that I have to solve)

1. the result of column 4 differs from the sum (shouldn't be)...
2. the shown result of column 4 is wrong...

[Jan Blok]

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.

Will be availeble in Servoy 2.0

[Harjo]

OKe Jan, great!
can it be adjusted too, that if you click in that field, that the two-digits stays?
Not presented as: 2,340067869?
but: 2,34

[IT2Be]

Great work jan,

Thanks...

[Harjo]

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

this is wrong! It must be: 23,28!

Please help! What am I doing wrong?

[jcompagner]

fixed in 2.0RC10

[tweetie]

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.

I hope y'all don't mind me expressing myself

[jcompagner]

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..

[tweetie]

Great...thx....
I can live with this solution.....

Now I just need to find the Firebird's databasemanager

But don't worry...as up from 1 April I'm gonna be a trained Servoy dude....
This is not a 1 April joke.