lib2geom-devel — development discussion

Re: [Lib2geom-devel] Question about the lib2geom coordinate system.

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

On 4/16/07, MenTaLguY <me...@ry...> wrote:
>
> On Mon, 16 Apr 2007 14:04:46 -0700, "Sunburned Surveyor" <
> sun...@gm...> wrote:
> > I know that SVG uses a coordinate system in which the "X" or "northing"
> > coordinate value increases as you move "down" the screen or page. Is
> this
> > the coordinate system that lib2geom uses, or does the library employ a
> > more typical coordinate system in which the "X" or "northing" coordinate
> value
> > decreases as you move "down" the screen or page.
> >
> > If lib2geom does not use the SVG coordinate system, does it provide code
> > to do the translation?
>
> The short answer is that (ideally) nothing in lib2geom really cares.  The
> ultimate interpretation of the coordinate system is up to the client.
>

Yeah, I've gotten in trouble for making methods like cw (clockwise) and ccw
(counter-clockwise) before, as these would imply a particular coordinate
system (or at least, the desired behavior varies depending on your view of
the coord sys).

[Lib2geom-devel] nested data parallel haskell

[MenTaLguY <me...@ry...>]

Check out the slides (PDF):

 http://research.microsoft.com/~simonpj/papers/ndp/index.htm

-mental

Re: [Lib2geom-devel] Question about the lib2geom coordinate system.

[MenTaLguY <me...@ry...>]

On Mon, 16 Apr 2007 14:04:46 -0700, "Sunburned Surveyor" <sun...@gm...> wrote:
> I know that SVG uses a coordinate system in which the "X" or "northing"
> coordinate value increases as you move "down" the screen or page. Is this
> the coordinate system that lib2geom uses, or does the library employ a
> more typical coordinate system in which the "X" or "northing" coordinate value
> decreases as you move "down" the screen or page.
>
> If lib2geom does not use the SVG coordinate system, does it provide code
> to do the translation?

The short answer is that (ideally) nothing in lib2geom really cares.  The ultimate interpretation of the coordinate system is up to the client.

-mental

[Lib2geom-devel] Question about the lib2geom coordinate system.

[Sunburned S. <sun...@gm...>]

I know that SVG uses a coordinate system in which the "X" or "northing"
coordinate value increases as you move "down" the screen or page. Is this
the coordinate system that lib2geom uses, or does the library employ a more
typical coordinate system in which the "X" or "northing" coordinate value
decreases as you move "down" the screen or page.

If lib2geom does not use the SVG coordinate system, does it provide code to
do the translation?

Thanks,

Scott Huey

Re: [Lib2geom-devel] Getting Started

[MenTaLguY <me...@ry...>]

On Mon, 16 Apr 2007 12:24:17 -0700, "Sunburned Surveyor" <sun...@gm...> wrote:
> [1] Should I be using the Inkscape codeing standards for my work on
> lib2geom?

Yes.  The one difference is that we have often been putting the underscore on the end of private/protected symbols rather than the beginning.  I don't think people care too much either way, and at this point there's actually quite a bit of style cleanup which will eventually have to be done regardless.

> [2] I was going to use Anjuta as my IDE. Are there any comments on this?

I've no particular experience with Anjuta or how it would integrate with cmake.  At worst, you can use it as a glorified text editor.

> [3] I can now see that a "pointer" and a "reference" are two totally
> different things in C++, although they have there similarities. Which
> should
> I use when creating a reference to an object? It seems like pointers are
> more powerful...

