[OpenSCAD] General approach

nop head nop.head at gmail.com
Sun Jul 7 11:05:30 EDT 2019


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.
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20190707/3d02061c/attachment.html>


More information about the Discuss mailing list