Exact Dimension Format

[MikeJarosz]

I thought I would share this with the AUGI community. Very often, because of inaccurate modelling, dimensions turn out to be wrong or not as expected, due to inaccurate modeling. I created a dimension format I call EXACT. For the units format I use this:

http://forums.augi.com/attachment.php?attachmentid=99507&stc=1

And for the alternate units format I use:

http://forums.augi.com/attachment.php?attachmentid=99508&stc=1

I apply the EXACT format to an existing dimension string and it shows the units in inches to 4 decimal places, about as exact as you would want it, then below it is the dimension as it would appear in a normal, rounded dimension string. In the following example, one dimension is 32.103 inches but reads as 2'-8". I find this clears up a lot of dimension mysteries.

http://forums.augi.com/attachment.php?attachmentid=99509&stc=1

Any comments?

[patricks]

Interesting technique. I never thought about using a decimal format. .0103 inches is somewhere in between 1/128 and 3/256". I wonder if it would show an increment smaller than 1/256" or .0039"?

What we do is have all of our dimensions set to 1/256" rounding, which makes any weird dimensions show up pretty easily.

[dkoch]

I have used decimal dimensions in the past, for the same reason, but I really like the idea of using alternate units to give the dimension in feet/inches/rounded fractional inches as well, as large numbers expressed just in inches are tedious to work with also. I just cannot seem to get my head to wrap around values in 256ths of an inch. Then again, I like to work in Engineering units in AutoCAD (feet/inches/decimal inches), as that exposes inaccuracies that having things rounded to 1/8" hides.

[MikeJarosz]

As maligned as the use of 1/256" by Revit is, it really is just the natural progression of 1/8, 1/16, 1/32, .... 1/256. And the programmers at AD probably like it too because of the binary arithmetic computers use. Ever wonder why colors are numbered 0-15 or something else is numbered 0-255? When you learn that computers start counting at 0, not 1 like most of us do, you realize that you are using powers of two! 255 decimal = 11111111 binary

[patricks]

Looks like Revit can indeed express an increment smaller than 1/256" by using 4 decimal places. I recall one time where I had two roofs with co-planar faces that wouldn't join properly because of a discrepancy of less than 1/256". Using our normal dimensions would not reveal the discrepancy but this method likely would have.

[dkoch]

As maligned as the use of 1/256" by Revit is, it really is just the natural progression of 1/8, 1/16, 1/32, .... 1/256. And the programmers at AD probably like it too because of the binary arithmetic computers use. Ever wonder why colors are numbered 0-15 or something else is numbered 0-255? When you learn that computers start counting at 0, not 1 like most of us do, you realize that you are using powers of two! 255 decimal = 11111111 binary

I understand that 256 is a power of two. My brain does well with power-of-two fractions through 16ths and can be stretched when necessary to deal with 32nds. But it flat out refuses to deal with 256ths. Revit shows me 193/256", and I have to reach for a calculator to understand it is a little more than 3/4". Show me 0.75390625", and I know that it is a little more than 3/4" without a calculator.

[MikeJarosz]

Looks like Revit can indeed express an increment smaller than 1/256" by using 4 decimal places. I recall one time where I had two roofs with co-planar faces that wouldn't join properly because of a discrepancy of less than 1/256". Using our normal dimensions would not reveal the discrepancy but this method likely would have.

This is why I occasionally use the exact format. Dimensions can make 4 distances look equal when they are not. Change the dimension format and find where the discrepancies are.