References are not very useful aside from avoiding copies for passing function arguments -- and very occasionally return values (_if_ you can guarantee the lifetime of the object you're returning a reference to appropriately).

As for pointers, I think the general consensus is that explicit use of pointers should be avoided when possible.  For the moment, we try to pass things around by value (or reference, in the cases where that is appropriate).

> [4] Is there a standard set of classes that I can use in lib2geom for
> things like strings and object collections?

Yes.  The C++ standard library provides a number of things like IO, string and exception classes, and collections are provided by STL -- see http://www.sgi.com/tech/stl for documentation of the latter.

note: lib2geom should not really need to do very much IO or string manipulation.

-mental

[Lib2geom-devel] Getting Started

[Sunburned S. <sun...@gm...>]

Guys,

I was able to donwload the daily snapshot of the SVN for lib2Geom. I printed
out the code for the Rect class and the Quadtree class so that I can review
them later. I was hoping you guys might be able to help me with a few
questions I came up when I cracked my C++ book and started to think about my
first lib2geom programming task.

[1] Should I be using the Inkscape codeing standards for my work on
lib2geom?
[2] I was going to use Anjuta as my IDE. Are there any comments on this?
[3] I can now see that a "pointer" and a "reference" are two totally
different things in C++, although they have there similarities. Which should
I use when creating a reference to an object? It seems like pointers are
more powerful...
[4] Is there a standard set of classes that I can use in lib2geom for things
like strings and object collections?

Thanks,

Scott Huey

Re: [Lib2geom-devel] some todos and wishes

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

> Sorry, I managed to leave an 's' off:
>   Compute the all the left and right derivatives on the edge and if they
>   are sufficiently equal, the curves are sufficiently equal.


Ahah, that would make more sense!  I think I'll still leave it to you though
- might want to factor the order of the derivative into the error equation.

> The nice thing about having a periodic class like this is that you can
> > control what can be done with periodics - you can't perform an operation
> on
> > two periodics (might have nearly irrational period ratios), you can't
> cast
> > periodics to anything else.  All it can do is render itself useful to
> > something finite.  There are still problems though.  Lets say, pw +
> > periodic.  Outside the pw's intended domain, the periodicity will
> dissapear.
>
> Whereas lazy pws are always mergable.


I suppose that is true.  However, as far as I know it would be hard for most
lazy languages to do what we want.  The problem is that in most, all data
types are a known size - multi size things like lists comes from nesting.
There are no pointers.  So, everything must be 'based' from some point.
This creates huge problems for structures that go infinitely both ways.  The
best solution is to pick an arbitrary split point, and have two lists.
Binary trees won't make any sense, because where do you pick a split when
the domain is infinite?  I suppose some wonky logarithmic binary tree might
work.  Anyway, the point is that it'd have to be some custom, new-style
laziness.

The true solution is to have a class for every operation, which extends the
class that the operation would normally return.  Then all of the methods
would be overloaded to figure out what they need to know to be performed,
check the memo cache, and ask for anything unknown.  Operations built on top
of the atomic ones would essentially construct operation trees.  This would
all be quite cool, in a horrifyingly convoluted sort of way.  I almost want
to implement it, but rationality holds me back.

-mgsloan

Re: [Lib2geom-devel] some todos and wishes

[njh <nj...@nj...>]

On Sat, 14 Apr 2007, mgsloan wrote:

>> 
>> > 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).
>> 
>> Compute the all the left and right derivative on the edge and if they are
>> sufficiently equal, the curves are sufficiently equal.
>
>
> That's what I thought at first, however, I'm not sure how that interacts
> with combining sbasis.  This would mean that any C0, C1 pw could be a single
> sbasis.  This may indeed be possible, however, we will need to do some cost
> weighing in the function - a combination isn't valuable if it produces a
> large coefficient count while reducing precision.

Sorry, I managed to leave an 's' off:
  Compute the all the left and right derivatives on the edge and if they
  are sufficiently equal, the curves are sufficiently equal.

> The nice thing about having a periodic class like this is that you can
> control what can be done with periodics - you can't perform an operation on
> two periodics (might have nearly irrational period ratios), you can't cast
> periodics to anything else.  All it can do is render itself useful to
> something finite.  There are still problems though.  Lets say, pw +
> periodic.  Outside the pw's intended domain, the periodicity will dissapear.

Whereas lazy pws are always mergable.

sounds good.
njh

Re: [Lib2geom-devel] some todos and wishes

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

>
> > 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).
>
> Compute the all the left and right derivative on the edge and if they are
> sufficiently equal, the curves are sufficiently equal.


That's what I thought at first, however, I'm not sure how that interacts
with combining sbasis.  This would mean that any C0, C1 pw could be a single
sbasis.  This may indeed be possible, however, we will need to do some cost
weighing in the function - a combination isn't valuable if it produces a
large coefficient count while reducing precision.

