total combined occupancy adds to many

[jarods350z]

I am getting descrepancies between rounding individual room totals vs rounding the total combined occupancy. For example, if you have 1.5 occupants required in a room, you round up to 2, right? But what if you add two rooms together before the rounding happens in a total. Say you have two rooms that give 1.5 occupants each. 1.5 x 2 = 3 occupants. If you round before adding, however, you get (1.5 rounded up) + (1.5 rounded up) = 4 total occupants, not 3 any more. Is there a fix for this it is bugging me because I use to do it now in 2014 I cant get it to work :banghead:

[greg.mcdowell]

I don't know what your old workflow was like but this behaviour is expected and is the same as in Excel. Both programs work on raw data regardless of how the display is rounded.

The solution is to either re-type the rounded information into a new cell (something we do anyway because calculated values can't appear in tags yet) or round the data as part of the formula; roundup(Area/Occupant Load Factor) should work.

[MikeJarosz]

this behaviour is expected and is the same as in Excel.

Check out any mathematical explanation of rounding on google. It's more complicated than you think. Here's an example from XL. Both additions are sums of the two numbers above.


95551

[greg.mcdowell]

What's complicated about it?

In your example, the raw numbers in column A are greater than 1.5 and the cells have been formatted to display no decimals which forces Excel (and Revit) to round (in this case up). The numbers in column C are entered as raw data (both 1's). Correct?

The attached Excel file might help?

[MikeJarosz]

The example on the left is 1.49 + 1.49. The sum is of course 2.98. Rounding all 3 numbers to an integer gives 1 + 1 = 3

The example on the right is 1 + 1 = 2 exact numbers with no formatting.

When summing up a long list of room areas, there is no statistical certainty that the round ups will balance the round downs and yield a satisfactory result. I recall a function in XL for sum as displayed, but I haven't used it in years.

Because I have a background in programming, I know how computers represent numbers. How they do it is nothing like the average Joe imagines it to be. I once watched a co-worker try to move a point to an exact number in Acad, something like xy = (12.000000, 27.000000 ) She kept getting coordinates like (12.000023, 27.000008). She tried moving x by -.000023 and would still not get 12.000000. Of course, she was not willing to hear a lecture on floating point numbers, so she never got what she wanted and walked away mumbling "stupid AutoCAD".

Number representation is also what limits Revit internal coordinates to 1 mile from origin, but allows shared coordinates to be anything. My guess is that internal coordinates are single precision and shared coordinates are double precision. Why? single precision calculates faster.

[jsteinhauer]

Please see the link below for more information. It is a bug in the way that Revit calculates each room based upon the formula, then gives you the totals for all the rooms combined.


http://forums.augi.com/showthread.php?154984-Plumbing-Fixture-Counts

[MikeJarosz]

OK -- I dare someone to read this to the end..... http://en.wikipedia.org/wiki/Rounding Wiki even warns that this article attempts to explain a complicated topic on a single page.

When writing computer code to do useful calculations that don't return apparent errors, the coder has to be very familiar with their topic. They are doing the hard work so that when we use their program it becomes easy for us. The hard work in this case is a mathematical understanding of rounding numbers. The wiki entry gives you some idea of the topic.

By the way, these calculations are not done in base 10. They are done in binary, and in the case of Revit areas, floating point binary, which is inherently inaccurate. Off the top of your head, can anyone tell be what the cube root of 11011 is? (+/- 1001) The result is converted to base 10 representation. What do we round here? The binary number?, the base 10 string representation?

This is why Acad returns numbers like 12.000023 and moving it -.000023 doesn't make it exactly 12.000000. Presenting the result of calculations to users in correct base 10 representation is in fact an extremely complex topic in computer science. Most of us take the results for granted, but behind the scenes, Revit is working its butt off to make it easy for you.

After all that, as Steinhauer points out, there can still be a bug.......:)

[jsteinhauer]

Mike,

I can duplicate the result from Revit within Excel or any other spreadsheet software. Instead of adding up all the room areas, then calculating a result based upon a formula, Revit calculates based upon the formula then totals the results. Basically, order of operations, and I don't see there being an easy fix anytime soon. Maybe a project parameter not associated with rooms what so ever, and the user has to manually coordinate area take offs with these parameters. I thought of using an area plan, and just making multiple boundaries for each occupancy classification. A BIM-panzee will still have to coordinate the area plans with the actual model. :( But, it is much better than getting wacky results from pulling the areas from the rooms.

Cheers,
Jeff S.

[greg.mcdowell]

All true but for what the OP is trying to do none of it matters.

You can take one of two actions to get repeatedly reliable results in Revit.

* Manually retype the numbers from the calculated values to a new parameter as integers and use that parameter for calculations/totals/etc.
* Use "roundup" before your formula to force Revit to round the numbers to the next highest integer for use in calculations/totals/etc. (You can also use "round" or "rounddown" depending on your situation.)

Wacky areas (as in non-integer numbers) divided by an integer per unit area returns more wacky numbers. You either round these numbers before you total, or you round the total. Doing both will lead to troubles when the rounds don't average out. If you round the total you'll need to do that manually in Revit as there is no method to have numbers in a column and force an integer as a total. You can round the numbered results to an integer before you total but then your total, if you round up, will be larger than it would be otherwise. It won't be any larger than the number of areas you're calculating though so, for my work, that's not a big deal.

I'll try and post an example file tomorrow... gotta go get the wife and kids now.

[MikeJarosz]

In the end, how important is perfect arithmetic anyway? When I was in school before the age of electronic calculators, all our engineering was done with slide rules. Slide rules have limited accuracy, and the results were considered adequate by everyone. Any building older than about 75 years was probably engineered with slide rules. Is anyone afraid to walk into one?

[greg.mcdowell]

In the attached file there are a series of rooms with "wacky" areas (as in no whole numbers).

In the "Occupancy Calculations_by Room" schedule each area is divided by an Occupant Load Factor (100 people/sf). The rest of the columns are either calculated values (dividing Area by OLF) or manually entered values (transferring one column to another). One column has its display rounded (by changing the Field Formatting to Fixed and 0 decimal places). All columns are calculating totals.

* Load (Raw) - non-whole numbers... nothing you'd want to see in an occupancy schedule - wacky total
* Load (Raw Number_Display Round) - same calculations as "Load (Raw)" but with Field Formatting changed - note the total of 39
* Load (Manual Copy of Raw Number_Display Round) - a manual transfer of numbers from the previous column - note the total of 40 and that it does not match the previous column (this is where people start to get concerned and say that Revit isn't adding correctly... I'm trying to show that it does but it's not adding what you think it should - the rounded numbers)
* Load (Raw Integer) - same calculations as "Load (Raw)" but the Parameter Type has been set to Integer which forces a standard round
* Load (Formula RoundUp) - same calculations as "Load (Raw)" with ROUNDUP
* Load (Formula Round) - same calculations as "Load (Raw)" with ROUND
* Load (Formula RoundDown) - same calculations as "Load (Raw)" with ROUNDDOWN

The first two columns are either unacceptable (at least around here) or give results that don't make sense without explanation.
The remaining 5 columns give reliably repeatable results and stand up to scrutiny.

Personally I find it necessary to use the Manual Copy method since we include this information in our Code Plans as Tags and Revit doesn't allow for calculated values to appear in Tags... yet anyway.

[MikeJarosz]

I opened your file. Your raw numbers are just as I mentioned in my post above. The round ups and the round downs are not statistically balanced. You have six round ups and 2 round downs. I'm assuming your problem is that the (raw number display round) column is displaying 39, when the column of rounded numbers above it actually adds up to 40. By adding columns for (all round up) and (all round down) to your schedule you are demonstrating how much rounding affects the reporting of numbers.

What Revit is doing is adding the actual internal areas. It applies the rounding rule to the result only. Your raw numbers add up to 39.39 and the sum of the rounded numbers displays 39 which is the correct rounding of the raw 39.39. What you appear to want is the sum of the numbers as displayed, which would be 40. This is why Excel has a setting "set precision as displayed" However, selecting that setting in Excel triggers a warning “Data Will Permanently Lose Accuracy.” To the best of my knowledge, Revit has no such setting. This behavior is common to all modern computers that use the IEEE 754 standard.

You have wandered into an issue that baffles most users of computers. One common misconception is that computers are of infinite accuracy. They are not. Read this article:

http://www.k2e.com/tech-update/tips/139-handling-rounding-issues-in-excel

By the way, is your data so perfectly drawn in Revit that tiny discrepancies matter? Are your CMU walls drawn to 6" or 5 7/8"? If so, try changing to smaller units like square inches or even square millimeters, then convert back to square feet in a calculated value. If that doesn't satisfy you, dump the schedule into Word and fake the numbers.

One thing Revit will not do is fake a number. This forum is full of posts from recovering Acad users who want to fake a dimension and can't find a way to do that in Revit.

There isn't any.

[greg.mcdowell]

What Revit is doing is adding the actual internal areas.

That's what I've been saying... I say raw, you say internal... same thing.

What the OP, and I imagine all architects, want is to have a schedule where the total is a sum of all the displayed numbers (we should actually say whole numbers or integers here) above... not necessarily the raw/internal/real numbers being calculated. If you don't force the round manually by one of the three methods I mentioned above you run the risk of the displayed integers not adding up to the displayed total.

We're saying the same thing.

It seemed to me that you, and possibly others, were saying it couldn't be done in Revit... I wanted to prove that it could.

Also, from my experience, most users desiring faked numbers are concerned about not dealing with fractions in dimension strings... and that can be, within a given tolerance, handled with rounded dimension styles. Whether you should or should not round dimensions is another topic that's been beaten to death. I say do what you need to get the job out the door as correct and accurate as your time/budget allows... if that means rounding some dimensions fine so long as you understand what you are doing and where/when it makes the most sense (and where/when it can really bite you in the ***). Afterall... Revit dimensions are rounded too... they're just rounded to the nearest 1/256"!