Try dumbing it down by moving these to a block or a new file, and repeating the operation there.

In a way it smells like a floating point calculation error in your processor, but I'd try fixing the problem in ACAD before trying to pin it on AMD or Intel.

As always, more details = more help: what version, what computer, what processor, what graphics card, etc. yadayada

Thanks for the response Spar, sorry I didn't include the info to start with...

Tried it in a block, still happened. Copyclip to a new file twice... First one didn't do it, second one did repeat the error.

However, did find out that in the original file, if I did a TTR circle, trimmed it all out and plined, it did NOT recreate it. Even took THAT version, filleted those corners back to 0.00R (still concentric at that stage, I checked again). Then, did an 0.310 fillet again, and it DID reappear with a 0.00000004 offset center to center.

Dell Precision 5550, 32GB ram, i7-10750H
Windows 10 Pro 22H2
Autocad 2019.1.4 P.205.0.0
NVidia Quadro T2000 (Driver 31.0.15.4609)

32GB, yeah that oughta be enough.

Do you feel like sharing the file?

Is the part a long way from 0,0,0?
Are the objects you are filleting at the same elevation or in the same plane?

Spar, I'll clean out info that I can't send, and see if the file still does it. If so, I'll post shortly.

IFR, I thought about that, and even moved it to 0,0. All components at zero Z elevation, still recreated error.

What every computer scientist should know about floating-point arithmetic.

https://www.itu.dk/~sestoft/bachelor/IEEE754_artic...

0.31 will not correspond exactly to a binary representation, causing rounding error.

0.3125 should. Worth a try to find out.

Spar, powers that be have, well... lets just say uploading might be more headaches than I want today, due to the levels of proprietary data to try and strip out and our resident security gurus... I do appreciate the time though.


Interesting read 3dDave, I'd never thought through it that far.

But, that said.... when I tried it again, with .030, .031, and .03125, it recreated the error... almost....

with .03125, it offset the center asymetrically one direction...

Distance = 0'-0.00000005", Angle in XY Plane = 228.20236786, Angle from XY Plane = 0.00000000
Delta X = -0'-0.00000003", Delta Y = -0'-0.00000004", Delta Z = 0'-0.00000000"

with .0300, it offset it the other direction

Distance = 0'-0.00000006", Angle in XY Plane = 48.20237863, Angle from XY Plane = 0.00000000
Delta X = 0'-0.00000004", Delta Y = 0'-0.00000005", Delta Z = 0'-0.00000000"

does it change if you use 0.310001 ?

IFR,

Guessing that you meant 0.0310001? If so, then yes.

However, I lengthened the standoff leg just to see, and tried it with .310001 as well. Still gives the same result.

There is a file called solar.dwg floating around the web. The orbit of Pluto fills the outer boundary of the model space. If you zoom in repeatedly you can find Earth's moon. Keep zooming in until you find the Apollo 11 landing craft, and read the text on the plaque. The whole thing is a demonstration of the level of precision that Autocad maintains in its numbers, which means that rounding errors will never affect anything of significance in a drawing.

Modifying an element caused it to move 3 times the diameter of a carbon atom on your drawing. If you're a software developer with an interest in forensic science that might give you a clue to how they programmed the thing. If not, you should take a break from the screen and crack open a beverage of your choice.

flight,

I've seen the file, and other similar to it, and have acknowledged that it is a minuscule amount of variance. When you're dealing with the width of a galaxy, what does a couple meters difference make? Depending on how close you may be to a gravity well, things may become distorted and compressed, and your measurements are off anyway unless you're talking relative vs absolute, and THAT gets into an entirely different discussion.

My question was more of a why did it happen, and if it was a glitch, has anyone encountered anything similar where that was magnified to the point that it did cause concern.

That said, how do you know that it's 3 diameters of a carbon atom? I would assume, even though I've never gotten an answer when I asked one, if they come in different sizes as well. (Yes, I know, carbon atoms don't talk much)



(no.... my jokes never get any better. My kids will tell you that)

I copied 0.00000004" into wolframalpha.com and that's one of the comparisons it spit out. To the best of my knowledge, all carbon atoms are the same size tiny little black balls that connect to tiny little red balls via tiny little wood dowels. But I could be wrong. I recently listened to the audiobook of Feynman's The Character of Physical Law, and zoned out during the quantum mechanics part.

A comparable problem, which I chalked up to a software glitch, was with XLINEs and trimming them. Using large shifts of zoom in and out toward the end of a XLINE after one TRIM command (making it a RAY) would lead to the end dodging around the screen. Selecting the apparent position of the line with a click didn't grab it. One needed a wide crossing window to grab its actual location, whwerever it drifted to. Once selected, the grips were in the right place and order could be restored.
I saw this in versions of ACAD over 10 years ago, but I haven't since.

I believe Ohiocad's problem, I just can't replicate it. I also know I could live with it.

For many years, I have had to revise and edit ACAD drawings created by other designers. The fury this has induced has worn down my OCD tendencies to the point that i just don't go looking for misplaced points less than 0.0001".