> 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.
>
> Right, the main value is for things like wiggles, which are periodic.  The
> other discus-ed idea was lazy sbs such as pseudo-random, perlin, most
> higher functions (sqrt, e.g.) etc.


Lazy pw<sb>s are hard.  Maybe for 2geom scala.

The nice thing about having a periodic class like this is that you can
control what can be done with periodics - you can't perform an operation on
two periodics (might have nearly irrational period ratios), you can't cast
periodics to anything else.  All it can do is render itself useful to
something finite.  There are still problems though.  Lets say, pw +
periodic.  Outside the pw's intended domain, the periodicity will dissapear.

Anyway, progress report:
Completed - define a plotter function for d2<pw<sb>> and pw<d2<sb>> (for
toys/tests)

I've also done half of some of the other ones, like d2pw bridges and pw/d2pw
bounds.

I've modified Pw's concat to hopefully deal with emptys gracefully, however,
it is untested.

Oh, and now interval's functions look like this:
Interval::unionWith(Interval)
unify(Interval, Interval)
intersect(Interval, Interval)

Hopefully at some point rect will mostly be replaced by D2<Interval>

-mgsloan

Re: [Lib2geom-devel] some todos and wishes

[njh <nj...@nj...>]

On Sat, 14 Apr 2007, mgsloan wrote:

> 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).

Compute the all the left and right derivative on the edge and if they are 
sufficiently equal, the curves are sufficiently equal.

> 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.

Right, the main value is for things like wiggles, which are periodic.  The 
other discus-ed idea was lazy sbs such as pseudo-random, perlin, most 
higher functions (sqrt, e.g.) etc.

njh

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

Re: [Lib2geom-devel] some todos and wishes

[njh <nj...@nj...>]

On Fri, 13 Apr 2007, mgsloan wrote:

> As far as the plotters, cairo_md_sb can handle D2<Piecewise<SBasis> >.
> Actually, Piecewise<D2<SBasis> > would be loads easier to implement - will
> do next time.

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.

> The thing is, either way there's going to be a check.  I suppose the good
> thing about disallowing it is that it doesn't matter what the function
> actually does.  The current convention is that it is indeed constant zero,
> but i suppose concat does need a bit of work in that respect.  Yes, that's
> the main way to reasonably represent 0.

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

>> - define some standard functions for pw<sb>: sqrt, cos, sin...

- general purpose bezier to sbasis (essentially a sparse matrix multiply)
- 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?)

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

njh

Re: [Lib2geom-devel] some todos and wishes

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

Hmm, I think i may not have sent it to the lists...

After playing a bit with the library, I came up with some todos and
> wishes, that I submit before I forget them; some might already be there
> but I was not aware, or some might be bad ideas for some other reason...
> These are just suggestions:
>
> First, things would be more pleasant if we had:
> - automatic conversions: sb to pw<sb> (Linear to sb, double to Linear).
> - allow +,-,* between double,sb,pw<sb>,d2<pw<sb>>,d2<pw<sb>>.
> - allow composition sb(pw<sb>)
> - allow composition d2<pw<sb>>(sb) and pw<d2<sb>>(sb)
> - define a plotter function for d2<pw<sb>> and pw<d2<sb>> (for toys/tests)
>


Sounds good!  There's at least an explicit constructor for sb -> pw<sb>, and
I know there is a Linear -> SBasis.  I think I have an accidental double ->
Linear too.  Turns out single parameter constructors are interpreted as
conversions!  At somepoint I'll probably switch the single param
constructors over to explicit conversions, and stick explicit on all
non-conversion constructors.

One thing I'd like to avoid is too many operators.  Often times when it
can't figure out what you mean by a particular operator, it'll print out all
of the declerations associated with it.  However, we certainly want a
complete, predictable set of operations across all.  It's possible we might
be able to leverage implicit conversion to minimize operator numbers.

As far as the plotters, cairo_md_sb can handle D2<Piecewise<SBasis> >.
Actually, Piecewise<D2<SBasis> > would be loads easier to implement - will
do next time.

