[OpenSCAD] General approach
Rogier Wolff
R.E.Wolff at BitWizard.nl
Sun Jul 7 11:57:59 EDT 2019
On Sun, Jul 07, 2019 at 04:05:30PM +0100, nop head 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.
Elaborating on my joke-corner-case of rotating by 30 degrees, the
point [2,0] becomes [sqrt(3), 1] Add an extra zero to do this if you
want this to happen in 3D. I maintain that one of the two-or-three
coordinates becomes irrational. Yes that makes the whole POINT
unrepresentable by rationals.
All this is irrelevant: Many rotations, including those by 30 degrees
will yield points not-precisely-representable 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.
Right. Good.
> 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.
rotating [0,13] by atan (12/5) should yield the point
[12,5]. Something with Pythagoras. For rationals on the X-axis, you
still get a rational destination point. But for any non-X-axis point
you still go off-rational-grid. I think. Where does 12,1 end up?
Rotate that vector back to the X axis and the point on the X-axis is
irrational (0, sqrt (145)), so when you rotate that by the atan (12/5)
you get something like [5/13*sqrt(145), 12/13*sqrt(145)] which remains
irrational.
Still, all this is of no practical use: Most cases people will design
things with irrational coordinates, so we have to do something about:
> 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.
When my suggestion of a user-configurable scaled-integer-grid is
implemented, the user has a crude way of controlling things. And it
offers extra functionality. If you know ALL your coordinates are a
multiple of 1 micron, you can set the scale of 1mm to 1000. If you are
designing a model of the death star, then setting it to 1 may be more
appropriate. The current "hidden" grid is not appropriate if you are
say designing say a model of a few atoms. Like when IBM used their new
SFM to move a few atoms into spelling IBM in a 5-atom high font.
It may not be too long from now when someone in a lab somewhere uses
openscad to design a 3D structure that might be manipulated into
existence with such tools. With the current hidden grid, that's going
to lead to surprises. Make it user-visible and when things go wrong,
that guy didn't read the manual. Case closed. Design software for
the future.
I suspect that the ATA and SD card spec guys consider their strategy
"job security". Each time we really hit the limits of the previous
standard they tack on a bunch of bits with a "well within my lifetime"
expiration date. Moore's law is pretty predictable. 5 extra address
bits expire in 10 years.
Setting the default scale to 1 million would mean the grid is 1 nm:
about ten atoms. A slight nudge is needed to design atom-scale objects
and that's acceptable.
This "there is a grid deep down below somewhere..." leads to
unpredictable behaviour. And that's not good.
Roger.
>
>
> 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
> >
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
** 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.
More information about the Discuss
mailing list