This started out as cleaning up warnings - but it actually turned into a
matter of semantics and correctness. Which lead to changes in .h files
which will have a ton of ripple effects.
A lot more of this to come.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There was also a function not being used that could be safely removed.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Structs and classes in C++ are basically the same thing and we want to
create a few zero-initialized values for some of them; Sadly, C++ doesn't
have the nice static struct initialization that C has.
One way to deal with that is to create a constructor and pass default
values to it, another is lambda-initialization, but we don't use C++11,
yet.
Since we initializate stuff on the constructor, we don't need to
re-initializate things again on the initialization list (which is also why
I removed the QStrings from the initialization lists, they are
automatically initialized to empty)
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is in the context of the iOS port and shouldn't impact any of the
other builds.
[Dirk Hohndel: refactored the iOS patches]
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is hard coded in version.cmake for now. The intent is to go to 1.0 in
the first release version and to increment from there whenever we create
an update.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The "virial" form of the Z compression factor is of the form
Z = 1.0 + A*p + B*p^2 + C*p^3 + ..
and it's considered the "right" polynomial form to use. It happens to
also make for one constant less per gas (since the 1.0 can be added
later), and can be used to simplify the expression and avoid a few
floating point operations.
However, in order for that kind of expression simplification to make
sense, we need to make sure that we don't calculate the powers of the
pressure multiple times either, and that means we have to inline all the
actual calculations.
Our compiler options still mean that the generated code isn't optimal,
but that's a separate issue. And it is a lot better than it used to be.
Being clever about this does potentially make the code a tiny bit less
legible, but maybe that's not too bad for something that we'd expect to
not ever touch once we get it right.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Lubomir found better compressibility data for the pure gases that we
need for scuba, making the air table superfluous: we get good values
from just regular linear mixing of the Oxygen, Nitrogen and Helium
calculations.
Also, rather than using a quintic polynomial, a cubic one does
sufficiently well, making for smaller code and fewer coefficients.
And judging by the reactions from people on G+ (as well as just looking
at how good the fit is with the air data), this is all the right way to
do this, and this thus removes the Redlich-Kwong equation.
All-credit-goes-to: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
.. and use a linear mix of them for arbitrary gas mixes.
For the special case of air, we continue to use the air-specific
polynomial.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This goes back to just doing air compressibility, but using the
least-squares quintic polynomial equation that Lubomir generated based
on the Wikipedia table for air at 300K in the 1-500 bar range.
We might be able to do similar things for mixed gases..
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The gas compressibility is such a specialized thing that I really prefer
having it separate.
This keeps Robert's Redlich-Kwong equation as-is, but let's experiment
with other models soon...
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