Some remarks about our conventions:
> - define "bridges" between d2<pw<sb>> and pw<d2<sb>>.
>   Although d2<pw<sb>> is usefull in some situations (plotting a function
>   for instance), many operations require synchronous cuts, so pw<d2<sb>>
>   instead. Note that once a d2<pw<sb>> has synchronous cuts, there is no
>   synchronizing for each new operation... To make this implicit, our
>   functions should accept both d2<pw<sb>> and pw<d2<sb>>, and do some
>   conversion if needed. Or should we get rid of d2<pw<sb>>?


I actually think pw<d2<sb>> might be a good way to handle that.  currently
i've got a sectionize function that does d2<pw<sb>> -> vector<d2<sb>> but
that's not very good.  pw<d2<sb>> would be a much better output for it.

- fix convention about empty sb/pw<sb>: an empty sb is the constant 0
>   while empty pw<sb> are not allowed. How do we represent 0 in pw<sb>
>   world? as (pw<sb>)Linear(0)?


The thing is, either way there's going to be a check.  I suppose the good
thing about disallowing it is that it doesn't matter what the function
actually does.  The current convention is that it is indeed constant zero,
but i suppose concat does need a bit of work in that respect.  Yes, that's
the main way to reasonably represent 0.

Some less relevant todos:
> - define some standard functions for pw<sb>: sqrt, cos, sin...
> - define pw<sb> and d2<pw<sb>> bounds.


Sounds good.  yeah, I never really put much time into d2, more of a copy
paste and modify of multidim

What do you think?


some good ideas!

[Lib2geom-devel] some todos and wishes

[<Jea...@ma...>]

Hi!

After playing a bit with the library, I came up with some todos and
wishes, that I submit before I forget them; some might already be there
but I was not aware, or some might be bad ideas for some other reason...
These are just suggestions:

First, things would be more pleasant if we had:
- automatic conversions: sb to pw<sb> (Linear to sb, double to Linear).
- allow +,-,* between double,sb,pw<sb>,d2<pw<sb>>,d2<pw<sb>>.
- allow composition sb(pw<sb>)
- allow composition d2<pw<sb>>(sb) and pw<d2<sb>>(sb)
- define a plotter function for d2<pw<sb>> and pw<d2<sb>> (for toys/tests)

I noticed some function are out of age (this is my fault!!)
- update 'unit-vector'
- update 'arc-length-sb'

Some remarks about our conventions:
- define "bridges" between d2<pw<sb>> and pw<d2<sb>>.
  Although d2<pw<sb>> is usefull in some situations (plotting a function
  for instance), many operations require synchronous cuts, so pw<d2<sb>>
  instead. Note that once a d2<pw<sb>> has synchronous cuts, there is no
  synchronizing for each new operation... To make this implicit, our
  functions should accept both d2<pw<sb>> and pw<d2<sb>>, and do some
  conversion if needed. Or should we get rid of d2<pw<sb>>?
- fix convention about empty sb/pw<sb>: an empty sb is the constant 0
  while empty pw<sb> are not allowed. How do we represent 0 in pw<sb>
  world? as (pw<sb>)Linear(0)?

Some less relevant todos:
- define some standard functions for pw<sb>: sqrt, cos, sin...
- define pw<sb> and d2<pw<sb>> bounds.

What do you think?
JF.

Re: [Lib2geom-devel] Curve/Path2 in Haskell

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

Have you already started the haskell version then? :)

Anyway, that's a pretty cool hack to allow external Curve implementations,
but do we really need it?  I'd think a 'data Curve = ' etc would be enough.
This is true of the C++ version as well - I'm for compile time
polymorphism.  If users want to add a curve type, they can contribute to the
lib.

On 3/15/07, MenTaLguY <me...@ry...> wrote:
>
> On Thu, 2007-03-15 at 12:01 -0700, MenTaLguY wrote:
> > In C++, I don't know whether it would work best for e.g. D2<SBasis> to
> > derive from Curve, or whether we keep SBasisCurve, which derives from
> > Curve and D2<SBasis> both.
>
> Alternately, we could do what the Haskell version does -- offer a choice
> between compile-time polymorphism (direct uses of SBasis, Bezier, etc)
> and run-time polymorphism (wrapped in Curve).
>
> That lets us choose either approach as appropriate, without forcing a
> performance tradeoff.
>
> -mental
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>
>
>

