I've researched possibilities in this direction extensively for

ImplicitCAD (implicitcad.org). This is basically logic programming for

programmatic CAD, which makes a lot of sense. The fact that

traditional CAD programs use geometric constraints, which is a weak

version of this, and they're super useful, is another indicator that

this is a promising direction.

If you only want to do affine equations, this is a pretty easy

problem. If you want to allow polynomials, it becomes Algebraic

Geometry (specifically Real Algebraic Geometry, which is much much

harder). You can solve these problems with Grobner Basis, but it's

asymptotic computational complexity is horribly nasty (worst case is

O(exp(exp(n)) where n is number of variables) and you don't get the

extension theorem in RAG, so if you're only interested in real

solutions and the solution space isn't finite, you're in a nasty

position.

I've got a good and fast solution working for a subset of this problem

using a combination of automated theorem proving techniques from

algebraic geometry and some numerical tricks for mech.ly (which is the

project I'm presently dedicated to) and may write a library for

ImplicitCAD as proof-of-concept.

Unless you're willing to do a ton of work, though, you should probably

use an existing computer algebra library, bind to that, and error when

it can't solve your problem.

Also, one big issue is that you usually don't have a single solution

to a problem like this, but a large class of solutions. Selecting one

in a programmatic CAD tool like OpenSCAD or ImplicitCAD is

problematic. Finding a solution to this is one of the things that made

me pivot into working on mech.ly.

Chris

On Sun, May 26, 2013 at 6:01 PM, Felipe Sanches <

[hidden email]> wrote:

> On Sun, May 26, 2013 at 6:47 PM, whosawhatsis <

[hidden email]> wrote:

>> When I want to do something like this, I enclose both objects in a single

>> translate() module, then further translate one or both to do the offset. If

>> I want to move just one (relative to the other), I change the inner

>> translate, and if I want to move them together, I modify the outer

>> translate. You can also set a variable for the translation elsewhere, and

>> include that term in two different translations, then change the variable if

>> you want to move both.

>

> Yes, I know we have ways to achieve the desired positioning result

> without modifing the language. But certainly we can improve the

> expressiveness of the language by having better positioning

> constructs. By the way, this is not restricted to positioning issues.

> It is actually a general problem about mutual mathematical relations

> between constants that can be used for anything. Positioning is just

> an easy/simple example. But these constants can be used for scaling of

> objects, for dimensions of portions of an object, etc... It applies to

> whatever the language constants can affect in the scene.

>

>>

>> Since there is no point-and-click manipulation, I see no reason you would

>> need to add such an alternative way of controlling positioning, which would

>> break the hierarchical structure of the language.

>

> One does not need a point and click interface to benefit from a better

> language construct that makes geometric ideas easier to describe.

> _______________________________________________

> OpenSCAD mailing list

>

[hidden email]
>

http://rocklinux.net/mailman/listinfo/openscad>

http://openscad.org -

https://flattr.com/thing/121566_______________________________________________

OpenSCAD mailing list

[hidden email]
http://rocklinux.net/mailman/listinfo/openscadhttp://openscad.org -

https://flattr.com/thing/121566