On 6/13/15 11:46 AM, Nick Sabalausky wrote:
> 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.
>

A rather cool usage of QR code I saw was a sticker on a device that was a link to the PDF of the manual.

-Steve

On Saturday, 13 June 2015 at 11:18:54 UTC, Ola Fosheim Grøstad wrote:
>
> I think linear algebra should have the same syntax for small and large matrices and switch representation behind the scenes.

Switching representations behind the scenes? Sounds complicated.

I would think that if you were designing it from the ground up, you would have one general matrix math library. Then a graphics library could be built on top of that functionality. That way, as improvements are made to the matrix math functionality, the graphics library would benefit too.

However, given that there already is a well developed math graphics library, I'm not sure what's optimal. I can see the argument for implementing gl3n in the standard library (as a specialized math graphics option) on its own if there is demand for it.

On Sat, 13 Jun 2015 21:57:42 -0400, Steven Schveighoffer wrote:

> A rather cool usage of QR code I saw was a sticker on a device that was a link to the PDF of the manual.

it's k001, but i'll take a printed URL for it in any time. the old good URL that i can read with my eyes.

On Sunday, 14 June 2015 at 02:56:04 UTC, jmh530 wrote:
> On Saturday, 13 June 2015 at 11:18:54 UTC, Ola Fosheim Grøstad wrote:
>>
>> I think linear algebra should have the same syntax for small and large matrices and switch representation behind the scenes.
>
> Switching representations behind the scenes? Sounds complicated.

You don't have much of a choice if you want it to perform. You have take take into consideration:

1. hardware factors such as SIMD and alignment

2. what is known at compile time and what is only known at runtime

3. common usage patterns (what elements are usually 0, 1 or a value)

4. when does it pay off to encode the matrix modifications and layout as meta information (like transpose and scalar multiplication or addition)

And sometimes you might want to compute the inverse matrix when doing the transforms, rather than as a separate step for performance reasons.

> I would think that if you were designing it from the ground up, you would have one general matrix math library. Then a graphics library could be built on top of that functionality. That way, as improvements are made to the matrix math functionality, the graphics library would benefit too.

Yes, but nobody wants to use a matrix library that does not perform close to the hardware limitations, so the representation should be special cased to fit the hardware for common matrix layouts.

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?

+1

nobody uses general purpose linear matrix libraries for games/graphics for a reason, many game math libraries take shortcuts everywhere and are extensively optimized(e.g, for cache lines) for the general purpose vec3/mat4 types.

many performance benefits for massive matrices see performance detriments for tiny graphics-oriented matrices. This is just shoehorning, plain and simple.

On Sunday, 14 June 2015 at 08:14:21 UTC, weaselcat wrote:
> nobody uses general purpose linear matrix libraries for games/graphics for a reason,

The reason is that C++ didn't provide anything. As a result each framework provide their own and you get N different libraries that are incompatible.

There is no good reason for making small-matrix libraries incompatible with the rest of eco-system given the templating system you have in D. What you need is a library that supports multiple representations and can do the conversions.

Of course, you'll do better if you also have term-rewriting/AST-macros.

On Sunday, 14 June 2015 at 09:07:19 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 14 June 2015 at 08:14:21 UTC, weaselcat wrote:
>> nobody uses general purpose linear matrix libraries for games/graphics for a reason,
>
> The reason is that C++ didn't provide anything. As a result each framework provide their own and you get N different libraries that are incompatible.
>
> There is no good reason for making small-matrix libraries incompatible with the rest of eco-system given the templating system you have in D. What you need is a library that supports multiple representations and can do the conversions.
>
> Of course, you'll do better if you also have term-rewriting/AST-macros.

The reason is general purpose matrixes allocated at heap, but small graphic matrices are plain structs. `opCast(T)` should be enough.

On Sunday, 14 June 2015 at 09:19:19 UTC, Ilya Yaroshenko wrote:
> The reason is general purpose matrixes allocated at heap, but small graphic matrices are plain structs.

No, the reason is that LA-libraries are C-libraries that also deal with variable sized matrices.

A good generic API can support both. You cannot create a good generic API in C. You can in D.

On Sunday, 14 June 2015 at 09:25:25 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 14 June 2015 at 09:19:19 UTC, Ilya Yaroshenko wrote:
>> The reason is general purpose matrixes allocated at heap, but small graphic matrices are plain structs.
>
> No, the reason is that LA-libraries are C-libraries that also deal with variable sized matrices.
>
> A good generic API can support both. You cannot create a good generic API in C. You can in D.

We need D own BLAS implementation to do it. Sight, DBLAS will be largest part of std.

On Sunday, 14 June 2015 at 09:59:22 UTC, Ilya Yaroshenko wrote:
> We need D own BLAS implementation to do it.

Why can't you use "version" for those that want to use a BLAS library for the implementation?

Those who want replications of LAPACK/LINPACK APIs can use separate bindings? And those who want to use BLAS directly would not use phobos anyway, but a direct binding so they can switch implementation?

I think a good generic higher level linear algebra library for D should aim to be equally useful for 2D Graphics, 3D/4D GPU graphics, CAD solid modelling, robotics, 3D raytracing, higher dimensional fractals, physics sims, image processing, signal processing, scientific computing (which is pretty wide) and more.

The Phobos API should be user-level, not library-level like BLAS. IMO. You really want an API that look like this in Phobos?

http://www.netlib.org/blas/

BLAS/LAPACK/LINPACK all originate in Fortran with a particular scientific tradition in mind, so I think one should rethink how D goes about this. Fortran has very primitive abstraction mechanisms. This stuff is stuck in the 80s…