This PR is not necessary but i think it is better this way and more consistent. I'm curious to know which runtime cannig read the raw data. It should be able to cast the pointer raw_data into the proper type to read it. If a runtime cannot read int16 format, then the converting library should modify the type of an initializer. I don't think we should keep this kind of weird behavior just to accomodate a runtime.

I suggest something in-between: we generalize the helper function make_tensor to generate the more efficient encoding, but the inefficient encoding should still be supported.

Specifically, I think we need to support backward-compatibility for pre-existing models, so we should not make proto changes that break backward-compatibility.

As long as there is an efficient encoding, and we help users create the efficient encoding, that should serve the main purpose. If someone wants to explicitly create the less efficient encoding, we should not prevent it.

Note that protobuf uses variable-length encoding for integers. So, a boolean value encoded as int32 is encoded using a single byte in the proto format. In fact, I believe values 1 to 127 are encoded using 1 byte (one bit is used as the continuation-bit). Similarly, values encodable using 14 bits take 2 bytes. Otherwise, it would be 3 bytes. Or, at least, that's my understanding based on a quick look at this description

In contrast, the raw format uses a fixed-length encoding.

This pull request introduces 1 alert when merging c78c905 into 895593a - view on LGTM.com

new alerts:

• 1 for Unused local variable

I updated the code to keep the former make_tensor. I read the documentation in onnx.proto and onnx implements what it says it should do. Maybe this PR is not needed. However, it still looks counterintuitive to me. We should probably do a benchmark to compare the loading / writing time when users use make_tensor(..., raw=True or False). That would help making the right decision.