#آموزش
Imperative (or Model Subclassing) APIs

این سبک API در ابتدا توسط فریم ورک Chainer در سال 2015 معرفی شد و در سال 2017 چندین چارچوب دیگر آن را به کار گرفت (از جمله موارد ذکر شده در اینجا). در چارچوب Keras، شوله، توسعه دهنده کراس آن را "API Subclassing Model" می نامد.

بعضی از افراد می گویند "شما نمیتوانید X در چارچوب Y را اجرا کنید، شما نیاز به چارچوب Z دارید".
حتی قبلا هم که همه فریم ورک ها یک api style خاص را پشتیبانی می کردند حرف درستی نبود، اما اکنون که همه این چارچوب ها این api style را پشتیبانی میکنند این ادعا خیلی مسخره تر است! در این استایل شما می توانید کدی از یک کتابخانه را به یه کتابخانه دیگر کپی کرده و با تغییرات جزئی استفاده کنید.

این ادعا هم از همان دسته از حرفهای بی پایه و اساس است که مردم ادعا می کنند "اگر شما این مدل را در چارچوب X اجرا کنید بهتر است" - خروجی یک الگوریتم به زبان شما در آن پیاده سازی ربطی ندارد!!

هوشمنداته ترین روش این است که ترکیب پارادایم های imperative و symbolic را استفاده کنید، همان روشی که در TF.Keras و Gluon انجام می شود.
شما در اغلب موارد مزایای اصلی گراف های کامپایل شده را حفظ می کنید و در عین حال وقتی به انعطاف پذیری گراف پویا نیاز دارید هم دسترسی خواهید داشت.

توصیه میکنم style api که اشاره کردم را در توئیت Francois Chollet

https://t.me/cvision/953

و مقایسه بین تعریف کردن symbolic مدل با Imperative api در تنسرفلو 2 را در اینجا ببینید.
https://t.me/cvision/954

#tensorflow #keras #symbolic #imperative

#آموزش

در مورد پست مدیومی که امروز در اینجا از تنسرفلو 2 منتشر کردم، و مباحثی که در اینجا مطرح شد. François Chollet در باز توئیت به پست تنسرفلو مجموعه مباحثی را در اینجا مطرح کرده که خواندن آنها خالی از لطف نیست.

Symbolic APIs are APIs to build graphs of layers. Their strong points are that: - They match how we think about our networks (NNs are always visualized as graphs of layers in textbooks & papers) - They run extensive static checks during model construction, like a compiler would

This gives you the guarantee that any model that you can build, will run. The only form of debugging you'd have to do at runtime would be convergence-related. The UX of these APIs is highly intuitive and productive

Meanwhile, the subclassing API has the look and feel of objected-oriented Numpy development. It's ideal if you're doing anything that cannot easily be expressed as a graph of layers, and you feel comfortable with software engineering best practices and large Python projects.

It will involve execution-time debugging, more code, and will expose a greater error surface, but at the same time it will give you greater flexibility to express unconventional architectures.

Importantly, in TF 2.0, both of these styles are available and are fully interoperable. You can mix and match models defined with either style. At the end of the day, everything is a Model! That way, you are free to pick the most appropriate API for the task at hand.

In general I expect ~90-95% of use cases to be covered by the Functional API. The Model subclassing API targets deep learning researchers specifically (about 5% of use cases).

I think it's great that we don't silo researchers and everyone else into completely separate frameworks. It's all one API, that enables a spectrum of workflows, from really easy (Sequential) to advanced (Functional) to fully flexible and hackable (Model subclassing)

#tensorflow #keras #symbolic #imperative

#آموزش
Keras: Multiple Inputs and Mixed Data
https://www.pyimagesearch.com/2019/02/04/keras-multiple-inputs-and-mixed-data/

اگر خاطرتان باشد در https://t.me/cvision/955 گفته شد: "هوشمنداته ترین روش این است که ترکیب پارادایم های imperative و symbolic را استفاده کنید". در این آموزش میتوانید با یک مثال عملی ببینید.

#keras #symbolic #imperative #Multiple_Input

#آموزش
این آموزش از خیلی جهات به نظرم مفیده.
صورت مساله یه رگرسیون تخمین قیمت خونه است.
نوع دیتاستش که جالبه. که هم داده ی ساختاری یافته داره، مثل اندازه خونه، تعداد اتاق و ... هم تصویر اون خونه ها را داره. که باید جفت این اطلاعات را برای تخمین قیمت استفاده کنیم.
استفاده از کراس هم جالبه اینجا، برای تعریف یکی از شبکه هاش هم از مدل sequential تو keras استفاده کرده. هم از اون مدل sequentialش به عنوان بخشی از تعریف مدل کلیش با functional api کراس استفاده کرده. که اینطوری ترکیب همزمان این دو روش را میشه دید.


https://t.me/cvision/995

#آموزش
Imperative (or Model Subclassing) APIs

این سبک API در ابتدا توسط فریم ورک Chainer در سال 2015 معرفی شد و در سال 2017 چندین چارچوب دیگر آن را به کار گرفت (از جمله موارد ذکر شده در اینجا). در چارچوب Keras، شوله، توسعه دهنده کراس آن را "API Subclassing Model" می نامد.

بعضی از افراد می گویند "شما نمیتوانید X در چارچوب Y را اجرا کنید، شما نیاز به چارچوب Z دارید".
حتی قبلا هم که همه فریم ورک ها یک api style خاص را پشتیبانی می کردند حرف درستی نبود، اما اکنون که همه این چارچوب ها این api style را پشتیبانی میکنند این ادعا خیلی مسخره تر است! در این استایل شما می توانید کدی از یک کتابخانه را به یه کتابخانه دیگر کپی کرده و با تغییرات جزئی استفاده کنید.

این ادعا هم از همان دسته از حرفهای بی پایه و اساس است که مردم ادعا می کنند "اگر شما این مدل را در چارچوب X اجرا کنید بهتر است" - خروجی یک الگوریتم به زبان شما در آن پیاده سازی ربطی ندارد!!

هوشمنداته ترین روش این است که ترکیب پارادایم های imperative و symbolic را استفاده کنید، همان روشی که در TF.Keras و Gluon انجام می شود.
شما در اغلب موارد مزایای اصلی گراف های کامپایل شده را حفظ می کنید و در عین حال وقتی به انعطاف پذیری گراف پویا نیاز دارید هم دسترسی خواهید داشت.

توصیه میکنم style api که اشاره کردم را در توئیت Francois Chollet

https://t.me/cvision/953

و مقایسه بین تعریف کردن symbolic مدل با Imperative api در تنسرفلو 2 را در اینجا ببینید.
https://t.me/cvision/954

#tensorflow #keras #symbolic #imperative