update related work docs

docs/overview/related_work.rst

@@ -1,81 +1,32 @@
 Related Work
 ============
 
-.. _`RWorks API Standards`: related_work/api_standards.rst
-.. _`RWorks Wrapper Frameworks`: related_work/wrapper_frameworks.rst
 .. _`RWorks Frameworks`: related_work/frameworks.rst
 .. _`RWorks Graph Tracers`: related_work/graph_tracers.rst
-.. _`RWorks Exchange Formats`: related_work/exchange_formats.rst
-.. _`RWorks Compiler Infrastructure`: related_work/compiler_infrastructure.rst
-.. _`RWorks Multi-Vendor Compiler Frameworks`: related_work/multi_vendor_compiler_frameworks.rst
-.. _`RWorks Vendor-Specific APIs`: related_work/vendor_specific_apis.rst
-.. _`RWorks Vendor-Specific Compilers`: related_work/vendor_specific_compilers.rst
-.. _`RWorks ML-Unifying Companies`: related_work/ml_unifying_companies.rst
+.. _`RWorks Ivy vs ONNX`: related_work/ivy_vs_onnx.rst
 .. _`RWorks What does Ivy Add?`: related_work/what_does_ivy_add.rst
 
-In this section, we explain how Ivy compares to many other very important and related pieces of work, which also address fragmentation but at other areas within the ML stack.
+In this section, we explain how Ivy compares to many other very important and related pieces of work, which also address 
+fragmentation in parts of the ML stack.
 
-Firstly, we need to look at the overall ML stack, and understand how the high level frameworks relate to the low level components.
-
-In order to conceptualize this rather complex hierarchy, we have broken the ML stack into 9 groups, which are: `RWorks API Standards`_, `RWorks Wrapper Frameworks`_, `RWorks Frameworks`_, `RWorks Graph Tracers`_, `RWorks Exchange Formats`_, `RWorks Compiler Infrastructure`_, `RWorks Multi-Vendor Compiler Frameworks`_, `RWorks Vendor-Specific APIs`_ and `RWorks Vendor-Specific Compilers`_, going from high level to low level respectively.
-
-.. image:: https://github.com/unifyai/unifyai.github.io/blob/main/img/externally_linked/related_work/ml_stack.png?raw=true
-   :width: 100%
-
-Each of these groups within the ML stack has it's own sub-section, linked below, within which we discuss various related projects which operate at that particular level within the stack.
-
-We then compare Ivy to some other ML-unifying companies which are working on very important problems and are helping to unify the lower levels of the ML stack.
-We see these efforts as being very complimentary to Ivy's vision for high level unification.
-
-Finally, we discuss how Ivy compares to each of these important works at all levels within the ML stack.
-
-
-| (a) `RWorks API Standards`_ 🤝🏽
-| Standardized APIs which similar libraries should adhere to
-|
-| (b) `RWorks Wrapper Frameworks`_ 🎁
-| Frameworks which wrap other ML frameworks
-|
-| (c) `RWorks Frameworks`_ 🔢
+| (a) `RWorks Frameworks`_ 🔢
 | Standalone ML Frameworks
 |
-| (d) `RWorks Graph Tracers`_ 🕸️
+| (b) `RWorks Graph Tracers`_ 🕸️
 | Extracting acyclic directed computation graphs from code
 |
-| (e) `RWorks Exchange Formats`_ 💱
-| File formats to exchange neural networks between frameworks
-|
-| (f) `RWorks Compiler Infrastructure`_ 🔟️🏗️
-| Infrastructure and standards to simplify the lives of compiler designers
-|
-| (g) `RWorks Multi-Vendor Compiler Frameworks`_ 🖥️💻🔟
-| Executing ML code on a variety of hardware targets
-|
-| (h) `RWorks Vendor-Specific APIs`_ 💻🔢
-| Interfacing with specific hardware in an intuitive manner
-|
-| (i) `RWorks Vendor-Specific Compilers`_ 💻🔟
-| Compiling code to specific hardware
-|
-| (j) `RWorks ML-Unifying Companies`_ 📈
-| Companies working towards unification in ML
+| (c) `RWorks Ivy vs ONNX`_ 💱
+| How Ivy compares in functionality to ONNX
 |
