Re: [Lib2geom-devel] some todos and wishes

[mgsloan <mg...@gm...>]

>
>
> I think JF has swayed me to only using pw<d2 for the bulk of operations
> and use sectionize to convert d2<pw to pw<d2.  I can't think of any
> compelling d2<pw cases really, other than perhaps avoiding excessing
> segmentation.  That suggests better joining algorithms.


Sounds good!  Yeah, one thing that might be nice would be an algorithm to
find combinable, adjacent segments, and do combine them.  Hopefully it can
be written in such a way that it works for both 1d and 2d (eg, write 1d
accuracy and combination algos, then do a 1d and 2d optimizer).


> My biggest dislike of empty = 0 is that there is no analogous constant
> vale version.


Well, there's always Linear(x) from 0 to 1.  I guess that's what your
talking about.  I think SBasis has a similar situation in that empty = 0.
However, empty = 0 isn't as pure for pw - with polynomials it makes sense.
So, I guess I agree :)

- general purpose bezier to sbasis (essentially a sparse matrix multiply)


I think yesterday you mentioned needing to re-write this.  I've committed a
bezier.h, which is basically just a 1D version of path2's bezer.  It may be
renamed to BezierComponent or something like that in the future, but anyway,
this would be a good spot to add the code.

- pow of various forms (pow(sb, double), pow(double, sb) etc)
> - solve boundary value ODE (which is essentially what exp and sin do
>      already)
> - compose with periodic function
> - geometric conversion to beziers (raph's algorithm perhaps?)


Sounds like most of that is yours/jfs domain.  As for the compose with
periodics, first off, we'd need a periodics class which stores offset,
period, and a pw or an sb for the period.  Given a portion operation which
returns a pw of an interval of the periodic, composing (periodic . pw) would
become (pw . pw).  Composing (pw . periodic) would result in a periodic, and
would essentially be the inner sb/pw composed with the first pw.  So, I
think periodic stuff can be managed fairly quickly.  They allow fairly easy
segment count explosion, though, if you go high-frequency and compose with a
pw.

There is also a fair amount of old code which can be removed or simplified
> with Path2


Yep.  While I like how path2 keeps itself within a few files, I think it's
time to proliferate it out a bit, as the classes get more code-heavy.  We
really want to avoid using multiple structures for the same kinds of data.

Then that old code can either be moved to the new structures or deleted.
I'm pretty sure we could remove all of the old path code right now and still
compile, but there might still be some good stuff to mine.

-mgsloan