[OpenSCAD] General approach

Rogier Wolff R.E.Wolff at BitWizard.nl
Sun Jul 7 10:11:35 EDT 2019


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.



More information about the Discuss mailing list