Sun Jul 7 12:15:47 EDT 2019

```I avoid floating point problems by never relying on values being exact
unless they are integers and by avoiding very close vertices that might get
merged.  See
for
an example.

On Sun, 7 Jul 2019 at 16:43, Dan Shriver <tabbydan at gmail.com> wrote:

> So, I'm not sure how I should be doing things.
>
> What I'm hearing is:
> -floating point numbers are bad (sure I get that, but I think, under
> normal circumstances my values should be far enough apart so two points
> don't end up in the same space even with rounding errors); AND rounding
> floating point numbers to some (1/2)^n is pointless
> -behind the scenes stuff snaps to a grid (not sure how I change the
> settings on this), maybe this is why the rounding is pointless since it is
> doing rounding
> -doing rotations is inherently bad
>
> So what is a better way to do what I want to do?
>
> On Sun, Jul 7, 2019 at 11:07 AM nop head <nop.head at gmail.com> wrote:
>
>> Coordinates are pairs or triples of numbers so "One of the coordinates
>> becomes irrational if you rotate by +/-30+-n*90 degrees. " doesn't make
>> sense. One of the ordinates will be rational but the other not, so the
>> coordinate can't be represented exactly by rationals.
>>
>> All integer degree angles are irrational because they are converted to
>> radians. The exceptions are just multiples of 90 because they are special
>> cases in the OpenSCAD trig functions.
>>
>> Yes rotating by atan of a rational would give a rational rotation in
>> theory, but it is done in floating point and converted from radians to
>> degrees and back again, so it would be lucky to yield integers. Your
>> example does seem to but rotating by atan(12/5) is slightly off.
>>
>> I think OpenSCAD snaps to a grid to avoid CGALs infinite precision
>> precision rationals exploding. The problem is if you limit the precision in
>> any way you risk near vertices becoming coincident and that requires the
>> mesh to be repaired before being fed back to CGAL. I had a go at removing
>> degenerate triangles but in some cases truncation and snapping can create
>> self intersections and that is harder to fix.
>>
>>
>>
>> On Sun, 7 Jul 2019 at 15:12, Rogier Wolff <R.E.Wolff at bitwizard.nl> wrote:
>>
>>> On Sun, Jul 07, 2019 at 02:44:03PM +0100, nop head wrote:
>>> > That said representing geometry with rational numbers is doomed
>>> because as
>>> > son as you rotate something all the coordinates become irrational.
>>>
>>> Technically ALMOST correct.
>>> None of the coordinates become irrational if you rotate by 90 degrees.
>>> One of the coordinates becomes irration if you rotate by +/-30+-n*90
>>> degrees.
>>> In all other cases
>>> >  All of the coordinates become irrational
>>>
>>> Just kidding. (but true, or have I missed a case?)
>>>
>>> Yup! I've missed a case! Lots of them: If you rotate (0,13) by atan
>>> (5/12) you get a rational result (integer even). In this case the
>>> rotation angle is irrational.
>>>
>>>
>>> I personally don't like the "invisible" snap-to-grid. Would it be an
>>> idea to make it more explicit: All coordinates are integer multiples
>>> of the grid, but the user-units are settable to a multiple of the
>>> grid. The default being something like a million.
>>>
>>> So when I specify [1,0], internally that's represented as [1000000,0]
>>> and when I rotate that by 45 degrees that becomes [707107,707107]
>>> exactly. Predictable, verifyable, etc.
>>>
>>> You can compare this with the "scale" variable in "bc".
>>>
>>> "bc" Does arbitrary precision integer math. But when you set scale=100,
>>> the "user interface" remains the same (77*13 is still 1001), but
>>> internally numbers are multiplied by 10^100 before being used and
>>> divided by
>>> 10^100 before being printed (and after being multiplied). This results in
>>> a 100 digit approximation to pi if you type
>>>   scale=100
>>>   4*a(1)
>>>
>>>         Roger.
>>>
>>> --
>>> ** R.E.Wolff at BitWizard.nl ** https://www.BitWizard.nl/ **
>>> +31-15-2049110 **
>>> **    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233
>>> **
>>> The plan was simple, like my brother-in-law Phil. But unlike
>>> Phil, this plan just might work.
>>>
>>> _______________________________________________
>>>
>> _______________________________________________