Round Normal

[bigblittlerent]

In both 2009 and 2010...

Maybe I do not know what 'normal' is, but...
It seems that there is something wrong with Round Normal...It does not round up consistently. Some values it will round up as expected and others it will not. See attached image.

Is there a workaround?

Brent

[fcernst]

However since you're looking to produce a mathematically closed boundary. This method tends to lead to a better closure.

The computer is always rounding for us during its floating point intermediate calculations for calculated decimal approximations of exact mathematical values derived from binary conversions, since many numbers can not be represented exactly in binary.

Then we want to round again, just one more time, at the very end?

Hey maybe not... it could just be a Federal offense:

In Martinez v. Allstate and Sendejo v. Farmers, litigated between 1995 and 1997, the insurance companies argued that double rounding premiums was permissible and in fact required. The US courts ruled against the insurance companies and ordered them to adopt rules to ensure single rounding.

[Cadguru42]

---

@Civil3DReminders_com wrote:

Actually its computers that don't know how to round. Computers are horrible at doing elementry school math rounding that is taught in schools. But the computers are using rounding that is IEEE compliant. So really you should be blaming Intel, HP, AMD, Microsoft, Apple, and a whole host of others for the rounding not being correct.

---

But that doesn't explain why two lines with the exact same length, but rotated differently, are having different label values for distance. I ran into this issue on a project I turned into our state DOT. There was an alignment PT label that they wanted me to change by 0.01. I wondered what was going on and found out it's due to the way C3D is rounding. It's not consistent. I had to manually edit the label and change the text just to make it work. 

EDIT: Just read where Autodesk calculates the distance based on coordinates, which can lead to different lengths. But I still don't get how a line with the same distance shown to 3 decimals when Autocad can read much more than that still produces two different values.

[Civil3DReminders_com]

It was already mentioned in the thread, the length is calculated by the
start and end points of the line. The rotation of the line introduces the
rounding into the end point if the line is roasted about the start point.

[fcernst]

But I still don't get how a line with the same distance shown to 3 decimals when Autocad can read much more than that still produces two different values.

I find the computer science involved in the topic interesting. Been doing a little more research... 

Computers are continually try to represent the infinite (i.e. the 1/3's of the world) with finite resources. Couple that, with the fact that many numbers do not fit precisely into a binary representation for the computer to work with. So there is continual rounding approximations, and binary to decimal conversions happening during the calculation process, resulting in roundoff error.

In addition to the above, the computations involve calls to proprietary low level math libraries such as +, sin, cos , etc. , So you could get different answers for just adding or multiplying between an HP and a Dell, but probably rarely notice because it may be only one digit out around the 1.0 E-16 range.

However, after multiple and iterative calculations, the inherent round off errors propogate and may potentially be noticed.

Couple thoughts:

1. Is this is why perhaps the C3D development team has used discretion and has not made iterative conditional looping possible in Expressions or SAC.

2. Is this why the default setting for label rounding in Civil 3D is set to Round Normal, to mitigate diferences between machines?

[AllenJessup]

---

fcernst wrote:

The computer is always rounding for us during its floating point intermediate calculations for calculated decimal approximations of exact mathematical values derived from binary conversions, since many numbers can not be represented exactly in binary.

Then we want to round again, just one more time, at the very end? 

---

Not exactly. I know the program is continually rounding can can create a very tight closure. However the closure is based on on the published boundary.

Allen

[AllenJessup]

---

fcernst wrote:

I find the computer science involved in the topic interesting. Been doing a little more research... 

---

Very good summary. You have to through Hexadecimal into the mix also.

Allen

[GTVic]

I believe the reason is that a number like 20.205 is stored internally as a binary number: 10100.0011010001111010111

When you convert that binary number back to decimal it is actually 20.2049999237060546875

So Civil 3D is "correctly" rounding 20.2049999... as 20.20, since it has no idea that the original number was 20.205.

https://www.rapidtables.com/convert/number/decimal-to-binary.html

https://www.rapidtables.com/convert/number/binary-to-decimal.html

You could possibly fix the problem by first rounding to the original entered precision and then rounding that to the desired display precision:

[jessica.lynch]

Thanks Brian - but this issue isn't actually solved.

In the example below two rectangular parcels have been drawn.

Both should be 262.5 sq m

I want both of these parcels to display with the same area when precision is 0.

The parcel label style uses Round Normal.

I don't want to truncate or round up so I'm stuck with Civil 3D's Round Normal setting.

I suspect the work around is to use an expression.

I don't think you can use if/then type statements in variables so the formula will take a bit of thinking.

Has anyone already come up with the formula?

Or preferably - Autocad could you please solve this issue by adjusting your rounding options

[jggerth1]

Keep in mind that the angles are internally calculate as radians, eg fractions of pi.  96 degrees is not a whole number, but approximately 1.67551608 internally. _ALL_ angles in CAD are approximate  

(well, other than zero....)

[BrianHailey]

I'm curious, what if you max out the precision of those area label styles. Do they still show exactly the same area?

Or, can you share the drawing? I want to know what's going on here for sure.

[GTVic]

25 x 10.5 = 262.5

I think it is likely that one is 262.499999999 and one is 262.5000000001 and there is nothing you can do about this. There is no such thing as absolutely identical in a situation like this unless the two parcels were exactly on top of each other then they would probably display the same number.

When you label 262, the implication to the viewer is that the actual the value is somewhere between 261 and 263. Also, the difference between 262 and 263 is 0.4% ... just sayin'. I think the only way to get them to display the same value is to change the accuracy to one decimal place but sooner or later you are going to run into the same situation at that level.

[jessica.lynch]

This was annoying me so I found a work around for my parcel label styles.

1. In Toolspace - Settings - Parcel - Label Styles - Area - Expressions ... Create a new expression

2. In the expression below I'm first rounding to 0.0001 sq m which is the maximum precision that's applicable to my areas. Then rounding again to an integer. 

Note the round function in the expression editor appears to work by rounding 0.5 up to 1.

So the result seems to more reliable than Round Normal.

But I've only tested this on a few datasets.

I had a think about an expression for unbiased rounding.

But it's quite a long expression (unless I'm overthinking this)

