fplll VS root

It's using the FPLLL lattice reduction library.

where ~= means "approximately equal to".

u is chosen as the product of primes of all a_i > 0 and v is chosen to be the product of all primes where a_i < 0. The hope is that (u - v*N) is also p_{n-1}-smooth, which, as far as I understand, most of the math in the paper is trying to justify.

The main innovation here, as far as I can tell, is that Schnorr is fiddling with the 'weighting' of the main diagonal when constructing the lattice basis. I interpret this as basically trying to randomize the initial lattice basis so that the chances of getting a different integer relation (for eventual construction of u,v) is more probable.

I've been confused about this for over a decade as variants of this algorithm, and Schnorr's work in general, have been well published. For example, there's a paper from 2010 on "A Note on Integer Factorization Using Lattices" by Antonio Vera which discusses Schnorr's [3] construction.

Is Schnorr trying to shout louder so people will listen or is there something else fundamentally flawed with this type of algorithm?

Just a word of warning, LLL solves polynomial factorization in polynomial time (given a polynomial with integer coefficients, find it's factor polynomials also with integer coefficients) [4] and has been used to break other (now very old) cryptosystems [5]. If there's a candidate algorithm to solve integer factoring, lattice reduction (LLL, PSLQ, etc.) are it.

I know of fplll that's a stand alone (FOSS) implementation of LLL and some extensions (BKZ, etc.) [6].

[0] https://en.wikipedia.org/wiki/Lattice_reduction

[1] https://en.wikipedia.org/wiki/Lenstra%E2%80%93Lenstra%E2%80%...

[2] https://www.newton.ac.uk/files/seminar/20140509093009501-202...

[3] https://arxiv.org/pdf/1003.5461.pdf

[4] https://en.wikipedia.org/wiki/Factorization_of_polynomials#F...

[5] https://web.eecs.umich.edu/~cpeikert/lic13/lec05.pdf

[6] https://github.com/fplll/fplll

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