Smallest unit which would make sense from a programming perspective?

CAD & CAM Tool Chain
1

One of the hall-marks of my computer usage is (La)TeX, which uses integer math for everything, so as to ensure that results are consistent from one CPU architecture to the next, so it uses the “scaled point”, 1/65,535th of a printer’s point (of which there are 72.27 to an inch) — I believe some successors have changed that base unit to be based on a Postscript point (of which there are 72 per inch), but the point still stands.

Given that metric is the default for many software programs, and that the Imperial inch was redefined in terms of the metric system, so that

1 inch == 25.4mm

that needs to be factored in, but the propensity of traditional units to be divided into halves and quarters and sixths and twelfths and so forth similar seems worthy of consideration.

Experimenting in OpenSCAD the 3D preview works all the way up through:

cube([10,10,7000000000000000000]);
//7,000,000,000,000,000,000

image
image2880×1728 188 KB

so large values shouldn’t be an issue at that end.

If we then take 72 as a base unit, double it several times to arrive at some reasonably large value (I picked 1,152) and multiply that times 254 we get:

1152 * 254 = 292608

and if we then pad that out with some zeroes we should arrive at a number, which when multiplied by pretty much any measurement one is likely to work with, then have some math operation applied to it, then convert it back by dividing by that number should work as an integer to yield an exact result.

Aside from the added overhead of having to multiply and divide to get into/out of this arbitrary unit system are there any potential problems?

2

As long as you (and OpenSCAD) are using integers I don’t see any problems with that. Are you sure that OpenSCAD still uses integers above 65535 ( the largest 16-bit unsigned integer value). Numbers in the range of your 7E18 do not even fit in a 32-bit unsigned integer. Will OpenSCAD developers keep using integers or start using floating point above a certain value?
Using floating point numbers creates a rounding problem at some point. The error will be small with 12 digits after the decimal point but when you are creating designs where one vector depends on an other, errors add up quickly.
Have you already figured out if there is a limit to the sizes for OpenSCAD designs?

1 Like
3

OpenSCAD uses only 64-bit double IEEE 754 double-precision floating point numbers with a 53-bit significant (and 11 bit exponent), not integers, fixed-point numbers, or any other floating-point representation. The only place it uses integers is for binary arithmetic (currently available only in development snapshots) where it converts the 64-bit float to a 64-bit integer, does the binary operations, then converts back to float.

Numbers are converted to 64-bit signed integers for binary arithmetic, and then converted back. Note that OpenSCAD numbers have 53 bits of precision; binary arithmetic exceeding 2^53 will be imprecise.

3 Likes
4

I kept adding zeroes, until the UI broke, then undid the last zero.

Darn. Well, that explains why I wasn’t finding an Int datatype back when I was looking for it in OpenSCAD — fortunately, I’m using Python, so can use an Int — unless someone has a Python math library which handles this sort of thing (which is simple enough, and has a license permissive enough that I can inline it, since I’m trying to keep this easy for other folks to use).

The reason I was concerned about large numbers was I initially considered a mode where one could toggle the conversion back off so that one would view gigantic versions of one’s models — not sure why I thought that was a good idea…

5

For the curious; OpenSCAD uses the GMP library (GNU Multiple Precision Arithmetic Library, https://gmplib.org/), at least for CGAL operations.

  • GMP allow pretty much arbitrary precision, limited only by system resources.

[this lib has been much on my mind lately.. I’m struggling to build it natively on my Fedora laptop; it’s a static dependency of the Prusa Slicer]

@WillAdams ; you might want to look at: gmpy2 · PyPI which might do what you want without losing precision

2 Likes
6

The manifold library which you definitely want to use for rendering in OpenSCAD uses doubles — have you looked at how manifold is integrated into OpenSCAD?

1 Like