Should 0.5 round up or down?
-
I did not ask "how" ... I learned to add 0.5 or 0.05 or .005 in elementary school. "Should" implies Generally Accepted Accounting Practices (GAAP) ... or what every search generally says about "rounding". I don't expect that every person who learned these "rules" goes back to check every day to see if "convention" has changed.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
float n = 0.2f; Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" ); n = 0.5f; Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" ); n = 0.6f; Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" ); n = 1.5f; Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" ); n = 1.2f; Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" ); n = 1.7f; Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" );Answer: 0.20: 0.00 0.50: 0.00 0.60: 1.00 1.50: 2.00 1.20: 1.00 1.70: 2.00
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Not sure what your original post was referring to. But my point is that business rules, not code usage, determines how rounding should happen. So no one should ever code rounding without understanding the business rules that require it.
I think you just want to add your 2 cents regardless of whether you understand the "original post" or not.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
My "question" was more philosophical than technical. I have built ERP systems from the ground up that passed audit from national accounting firms. My "naive" approach to rounding was never a problem. (And this was "before" .NET) The concept of randomly deciding to go up or down, is not "determinate" from an auditing point of view.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
My "question" was more philosophical than technical. I have built ERP systems from the ground up that passed audit from national accounting firms. My "naive" approach to rounding was never a problem. (And this was "before" .NET) The concept of randomly deciding to go up or down, is not "determinate" from an auditing point of view.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
There is a good option there which is not random: always round to the even number. Not being an accountant I don't know if auditors have their own rule.
-
I have worked at different fintech companies for 10 years. At least in one part of the industry rounding was specifically regulated. It varied by locality. And over time.
-
There is a good option there which is not random: always round to the even number. Not being an accountant I don't know if auditors have their own rule.
The "drift" on the internet is: 0.5 rounds to 1; not 0. Having assumed this all along, I was wondering if others had "contemplated" this; as opposed to simply saying "business rules". I usually talk "businesses" out of bad habits for the good of all (like deleting "code table" entries).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
So what about a programming developing an accounting application in C#?
Religious freedom is the freedom to say that two plus two make five.
What would you do in any other language? There isn't a magic-bullet solution to this problem in any language. If the rules are subject to change, then you either need to recompile, or have some means of configuring the code to use specific rounding rules in specific situations. The only complaint with .NET / C# is if you're stuck with .NET Framework, where you only options are "to even" or "away from zero"; the options for "to zero", "to negative infinity", and "to positive infinity" were added in .NET Core 3.0.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
So what about a programming developing an accounting application in C#?
Religious freedom is the freedom to say that two plus two make five.
-
Not sure what you mean. I presume there are accountants that still use paper ledgers. But the vast majority of accountants use software applications. Consider any sort of interest bearing account. Savings, CDs, Loans, Mortgages, etc. The interest is calculated on a schedule that is either defined by the institution or some other regulatory body. That happens in software (vast majority of cases.)
-
Not sure what you mean. I presume there are accountants that still use paper ledgers. But the vast majority of accountants use software applications. Consider any sort of interest bearing account. Savings, CDs, Loans, Mortgages, etc. The interest is calculated on a schedule that is either defined by the institution or some other regulatory body. That happens in software (vast majority of cases.)
I merely pointed out to Gerry that .NET offers some options as to how numbers may be rounded, including the one to always round towards the even number. Whether he (or you) use that feature is a completely free choice, and has nothing to do with rules set by accounting, audit, or other business systems.
-
What would you do in any other language? There isn't a magic-bullet solution to this problem in any language. If the rules are subject to change, then you either need to recompile, or have some means of configuring the code to use specific rounding rules in specific situations. The only complaint with .NET / C# is if you're stuck with .NET Framework, where you only options are "to even" or "away from zero"; the options for "to zero", "to negative infinity", and "to positive infinity" were added in .NET Core 3.0.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Richard Deeming wrote:
is if you're stuck with .NET Framework,
You can of course add code to potentially handle other situations. Probably the most stringent part of this is that the developer should be able to show why they are using a specific rounding and then document it. Probably need to explain it as well. Both for potential audits as well as insuring future maintenance programmers do not 'fix' anything. I have certainly had to explain this to non-developers before that should have already understood it since they were dealing with financial decisions daily. This would always be the case when dealing with financial transactions. This can even become a problem when developers decide to store currency amounts in floating point data types. Then even something like addition can be impacted by rounding. I never experienced a problem with scientific results but when I was programming for that I was not aware of any of the issues. To be fair back then even financial institutions did not seem aware of it. The theory was known but in had not made a transition to practical usage (in many cases.)
Richard Deeming wrote:
If the rules are subject to change, then you either need to recompile,
It probably is going to be more complicated than that. For one time calculations then ok. But one must insure that that business rule will never change. The case I encountered was where the company was using paper records printed years before. Sometimes those were lost. So they printed (ran a report) again. After the rules had changed. No one in the company was aware of this problem until I pointed it out once I needed to do an update on the report. As you pointed out this required a dynamic solution which I implemented.
-
float n = 0.2f; Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" ); n = 0.5f; Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" ); n = 0.6f; Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" ); n = 1.5f; Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" ); n = 1.2f; Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" ); n = 1.7f; Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" );Answer: 0.20: 0.00 0.50: 0.00 0.60: 1.00 1.50: 2.00 1.20: 1.00 1.70: 2.00
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
I learned in school: "When you have a 5 to round from; the number to round to shall be even." Let me give you some examples: Rounding to no decimals: 0.5 --> 0 1.5 --> 2 2.5 --> 2 3.5 --> 4 Rounding to one decimal: 0.35 --> 0.4 0.45 --> 0.4 0.55 --> 0.6 0.65 --> 0.6
