I'm trying to analyse phase shift fault analysis in trivium and came across a system of non-linear equations to solve. I read about sat-solvers and Gaussian elimination but unfortunately, none of the articles I found on the internet shows how to tackle a non-linear system of equations with a large number of variables (here trivium gives 288 variables). So I'm pretty much stuck now on how to solve for these variables.
You could express your problem as a network of Boolean gates - a netlist - and use bc2cnf to translate it to CNF. You can instruct bc2cnf to output XOR clauses in XCNF format, an extended CNF format with "x" clauses denoting XOR clauses.
SAT solvers like cryptominisat are capable of reading XCNF and/or detecting the contained XOR gates and performing Gaussian elimination. Cryptominisat reportedly has been used several times to attack the Trivium stream cipher.
I'd recommend taking a look at an SMT solver, e.g. Z3. With SMT you can express Boolean equations and inequalities in a natural way instead of bit-blasting everything down to a SAT instance. There's plenty of documentation online to get you started.
Related
Symbolic calculations performed manually or by a computer algebra system may be faulty or hold only subject to certain assumptions. A classical example is sqrt(x^2) == x which is not true in general but it does hold if x is real and non-negative.
Are there examples where proof assistants/checkers such as Coq, Isabelle, HOL, Metamath, or others are used to certify correctness of symbolic calculations? In particular, I am interested in calculus and linear algebra examples such as solving definite or indefinite integrals, differential equations, and matrix equations.
Update:
To be more concrete, it would be interesting to know whether there are examples of undergraduate assignments in calculus and linear algebra that could be formally solved (possibly with the help of a proof assistant) such that the solution can be automatically verified by a proof checker. A very simple example assignment for Lean is here.
For the Coq proof assistant there are several libraries to help with that. One matching your request quite well is Coquelicot (https://gitlab.inria.fr/coquelicot/coquelicot). The Coquelicot team made an exercise and participated in the French baccalauréat - I would say comparable more to a college than a high school math exam - and finished proofs for a good part of the exercises. The proofs can be found in the examples here (https://gitlab.inria.fr/coquelicot/coquelicot/-/tree/master/examples). I thought about translating the exercises and solutions to English.
But this was quite a few years ago and meanwhile there are very powerful tools for specific applications. E.g. there is coq-interval (https://gitlab.inria.fr/coqinterval/interval) which fully automatically does Coq proofs of rather complicated inequalities, say that a high order polynomial matches a sine function in a certain interval with a certain maximum deviation. It does this by Taylor decomposition and computing upper bounds for the residual. It can also do error proofs for a wide range of numerical integrals. A new feature added recently is the ability to do proven correct plots.
A tool for proving in Coq the error between infinite precision real and floating point computations is Gappa (https://gitlab.inria.fr/gappa/gappa).
Another very interesting Coq development is CoRN (https://github.com/coq-community/corn), a formalization of constructive reals in Coq. Constructive Reals are true real numbers which do compute. Essentially a constructive real number is an algorithm to compute a number to any desired precision together with a proof that this algorithm converges. One can prove that such numbers fulfill all usual properties of real numbers. An interesting side effect of constructive reals is that they need only LPO as axiom, while in classical reals the existence of the real numbers itself is an axiom. Any computation you do in CoRN, say pi>3, is automatically proven correct.
All these tools are included in Coq Platform, a common distribution of the Coq proof assistant.
There is more and this is steadily increasing. I would say it is not that far in the future that we have a usable proven correct CAS.
The only thing that comes to my mind is that Isabelle/HOL can replay SMT proofs (as produced e.g. by Z3 or CVC4), e.g. involving integer and real arithmetic. For computer algebra systems, I don't know of any comparable examples.
The problem is that computer algebra systems tend not to be set up in a way where they can output a detailed certificate for their simplifications – if they were able to do that, one could attempt to replay that in a theorem prover. But it would have to go beyond purely equational reasoning, since many rules (such as your example) require proving inequalities as preconditions.
If computer algebra systems were able to output a trace of their computations as a list of rewrite rules that were used, including how to prove each of their preconditions, one could in principle replay such a trace in a theorem prover – but that would of course require that every rule used by the CAS has a corresponding rule in the theorem prover (this is roughly how replaying SMT proofs works in Isabelle). However, I do not know of any projects like this.
There are, on the other hand, various examples where CASs are used to compute some easily verifiable (but hard to compute) result, e.g. factoring a polynomial, isolating the roots of a real polynomial, Wilf–Zeilberger witnesses, and then verifying that this is really a valid result in a theorem prover. However, this does not involve certifying the computation process of the CAS, just the result.
for demonstration purposes, I prepared a small "fake exercise" both to illustrate what it means to verify a calculation and to illustrate the most graphical approaches available in Coq (this shows some of the things you can do in Nov. 2021).
It can be seen on github at github.com:ybertot/osxp_demos_coq, especially the file sin_properties.v.
The demonstration follows this path:
Show that we can state and prove automatically a statement giving a "safe approximation" of PI (that's the name of the mathematical constant in the Coq library).
Show that Coq can be used to plot a known mathematical function, in this case the sin function between 0 and PI. This relies on a connexion to gnuplot for the graphical display. I am afraid that gnuplot will not be included in the Coq platform mentioned by M. Soegtrop in another answer.
Show that we can also plot the function sin(1/x) using Coq
(the plot is actually preserved as a pdf file on the github repository)
Show that a generic function plotter actually returns a misleading result in that case (the generic function plotter is gnuplot).
The misleading plot is also given in the github repository as a pdf file.
The next step is to show that we can prove guaranties of intervals for some computations, sometimes automatically using the interval tactic, and sometimes the interval tactic fails to conclude. The important point here is that the command fails to conclude, instead of giving an answer that cannot be trusted. When this happens, users can rely on knowledge and mathematical reasoning to obtain the desired result. The demo shows how to prove that for any x in a certain range, the sin function is guaranteed to have a positive value.
The next step is about proving that sin x < x for every positive x, it shows that mathematical reasoning can rely on various techniques of mathematics:
decomposing the interval in two parts,
using the mean value theorem,
computing the derivative of x - sin x (and this can be done automatically in Coq),
relying on the fact that cos is known to be strictly decreasing between 0 and PI.
This is just a short demo, which is also meant to explain how a theorem prover has to be used differently from a pocket calculator, because just returning an approximation without qualification for the value of a mathematical formula is a process that cannot really be trusted.
The original question also includes questions about computing integrals. The interval package also contains facilities for this.
Has anyone tried to implement the Navier Stokes Partial Differential Equations (PDE) in Modelica?
I found the method of the spatial basis functions (SBF) which by means of numerical modifications gets Ordinary Differential Equations (ODE) that could be handled by Dymola.
Regards,
Victor
The aim of the method I was saying before is to convert PDEs in ODEs, so the issues with the CFL coefficient would disappear, the problem is that the Modelica.Fluids elements just define the equations in function of the variables in both ends of each component.
i.e dp=port_a.p-port_b.p
but with that sort of methodology, the variables such as pressure, density, mass flow... would be function also of the surrounding components... it would be a kind of massive interaction between all the components,
I would like to see an example in Modelica, because I hardly haven't found information about that topic linked to Modelica.
Modelica is a language for modeling behavior described by DAEs. As such, as long as you can create a system of ODEs, you should be able to express your problem in Modelica.
However, if your PDEs are hyperbolic, the wave dynamics in the equations might cause some issues with simulation. This is because the CFL condition imposes limits on time steps that an ordinary differential equation solver will be unaware of. If the solver includes error control, it will probably manage to get a solutions but may run quite slow because it won't know how to explicitly limit the simulation step size. If it doesn't include error control and it violates the CFL condition, the system will go unstable. Note, this only applies to systems where the CFL condition applies.
I'm building a Media-Library in Dymola similar to Helmholtz-Media but for Ammonia+Water, a mixture.
You get a lot of not explicitly solvable equations.
Because of the structure of the Media and Fluid libraries in Modelica I need to be able to get my thermodynamic state from p, h and x. The state-vector consists of d, T, and x.
This is a simple example how to get the state-vector:
model getState_phX
parameter AbsolutePressure p = 500000 "pressure";
parameter SpecificEnthalpy h = 2500000 "enthalpy";
parameter SI.MassFraction x = 0.7 "mole fraction of amonia";
parameter Real[2] start = getStart_Td_phx(p,h,xL);
output ThermodynamicState state(d(start=start[2]),T(start=start[1]),X={(1 - xL),xL});
DerivateFull f = Derivates(state);
equation
p = (1 + f.delta*f.phirdelta)*R*state.T*state.d/molarMass(state);
h = state.T*R*(1 + f.delta*f.phirdelta + f.tau*f.phirtau + f.tau0*f.phi0tau0)/molarMass(state);
end getState_phX;
Please don't mind the parts of the equations. They consist of many parts (sums and log) dependent on the state-vector.
This is solved by the solver in Dymola with good start values.
But I don't really need all of the 'time-dependent' solving capabilities of Dassl.
Are there build in libraries for solving such stationary equation systems without the solver?
Is it possible to make a Function out of this Model using these?
I know I could write a simple solver by hand but for other parts of the Media-Model (VLE) I need highly reliable stationary solver too (but with 4 nonlinear independent equations)
Please tell me if I didn't explain myself clearly. Thank you for the help.
The basis of your fluid properties library is a forward part, that is the actual Helmholtz energy equation of state (EoS). It takes d,T,X as input. That part is more or less straigthforward to implement.
If you want to specify the thermodynamic state using p,h,X or if you want to find the equilibrium between multiple phases, you will usually set up a system of resdiual functions and try to find the root of your system of equations using some iterative procedures. Span (2000) writes
"the formulation of reliable iterative procedures [for root finding]
is often the most crucial problem when setting up program packages for
the evaluation of equations of state".
Re-using existing solvers has advantages and disadvantages, they are usually very well tested, writing them takes a lot of effort, but if you write your own solver, you have more control about what it does. As far as I know, Dassl has various strength, but solving that kind of equations is not its original objective.
Olson, Tummescheit and Elmqvist (2005) tried to use the Dymola solver to find the VLE, see section 3.2 of the linked pdf. Sounds like it works, but not very reliable.
The MSL already includes a non-linear solver, based on the Brent algorithm, which works with one unknown only, see Modelica.Math.Nolinear.solveOneNonlinearEquation. You could, if you want, add additional generic solvers.
Before writing your own solver, you should get in touch with the developers of the Modelica.Media interface (it will be extended in future versions of the MSL to include multi-component, multi-phase mixtures) and also consider re-using existing fluid properties libraries like RefProp, CoolProp, FluidProp or MultiFlash, to name just a few.
I read at a few places (in the doc and in this blog post : http://blogs.mathworks.com/loren/2007/05/16/purpose-of-inv/ ) that the use of inv in Matlab is not recommended because it is slow and inaccurate.
I am trying to find the reason of this inaccuracy. As of now, Google did not give m interesting result, so I thought someone here could guide me.
Thanks !
The inaccuracy I mentioned is with the method INV, not MATLAB's implementation of it. You should be using QR, LU, or other methods to solve systems of equations since these methods don't typically require squaring the condition number of the system in question. Using inv typically requires an operation that loses accuracy by squaring the condition number of the original system.
--Loren
I think the point of Loren's blog is not that MATLAB's inv function is particularly slower or more inaccurate than any other numerical implementation of computing a matrix inverse; rather, that in most cases the inverse itself is not needed, and you can proceed by other means (such as solving a linear system using \ - the backslash operator - rather than computing an inverse).
inv() is certainly slower than \ unless you have multiple right hand side vectors to solve for. However, the advice from MathWorks regarding inaccuracy is due to a overly conservative bound in a numerical linear algebra result. In other words, inv() is NOT inaccurate. The link elaborates further : http://arxiv.org/abs/1201.6035
Several widely-used textbooks lead the reader to believe that solving a linear system of equations Ax = b by multiplying the vector b by a computed inverse inv(A) is inaccurate. Virtually all other textbooks on numerical analysis and numerical linear algebra advise against using computed inverses without stating whether this is accurate or not. In fact, under reasonable assumptions on how the inverse is computed, x = inv(A)*b is as accurate as the solution computed by the best backward-stable solvers.
I read at a few places (in the doc and in this blog post : http://blogs.mathworks.com/loren/2007/05/16/purpose-of-inv/ ) that the use of inv in Matlab is not recommended because it is slow and inaccurate.
I am trying to find the reason of this inaccuracy. As of now, Google did not give m interesting result, so I thought someone here could guide me.
Thanks !
The inaccuracy I mentioned is with the method INV, not MATLAB's implementation of it. You should be using QR, LU, or other methods to solve systems of equations since these methods don't typically require squaring the condition number of the system in question. Using inv typically requires an operation that loses accuracy by squaring the condition number of the original system.
--Loren
I think the point of Loren's blog is not that MATLAB's inv function is particularly slower or more inaccurate than any other numerical implementation of computing a matrix inverse; rather, that in most cases the inverse itself is not needed, and you can proceed by other means (such as solving a linear system using \ - the backslash operator - rather than computing an inverse).
inv() is certainly slower than \ unless you have multiple right hand side vectors to solve for. However, the advice from MathWorks regarding inaccuracy is due to a overly conservative bound in a numerical linear algebra result. In other words, inv() is NOT inaccurate. The link elaborates further : http://arxiv.org/abs/1201.6035
Several widely-used textbooks lead the reader to believe that solving a linear system of equations Ax = b by multiplying the vector b by a computed inverse inv(A) is inaccurate. Virtually all other textbooks on numerical analysis and numerical linear algebra advise against using computed inverses without stating whether this is accurate or not. In fact, under reasonable assumptions on how the inverse is computed, x = inv(A)*b is as accurate as the solution computed by the best backward-stable solvers.