tensorflow

Oh interesting, I thought this was going to be a .gitignore file we could use in all projects :D Do you have any thoughts on rather than listing all the file extensions you don't want to track: - https://github.com/tensorflow/tensorflow/blob/master/.gitign... - https://github.com/redis/redis/blob/unstable/.gitignore - https://github.com/elastic/elasticsearch/blob/main/.gitignor... You'd list the file extensions you want to track? Here is an example for a PHP project: * !/ !.php !.md !.xml !.gitignore !composer.json Or Clojure: * !/ !.clj !*.md target/ !.gitignore If you have exceptions on these rules, you can always force-add the files or add the extension to .gitignore, to configure it not being ignored.

I think just native https://pkg.go.dev/github.com/tensorflow/tensorflow/tensorfl... but tfgo looks interesting. Actually the docs around this weren’t great. Took the train-in-python & inference-in-go approach. And only for versions greater than tf2

Right but that's not an inherent GPU determinism issue. It's a software issue. https://github.com/tensorflow/tensorflow/issues/3103#issueco... is correct that it's not necessary, it's a choice. Your line of reasoning appears to be "GPUs are inherently non-deterministic don't be quick to judge someone's code" which as far as I can tell is dead wrong. Admittedly there are some cases and instructions that may result in non-determinism but they are inherently necessary. The author should thinking carefully before introducing non-determinism. There are many scenarios where it is irrelevant, but ultimately the issue we are discussing here isn't the GPU's fault.

This is indeed the bread-and-butter, but there is use of all sorts of standard linear algebra algorithms. You can check various xla-related (accelerated linear algebra) folders in tensorflow or torch folders in pytorch to see the list of what is used [1],[2] [1] https://github.com/tensorflow/tensorflow/tree/8d9b35f442045b... [2] https://github.com/pytorch/pytorch/blob/6e3e3dd477e0fb9768ee...

you can't store a function as a tensor. the tensors are the inputs/outputs that flow along the edges of the graph. TF stores things directly as a graph: https://github.com/tensorflow/tensorflow/blob/master/tensorf... while Jax represents computations in an intermediate representation: https://jax.readthedocs.io/en/latest/jaxpr.html

I never understood why people have extensive lists of file extensions in their .gitignore files, for example `.DS_Store, .so, .dll, .pyc, .pyd, *.bak, ...`: - https://github.com/tensorflow/tensorflow/blob/a7691d53e5d3a4... - https://github.com/pytorch/pytorch/blob/02179827cb7cbc805277... I find it much easier to list the file extensions I wish to track: - https://github.com/nikonyrh/docker-scripts/blob/4aa3dc38ab59... - https://github.com/nikonyrh/rubikstimer-clj/blob/3e77b9ad88f...

If you mean StableHLO, then it has an MLIR dialect: https://github.com/openxla/stablehlo/blob/main/stablehlo/dia.... In the StableHLO spec, we are talking about this in more abstract terms - "StableHLO opset" - to be able to unambiguously reason about the semantics of StableHLO programs. However, in practice the StableHLO dialect is the primary implementation of the opset at the moment. I wrote "primary implementation" because e.g. there is also ongoing work on adding StableHLO support to the TFLite flatbuffer schema: https://github.com/tensorflow/tensorflow/blob/master/tensorf.... Having an abstract notion of the StableHLO opset enables us to have a source of truth that all the implementations correspond to.

I am pretty sure it used to be 2 spaces as well. Some public repositories such as https://github.com/tensorflow/tensorflow/tree/master/tensorf... appear to use 2 space indent throughout. I think all these will be covered by the "be consistent" clause, and whoever made the first commit decides the style.

> has on average 2.5x the number of bugs This claim is not supported by the linked article. In fact, the main claim (only 2% of bugs are type errors) of the linked article also does not make any sense. It is based on the assumption, that typing errors only ever cause TypeError, AttributeError, or NameError in Python, which is, ironically, false, because Python is a dynamic language. To give a concrete example, I went out to GitHub, got into top Python repository (TensorFlow), and searched for a first closed pull request which explicitly mentioned ValueError and did not mention either of the above. It turned out to be this one: https://github.com/tensorflow/tensorflow/pull/47017 This issue is an obvious type error: in statically-typed languages the value of float can not be nil. You could probably repeat that experiment with other closed p