Round Normal

[Anonymous]

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

[Civil3DReminders_com]

I don't think you are looking at the correct number to determine if the number is being rounded correctly. You'd have to look at four significant digits (or more) in the profile editor. The number could be 445.1548, in which the number is being rounded correctly for the two significant digits.

Christopher
http://blog.civil3dreminders.com/

[Anonymous]

Christopher,

My apologies...A little more coffee today and I would have anticipated your response.

The value of 445.155 was entered....There are no additional sig figs. Test it a couple of times with various numbers. You will see that there is a bug, unless I am grossly overlooking something.

This is occurring on multiple machines and multiple drawings. Also, the rounding 'error' occurs with various label styles using rounding normal within the label style or when using expressions.

Thank you,

Brent

[Civil3DReminders_com]

That's the only idea I have, I don't think I've noticed it before, outside of custom programming things for Civil 3D. For some reason programming languages use a method different than what you or I learned in school.

[BrianHailey · Accepted solution]

From wikipedia:

Round half to even

A tie-breaking rule that is even less biased is round half to even, namely

* If the fraction of y is 0.5, then q is the even integer nearest to y.

Thus, for example, +23.5 becomes +24, +22.5 becomes +22, -22.5 becomes -22, and -23.5 becomes -24. This variant of the round-to-nearest method is also called unbiased rounding, convergent rounding, statistician's rounding, Dutch rounding, Gaussian rounding, or bankers' rounding. For most reasonable distributions of y values, the expected (average) value of the rounded numbers is essentially the same as that of the original numbers, even if the latter are all positive (or all negative). This is widely used in bookkeeping.
http://en.wikipedia.org/wiki/Rounding

Civil 3D probably follows a similar rule.

Brian Hailey
http://www.cad-1.com
http://www.AtYourDeskTraining.com
http://Civil3DPlus.wordpress.com

[DeaconDave]

Is anyone aware if there has been a fix for this issue?  When documents created from the same data that your drawing is created from and they display two different ouputs there's a problem.  Especially, if it's not caught before the client catches it.

[BrianHailey]

It rounds according the rules I posted above from wikipedia.

If the roiunding value is 5, then it will round to the nearest even value. There is no error, this is the correct way to round.

[caddzeus]

To the OP, you are correct. Autodesk apparently doesn't know how to round. The example I've attached shows the EXACT SAME line, copied and rotated slightly. Both lines list as 88.7350 yet label differently. It is completely unacceptable for Autodesk or any of their cronies to write this off as "the correct way to round". Anyone out there can try this for themselves. Draw a line 887.350 units in any direction. Use polar array and fill a circle with 200 copies of that line, then label it with a style that rounds to the nearest hundredth, or change your unit display to the nearest hundredth and list some of them. I've confirmed this in 2011, 2013 and 2014 civil3d. Just so there's no misunderstanding it does NOT follow the rules Brian posted from wikipedia (wikipedia?? seriously??) or they would have both rounded to .74.  I currently have a subdivision plat with a curve on the boundary that was typed in with a radius of "475", yet labels as "475.01".  This kind of rounding problem and Autodesks dismissive response to it's clients is complete BS. In dealing with property boundaries and legal documents this is a HUGE deal. FIX IT!

[Civil3DReminders_com]

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.

[jmayo-EE]

It's not a bug just a poor choice. We should be rounding half up. I NEVER want 0.155 rounded to 0.15 on my plans.

[Civil3DReminders_com]

It is possible to create an expression to round the way you want it to be labeled. Then add it to the label instead of the default one.

[fcernst]

should be blaming Intel, HP, AMD, Microsoft, Apple, and a whole host of others for the rounding not being correct.

Never heard that before. Here's how Excel handles the example with their basic round function:

[Civil3DReminders_com]

Yep, and bankers complain that Excel doesn't round correctly just has passionitely as the others in the thread have indicated for Civil 3D. So there are people out there who think Excel rounds incorrectly and would be passionate in saying Civil 3D is correctly rounding.

I guess we can say it's a failing of schools in not emphasizing both forms of rounding methods.

[jggerth]

There's one other factor in the posted example with lines copied and rotated slightly differently.  Length is NOT an inherent property of the line, it's calculated from the endpoints.  And when an angle other than zero is involved, autocad calculates the distance using radians.  since radians are derived from pi, the answer will never be an integer distance.  

[fcernst]

What is going on is there is no one "most correct" method to round. It's free choice to choose a certain final rounding method. Rounding is just a less accurate answer.

There is the most common method : rounding from 5's up.

You can also round from 5's down.

You can not consider 5, and use the Floor and Ceiling rounding functions.

You can round from 5's to the even or odd number like Hailey shows to try to prevent bias.

Intermediate Calculations:

You know more about this than me, but I think it was in 1968 or so that IBM introduced the concept of providing extra guard digits to mitigate floating point rounding errors in the firmware. 

More complex, but akin to keeping all your digits through calculations, then round your final answer (if you choose to do so). 

[AllenJessup]

As JGert pointed out. The distance in not a property of the line. It is a calculated result. By twisting the line you will probably have created a situation where the coordinates of the endpoint, being calculated out to 16 decimal places, now produce a result that rounds slightly differently from the original line.

To investigate the line length out to 14 decimal places. Use the attached lisp. After loading it type LG at the command line.

Allen

The lisp wouldnt attch so:

;; Return line length to 14 decimal places as a string.
:: By Joe Burke in Autocad 2006 discussion group on 02-09-2006

(defun c:LG ( / e )
  (vl-load-com)
  (if (setq e (car (entsel "\nSelect line: ")))
    (progn
      (setq e (vlax-ename->vla-object e))
      (rtos (vlax-get e 'Length) 2 14)
    )
  )
)
(princ "Type LG to start") ;end

 Allen

[fcernst]

The Help says here that C3D's Round Normal function uses the odd/even method for it's tie-breaking decision:

[fcernst]

Here is a spot elevation with precisions of 2 through 8 displayed. They are all Round Normal rounding format except for precision = 3 where I chose to Truncate.

If I chose at that precision level to use C3D's version of Round Normal, or chose Round Up, it would go from a 3/1000 up to a 4/1000.

I don't feel really compelled, or even authorized now, to go ahead and change it to a 4/1000 after contemplating all the floating double precision calcs with guard digits that the computer just went through on this for me, if this is the precision I want to use.

The second image is all Truncate rounding.

[AllenJessup]

I think we need to talk about 2 different cases here. One is elevation. Unless you're doing very precise and critical work in elevation. It doesn't matter much which rounding rule you follow.

In Surveying I was taught to use the odd-even rule. This tends to lead to a more balanced method of rounding a boundary description. The same statement goes for boundary as for elevation. You're usually not wording at a level of accuracy that it would matter. However since you're looking to produce a mathematically closed boundary. This method tends to lead to a better closure.

Allen

[Anonymous]

Autodesk should change the name of the setting to "Round Abnormal"