Any graph must start with function:func:`start <onnx_array_api.light_api.start>`.

It is usually following by `vin` to add an input.

* bring (:meth:`cst <onnx_array_api.light_api.Var.bring>`,:meth:`cst <onnx_array_api.light_api.Vars.bring>`):

* bring (:meth:`Var.bring <onnx_array_api.light_api.Var.bring>`,

:meth:`Vars.bring <onnx_array_api.light_api.Vars.bring>`):

assembles multiple results into a set before calling an operator taking mulitple inputs,

* cst (:meth:`cst <onnx_array_api.light_api.Var.cst>`,:meth:`cst <onnx_array_api.light_api.Vars.cst>`):

* cst (:meth:`Var.cst <onnx_array_api.light_api.Var.cst>`,

:meth:`Vars.cst <onnx_array_api.light_api.Vars.cst>`):

adds a constant tensor to the graph,

* rename (:meth:`cst <onnx_array_api.light_api.Var.rename>`,:meth:`cst <onnx_array_api.light_api.Vars.rename>`):

* rename (:meth:`Var.rename <onnx_array_api.light_api.Var.rename>`,

:meth:`Vars.rename <onnx_array_api.light_api.Vars.rename>`):

renames or give a name to a variable in order to call it later.

* vin (:meth:`cst <onnx_array_api.light_api.Var.vin>`,:meth:`cst <onnx_array_api.light_api.Vars.vin>`):

* vin (:meth:`Var.vin <onnx_array_api.light_api.Var.vin>`,

:meth:`Vars.vin <onnx_array_api.light_api.Vars.vin>`):

adds an input to the graph,

* vout (:meth:`cst <onnx_array_api.light_api.Var.vout>`,:meth:`cst <onnx_array_api.light_api.Vars.vout>`):

* vout (:meth:`Var.vout <onnx_array_api.light_api.Var.vout>`,

:meth:`Vars.vout <onnx_array_api.light_api.Vars.vout>`):

declares an existing result as an output.

These methods are implemented in class:class:`onnx_array_api.light_api.var.BaseVar`

The mathematical function must first betranslate with:epkg:`ONNX Operators` or

The mathematical function must first betranslated with:epkg:`ONNX Operators` or

primitives. It is usually easy because the primitives are very close to what

numpy defines. It can be expressed as (the syntax is just for illustration).

return model

model = make_euclidean()

print(model)

model = make_euclidean()

print(model)

Since it is a second implementation of an existing function, it is necessary to

check the output is the same.

The development is usually driven by what they are used for. Each of them

may not fully support all your needs and it is not always easy to understand

the error messages they provide when something goes wrong.

It is better to understand its own needfefore choosing one.

It is better to understand its own needbefore choosing one.

Here are some of the questions which may need to be answered.

* ability to easily write loops and tests (control flow)

It converts python code to onnx code by analyzing the python code

(through:epkg:`ast`). The package makes it very easy to use loops and tests in onnx.

It is very close to onnx syntax. It is not easy to support multiple

implementing depending on the opset version required by the user.

implementation depending on the opset version required by the user.

Example taken from the documentation :

spox

The syntax of epkg:`spox` is similar but it does not use:epkg:`ast`.

The syntax of:epkg:`spox` is similar but it does not use:epkg:`ast`.

Therefore, `loops and tests<https://spox.readthedocs.io/en/latest/guides/advanced.html#Control-flow>`_

are expressed in a very different way.

are expressed in a very different way. The tricky part with it is to handle

the local context. A variable created in the main graph is known by any

of its subgraphs.

Example taken from the documentation :

:epkg:`sklearn-onnx` also implements its own API to add custom graphs.

It was designed to shorten the timespend in reimplementingthescikit-learn

code into onnx code. It can be used to implement a newconverted as

described in this example:

It was designed to shorten the timespent in reimplementing:epkg:`scikit-learn`

code into:epkg:`onnx` code. It can be used to implement a newconverter

mapped a custom model asdescribed in this example:

`Implement a new converter

<https://onnx.ai/sklearn-onnx/auto_tutorial/plot_icustom_converter.html>`_.

But it can also be used to build standaloneexample:

But it can also be used to build standalonemodels.

..runpython::

import numpy as np

import onnx

import onnx.helper as oh

from onnx_array_api.plotting.text_plot import onnx_simple_text_plot

dummy = np.empty([1], np_type)

return final.to_onnx({"X": dummy, "Y": dummy})

model = make_euclidean()

print(onnx_simple_text_plot(model))

model = make_euclidean_skl2onnx()

print(onnx_simple_text_plot(model))

onnxblocks

`onnxblocks<https://onnxruntime.ai/docs/api/python/on_device_training/training_artifacts.html#prepare-for-training>`_

was introduced in onnxruntime to define custom losses in order to train

a model with:epkg:`onnxruntime-training`.

a model with:epkg:`onnxruntime-training`. It is mostly used for this usage.

..code-block::python

numpy API for onnx

See:ref:`l-numpy-api-onnx`. This API was introduced to creategraph

See:ref:`l-numpy-api-onnx`. This API was introduced to creategraphs

by using numpy API. If a function is defined only with numpy,

it should be possible to use the exact same code to create the

corresponding onnx graph. That's what this API tries to achieve.

Y=np.random.rand(3,4).astype(np.float32)

expected= ((X-Y)**2).sum(keepdims=1)

got=ref.run(None, {"X":X,"Y":Y})[0]

self.assertEqualArray(expected,got)

self.assertEqualArray(expected,got,atol=1e-6)

if__name__=="__main__":