Here, we explain all tasks which are currently open for contributions from the community!
This section of the docs will be updated frequently, whereby new tasks will be added and completed tasks will be removed. The tasks outlined here are generally broad high-level tasks, each of which is made up of many individual sub-tasks, distributed across task-specific ToDo List Issues.
Please read about ToDo List Issues in detail before continuing. All tasks should be selected and allocated as described in the ToDo List Issues section. We make no mention of task selection and allocation in the explanations below, which instead focus on the steps to complete only once a sub-task has been allocated to you.
The tasks currently open are:
Ivy Experimental API
Please always use the latest commit on GitHub when working on any of these tasks, DO NOT develop your code using the latest PyPI release of
Currently, we have many ToDo list issues open for a general function formatting task, which is explained below.
Each function in each submodule should be updated to follow the implementation instructions given in the Deep Dive section. The updates should be applied for the:
all backend APIs
array instance methods
container instance methods
array reverse operators
container reverse operators
The Deep Dive is an essential resource for learning how each of these functions/methods should be implemented. Before starting any contribution task, you should go through the Deep Dive, and familiarize yourself with the content.
At the time of writing, many of the functions are not implemented as they should be. You will need to make changes to the current implementations, but you do not need to address all sections of the Deep Dive in detail. Specifically, you do not need to address the following:
Implement the hypothesis testing for the function
Get the tests passing for your function, if they are failing before you start
However, everything else covered in the Deep Dive must be addressed. Some common important tasks are:
lambdaand direct bindings for the backend functions (in
ivy.functional.backends), with each function instead defined using
Implement the following if they don’t exist but should do:
ivy.Arrayreverse special method,
ivy.Containerreverse special method.
Make sure that the aforementioned methods are added into the correct category-specific parent class, such as
Correct all of the Function Arguments and the type hints for every function and its relevant methods, including those you did not implement yourself.
Add the correct Docstrings to every function and its relevant methods, including those you did not implement yourself.
Add thorough Docstring Examples for every function and its relevant methods and ensure they pass the docstring tests.
After creating your Pull Request on github, you should then produce the checklist for the formatting task as follows:
Add a comment with the following format:
add_reformatting_checklist_<category_name>on your PR, where <category_name> is the name of the category that the function belongs to. An example of this is shown below.
Using this formatting will then trigger our github automation bots to update your comment with the proper markdown text for the checklist. These updates might take a few moments to take effect, so please be patient 🙂.
After adding the checklist to your PR, you should then modify this checklist with the status of each item according to the symbols(emojis) within the LEGEND section.
When all check items are marked as (✅, ⏩, or 🆗), you should request a review for your PR and we will start checking your implementation and marking the items as complete using the checkboxes next to them.
4. In case you are stuck or need help with one of the checklist items, please add the 🆘 symbol next to the item on the checklist, and proceed to add a comment elaborating on your point of struggle with this item. The PR assignee will then see this comment and address your issues.
It is important that the PR author is the one to add the checklist generating comment in order to ensure they will have access to edit and update it later.
The checklist items’ statuses should be manually updated by the PR author. It does not automatically run any tests to update them!
Do not edit the checklist text, only the emoji symbols. 😅
Please refrain from using the checkboxes next to checklist items.
For this task, the goal will be to implement functions for each of the frontend functional APIs (see Ivy as a Transpiler), with frontend APIs implemented for:
Currently, we have many ToDo list issues open for this task.
The general workflow for this task is:
Find the correct location for the function by following the Where to place a frontend function subsection below
Implement the function by following the Ivy Frontends guide
Write tests for your function by following the Ivy Frontend Tests guide
Verify that the tests for your function are passing
If you feel as though there is an ivy function
ivy.<func_name> clearly missing, which would make your frontend function much simpler to implement, then you should first do the following:
Create a new issue with the title
Add the labels
Next Releaseto it
Then simply leave this issue open.
- At some point, a member of our team will assess whether it should be added, and if so, they will add it to another appropriate ToDo list issue (see the open task below).
You do not need to wait for this in order to proceed.
After this, you then have two options for how to proceed:
Try to implement the function as a composition of currently present ivy functions, as explained in the Short Frontend Implementations sub-section of the Ivy Frontends guide, and add the
#ToDocomment in the implementation as explained. Once the PR is merged, your sub-task issue will then be closed as normal.
Alternatively, if you do not want to try and implement the frontend function compositionally, or if this is not feasible, then you can simply choose another frontend function to work on. You could also choose to work on another open task entirely at this point if you wanted to. For example, you might decide to wait for a member of our team to review your suggested addition
ivy.<func_name>, and potentially add this to an Ivy Experimental ToDo list issue (see the open task below). In either case, you should add the label “Pending other Issue” to the frontend sub-task issue, and leave it open. This issue will then still show up as open in the original frontend ToDo list, helpfully preventing others from working on this problematic frontend function, which depends on the unimplemented
ivy.<func_name>. Finally, you should add a comment to the issue with the contents:
pending <issue_link>, which links to the
ivy.<func_name>issue, making the “Pending other Issue” label more informative.
There are a few other points to take note of when working on your chosen frontend function:
You should only implement one frontend function.
The frontend function is framework-specific, thus it should be implemented in its respective frontend framework only.
Each frontend function should be tested on all backends to ensure that conversions are working correctly.
Type hints, docstrings, and examples are not required for frontend functions.
Some frontend functions shown in the ToDo list issues are aliases of other functions. If you detect that this is the case, then you should add all aliases in your PR, with a single implementation and then simple bindings to this implementation, such as
<alias_name> = <function_name>. If you notice that an alias function has already been implemented and pushed, then you can simply add this one-liner binding and get this very simple PR merged.
In the case where your chosen function exists in all frameworks by default, but is not implemented in Ivy’s functional API, please convert your existing GitHub issue to request for the function to be added to Ivy. Meanwhile, you can select another frontend function to work on from the ToDo list! If you’re stuck on a function that requires complex compositions, you’re allowed to reselect a function too!
Where to place a frontend function#
The placement of new frontend functions for a given backend should follow the categorisation of the backend API as faithfully as possible.
In each issue description, there will be a link to the relevant reference API.
Check where the function you’re working on is located, e.g.
numpy.inner falls under
Then, in the Ivy source code, check
ivy/functional/frontends/[backend] for pre-existing files which best match the function’s category in the backend reference API.
numpy.inner as an example, we can see that there are a few
ivy/functional/frontends/numpy sub-directories to choose from:
creation_routines fft indexing_routines linalg logic ma manipulation_routines mathematical_functions matrix ndarray random sorting_searching_counting statistics ufunc
There is a
linalg sub-directory, so we choose this.
Then we need to choose from the files in this hierarchy:
__init__.py decompositions.py matrix_and_vector_products.py matrix_eigenvalues.py norms_and_other_numbers.py solving_equations_and_inverting_matrices.py
This may require a bit of reasoning.
inner calculates the inner product of two arrays, so
matrix_and_vector_products.py seems like the most appropriate option.
It is important to note that some functions require the
np.linalg.[func] namespace, as can gleamed from the numpy reference API.
These functions are listed out under the
There are some functions which have not been implemented yet, and are therefore commented out.
Once you have finished the implementation of one of these functions, uncomment it from the list.
The location of
test_numpy_inner should mirror the location of its corresponding function, this time in
If you’re unsure about where to put the function you’re working on, explore the content of these files to see if you can find a similar function.
matrix_and_vector_products.py, we can see other functions such as
outer that are similar to
This is confirmation that we’ve found the correct place!
If many of the files are empty and you’re unsure where to place your function, feel free to ask the member of the Ivy team reviewing your PR.
After creating a frontend-related Pull Request on github, you will notice a checklist is automatically added. This checklist describes the main points that need to be taken into consideration when adding a new frontend function. Please do not worry if you don’t understand everything in that checklist! It’s mainly there for the reviewer to make sure everything has been done correctly.
However, you can still use the checklist as a reference in cases where you do understand the content, if you find it helpful in your development efforts. In that case, feel free to update any “not completed” (marked with ❌) items of the list to “stuck” (🆘) and/or “ready for review” (✅) status. Your reviewer will make sure to guide you as needed 🙂.
More details on how to update the checklist items can be found in the Formatting checklist part of our docs.
Do not edit the checklist text, only the emoji symbols.
Please refrain from using the checkboxes next to checklist items.
Ivy Experimental API#
The goal of this task is to add functions to the existing Ivy API which would help with the implementation for many of the functions in the frontend.
Your task is to implement these functions in Ivy, along with their Implementation in the respective backends which are
You must also implement tests for these functions.
There is only one central ToDo list issue for this task.
A general workflow for these tasks would be:
Analyze the function type, we have a very detailed section for it in the deep dive Function Types Guide
Every function will have a different file structure according to the function type, refer to Where to place a backend function subsection below.
Implement the container instance method in
ivy/container/experimental/[relevant_submodule].pyand the array instance method in
Write tests for the function using the Ivy Tests guide, and make sure they are passing.
A few points to keep in mind while doing this:
Make sure all the positional arguments are positional-only and optional arguments are keyword-only.
In case some tests require function-specific parameters, you can create composite hypothesis strategies using the
drawfunction in the hypothesis library.
If you’re stuck on a function which requires complex compositions, feel free to reselect a function
Extending the Ivy API#
We primarily invite contributors to work on the tasks listed as Open Tasks, as these are on our current roadmap. As a result of this, we prompt everyone interested in contributing to our Experimental API to do so under the Ivy Experimental API Open Task.
However, if you would like to extend Ivy’s functionality with a new function, you are invited to open an issue using the Missing Function Suggestion template as described in Creating an Issue on Ivy’s GitHub using a Template.
In this template form, you’ll be asked to fill in the reason you think we should implement the suggested function, as well as the links to any native implementations of the suggested function.
We will review your issue as soon as possible and let you know if it’s been accepted or not. In case we deem that the suggested function fits our roadmap, we will add it as a subtask to the Ivy Experimental API Open Task.
Where to place a backend function#
The placement of the backend function should be in the proper location to follow the proper structure as guided below.
There are multiple types of backend functions as discussed above, we will go through 3 of those which you will encounter while adding a backend function in our Functional API:
Implement the function in
ivy/functional/ivy/experimental/[relevant_submodule].py simply deferring to their backend-specific implementation
(where ivy.current_backend(x).function_name() is called), refer to the Ivy API Guide
to get a clearer picture of how this must be done. Then, implement the functions in each of the backend files
you can refer to the Backend API Guide for this.
Implement the function in
ivy/functional/ivy/experimental/[relevant_submodule].py, we will not use the primary function approach in this
case, the implementation will be a composition of functions from Ivy’s functional API. You can refer to
Compositional Functions for a better understanding of this.
You don’t need to add any implementation in any other file in this case.
Sometimes, a function may only be provided by some of the supported backends. In this case, we have to take a mixed approach. You can say that this is a mix of both
primary and a compositional function. For this, you have to implement the function in
ivy/functional/ivy/experimental/[relevant_submodule].py, where the implementation
will be a composition of functions from Ivy’s functional API. After you are done with this, you then have to implement the functions in each of the backend files
Other Function Types
Standalone Functions, Nestable Functions and Convenience Functions are the ones which you will rarely come across while implementing a function from the ToDo List but they are an essential part of the Ivy API.
Creating an Issue on Ivy’s GitHub using a Template#
Go to the GitHub Ivy page, select the Issues tab, and click on the green button
New issueat the centre-right of the screen.
You will see 5 options. Each option has a predetermined form. To start filling in the form, click on the green button at the right which says
Get started. The options are explained as follows:
- Bug Report:
In case you find a bug in our API, you have to provide details in the form and the issue will be assigned to one of our team members to look into.
- Feature request:
If you want to suggest an idea for our project, our team is always open to suggestions.
- Missing Function Suggestion:
In case you find a function that the other frameworks have and is missing in our API or we have some functionality missing that the other frameworks support(superset behavior).
Reserve a sub-task from a ToDo list issue.
If you want to interact with the Ivy community to ask for any type of help, discussing and more!
To submit your issue, you will have to complete the requirements in the form and click on the green button
Submit new issueat the right-bottom of the screen.
This should have hopefully given you a good understanding of the basics for contributing.