Dan Shriver tabbydan at gmail.com
Sun Jul 7 11:42:18 EDT 2019

```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

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.
>>
>> _______________________________________________