Modelling space size?

Oct 08, 2003 33 Replies
64 bits processors can handle 64 bits integers (you don't often use numbers larger than 4 billions, do you?), but floating point numbers used in SW and most (all?) other cads are already 64 bits "double-precision" (see
formatting link
page 3) that have a mantissa of 53 bits. As I explained earlier in this thread, the double format " guarantees 15 decimal digits of precision.This means the largest and smallest dimensions that can be added and still give a correct result must not have a ratio larger than 1/10E15. If you want to measure nanometers (1E-9 m) and still have some margin for geometric operations, you can't allow dimensions much larger than 1E3 m " By using the "double-extended" format (80 bits, 64 bits mantissa), you could reach 18 digits of precision, which is the maximum "floating point units" of current processors (32 and 64 bits) can handle. As you can see on intel's page, their processors use an internal representation with a larger exponent, but the mantissa is max. 64 bits.

Bignums are handled as string (usally in coded in BCD, with one decimal digit coded on 4 bits, so 2 per byte). They are fun, but definitely not fast enough for interactive applications

Which I had deleted before I noted the thread .

As floating points become larger the distance between them becomes greater .... which can create errors you did not intend.

This is one of the things that used to create problems with translating & copying geometry which led to poor designs. It may still account for some of the problems with imported geometry when the creator of same did such things ....

OTOH The good old "squash part flat" command (used for faking

2D in 3D ) just set all Z values to zero .... which could be done by translating the geometry a large enough distance in Z and then back ... the distance between numbers at that distance being far larger than the part geometry it all ended up with the same in Z when translated ..

See, I told you I didn't know what I was talking about. So, if SW can now store a number of the same precision in a single word, rather than two, should we expect a significant spped increase from a prot to say, AMD64?

Some things that now take A*N clock cycles might be done in N ....

Since you all brought the subject of units, I have a question. First some background; I am considering purchasing Solidworks, after we had a failed effort to incorporated Inventor into our design process. One of the minor hassles I ran into with Inventor were limitations and inconsistancies when using feet-inch units. Eventually I realized that this was because Inventor was purely metric, even when the chosen units were feet-inch. The hassles were simply the result of the metric-mindedness of the program.

Is Solidworks also purely metric internally (i.e. all units are converted to metric for the internal drawing database)? Are there hassles I should expect for using Solidworks for an industry which is purely feet-inch?

[By the way, I have significant doubts the U.S. will ever totally convert to metric.]

Joe Dunfee

The only dificulty I have run into is when using API. It is a simple conversion though. I have never noticed a problem, we work solely in Inches. Could you describe the problems you ran into, I will be sure to watch for similar behavior.

Corey

CAD/CAM databases are internally dimensionless except for a flag (1) for the entire part database AFAIK. Alter that one flag and the system will consider the units to be something else.

Not metric, not feet, not inches or lightyears or feet AND inches.

The user interface and applications programs *may* support various units and their conversion and display (such as foof/inch dimensioning of metric flagged databases) but the internal numbers are just that ... numbers without units beyond the flag. The flag is used by applications programs to do whatever conversions are needed/expected.

You will see such a flag in the first line or two of an IGES file BTW.

Part of the reason that the *real* US economy is collapsing. It would now take decades to regain, if even possible, .....

I'm pretty sure this is not true of Inventor. The internal database and working unit is the centimeter. Input and output values are converted before and after the fact (being fed to and returned from the function doing the computations). I think this was their way of dealing with mixed unit assemblies. (Not absolutely sure about this, but think that's the way I've seen it explained.)

I don't believe this is the reason for difficulty with feet - inch units, though, as all computations, be the system unitless or not, are done with floating point real numbers.

I guess it's all what you are used to. I personally can't think of anything more confusing and harder to work with than feet - inches - fractions. Is that why US aerospace uses decimal inches as the standard unit? 8~)

=================

Jeff, You may have had the default database units set to centimeters, many systems allow default settings for the database unit for new parts created from scratch. About the only way to convert that is to insert the part in another with another database unit and the conversion should be automatic .... at least on the systems I know.

It's still just a flag and IIRC AutoCad is widely used in the AEC fields where feet and inches are quite common so I'd expct that the inch (or the foot) could be chosen as the database default unit. Never both though . That would/could be used by the dimensioning and data input programs easily enough though.

Perhaps some of the AutoCad experts here will comment .... it's been many years since I looked at a copy ...

Well, you got me wondering. Below is an excerpt from a VBA help document. I know it's not of any real interest except as geewhiz info, so hope I'm not tracking up the floor.... 8~)

---------------

The user can change the default units and precision at any time, without impacting the model in any way. A peek within the internals of Autodesk Inventor will provide a better understanding of how the units work. Internally, Autodesk Inventor uses a consistent set of units regardless of what the user has specified as the document default. The precision is always double-precision floating point, regardless of the precision specified by the user. The internal units used by Inventor for the various types of units are listed below:

Mass: Kilogram Length: Centimeter Time: Second Temperature: Kelvin Angle: Radian

When the user uses the Units tab to specify display units, this does not affect the internal database units in any way. The data is always saved and utilized using the database units listed above. Autodesk Inventor uses the display units whenever it needs to interact with the user and display unit information or when it needs to interpret unit information the user has entered. For example, let's look at the extrusion depth in more detail. When the user specifies "5" as the depth of the extrusion, the document length unit is used to interpret this as five inches. This value is converted to the internal length unit of centimeters and stored as a double precision value. All internal calculations use this value. When the length of the extrusion needs to be shown to the user, the internal centimeter value is converted to the current document unit with the specified precision and displayed. The internal value for the length, however, remains in centimeters with the full double precision accuracy.

==============================

I'd really wonder about the tech writer that wrote that .

What it may mean is that all applications programs that use a dimension other than centimeter must do the conversion .... which probably adds system overhead IMHO. If this is the case then all IGES files FROM Autocad would have centimener units as the flag I think ... no options ....

"Internal units" should be just dimensionless numbers ... except for that (integer) flag.

Does anyone know if this was also the case in earlier versions?

IV has been that way, for better or worse, since it's inception (or so I guess; since at least v4 which was my first exposure). Doesn't apply to Autocad which is a unitless system, as you have described. Also, it wouldn't (or shouldn't... there's a bug in Acad2004 that writes all SAT's out as mm regardless of user spec units; they simply set the flag incorrectly) effect translations, as values are converted before being fed to the iges write function.

The problems I ran across in Inventor were mostly in the sketch creation. Regardless of the units you choose as default, it always showed a decimal version. (though it accepted and then converted most any unit you typed in) If you wanted feet-inch, it would show decimal feet. There were a few other areas where it was inconsistant, but I don't recall them now.

I think CAD programs should always be unitless internally. That way, it wouldn't matter if you want to work in angstroms, wavelengths, inches, meters, or lightyears.

Joe Dunfee

Jeff, Thanks. It is strange though. Usually options are added, not deleted, as systems evolve.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required