Re: [Lib2geom-devel] Curve/Path2 in Haskell

[MenTaLguY <me...@ry...>]

On Thu, 2007-03-15 at 12:01 -0700, MenTaLguY wrote:
> In C++, I don't know whether it would work best for e.g. D2<SBasis> to
> derive from Curve, or whether we keep SBasisCurve, which derives from
> Curve and D2<SBasis> both.

Alternately, we could do what the Haskell version does -- offer a choice
between compile-time polymorphism (direct uses of SBasis, Bezier, etc)
and run-time polymorphism (wrapped in Curve).

That lets us choose either approach as appropriate, without forcing a
performance tradeoff.

-mental

Re: [Lib2geom-devel] Curve/Path2 in Haskell

[MenTaLguY <me...@ry...>]

On Thu, 15 Mar 2007 12:01:56 -0700, MenTaLguY <me...@ry...> wrote:
> fromCurve :: (ICurve c, Typeable c) => Curve -> c

this should be:

fromCurve :: (ICurve c, Typeable c) => Curve -> Maybe c

[Lib2geom-devel] Curve/Path2 in Haskell

[MenTaLguY <me...@ry...>]

I've been thinking about Curve more since last night and I think Mike is correct that the Curve implementations and the various function types ought to be unified.  As usual, formulating the problem in Haskell has been helpful:

module Geom2.Curve (
  Curve (Curve), ICurve (..)
) where

import Control.Monad
import Data.Maybe
import Data.Typeable
import Data.Dynamic

import Geom2.D2
import Geom2.Point -- type Point = D2 Double
import Geom2.Rect  -- type Rect = D2 Range
import Geom2.Function

class ICurve c where
  initialPoint :: c -> Point
  finalPoint :: c -> Point
  fastBounds :: c -> Rect
  exactBounds :: c -> Rect
  winding :: Point -> c -> Maybe Int
  subdivide :: Double -> c -> (Curve, Curve)
  pointAt :: Double -> c -> Point
  pointAndDerivativesAt :: Double -> Int -> c -> [Point]
  toSBasis :: c -> D2 SBasis

data Curve = forall c. (ICurve c, Typeable c) => Curve c

fromCurve :: (ICurve c, Typeable c) => Curve -> c
fromCurve (Curve c) = fromDynamic $ toDyn c

instance ICurve Curve where
  initialPoint (Curve c) = initialPoint c
  finalPoint (Curve c) = finalPoint c
  fastBounds (Curve c) = fastBounds c
  exactBounds (Curve c) = exactBounds c
  winding p (Curve c) = winding p c
  subdivide t (Curve c) = subdivide t c
  pointAt t (Curve c) = pointAt t c
  pointAndDerivativesAt t n (Curve c) = pointAndDerivativesAt t n c
  toSBasis (Curve c) = toSBasis c

-- and then we should be able to define for all D2'ed functions...
instance (Function f) => ICurve (D2 f) where
  -- etc...

In C++, I don't know whether it would work best for e.g. D2<SBasis> to derive from Curve, or whether we keep SBasisCurve, which derives from Curve and D2<SBasis> both.

[Lib2geom-devel] pw_sb restructure proposal

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

