tfgo VS root

eh, awesome! Seems this one, right? https://github.com/galeone/tfgo. Quite many stars.

I'm excited to share a project I've been working on: [GoFaceRec](https://github.com/modanesh/GoFaceRec). This is a face recognition tool built in Go, leveraging the power of MTCNN for face detection and QMagFace for face recognition. The project was born out of a desire to bring the power of deep learning models to the Go community. After much effort, I concluded that the best approach was to convert models to TensorFlow and then work with tfgo, a Go binding to TensorFlow's C API. In GoFaceRec, the input image is first processed, and then its embeddings are compared against the ones already computed from our dataset. If the distance between embeddings falls below a specific threshold, then the face is considered as unknown. Otherwise, the proper label will be printed. The project is tested using Go 1.17 on Ubuntu 20.04. For gocv, the version of OpenCV installed is 4.7. And for tfgo, I installed [this version](https://github.com/galeone/tfgo) instead of the official one. You can install this package by running the following command in your project: > go get github.com/modanesh/[email protected] You can find more detailed instructions on how to use the tool in the [GitHub repository](https://github.com/modanesh/GoFaceRec). I welcome any feedback, suggestions, or contributions to the project. I'm looking forward to seeing how the community uses GoFaceRec and hope it can be a valuable tool for those working on face recognition tasks. Happy coding! 🚀

Paolo Galeone has improved bindings (tfgo) that can be used for training and deployment.

https://github.com/galeone/tfgo here is a very good tutorial. I would suggest starting there.

Tensorflow is actually written in C++, and the python package is just bindings to tensorflow. There are Tensorflow Go bindings: https://github.com/galeone/tfgo.

have you tried your hands at [galeone/tfgo](https://github.com/galeone/tfgo); I've just hello-world it... so can't vouch on efficiency

I think the process of data acquisition isn't so clear-cut. Take CERN as an example: they release loads of data from various experiments under the CC0 license [1]. This isn't just a few small datasets for classroom use; we're talking big-league data, like the entire first run data from LHCb [2].

On their portal, they don't just dump the data and leave you to it. They've got guides on analysis and the necessary tools (mostly open source stuff like ROOT [3] and even VMs). This means anyone can dive in. You could potentially discover something new or build on existing experiment analyses. This setup, with open data and tools, ticks the boxes for reproducibility. But does it mean people need to recreate the data themselves?

Ideally, yeah, but realistically, while you could theoretically rebuild the LHC (since most technical details are public), it would take an army of skilled people, billions of dollars, and years to do it.

This contrasts with open source models, where you can retrain models using data to get the weights. But getting hold of the data and the cost to reproduce the weights is usually prohibitive. I get that CERN's approach might seem to counter this, but remember, they're not releasing raw data (which is mostly noise), but a more refined version. Try downloading several petabytes of raw data if not; good luck with that. But for training something like a LLM, you might need the whole dataset, which in many cases have its own problems with copyrights…etc.

[1] https://opendata.cern.ch/docs/terms-of-use

[2] https://opendata.cern.ch/docs/lhcb-releases-entire-run1-data...

[3] https://root.cern/

The odd part is that this is not just for fun. For many physicists when I was at CERN, a C++ REPL was a commonly used tool to interactively debug analyses to such a degree that many never compiled their code. Back then, I believe, it was some custom implementation included in ROOT (https://root.cern/). I even went out of my way to write C++ code compatible to it just so it could run with this implementation, otherwise some colleagues weren't interested in collaborating at all.

That Python ML code is calling C++ code running in the GPU, one more reason to use C++ across the whole stack.

CERN already used prototyping in C++, with ROOT and CINT, 20 years ago.

https://root.cern/

Nowadays it is even usable from Netbooks via Xeus.

It is more a matter of lack of exposure to C++ interpreters than anything else.

Quantum computing is a pretty interesting science too. https://home.cern/news/press-release/knowledge-sharing/cern-quantum-technology-initiative-unveils-strategic-roadmap they have to deal with lots of data streaming too https://root.cern/

I'm a user of CERN's ROOT (https://root.cern/) and while I'd usually write in C++, I've been trying to write as much Python as I can recently to get a bit better in the language.

I'm dealing with a C++ software called ROOT made by CERN, which is, if I'm not wrong, the only C++ API that we could use for data analysis such as plotting histograms, fitting multi-parameter functions and storing data in the size of TB to the disk and many more. That's the only reason why physicists still stick to this software. you can check here .

Hey, I found something which could be useful: https://root.cern