Error on duplicate objects with the "Offset" command.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Error on duplicate objects with the "Offset" command.

White
This post was updated on .
Please, look at the example from the image:

- on the left, the first Line (vertical, green, length 100 mm) created with snap on grid;

- on the right, the second Line created with command "Offset" (200 mm);

- the Properties of the second Line reveals an error on the value "Start point (y)" which is not zero!



The others similar commands "Draw>Line>Parallel" and "Draw>Line>ParallelThroughPoint" show the same error.

Setting the "Precision" at the best value not solve the problem (see image).

Tested with:
- LibreCAD version 2.0.9 installed on "Linux Mint 18.3 Cinnamon 64-bit" (cpu AMD A10-8700P);
- LibreCAD version 2.2.0 ALPHA installed on "Linux Ubuntu MATE 16.04.4 Xenial 64-bit" usb live (cpu AMD A10-8700P).

Any ideas or solutions?

Does your "LibreCAD" reveal the same type of error with the "Offset" command?

Best regards.

Reply | Threaded
Open this post in threaded view
|

Re: Error on duplicate objects with the "Offset" command.

LordOfBikes
Administrator
Hi White,

the bug sits inside your PC, it's the big chip with the heatsink and fan on top .

But seriously, it's indeed the CPU. Digital processing units and floating point numbers are no good friends.
They lead to headache for developers more than once.
Specifically for LibreCAD, which is based on lots of mathematics, this is a balancing act between precision and tolerance.

I assume, that the digital representation of the endpoint is not exactly (x)0, (y)100 but something like (x)0, (y)99.9999999999999. This leads to an angel of not exactly 90° and at least to what you have observed.

The precision from Current Drawing Preferences are mainly for the coordinate box on the bottom left and maybe for output in the command history window. Obviously not used in the entity property window.

Of course, you are right, that -4.89859e-14 is not 0. But, -0.0000000000000489859 is nearly 0 in relation to line length of 100. And with the precision setting this value wouldn't change either, as this is the calculated value used internally. Only when printed, the value could be rounded to match the precision setting.

So this is a good and well documented observation. I wish all bug reports would have this quality, what is not true for our bug tracker. But I'm afraid, there is nothing we can do with reasonable efforts.

Armin
Reply | Threaded
Open this post in threaded view
|

A quick solution...

White
This post was updated on .
Thanks for the accurate answer, I point out a quick solution: the problem affect the "offset" function only if invoked from Command line, not if invoked from the menu Modify.

Offset by "menu" operations: 
a. click on menu Modify > Offset;
b. click on object to duplicate;
c. type in the cell on top the Distance (example "200");
d. click on drawing for Specify direction;
e. done without tolerance.

Offset by "Command line" operations: 
a. type in the Command line "offset";
b. type in the Command line the Distance (example "200");
c. click on drawing for Specify direction;
d. done with very small tolerance.

(Tested with LibreCAD version 2.0.9 installed on "Linux Mint 18.3 Cinnamon 64-bit").

Tips: the current value of the offset Distance entered by the user is stored in two different variables: one for "menu" operations (shown in the cell on top) and the other for "Command line" operations (shown in triangular brackets). Almost always these two variables return the same value, but sometimes they return different values.

I hope this tip is useful for developers: LibreCAD is really good software!

Best regards.
Reply | Threaded
Open this post in threaded view
|

Only for developers' eyes

White
This post was updated on .
For orthogonal lines and circles it would be sufficient to add/subtract the offset distance to the initial coordinates/radius before parsing.

Instead, for non-orthogonal lines and arcs the final result can be influenced by roundings and/or tolerances applied.

A small additional problem is determined by Linux users, who are fond of the "Command line", the keyboard (vs mouse) and in particular the TAB key for autocompletion...


Best regards.