when using hulls to calculate Delaunay then you calculate everything in d+1
dimensions, which for 2D has a 4X slower predicate. Also predicates are
mostly precalculated (already implemented in the updated gist above), so
their repeated calculation in the swap method should be fast.
Anyway, let
Thank you so much!
I am very busy with other things at the moment, but will dive into the
code, attempt to update as necessary in a few weeks and share the results,
if any.
On Monday, 12 May 2014 22:52:17 UTC+2, Ariel Keselman wrote:
Just looked for the code in some old backup drive and
they are MIT licensed, no need for permission :)
how efficient is Voroni construction using conic hulls, I think Qhull which
uses convex hulls is way slower than what I plan with the algorithms
described in here: http://arxiv.org/pdf/0901.4107v3.pdf
On Thursday, 15 May 2014 09:36:06 UTC+2, Ariel Keselman wrote:
they are MIT licensed, no need for permission :)
Right, I missed that. Good :)
how efficient is Voroni construction using conic hulls, I think Qhull
which uses convex hulls is way slower than what I plan with the
Very cool!
I also dream of having a good Voronoi code in Julia. What I'm after in
particular is dynamic construction (insertion and removal) of power
diagramshttp://en.wikipedia.org/wiki/Power_diagram(a generalization of
Voronoi diagrams with weights on the generators). To
that end, I started
p.s. I implemented this some time ago (a few years?) using golang, you can
see some demo here:
https://www.youtube.com/watch?v=dfx1QA3n2xYlist=UUrqGGYkH7y1W8yH1MbxLXYg
and using Julia it was much more pleasant... of course I still have to do
all the Voronoi stuff which is really the hard part
Cool stuff, and rather a large number of calculations. In developing that,
typos would have cost me hours :).
One thought: can you make the interface more intuitive with a couple of well-
chosen immutables? I'm thinking of a SphereN (N = 2 or 3) type that you define
with the first nd+1 points,
Most of the calculation text is just generated with sympy+some text
processing, so I'm not afraid of typos :)
The calculation could be organized better resulting with much less terms if
I move the origin to overlap with one of the SphereND points.
Also I like very much the idea of having an
