operator specific init function about connxr

[alrevuelta]

therefore resolving can only happen after a previous operator has been executed.
Not sure what you mean by this.

Yes, this is something that we have to fix. Our current implementation is hardcoded to float.

// inference.c
...
all_context[nodeIdx].outputs[i]->data_type = 1;
...

So I imagine that the "initialisation" function that you are referring to is a function that populates this data_type for a given operator, right? Or what do you mean by "initializes its outputs"?

Someway related to #40, we have to think a way to know the output data_type for each operator. I haven't deeply looked into it but I had in mind some kind of generic function, and treat the specific cases aside. Some come cases from the top of my mind:

• If the operator has only 1 input and 1 output. Output data_type is the same as the input one (with some exceptions ofc)
• If there are two inputs, take the data_type of the first one.
• Treat aside specific cases such as Cast, Constant,...

[nopeslide]

In order to run an operator, all its inputs must be allocated (i.e. data field, not the tensor itself), have a set datatype/shape/... attribute and be filled with data.
Currently the executer does all of these things at once, I would like to split these things up.
As far as I see it, the allocation and setting of datatype/shape/... can be done before any calculation.
So we could split up these parts into two functions, one that does the actual calculation and one that does all the other stuff needed beforehand.

Someway related to #40, we have to think a way to know the output data_type for each operator. I haven't deeply looked into it but I had in mind some kind of generic function, and treat the specific cases aside. Some come cases from the top of my mind:

At least for things like the shape attribute, I don't think a generic approach is possible. Would be great, but I don't see it.

[alrevuelta]

Sounds good. I wasn't thinking about the shape but can help to remove repeated code. Some operators like Conv need quite a lot of code to calculate the output shape, and with the current implementation we have to run this calculations for every type (float, double). This idea might help with that also.