I just had an idea for a possible restructure of the pw_sb end of things.
Sadly, ACSpike is mostly right, the 2geom WoC is over.  I have to focus on
school etc., not to mention C++ was starting to piss me off again..  I
seriously get the feeling that haskell + dependant types (something that
doesn't really exist...) could fit much of 2geom in 1000 lines - or at
least, most of the functions would be unnecessary.

True, I'm the main pw_sb guy, however, I've got a few possible ideas for
review:

First off, I think I recall rearing that SBasis was considered undefined
outside [0,1].  In my opinion, if we have pw_sb continue it's extreme
segments, SBasis should only really care about the interval [0, 1] in
regards to the BezOrds that make it up.

Anyway, my main plan is to combine md_pw_sb and pw_sb, generalizing the
concept of pointwise.  I think there is no real utility in having different
cuts for different dimensions, though I could be wrong - most md_pw_sb
operations seem to require cut equivalence, and thus make partition calls.

Pointwise <SBasis>
Pointwise <MultidimSBasis>

or, I suppose we could go abbreviation style:

pw<sb>
pw<md_sb>

All that is required for point-wise-ification would be a portion(double
from, double to) method.

Looking back on this plan, it seems like a good one.  Maybe enough to shake
my dissatisfaction with C++ :P

Re: [Lib2geom-devel] 0.1 release on friday?

[Aaron S. <aa...@ek...>]

mgsloan wrote:
>     * path2 from svgd - ragel/mgsloan code? (working now?)
> 
> Well, for one thing, it'd be handy if path2 could start new subpaths
> within the context of appendNew, so the code doing the building doesn't
> have to keep track of an extra var.  This also comes up with my
> extremely rudimentary inkscape interfacing code.

This is one of the reasons I was working on moving path-builder to
path2. The other thing I'd like to address in some way is assembling
SBasis that differ by a slight rounding error into a continuous path. In
gear.cpp I nudge one endpoint just slightly. It may also be possible to
nudge both endpoints. Mental is concerned about the numerical issues we
will run into here. Another option would be to add tiny line segments.
I'm concerned that these tiny segments will come back to haunt us with
bug reports when we output svg because it will seem that the nodes
double. I suppose that SBasis to bezier conversion could possibly result
in unexpected segments anyway.

Sometimes path2builder seems completely superfluous. But there are
issues and concepts around it that need to be settled and have best
practices declared.


Aaron Spike

Re: [Lib2geom-devel] 0.1 release on friday?

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

> I propose that we release version 0.1 on friday(last day of leave for me).


I suppose.  I won't be able to do so much, as finals for this semester are
going on right now, and there's a Jazz Contest/Festival thing I'm playing at
saturday.

* path2 from svgd - ragel/mgsloan code? (working now?)


Well, for one thing, it'd be handy if path2 could start new subpaths within
the context of appendNew, so the code doing the building doesn't have to
keep track of an extra var.  This also comes up with my extremely
rudimentary inkscape interfacing code.

* write to svgd/svg (we currently use cairo, but having our own writer is
> probably a good idea)


We've got a rudimentary svgd writer in read-svgd.cpp/.h

* modify the suitable toys to work with full paths rather than single
> beziers (I see that aaron/mgsloan have ported everything to use path2,
> perhaps this is sufficient for 0.1?)


Did we?  I wasn't notified! :P.  I think there are a few things still on
path, and a few on both.


> * readme/install/hacking


 I did a rudimentary HACKING a while back, and there's a README.win32 I
mostly left alone.

* release notes


Do we really need these if its the first release?

Where are we going to announce this release?


Typical inkscape news stuff.  Anything bigger would probably be overkill at
this stage.

Are we GPL or LGPL?  I forget. (GPL I think?)


I favour LGPL for this.

mgsloan

Re: [Lib2geom-devel] 0.1 release on friday?

[Aaron S. <aa...@ek...>]

njh wrote:
> * make install (aaron has this mostly working?)

Should be working now including pkg-config files. Needs testing and more
eyes.

> * readme/install/hacking

and COPYING


Aaron Spike

[Lib2geom-devel] 0.1 release on friday?

[njh <nj...@nj...>]

I propose that we release version 0.1 on friday(last day of leave for me).

Todo:
* path2 from svgd - ragel/mgsloan code? (working now?)

* write to svgd/svg (we currently use cairo, but having our own writer is 
probably a good idea)

* modify the suitable toys to work with full paths rather than single
beziers (I see that aaron/mgsloan have ported everything to use path2,
perhaps this is sufficient for 0.1?)

* fix up toys to use sb-geometry (done apart from normal-bundle, njh)

* make install (aaron has this mostly working?)

* delete path1? (need to port things like centroid, nearest location etc)

* delete useless/obsolete toys (mostly done, njh)

* copyright/licence headers (can everyone please put copyrights on this 
code).

* readme/install/hacking

* release notes

Where are we going to announce this release?

Are we GPL or LGPL?  I forget. (GPL I think?)

Comment?  Ca Va?

njh