Lukasz Stafiniak
Lukasz Stafiniak
Let's consider this together with figuring out how to support `Float16`.
This isn't really worthwhile, we would rather need the significantly harder support for quantization.
We now don't have constant inlining as a separate pass -- it's just virtual node inlining.
We can also support other precisions, see [Wikipedia Bfloat16](https://en.wikipedia.org/wiki/Bfloat16_floating-point_format).
There's interest in fixed precision numbers, that would also be great in tests for reproducibility across machines.
Dynamic indexing is reverted for now, but we might reintroduce it. However, this is a general suggestion about inlining.
It's easy to handle the `Fixed_idx` and `Task_id` cases. Given that for now we don't have tensors defined locally in scope of other tensors' loops), what remains is non-linear symbols....
But let's work through a vision transformer beforehand. Maybe we come up with something less crude than fixed-receptive-field convolutions.
Ah! Could this be https://github.com/ocaml/opam/issues/601#issuecomment-1075566540 "On macOS having a gcc or binutils install that overrides xcode tools"? ( https://github.com/ocaml/opam/issues/4837, https://github.com/ocaml/opam/issues/4912, https://github.com/ocaml/opam/issues/3650, https://github.com/ocaml/opam/issues/5783 )
The functionality (gcc on MacOS) is no longer important / needed for me. If this issue is sufficiently discoverable to serve as documentation, maybe closing it is OK now.