On 20/04/2016 4:49 PM, Relja Ljubobratovic wrote:
> On Wednesday, 20 April 2016 at 04:37:10 UTC, rikki cattermole wrote:
>> On the note of linear algebra.
>> Would you be willing to improve gfm:math (or start from scratch I
>> don't really care too much) for Phobos inclusion?
>>
> Frankly, I didn't know about the gfm project - it seems nice! About the
> math module, I'm not really sure how (or where) it would fit into
> Phobos? Seems to me that such module really should be kept as a library.
> Isn't there a isolated 3D math library present in dub? Anyways, I'll
> look into it more closely when I find time!


I was thinking std.math.linalg kinda seems like the right place once std.math is split up.
There is an isolated one other than gfm.math. gl3n but I don't have permission to relicense to Boost. Its mostly ready unfortunately.

>> Also how much do you know about color theory?
>> Manu really needs help to get his color work to support blending (its
>> mostly time thing really) and that would really help since its meant
>> for Phobos.
>
> I've given it only a quick look just now, and it seems great! - I'll
> definitely look into it!

Please!

Great project, good luck!

A minor note. Any specific reason, you've chosen MIT license over Boost ?

AFAICT they are practically identical, but Boost is more popular in this community, so it would be easier in the future to exchange code between your project and dlang-science, for example.

-Alexander

On Wednesday, 20 April 2016 at 06:10:50 UTC, tost wrote:
> On Wednesday, 20 April 2016 at 04:31:33 UTC, Relja

> I have an implementation of BFGS in D (except [open]BLAS :). BFGS is an algorithm for unconstrained optimization of nonlinear smooth functions. It is NOT L-BFGS and requires O(n*n) memory for optimizing f: R^n -> R. The linesearch may be useful to implement other algorithms.

Sound great! Although I'm far from implementing methods that use optimization techniques for dcv, I'll be sure to remember this. Maybe you should push the solution to github and have other people take a look?

On Wednesday, 20 April 2016 at 06:14:58 UTC, rikki cattermole wrote:
> I was thinking std.math.linalg kinda seems like the right place once std.math is split up.
> There is an isolated one other than gfm.math. gl3n but I don't have permission to relicense to Boost. Its mostly ready unfortunately.

I agree it sounds nice to have linalg package in the standard library. Although I'm still not sure about it - I've never seen such package in any other language's standard library. I'm not saying it's not right, just a bit strange to me.

On Wednesday, 20 April 2016 at 07:13:44 UTC, xenon325 wrote:
> Great project, good luck!
>
> A minor note. Any specific reason, you've chosen MIT license over Boost ?
>
> AFAICT they are practically identical, but Boost is more popular in this community, so it would be easier in the future to exchange code between your project and dlang-science, for example.
>
> -Alexander

Hey Alexander, thanks! I chose the MIT at first, but I've realized since then it would be more appropriate to license it under Boost. I will change it to boost for sure.

Thanks for the suggestion!

On Wednesday, 20 April 2016 at 07:43:01 UTC, Relja Ljubobratovic wrote:
> Sound great! Although I'm far from implementing methods that use optimization techniques for dcv, I'll be sure to remember this. Maybe you should push the solution to github and have other people take a look?

hopefully at the weekend. I want to tidy up first...

On 2016-04-20 06:31, Relja Ljubobratovic wrote:

> I've given this a lot of thought. I use OpenCV daily on the job, and I'm
> very familiar with it. I too believe it would probably be smarter,
> faster and safer to wrap its C interface with D, from the user's point
> of view.

https://github.com/jacob-carlborg/dstep

-- 
/Jacob Carlborg

On Wednesday, 20 April 2016 at 19:53:27 UTC, Jacob Carlborg wrote:
> On 2016-04-20 06:31, Relja Ljubobratovic wrote:
>
>> I've given this a lot of thought. I use OpenCV daily on the job, and I'm
>> very familiar with it. I too believe it would probably be smarter,
>> faster and safer to wrap its C interface with D, from the user's point
>> of view.
>
> https://github.com/jacob-carlborg/dstep

Is it even safe to depend on currently unmaintained C interface?

http://answers.opencv.org/question/17546/opencv-will-drop-c-api-support-soon/

On 20/04/2016 7:46 PM, Relja Ljubobratovic wrote:
> On Wednesday, 20 April 2016 at 06:14:58 UTC, rikki cattermole wrote:
>> I was thinking std.math.linalg kinda seems like the right place once
>> std.math is split up.
>> There is an isolated one other than gfm.math. gl3n but I don't have
>> permission to relicense to Boost. Its mostly ready unfortunately.
>
> I agree it sounds nice to have linalg package in the standard library.
> Although I'm still not sure about it - I've never seen such package in
> any other language's standard library. I'm not saying it's not right,
> just a bit strange to me.

I only need matrices and vectors in Phobos.
Whey do I want them? Simple.

I want windowing in Phobos. Which just so happens to have contexts such as OpenGL, Vulkan and DirectX.
Why does that matter? window.size * projMatrix is why. Making things just work without extra work.

And yes, Java does have a definition in its standard lib for Point which is what I need. Its just better to unify instead of separating it out.

On Wed, Apr 20, 2016 at 9:26 PM, rikki cattermole via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:

> On 20/04/2016 7:46 PM, Relja Ljubobratovic wrote:
>
>> On Wednesday, 20 April 2016 at 06:14:58 UTC, rikki cattermole wrote:
>>
>>> I was thinking std.math.linalg kinda seems like the right place once
>>> std.math is split up.
>>> There is an isolated one other than gfm.math. gl3n but I don't have
>>> permission to relicense to Boost. Its mostly ready unfortunately.
>>>
>>
>> I agree it sounds nice to have linalg package in the standard library. Although I'm still not sure about it - I've never seen such package in any other language's standard library. I'm not saying it's not right, just a bit strange to me.
>>
>
Fortran has some linear algebra functions in the standard library.  :-)
Java and many other modern languages are pretty much actively hostile to
doing numerical computation,
so including a linear algebra package in the standard library of those
languages would just highlight how bad they are at it.
C++ has a tradition of not having a standard library for anything you might
actually need to get work done, so I wouldn't follow their example.

--bb