On 13/06/2015 10:35 p.m., Tofu Ninja wrote:
> On Saturday, 13 June 2015 at 08:45:20 UTC, John Colvin wrote:
>> The tiny subset of numerical linear algebra that is relevant for
>> graphics (mostly very basic operations, 2,3 or 4 dimensions) is not at
>> all representative of the whole. The algorithms are different and the
>> APIs are often necessarily different.
>>
>> Even just considering scale, no one sane calls in to BLAS to multiply
>> a 3*3 matrix by a 3 element vector, simultaneously no one sane
>> *doesn't* call in to BLAS or an equivalent to multiply two 500*500
>> matrices.
>
> I think there is a conflict of interest with what people want. There
> seem to be people like me who only want or need simple matrices like glm
> to do basic geometric/graphics related stuff. Then there is the group of
> people who want large 500x500 matrices to do weird crazy maths stuff.
> Maybe they should be kept separate? In which case then we are really
> talking about adding two different things. Maybe have a std.math.matrix
> and a std.blas?

IMO simple matrix is fine for a standard library. More complex highly specialized math library yeah no. Not enough gain for such a complex code.

Where as matrix/vector support for e.g. OpenGL now that will have a high visibility to game devs.

On Saturday, 13 June 2015 at 10:35:55 UTC, Tofu Ninja wrote:
> On Saturday, 13 June 2015 at 08:45:20 UTC, John Colvin wrote:
>> The tiny subset of numerical linear algebra that is relevant for graphics (mostly very basic operations, 2,3 or 4 dimensions) is not at all representative of the whole. The algorithms are different and the APIs are often necessarily different.
>>
>> Even just considering scale, no one sane calls in to BLAS to multiply a 3*3 matrix by a 3 element vector, simultaneously no one sane *doesn't* call in to BLAS or an equivalent to multiply two 500*500 matrices.
>
> I think there is a conflict of interest with what people want. There seem to be people like me who only want or need simple matrices like glm to do basic geometric/graphics related stuff. Then there is the group of people who want large 500x500 matrices to do weird crazy maths stuff. Maybe they should be kept separate? In which case then we are really talking about adding two different things. Maybe have a std.math.matrix and a std.blas?

Yes, that's what I was trying to point out. Anyway, gl3n or similar would be great to have in phobos, I've used it quite a bit and think it's great, but it should be very clear that it's not a general purpose matrix/linear algebra toolkit. It's a specialised set of types and operations specifically for low-dimensional geometry, with an emphasis on common graphics idioms.

On Saturday, 13 June 2015 at 10:37:39 UTC, Rikki Cattermole wrote:
> On 13/06/2015 10:35 p.m., Tofu Ninja wrote:
>> On Saturday, 13 June 2015 at 08:45:20 UTC, John Colvin wrote:
>>> [...]
>>
>> I think there is a conflict of interest with what people want. There
>> seem to be people like me who only want or need simple matrices like glm
>> to do basic geometric/graphics related stuff. Then there is the group of
>> people who want large 500x500 matrices to do weird crazy maths stuff.
>> Maybe they should be kept separate? In which case then we are really
>> talking about adding two different things. Maybe have a std.math.matrix
>> and a std.blas?
>
> IMO simple matrix is fine for a standard library. More complex highly specialized math library yeah no. Not enough gain for such a complex code.
>
> Where as matrix/vector support for e.g. OpenGL now that will have a high visibility to game devs.

Linear algebra for graphics is the specialised case, not the other way around. As a possible name for something like gl3n in phobos, I like std.math.geometry

On Saturday, 13 June 2015 at 11:05:19 UTC, John Colvin wrote:
> Linear algebra for graphics is the specialised case, not the other way around. As a possible name for something like gl3n in phobos, I like std.math.geometry

A geometry library is different, it should be type safe when it comes to units, lengths, distances, areas...

I think linear algebra should have the same syntax for small and large matrices and switch representation behind the scenes.

The challenge is to figure out what kind of memory layouts you need to support in order to interact with existing frameworks/hardware with no conversion.

On 06/13/2015 12:35 PM, Tofu Ninja wrote:
> On Saturday, 13 June 2015 at 08:45:20 UTC, John Colvin wrote:
>> The tiny subset of numerical linear algebra that is relevant for
>> graphics (mostly very basic operations, 2,3 or 4 dimensions) is not at
>> all representative of the whole. The algorithms are different and the
>> APIs are often necessarily different.
>>
>> Even just considering scale, no one sane calls in to BLAS to multiply
>> a 3*3 matrix by a 3 element vector, simultaneously no one sane
>> *doesn't* call in to BLAS or an equivalent to multiply two 500*500
>> matrices.
>
> I think there is a conflict of interest with what people want. There
> seem to be people like me who only want or need simple matrices like glm
> to do basic geometric/graphics related stuff. Then there is the group of
> people who want large 500x500 matrices to do weird crazy maths stuff.

(It's neither weird nor crazy.)

> Maybe they should be kept separate?

I think there's no point to that. Just have dynamically sized and fixed sized versions. Why should they be incompatible? It's the same concept.

On 06/08/2015 03:55 AM, ezneh wrote:
>
> - Create / read QR codes, maybe ? It seems we see more and more QR Codes
> here and there, so it could potentially be worth it

I see them everywhere, but does anyone ever actually use them? Usually it's just an obvious link to some company's marketing/advertising. It's basically just like the old CueCat, if anyone remembers it: <https://en.wikipedia.org/wiki/CueCat>

Only time I've ever seen *anyone* actually using a QR code is when *I* use a "display QR link for this page" FF plugin to send the webpage I'm looking at to my phone.

Maybe I'm just not seeing it, but I suspect QR is more someone that companies *want* people to care about, rather than something anyone actually uses.

On Sat, 13 Jun 2015 11:46:41 -0400, Nick Sabalausky wrote:

> Maybe I'm just not seeing it, but I suspect QR is more someone that companies *want* people to care about, rather than something anyone actually uses.

same for me.

On 06/07/2015 02:27 PM, Robert burner Schadek wrote:
> Phobos is awesome, the libs of go, python and rust only have better
> marketing.
> As discussed on dconf, phobos needs to become big and blow the rest out
> of the sky.
>
> http://wiki.dlang.org/DIP80
>
> lets get OT, please discuss

What are the problems with std.json?

On Saturday, 13 June 2015 at 16:53:22 UTC, Nick Sabalausky wrote:
> On 06/07/2015 02:27 PM, Robert burner Schadek wrote:
>> Phobos is awesome, the libs of go, python and rust only have better
>> marketing.
>> As discussed on dconf, phobos needs to become big and blow the rest out
>> of the sky.
>>
>> http://wiki.dlang.org/DIP80
>>
>> lets get OT, please discuss
>
> What are the problems with std.json?

slow

Good start:
http://code.dlang.org/packages/dip80-ndslice
https://github.com/9il/dip80-ndslice/blob/master/source/std/experimental/range/ndslice.d

I miss the function `sliced` in Phobos.