I think the expression is something like

If parcel area needs tie break 

  If parcel area (as integer) is even 

     Round up

  Else Round down

Else round normally

Has anyone already written this expression?

[GTVic]

I think your double ROUND expression is optimal and I don't think you can come up with a valid expression to determine if a tie break is needed.

The first ROUND changes 262.4999999 to 262500 and then ROUND of 262.500 goes as expected to 263. Conversely, the first ROUND also changes 262.50000001 to 262500 and the same result.

[doni49]

I hate to revive an old thread.  But I'm trying to wrap my head around this.

In the example below, I have two sets of numbers -- one set is rounded to 1 decimal place and the other is rounded to two decimal places.  

In the set rounded to two decimal places, the difference between the two is EXACTLY 0.01.  But the way they're rounded, it appears the difference is 0.02.  I could understand if the difference between the two was CLOSE to 0.015.  That would in my mind be a valid reason to possibly deviate.  So this just really confuses me.

Similarly, the difference between the other two is 0.1.  But the way they're rounded, it appears the difference is 0.1.

[fugitt_christopher]

Computers use what is sometimes called "banking rounding". It is trying to balance how numbers get rounded to be more evenly distributed. If you use 5 always going up, then you'll favor one party over another. If you used the previous digit's property of being either odd or even to determine the rounding then you'll get a more even distribution between the two parties. Rounding is a surprisingly complicated topic, as shown in the Wiki article about rounding: https://en.wikipedia.org/wiki/Rounding

I think to get a true comparison you should generate a larger data set and then look at the distribution of the numbers to see how the rounding affects. I wasn't able to find a YouTube video of this concept, but ChatGPT helped me create an illustration.

To graphically show why Round Half Even (often called Banker's Rounding) is considered a better method for calculations in banking and finance, we can create a simple visualization. This visualization will compare the sum of a series of rounded numbers using both Round Half Up and Round Half Even methods. The key idea here is to illustrate how Round Half Even can reduce rounding bias over a large number of transactions, leading to a fairer and more accurate total.

We'll simulate a scenario with a large set of random decimal values, representing financial transactions, that are close to half (e.g., values around 0.5, 1.5, 2.5, etc.). We will round these values using both methods and then sum them up to compare the totals. The goal is to show that the total using Round Half Even is closer to the true sum of the original values, demonstrating its effectiveness in reducing rounding bias.

Let's proceed with the simulation and the visualization.

The bar chart illustrates the comparison of the total accuracy when using the True Sum (the actual sum of the original values), Round Half Up Sum, and Round Half Even Sum for a series of simulated financial transactions.

The True Sum is the exact total of the original decimal values, without any rounding applied.
The Round Half Up Sum shows the total after rounding each transaction using the Round Half Up method, which tends to introduce a positive bias by rounding .5 up to the next integer.
The Round Half Even Sum is the total after rounding each transaction using the Round Half Even method, which aims to round to the nearest even number when the value ends in .5, reducing the overall rounding bias.
In this simulation, the True Sum is approximately -620.74. The Round Half Up method resulted in a total sum of -638, demonstrating a significant deviation from the True Sum due to the consistent rounding upwards of .5, introducing a positive bias. In contrast, the Round Half Even method produced a sum closer to the True Sum, at -615, showcasing its effectiveness in minimizing rounding bias over a large set of transactions.

This graphical comparison highlights why Round Half Even is preferred in banking and finance: it leads to a fairer and more accurate representation of totals by reducing systematic bias in rounding, especially important in scenarios involving a large number of financial transactions. ​

So while in your case it might show a greater difference than you expect over a larger sample size its likely you'll get better results. 

[doni49]

In the grand scheme of things, I completely understand that overall it's better.  But when looking at two numbers that I *KNOW* are only different by a certain number but they display a difference that is DOUBLE that, it creates issues.

[fugitt_christopher]

What issues does it create? Last time I looked contractors couldn't even build to elevations shown on the plans and often get within a 0.1' or 0.05' of the number shown on the plans. The error demonstrated is within the expected error of what is going to be built. Or is this a human issue where you have to explain to others rounding (or manually change the numbers to avoid the conversations)? 

[doni49]

---

@fugitt_christopher wrote:

What issues does it create?  

---

Because we've encountered some   a n a l  retentive reviewers who nitpick every little thing.  If they see two numbers that they are sure should be X but because of rounding, they see Y, they send it back to us.

[BrianHailey]

---

@doni49 wrote:

---

---

Because we've encountered some   a n a l  retentive reviewers who nitpick every little thing.  If they see two numbers that they are sure should be X but because of rounding, they see Y, they send it back to us.

---

Ahhh. The beginning of understanding rounding for many an engineer. This is exactly how I started my journey into understanding rounding. In my case, it was pipe slope. If you take the elevations and stations as written on the plans and use them to calculate the slope, that was different than the labeled slope. This is when I learned that 2+2=5 for very large values of 2 (additionally 2+2=3 for very small values of 2). 

[Civil3DReminders_com]

The issue isn't one of addition, but of significant figures for the pipe slope and elevations. The submittal requirements should be changed to reflect how they want the values to show up and then be recreated via a calculator. 
https://blog.civil3dreminders.com/2011/10/pipe-slope-label-precision.html