Image recognition software

@rschumac

I do indeed know NR. (Unfortunately, it’s one of the trouble spots when it comes to permissive licenses.) Actually, while doing some of what I mentioned above, I consulted the relevant chapter while writing some FFT code. Unsurprisingly, this wasn’t very fast in pure Lua.

For that matter, I dabbled in SVDs too.  :) (Rank decomposition.) There’s a lot of ongoing research here! More than ever with all the new tensor libraries, I suppose. I even tried to read some of it, eventually picking up a book for some better grounding. Didn’t follow up much with SVDs, but have implemented a few other things from that, though it always comes back around to speed. And even if the math itself were fast, all these operations will punish you to no end if you don’t have an amenable memory layout, and it doesn’t help that they tend to grow quickly in size.  :smiley:

Good luck with Tensorflow! (On topic.)

If this is any indication, there’s definitely some interest in getting something going. The poster’s last words also seem to corroborate that “the most common use case is probably going to be using them, rather than training them”.

https://youtu.be/LX2qWb1NMFo

@StarCrunch, I agree… definitely using them… is the real use case. I just added my vote to that feature request. I was curious about the training part to understand the math behind it and thought it would be kind of cool to create your own little deep learning helper.

@ScottHarrison, nice stuff !.. keen to see it available in the marketplace 

@rschumac (or anybody else whose interest was piqued)

Over the course of the last few days I’ve started the aforementioned Eigen library: VERY early docs

I think by and large this supersedes my “homegrown array / tensor of sorts”, which I have mixed feelings about considering how much time I sank into that.  :smiley:

Eigen’s a templated beast, so it takes ages to compile, and that’s even with most data types disabled to speed it up). Almost inevitably, the binding code is macro- and template-heavy as well. It’s also been interesting trying to work around some of the mismatches between C++ operators and Lua, e.g. not being able to assign to return values. Quite a few auxiliary types (mappings, views) remain in limbo until I suss some of that out; I ran into this with ArrayFire too, never really coming up with anything.

The various solvers seem to work, so I might throw LU or QR (I hope I get bonus points for overloading already-obscure acronyms in the same thread) decomposition at a morphing test I have, and maybe inverse kinematics would be worth a try too. Further suggestions welcome!

@StarCrunch, great stuff! Looking forward to seeing it in the marketplace to have a play with it. I vote for IK… mainly because it just set off a (not terrible) memory of the DH method in a robotics class from the early 2000’s… but I could possibly think of use cases for a game also.