You can use: ```
Number(Math.round(4.725+‘e2’)+‘e-2’)
Or in a function with support for negative numbers:
function round(value, decimals) {
result = Number(Math.round(Math.abs(value)+‘e’+decimals)+‘e-’+decimals)
if (value<0) {return result*-1} else {return result}
}
Rounding is kind of formatting, so it is something “to display”
That means to me the number that you want to format, must become a String, it can’t be a number after rounding because you still have a problem it must fit into the floating point notation (that changes the number again)
so in the 4.725 if you try to round that by first doing *100
472.5
if you round that:
473 (as a whole number)
if you then divide this again by 100
then it very like becomes:
4.72999999
so you see again 4.72
you really should avoid rounding like this, it makes no sense to me to do that.
Because i guess you really want to round to display the value to a user (not to calculate with it because then i do hope you don’t make a financial product…)
so in pseudo code when rounding and going from a number to a string:
var x = 4.725
var y = x * 100; (472.5)
var z = Math.round(y); (473 as a whole number)
var asString = z.toString(); “473”
now calculate a position (how long the string is where the comma must be)
var position = 1; (hard coded for now)
var roundedDisplay = asString .substr(0, position) + “,” + asString .substr(position);
I guess if you DO use it to make a financial product you can always let ‘the Pros’ handle it (i.e. not JavaScript, but your database)
function roundValue(value, decimals) {
// sadly PostgreSQL doesn't allow type modifiers to be placeholders so we must concatenate this in the string :(
var _ds = databaseManager.getDataSetByQuery("myConnection", "SELECT CAST(? AS NUMERIC(15," + decimals + "))", [value], -1);
if (_ds.getException()) {
throw _ds.getException();
}
return _ds.getValue(1, 1);
// NOTE: adjust your datatype casting to match your vendors datatypes (numeric vs number, etc.)
}
jcompagner:
Rounding is kind of formatting, so it is something “to display”;
I do not agree, because a currency value from “real life” should be represented the same in the database.
Otherwise you get problems at once when you have two invoices with VAT-values of e.g. 8.055 and then want to SUM them to calculate your obligation to pay towards the fiscal authorities.
So best would be numeric type for storage, with two fixed decimals.
However in case of storage as floating-point, 8.0600000001 or 8.059999999 is still much better than the wrong value of 8.055, because there is just no half cent in real life.
So I also do not see why rounding should return the type string.
the problem is that rounding in the floating point notation that javascript uses is just not really 100% possible
how ever you round it can be that you round to for example 7.25 (because it was 7.245) but 7.25 is in floating point notation: 7.2499999999999
So it is still not correct if after that you just show the 2 decimals…
i guess in this scenario you kind of want to make it 7.2500000001 …
So lets say you you want to round up after 2 decimals, that kind of means just added 0.005 to it right?
Problem is that 0.005 in js can be 0.0049999
So if you have 7.245 then it would be 7.2499999 and it still wont work…
So lets say we first go to a real integer values:
7.245 * 1000 = 7245
then we add that 0.005 (which is now just 5)
so that kind of works now:
7250
but now divided it again by 1000
then you would think you would get: 7.250
problem is this is suddenly an floating point notation again and you could get: 7.249999999
back to square one…
So maybe we should just not add 5 to it but 5.1
then we would get
7250.1 / 1000 that should result in at least 7.250something
i think this should work, but maybe you guys can think if we then cross boundaries the other way (so we round up to soon what we don’t intent to)
like input is:
7.244999999999
how should that round? do you really look only that the 0.004 and see that should not round up. or should you really first look at that 0.0009 and first round that up? so it rolls up to the . and then it does become 7.245 and because of that 7.25? Or should that stay 7.24?
Because if the above should become 7.25 also
then we can do the thing above i guess
*1000 = 7244.9999 + 5.1 = 7250.09999 that will be then 7.250099999
if that shouldn’t be rounded to 7.25 then i guess we need:
7244 (and round that to an integer, so remove the .99999) and then add 5.1 so we get: 7249.1 and that will then be 7.24911111 (so rounded to 7.24)
We use our own rounding function throughout our whole Servoy application where rounding is needed, for example rounding to euro cents.
Just counted: used > 2000 times in our code…
lwjwillemsen:
We use our own rounding function throughout our whole Servoy application where rounding is needed, for example rounding to euro cents.
Just counted: used > 2000 times in our code…
You won’t believe it, Harjo, but I currently wrote nearly the same:
“Looks very complicated, this matter.
Maybe one solution would be to just store everything in cents instead of Euros, so that one can use only integers.”
omar:
Same problem, you still have to calculate the VAT and round to whole cents…
True, but you could use integers in JavaScript, too, which have their counterparts as integers in the database.
For calculations you would need a temporary variable that can handle decimals.
However in my feeling that is not very practical in programming, so I overall agree with Harjo.
Oke Lambert, it IS rocketscience, did you try to round: 4.725 with your method?? it also returns 4.72
and 4.725 is not the only value what is failing
Thanks Harjo, did not realize that!
I have added the 0.00000001 addition after the multiplying with 100 in my function.
I believe that is numerical better.