-| (k) `RWorks What does Ivy Add?`_ 🟢
+| (d) `RWorks What does Ivy Add?`_ 🟢
 | How does Ivy fit into all of this?
 
 .. toctree::
    :hidden:
    :maxdepth: -1
    :caption: Related Work
 
-   related_work/api_standards.rst
-   related_work/wrapper_frameworks.rst
    related_work/frameworks.rst
    related_work/graph_tracers.rst
-   related_work/exchange_formats.rst
-   related_work/compiler_infrastructure.rst
-   related_work/multi_vendor_compiler_frameworks.rst
-   related_work/vendor_specific_apis.rst
-   related_work/vendor_specific_compilers.rst
-   related_work/ml_unifying_companies.rst
+   related_work/ivy_vs_onnx.rst
    related_work/what_does_ivy_add.rst

docs/overview/related_work/ivy_vs_onnx.rst

@@ -0,0 +1,43 @@
+.. _`RWorks Ivy vs ONNX`:
+
+Comparing Ivy with ONNX
+=======================
+
+.. _`Open Neural Network Exchange (ONNX)`: https://onnx.ai/
+.. _`ONNX`: https://onnx.ai/
+
+.. |onnx| image:: https://raw.githubusercontent.com/unifyai/unifyai.github.io/main/img/externally_linked/related_work/exchange_formats/onnx.png
+    :height: 20pt
+    :class: dark-light
+.. |ivy| image:: https://raw.githubusercontent.com/ivy-llc/ivy-llc.github.io/main/src/assets/full_logo_dark_long.svg#gh-dark-mode-only
+    :height: 26pt
+    :class: dark-light
+
+ONNX |onnx|
+-----------
+
+Neural network exchange formats define a standardized file representation specifically for neural networks. The idea is that these can be used as 
+an intermediate representation for communicating or “exchanging” neural network architectures between different ML frameworks or between ML frameworks 
+and the target hardware. The focus is generally on simplifying the deployment of neural networks, with a typical workflow being: train the model, 
+save in an exchange format, and use this exchange format to communicate with the target compilers and hardware for model inference.
+
+The `Open Neural Network Exchange (ONNX)`_ is a standardized static file format which fully defines the structure of a neural network and all of its weights.
+Third parties can implement their own bindings to the ONNX standard format, which then enables the model to be saved to disk in the standard ONNX file format, 
+and be deployed on any hardware which supports the ONNX format. Some frameworks have also added support to "load in" ONNX models from disk, as well as support 
+for exporting to the format. This enables some degree of model conversion between frameworks, but generally only for model deployment and not training. ONNX 
+focuses on core neural network operations, with limited support for other more general array processing functions such as high order optimization, 
+signal processing, and advanced linear algebra.
+
+|ivy|
+-----------
+
+The goal of Ivy is to be a comprehensive ML code conversion tool for all aspects of ML development, rather than solely focusing on deployment. 
+Ivy's transpiler uses a source code-to-source code approach to conversion, allowing any ML code to be converted. This includes models, functions, tools, 
+and entire libraries or codebases, providing a holistic solution for ML framework interoperability. Exchange formats like ONNX primarily work with deep 
+learning models, focusing on deployment and inference optimization. While ONNX offers a standardized file format that ensures consistent model representation 
+and efficient inference across diverse hardware platforms, it has limited support for model training and may not fully support advanced framework-specific 
+features. In contrast, Ivy supports both training and inference for converted models, enabling seamless end-to-end ML workflows within different frameworks. 
+By preserving the full functionality and flexibility of the original code, Ivy allows developers to leverage advanced features and optimizations specific to 
+each framework, thus addressing the limitations of exchange formats that only handle deep learning models for inference purposes. Ultmately, Ivy aims to solve 
+the broader challenge of enabling seamless development and flexibility across multiple ML frameworks, whereas ONNX addresses deployment of trained models 
+across various platforms and hardware environments.