You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Claudio Squarcella <sq...@dia.uniroma3.it> on 2012/02/22 11:22:00 UTC
[math] computational geometry = math + graph ?
Hi all,
after reading the issue MATH-751[1] about computational geometry
algorithms I realized it could make sense to look at what we already did
in [graph], especially in terms of data structures. Things like
triangulations, Voronoi diagrams, etc. would need graph representations
anyway -- IMHO [math]ers should avoid to reinvent the wheel and/or
create a different representation for graphs.
Of course the downside is that [graph] in currently in Sandbox without a
Release. Still, if we agree that it would make sense to "link" the two,
maybe it is worth to wait a bit more for MATH-751 until [graph] is ready
(we're working on that!).
Looking forward to comments!
Claudio
[1] https://issues.apache.org/jira/browse/MATH-751
--
Claudio Squarcella
PhD student at Roma Tre University
http://www.dia.uniroma3.it/~squarcel
http://squarcella.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] computational geometry = math + graph ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
>
> thank you for your answers!
>
> As Thomas suggests, maybe the right solution is to build that stuff
> in [graph]. Or maybe even in a new project for computational
> geometry and graph drawing! I agree that including [graph] as a
> dependency for [math] does not sound quite right; maybe the other
> way around ...
Then, what if a user needs features in a version of [Math] than is not
compatible with the requirements of [Graph]?
Of course, you could package a shaded version of [Math] in the [Graph] JAR
but that would contain a lot of "unused" (by [Graph]) code.
>
> Also since we're talking of [math+graph], we had another overlap
> recently while dealing with properties of weights -- you know,
> semigroups, monoids, that kind of stuff. I think at some point we
> should "sit together" and understand how to deal with common
> concepts in a unified way.
In principle, it is appealing to split [Math] into sub-projects that would
seem more focused and more manageable. However, the danger is to loose
consistency, which would become really annoying in the parts of the code
that could as well sit in one library as in another (who apply different
design rules). People who need features from the first library + the new
code would prefer it to be also in the first library; and the other way
around for users of the second library.
Given that the "Commons" project looks much more like many independent
projects: Discussions on this forum are rarely cross-components, and when so
there are always people who don't think that convergence towards common
("Commons"?) rules is not worth it. [I don't claim that it is not the most
effective attitude, since it might well be that an agreement on the goal of
common rules will lead to endless discussions as to what those rules should
be...]
And changing habits... well, let's forget it ;-)
So for this issue of convergence between "geometry" in [Math] and [Graph],
will we be able to overcome the problems?
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] computational geometry = math + graph ?
Posted by Claudio Squarcella <sq...@dia.uniroma3.it>.
Hi all,
thank you for your answers!
As Thomas suggests, maybe the right solution is to build that stuff in
[graph]. Or maybe even in a new project for computational geometry and
graph drawing! I agree that including [graph] as a dependency for [math]
does not sound quite right; maybe the other way around ...
Also since we're talking of [math+graph], we had another overlap
recently while dealing with properties of weights -- you know,
semigroups, monoids, that kind of stuff. I think at some point we should
"sit together" and understand how to deal with common concepts in a
unified way.
Best,
Claudio
On 23/02/2012 10:30, Thomas Neidhart wrote:
> On Wed, Feb 22, 2012 at 1:14 PM, Simone Tripodi<si...@apache.org>wrote:
>
>> Hi Gilles,
>>
>> having a self-contained library is indeed *really* important, you get
>> a big +1 from my side.
>>
>> Anyway, I'd suggest you to adopt a strategy of shading [graph] stuff
>> useful for math, without duplicating the code nor bring the [graph]
>> dependency in [math].
>>
>> [graph] codebase is ATM in a decent state, what we miss is a little
>> bit of documentation and 2-3 algorithms impl, but in therms of design
>> I think we found a way and additional stuff can be added later in new
>> releases.
>> OTOH, we are still a little far from having arelease in the immediate
>> future, so I cannot promise "we are ready in 1 month" to release :P
>>
> As Gilles said, the self-containment of CM is a strong point, and I doubt
> if this policy should be changed.
> OTOH, duplicating things does not make sense either, so we will have to
> see. If the addition of these new features
> results in a o.a.c.m.graph package, then CM is maybe not the right place
> for it.
>
> Thomas
>
--
Claudio Squarcella
PhD student at Roma Tre University
http://www.dia.uniroma3.it/~squarcel
http://squarcella.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] computational geometry = math + graph ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> >
> > having a self-contained library is indeed *really* important, you get
> > a big +1 from my side.
> >
> > Anyway, I'd suggest you to adopt a strategy of shading [graph] stuff
> > useful for math, without duplicating the code nor bring the [graph]
> > dependency in [math].
> >
> > [graph] codebase is ATM in a decent state, what we miss is a little
> > bit of documentation and 2-3 algorithms impl, but in therms of design
> > I think we found a way and additional stuff can be added later in new
> > releases.
> > OTOH, we are still a little far from having arelease in the immediate
> > future, so I cannot promise "we are ready in 1 month" to release :P
> >
>
> As Gilles said, the self-containment of CM is a strong point, and I doubt
> if this policy should be changed.
> OTOH, duplicating things does not make sense either, so we will have to
> see. If the addition of these new features
> results in a o.a.c.m.graph package, then CM is maybe not the right place
> for it.
I think that the most promising route is, as suggested, to package the
[graph] code inside the CM JAR: code reuse + complete control over the
dependency.
Maybe that the shading "trick" could have spared us a lot of discussion
about other topics (namely the use of "cal10n"...).
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] computational geometry = math + graph ?
Posted by Thomas Neidhart <th...@gmail.com>.
On Wed, Feb 22, 2012 at 1:14 PM, Simone Tripodi <si...@apache.org>wrote:
> Hi Gilles,
>
> having a self-contained library is indeed *really* important, you get
> a big +1 from my side.
>
> Anyway, I'd suggest you to adopt a strategy of shading [graph] stuff
> useful for math, without duplicating the code nor bring the [graph]
> dependency in [math].
>
> [graph] codebase is ATM in a decent state, what we miss is a little
> bit of documentation and 2-3 algorithms impl, but in therms of design
> I think we found a way and additional stuff can be added later in new
> releases.
> OTOH, we are still a little far from having arelease in the immediate
> future, so I cannot promise "we are ready in 1 month" to release :P
>
As Gilles said, the self-containment of CM is a strong point, and I doubt
if this policy should be changed.
OTOH, duplicating things does not make sense either, so we will have to
see. If the addition of these new features
results in a o.a.c.m.graph package, then CM is maybe not the right place
for it.
Thomas
Re: [math] computational geometry = math + graph ?
Posted by Simone Tripodi <si...@apache.org>.
Hi Gilles,
having a self-contained library is indeed *really* important, you get
a big +1 from my side.
Anyway, I'd suggest you to adopt a strategy of shading [graph] stuff
useful for math, without duplicating the code nor bring the [graph]
dependency in [math].
[graph] codebase is ATM in a decent state, what we miss is a little
bit of documentation and 2-3 algorithms impl, but in therms of design
I think we found a way and additional stuff can be added later in new
releases.
OTOH, we are still a little far from having arelease in the immediate
future, so I cannot promise "we are ready in 1 month" to release :P
All the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Feb 22, 2012 at 11:55 AM, Gilles Sadowski
<gi...@harfang.homelinux.org> wrote:
> Hello.
>
>> after reading the issue MATH-751[1] about computational geometry
>> algorithms I realized it could make sense to look at what we already
>> did in [graph], especially in terms of data structures. Things like
>> triangulations, Voronoi diagrams, etc. would need graph
>> representations anyway -- IMHO [math]ers should avoid to reinvent
>> the wheel and/or create a different representation for graphs.
>>
>> Of course the downside is that [graph] in currently in Sandbox
>> without a Release. Still, if we agree that it would make sense to
>> "link" the two, maybe it is worth to wait a bit more for MATH-751
>> until [graph] is ready (we're working on that!).
>>
>> Looking forward to comments!
>
> In principle, +1 for sharing.
>
> But this will bring back the issue that some people did not want Commons
> Math to have any external dependencies...
>
>
> Best regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] computational geometry = math + graph ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> after reading the issue MATH-751[1] about computational geometry
> algorithms I realized it could make sense to look at what we already
> did in [graph], especially in terms of data structures. Things like
> triangulations, Voronoi diagrams, etc. would need graph
> representations anyway -- IMHO [math]ers should avoid to reinvent
> the wheel and/or create a different representation for graphs.
>
> Of course the downside is that [graph] in currently in Sandbox
> without a Release. Still, if we agree that it would make sense to
> "link" the two, maybe it is worth to wait a bit more for MATH-751
> until [graph] is ready (we're working on that!).
>
> Looking forward to comments!
In principle, +1 for sharing.
But this will bring back the issue that some people did not want Commons
Math to have any external dependencies...
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org