The reason why Keras became so popular is that it borrowed a lot of concepts from Lua Torch (which predates even Theano). And anyone who worked with Torch immediately sees it reading Keras code. But Torch was Lua and naturally it received less recognition than it deserved. Your will not lose anything by simply moving to PyTorch.
I think it was just a matter of time till TF would get superseded by PyTorch. The only reason we kept TF on prod is the java api which allowed us to quickly load and serve TF models. I spent so many sleepless nights trying to port Torch model to TF back in the days and make it work the same as Lua based prototype. Whole TF "experience" made us switch to plain Python services model throwing away all the boilerplate Scala/Java code for TF. It doesn't happen often in tech that a better engineered product gets more traction and recognition eventually and I am glad that PyTorch did.
It is not as easy as it sounds. There are a lot of ppl who earn the living by doing the accounting for you and for that they use paper form. Most companies do use and are obliged by legislation to do accounting in paper form too. Paper is here to stay, for a while.
Rust is definitely more difficult but it has it benefits, I guess? For me as a Python guy D was just easier both concept wise and syntax wise. I could write a relatively complex algorithm after 2 weeks of reading a D programming book with just standard ops. And it was definitely faster. Maybe not as fast as C but I felt efficient. Personally, I liked that D does pray FP like Scala while also being a multiparadigm language. Aaand it is definitely more readable.
It's a nice overview article for anyone interested in the topic of IE from financial documents. However, for industrial level solutions Tesseract does not cut it. Abbyy is the best OCR engine on the market currently. Receipt IE works just fine with rules supported by a small BiLSTM as fallback just because receipts do not contain a lot of text. With invoices this approach is suboptimal. On a general note no DL approach will give you fast and high enough results just because any advanced network would be too slow and too generic. If extraction takes more than 5 sec. it is hard to sell such system.
Notebooks are bad and unreliable. You are repeating your code all the time, you are limited to work with smaller datasets. If you are into visual data analysis use Orange or other similar data mining tools.
We allow usage of notebooks only for presentation purposes.
I would argue that because it could have been Lua in the first place. Fastest C ffi. Faster, simpler scripting language with natural 1 - indexed arrays like in fortran, matlab. It got some traction, yes, from ML community thanks to Torch but Python had better batteries already at that time.
yep, it is the current state of things. However, it would be better to have all this huge ecosystem written in a single performant language. People trade perceivable simplicity for things that are more beneficial long term.
Kaggle doesn't make a lot of sense to me. It's a good self education platform but that's it. It is kind of sad to see job interview candidates for ML positions whose only ML experience is Kaggle.
It depends. We do commercial pdf and scanned information extraction as well as table detection for line items for invoices, receipts and remittance slips. We have been successfully using rule-based system for years but are mixing in deep learning now. I also know a about 5 other companies competing in the same field. So, I wouldn't say it is underdeveloped.
I started reading about D couple of months ago after work. For me, it appeared to be easier than Scala for example which I use at work. Not only is it simpler, it is faster and I am not even talking about compile times. These features alone persuaded me to rewrite couple of Scala based data processing algorithms we use for our ML models to give it a try. What I really liked is that you don't have to know all about the language to write perfomant code. Still keep wondering how does it get constantly overlooked.
That is if we count the development of D1 which appeared in 1999. Later in 2007 D2 emerged with breaking changes. D1 was discontinued in 2011 and D2 became simply D. So, yes formally D is 20 years old but one could say that it's newer reworked version is just 12.
Cannot but agree. Above that 1.14 documentation was simply deleted from the tensorflow website and now we are scratching our heads at what to do when it comes to model maintenance.
We serve our models via TF Java API since our system is Java/Scala based. We can't even update existing TF Java API because it is incompatible with anything prior to 1.15. It's an utter mess.