RE: WP-34S galUS-> l Precision
(11-27-2016 03:12 PM)Dieter Wrote: (09-07-2016 10:20 PM)Nick Wrote: The US Gallon has an exact value of 3.785411784 per:
1 yd (36 in) = 0.9144 m [international definition]
1 gal = 231 in^3 [US definition]
If that's accurate, can the precision be increased?
By simply changing the respective constant in the 34s source code. Technically this should be no problem at all. A source for the correct constant should not be hard to find. If everything else fails: HP correctly implements 3,785411784 l/gal in their calculators. I imagine my 35s is not the only one that does so. And, honestly, I think the 34s should be at least on par with it. ;-) So I agree it's time for a new build.
Dieter
Here's the source code containing the conversion constants: it's in the file compile_consts.c .
Code:
/* Imperial/metric conversions.
* Data taken from http://physics.nist.gov/Pubs/SP811/appenB9.html
* In general, the values are rounded to 6 or 7 digits even though
* more accurate values are known for many of these.
*/
struct _constsml conversions[] = {
CONV("kg", "lb", "KG_LBM", "0.4535924"), // source: NIST
CONV("kg", "stone", "KG_STONE", "6.3502936"), // derived: 14 lbs to a stone
CONV("kg", "cwt", "KG_CWT", "50.8023488"), // derived: 112lb to a long cwt
CONV("kg", "s.cwt", "KG_SHCWT", "45.35924"), // source: NIST hundredweight, short 100lb
CONV("g", "oz", "G_OZ", "28.34952"), // source: NIST
CONV("g", "tr.oz", "G_TOZ", "31.10348"), // source: NIST
CONV("l", "galUK", "L_GALUK", "4.54609"), // source: NIST
CONV("l", "galUS", "L_GALUS", "3.785412"), // source: NIST
CONV("l", "cft", "L_CUBFT", "28.31685"), // source: NIST
CONV("ml", "flozUK", "ML_FLOZUK", "28.41306"), // source: NIST oz UK fluid
CONV("ml", "flozUS", "ML_FLOZUS", "29.57353"), // source: NIST oz US fluid
CONV("cm", "inches", "CM_INCH", "2.54"), // source: NIST
CONV("m", "fathom", "M_FATHOM", "1.8288"), // derived: 6 feet
CONV("m", "feet", "M_FEET", "0.3048"), // source: NIST
CONV("m", "feetUS", "M_FEETUS", "0.3048006096"), // source: Wikipedia etc
CONV("m", "yards", "M_YARD", "0.9144"), // source: NIST
CONV("km", "miles", "KM_MILE", "1.609344"), // source: NIST
CONV("km", "l.y.", "KM_LY", "9.4607304725808E12"), // source: IAU (see http://www.hpmuseum.org/forum/thread-2262.html)
CONV("km", "pc", "KM_PC", "3.085678E13"), // source: NIST
CONV("km", "AU", "KM_AU", "149597900"), // source: NIST, IAU 2009 gives 1.49597870700E11
CONV("km", "nmi", "KM_NMI", "1.852"), // source: NIST
// CONV("m\232", "square", "M_SQUARE", "9.290304"), // derived:
// CONV("m\232", "perch", "M_PERCH", "25.29285264"), // derived:
CONV("ha", "acres", "HA_ACREUK", "0.40468564224"), // derived: 43560 square feet
CONV("ha", "acreUS", "HA_ACREUS", "0.4046873"), // source: NIST
CONV("N", "lbf", "N_LBF", "4.448222"), // source: NIST
CONV("J", "Btu", "J_BTU", "1055.056"), // source: NIST BTUit
CONV("J", "cal", "J_CAL", "4.1868"), // source: NIST calorie it
CONV("J", "kWh", "J_kWh", "3600000"), // source: NIST
CONV("Pa", "atm", "Pa_ATM", "101325"), // source: NIST atmosphere standard
CONV("Pa", "bar", "Pa_bar", "100000"), // source: NIST
CONV("Pa", "mmHg", "Pa_mmHg", "133.3224"), // source: NIST cm mercury conventional
CONV("Pa", "psi", "Pa_psi", "6894.757"), // source: NIST pound-force per square inch
CONV("Pa", "inHg", "Pa_inhg", "3386.389"), // source: NIST inch of mercury conventional
CONV("Pa", "torr", "Pa_torr", "133.3224"), // source: NIST
CONV("W", "hp(I)", "W_HP550", "745.6999"), // source: NIST horsepower 550 ft . lb / s
CONV("W", "hp(M)", "W_HP", "735.4988"), // source: NIST horsepower metric
CONV("W", "hp(E)", "W_HPe", "746"), // source: NIST horsepower electric
CONV("t", "tons", "T_TON", "1.016047"), // source: NIST ton, long 2240lb
CONV("t", "s.tons", "T_SHTON", "0.9071847"), // source: NIST ton, short 2000lb
CONV(NULL, NULL, NULL, NULL)
};
This code is processed to give single-precision (about 16 sf) conversion factors; there's no support in the code as it stands for double precision, but this shouldn't really be a problem.
What changes to the constants in this code would people like to see? If the changes are properly sourced perhaps Paul would replace the code above with the new improved version; if not, I could include the new code as a compile-time option and build a version of the firmware using it.
Nigel (UK)
|