Please excuse me for my OpenCL lobbying, but I pretty much came to Julia, to have these kind of algorithms as fast as possible :)
These considerations won't necessarily slow down the development of any Julia algorithm, as the implementation is rather orthogonal - which is why I don't see any harm in getting OpenCL into the discussion. I just mentioned, what I will be doing, in the hope, that people who develop any geometric algorithm in Julia keep it in mind, while designing the library. For example, the library should only use parametric types, which would enable me to use Float32. It's a small thing if you do it from the beginning, but gives you quite a headache if you try to integrate it later on. This way it becomes a lot simpler, to smuggle in some OpenCL implementations( e.g. via multiple dispatch) parallel to the already established algorithms written in Julia. I'm not talking theoretically about this, but I mention this because this is the reason why I can't use two very nice packages (namely Color.jl and Meshes.jl), without a lot of unnecessary conversions. I'm very well aware, that not everyone wants to put the extra effort into developing in OpenCL. That's why I wrote: "lets start with julia and add OpenCL later" Am Freitag, 9. Mai 2014 23:13:06 UTC+2 schrieb Steve Kelly: > > I am going to be developing some software for 3D printing. For path > planning, we will need to use the clipping algorithm. > > Graphics.jl mentions a clip function. > https://github.com/JuliaLang/julia/blob/master/base/graphics.jl > Cairo.jl uses the C implementation in Cairo. > > I would like to implement this algorithm natively in Julia. My question to > the community is whether it be more appropriate to create a new package or > optionally add the algorithm to Graphics.jl (or another package)? > > Thanks, > Steve >
