fplll VS casadi

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

Interface for several solvers and integrators.

Howdy! Collocation methods can be... tricky. For NMPC control of vehicles, success has been had using direct multiple shooting. Also easier to implement and more intuitive. In fact, this example from the GH is pretty instructive: https://github.com/casadi/casadi/blob/master/docs/examples/python/race_car.py

JuMP.jl (Julia) or casADi (Python) are good choices.

Python is not mature in this area. If you ask Google what Simulink for Python is, you get responses that point to dead libraries that were never feature complete and slow. The absolute closest is CASADI which is nice for some things but doesn't even have a true causal modeling interface and is mostly abandoned by the developers (they put a patch in every now and then, but just look at the commit graph), and it's slow compared to the Julia tools, so much so that PyBAMM is interfacing with ModelingToolkit.jl in Julia for a performance boost. Python is not the place to be for causal/acausal modeling or controls. Anyone who is saying "Python is mature" here is saying it in the abstract and not in the context of your actual question. Yes, Python has web development frameworks. No it does not have good libraries for tons of areas (control, acausal modeling, pharmacometrics, etc.).