Template talk:Chem molar mass

ParserFunction errors

The implementation of this template has generated over a dozen ParserFunction errors in articles where it's transcluded.

I've fixed a couple of them:

• Theobromine had a reference in the infobox, which broke the calculation. I simply moved the ref. to the article body.
• Irinotecan had an "e" which broke the calculation, so I removed it. If the "e" indicates something significant and should be kept there, then I suppose a solution similar to that used in the first section above is in order.
• Likewise, Pegfilgrastim has a "+ PEG" that breaks the calculation.

I'll leave it as an exercise for DePiep or someone more familiar with chemistry to fix the rest of these. – Wbm1058 (talk) 15:33, 3 July 2015 (UTC)

Will take a look. In general, entering like | O=3 foo is not a documented option. -DePiep (talk) 23:15, 3 July 2015 (UTC)

Fixed. Error is catched in {{Chem molar mass}} + categorised + tagged. Also checked those artiles previously listed in this. -DePiep (talk) 11:42, 4 July 2015 (UTC)

A slight inaccuracy for calculating the molar mass of charged particles

The molar mass of Pyrosilicate, which is calculated using this template, is shown as 168.16 g·mol⁻¹. However, it fails to account that the electron has a nonzero—albeit small—mass, approximately equal to 1/1,823 amu. While this may seem insignificant for calculations, it is worth keeping in mind that the template typically provides molar mass calculations to the hundredths place of grams per mole (equivalent to atomic mass units per molecule), so a difference of one electron per molecule is actually about 1/18th of a precision point for this template with default rounding. For some compounds, this actually makes a different for some compounds. For example, the molar mass of pyrosilicate displays as 168.16 after rounding but should actually be 168.17 after rounding. While I understand that this small difference may not appear to amount to much, the number of decimal places that have been provided for the molar masses for some of the elements, like fluorine and phosphorus, in this template, shows a commitment to preventing far smaller error, and if we do not account for the nonzero mass of an electron, then any effort to prevent smaller inaccuracies will go to waste. Care to differ or discuss with me? The N^th User 23:30, 31 December 2018 (UTC)

What do you propose? -DePiep (talk) 23:10, 1 January 2019 (UTC)

Add net_charge (default = 0) as an optional parameter to the template and subtract (1/1823)*(net_charge) from the total MW. (Positively charged molecules weigh less, negatively charged molecules weigh more). Boghog (talk) 07:20, 2 January 2019 (UTC)

Yes, that is what I had in mind. The {{Chembox}} template would also have to be changed to use this parameter for ions. Care to differ or discuss with me? The N^th User 00:55, 24 January 2019 (UTC)

@Boghog: Subtracting (net charge)/1,822.8884845 would be more accurate. Care to differ or discuss with me? The N^th User 02:00, 26 January 2019 (UTC)

@The Nth User: Sorry, perhaps I was not quite as clear as I could have been. My statement had two parts. The first part states that we should add a parameter named net_charge to the template script. In the second part, we should subtract the parameter value from the total MW. Boghog (talk) 05:01, 26 January 2019 (UTC)

Would it be OK to name the parameter |charge=? This is what we use in formula templates like {{Chem}} and {{Chem2}}, IMO with exactly the same meaning. Or is there an other "charge" that could cause confusion? -DePiep (talk) 10:57, 26 January 2019 (UTC)

@DePiep: Yes; naming it charge would work fine. Care to differ or discuss with me? The N^th User 01:36, 29 January 2019 (UTC)

By numbers, pyrosilicate

Recapture:

a. Electron mass, per proton-to-electron mass ratio: μ = m_p/⁠m_e = 1836.152673426(32).

1822.8884861915 amu (see note ^[t]; values below adjusted)

b. Inverse: 1/(1836.15267389) = 0.00054461702135119

1/(1822.8884861915) = 0.00054857990907017^[t]

c. Uncertainty: ignored (removed) the (17)^[t]. Also, uncertainty in std atomic weights is ignored in {{Chem molar mass}} (CMM). (Some other time to improve that one).

d. Rounding: in CMM set |round=no. Rounding only should be applied once, at the very end.

e. Unit, conversion: both g/mol (molar) and dimensionless relative mass, or amu (atomic) can be used without changing the number part.

k. Pyrosilicate formula: O
₇Si⁶⁻
₂

l. Current {{CMM}} calc, no rounding: 168.166 g·mol⁻¹

m. Correction^[t] for charge −6: +0.003291479454421

n. Corrected MW^[t]: +168.16629147945

o. Using the long numbers this way may introduce false precision. However the main thrust remains (significant change of end value, that is: the lefter, higher value digits).

p. The difference between (l.) 168.163 and (n.) 168.166 is significant^[t]. It affects the common rounding result (into five digits), that is: 168.16 vs. 168.17.

-DePiep (talk) 10:54, 26 January 2019 (UTC)

q. On second thought (see testcases), I think the number used must be trunckated for precision. Its precision should not be relaterd to the largest precision of std atomic weight used (i.e., number of decimals, roughly. F: 18.998403163(6), Ca 40.078(4)).

However, this requires to evaluate all individual atomic weights (elements) used in a certain calculation, which is better be done in a Lua module not wikitext templates.

r. For now in CMM, I think we should use no more than five(?) decimals for electron mass, since most atomic weights have 1 to 2 decimals.

-DePiep (talk) 13:07, 26 January 2019 (UTC)

s. More on precision. Our pyrosilicate example with O and Si is borderline. Both atomic weights used (15.999, 28.085) are derived from their interval value ([15.99903, 15.99977], [28.084, 28.086]), which indicated a serious "uncertainty" in the fourth (O) and third (Si) decimal. It follows that the electron mass starting at the fourth decimal (0.00054 is same order of magnitude as both uncertainties (in their uncertainty range). I wrote "uncertainty" because interval calculations work differently.

This is even stronger in charged Pb compounds (plumbate mentions anion PbO⁴⁻
₄, this example is OK?). Because Pb has atomic weight 207.2(1), its uncertainty is in its first decimal. Sure then a fourth-decimal (or even third-decimal, when 4- charged) change should not be applied: dwarfed by the main uncertainty (+/- 0.1). (correct route is: or fully calculate with uncertainties, or when Pb is involved, do not use third+ decimals i.e., no electron charge correction). -DePiep (talk) 13:39, 26 January 2019 (UTC)

t. After electron mass discussion below, 03:35, 27 January 2019: changed electron mass ration (a.) to 1822.8884861915 amu per NIST, and subsequesnt calculations. Incidentally, the rounded values in conclusion (p.) do not change, so the conclusion is the same. -DePiep (talk) 08:23, 28 January 2019 (UTC)

@DePiep: One possible solution is to make the default rounding three but set it to zero when technetium, promethium, or any of the elements after bismuth besides thorium through uranium are included, set it to one if lead is included (and the previous condition is not met), and set it to two if lithium, boron, sulfur, chlorine, thallium, zinc, strontium, molybdenum, ruthenium, palladium, tellurium, samarium, gadolinium, hafnium, tungsten, or osmium is included (and neither of the previous conditions are met). Showing four or more decimal places if there are no elements whose atomic masses are given to three decimal places or guess could also be done but seems like overkill considering how many elements have atomic masses given to three decimal places and how common some of them (like hydrogen, carbon, and oxygen) are in chemistry. Also, for the calculations, shouldn't the amu-to-electron mass ratio, which is 1822.8884845 per Electron, be used? Care to differ or discuss with me? The N^th User 23:24, 26 January 2019 (UTC)

Thanks. All in all, we just should go Lua module for these complicated calculations (for example, handling element-dependent numbers), and apply IUPAC explanation about how to handle intervals and uncertainties (link to follow). Wikidata is no help. -DePiep (talk) 23:42, 26 January 2019 (UTC)

re "amu-to-electron mass ratio" -- I do not underand this detail. Is it about 1822 vs. 1836? Which number to use for |charge=-1? -DePiep (talk) 23:58, 26 January 2019 (UTC)

You will not get the mass of an atom if you adds the rest mass of electrons, neutrons and protons the atom contains. (E.g. ¹²
C mass is 12 u and not 6*1.007276u + 6*1.008664u + 6*0.000545u = 12.09891 u). And the mass of the electrons removed from an atom to form an ion is not equal to the rest mass of the electrons. Christian75 (talk) 00:18, 27 January 2019 (UTC)

Really, Christian75, I do not understand what you say (could be me). Could you reply to the issue: "The charge of a molecule may influence its molar weight"? -DePiep (talk) 00:30, 27 January 2019 (UTC)

@DePiep: The nucleons in a nucleus have slightly lower mass than individually (which is what I think Christian75 means by the mass of an atom being different from the rest mass of the individual particles) because the strong force attraction means that when they are bound together in a nucleus, they are in a lower energy state than separate, so joining to form a nucleus decreases their mass via E=mc². (Presumably, this also makes the mass of a molecule dependent upon its standard enthalpy of formation, but including that is probably overkill because the energy differences are much smaller (which is demonstrated by the fact that nuclear reactions can release much more energy than chemical ones).) One amu is defined such that 12amu equals the mass of one carbon-12 atom, not 12 individual protons or 6 individual protons and 6 individual neutrons. Because the protons are bound together in nuclei, they have a lower atomic mass, so the mass of a proton is actually 1.007276466879amu per Proton, which explains why the atomic mass of hydrogen is 1.008amu, not 1.0002amu, even though deuterium is only 0.02% abundant. Care to differ or discuss with me? The N^th User 03:35, 27 January 2019 (UTC)

Thank you both for this (difficult) improvement. I have added note (t.), and changed the number accordingly.

Is there a source or article for that 1822.888... number? (NIST still in shutdown right now: "NIST will reopen at 6:00 AM on Monday, January 28, 2019" - local time I assume).

Now something tells me that I should check once more the unit(s) to be used: the dimensionless value (relative mass) is still equal to the molar weight in amu; kg/mol? IOW, the number can be used & converted 1:1 between those, without being incorrect? -DePiep (talk) 08:23, 28 January 2019 (UTC)

@DePiep: I got the mass value from Electron. I believe that amu per particle is grams per mole, not kilograms per mole. Care to differ or discuss with me? The N^th User 01:36, 29 January 2019 (UTC)

Thanks. Missing a source there. Searched further: Wikidata d:electron gives 0.00054857990907016 (unc=?) sourced by From 1822.8884861915 then (slightly different number).

• u. I note that this effect is substantial between H and H⁺ after rounding:

defunct /sandbox

defunct /sandbox → defunct /sandbox

-DePiep (talk) 08:43, 28 January 2019 (UTC)

• v. concluding (2019-01-30): the actual value is 0.00054857990957921 amu (unk=?), to be used rounded (as explained above) 0.00055. -DePiep (talk) 08:50, 29 January 2019 (UTC)

• Actually, I got it to work on Wikipedia. See User:The Nth User/Molar mass test and User:The Nth User/Molar mass test/testcases. Care to differ or discuss with me? The N^th User 04:06, 29 January 2019 (UTC)

The_Nth_User Yes, that is how it is gonna be like. All looks good then? Demo page Template:Chem molar mass/testcases may look intimidating, but it does a lot of good things. Such as comparing old and new template results. If you want other tests, just whistle. -DePiep (talk) 07:51, 29 January 2019 (UTC)

In sandbox, for testing

I have prepared the sandbox to add charge calculation as requested. Please look at /testcases. Notes:

• for now, the new parameter is named |charge=
• It accepts +, unsigned and - (or minus −) values. Also any decimals are used in the calculation (FWIW).
• Per note q. and r. above, we must consider rounding the electron weight number to say 0.00054 (five decimals) from 0.00054461702135119. BTW, do we agree on this number?
• Any more tests we should do?

-DePiep (talk) 13:05, 26 January 2019 (UTC)

@DePiep: I think that, as I stated in the previous section, we should use the mass of an electron in amu, not proton mass units, so we should use 0.00054857990958 (or if rounded, 0.00055) instead. However, considering that the final molar mass is already rounded, I don't think that we should round any of the intermediate calculations. Care to differ or discuss with me? The N^th User 01:46, 28 January 2019 (UTC)

OK, I changed this in CMM; amu = atomic mass unit. I'd like to have a source or article for this value.

1/(1822.8884845 amu) = 0.00054857990957921 amu^{-1 [t]} (not exactly your number then?).

-DePiep (talk) 08:28, 28 January 2019 (UTC)

@DePiep: I got the electron's mass from the infobox in Electron. Also, I agree that we shouldn't round any intermediate steps. Care to differ or discuss with me? The N^th User 01:36, 29 January 2019 (UTC)

• Boghog, Christian75, The_Nth_User: see /testcases. Per the above, I propose to put this live. -DePiep (talk) 08:56, 29 January 2019 (UTC)

Next step: improve rounding

@DePiep: I modified the rounding based on my testcase, so I think that we should use the unrounded value for the mass of the electrons because the difference will show for ions like fluoride, arsenide, hexafluorophosphate, and tetrafluoroberyllate. Also, it's good practice in general to only round calculations at the end. Care to differ or discuss with me? The N^th User 05:04, 30 January 2019 (UTC)

Yes, that rounding principle is good & great! (Missed it yesterday). That's the way to do it: no precision suggesting (until we do real uncertainty calculations). Want to take another look at the details in your version, not today. So not live yet. BTW, next to the testcases, the /sandbox in its documentation shows individual element /sandbox values, also nice for checking. -DePiep (talk) 08:03, 30 January 2019 (UTC)

@DePiep: Thanks for telling me about the element values; I found them helpful. Also, I changed the charge-based modifier part in Template:Chem_molar_mass/sandbox to -({{{charge|0}}} / 1822.8884861915). I believe that that is the correct value. Care to differ or discuss with me? The N^th User 01:26, 31 January 2019 (UTC)

I have done these tests and cleanup:

1. Check & edit the values we use: standard atomic weight, number of decimals. Source: Template:Infobox element/symbol-to-saw (this is the thorough CIAAW maintained value list; also has the most stable isotope values where needed). [5].

2. Using your new rounding detection ("smart rounding"): make this default, make this also per option |round=default

3. Reorganise the |round= input internally (differentiate "|#default" from the "new smart option").

4. For now, new smart rounding can be triggered by: |round=default. Also by: |round=<blank>, this is a change in behaviour (do we want this?). -DePiep (talk) 11:51, 31 January 2019 (UTC)

Tests are in Template:Chem molar mass/sandbox (table in documentation shows element values), and Template:Chem molar mass/testcases (manual examples, good testing).

5. Re your edit [6] (to not use new subtemplate {{Chem molar mass/calc charge}} any more), I get the idea.

This nicely works with both hyphen and minus sings in input: -6 and −6.

However, now the template (/sandbox) breaks in this situation:

Pyrosilicate is O
₇Si⁶⁻
₂. So it is acceptable to write "6-" too, next to "-6". But the "6-" input does not calculate (see first testcase).

The subtemplate solves this, so want to reinstall it. OK? -DePiep (talk) 11:59, 31 January 2019 (UTC)

6. The sandbox temp\ate uses {{Chem molar mass/format/sandbox}}, because that one accepts negative values (eg when we want to calculate or test |charge=+1), and also some code is improved. -DePiep (talk) 12:13, 31 January 2019 (UTC)

7: Once again, which number to use?

In this edit, you calculate charge / 1822.8884861915. However, I cannot find that ...1915 ending number.

OTOH, NIST has this list for electron mass, and it gives this value for "electron mass in u" m_e:

5.48579909070×10⁻⁴ u, which as a factor (1/5.485...×10e-4) is: 1822.8884861921, ending ...1921.

Question is: is this NIST page the right source, the right mass definition, and so the right number to use? -DePiep (talk) 12:36, 31 January 2019 (UTC)

8. Maybedone, see below the editors input like |round=5 should be overruled for an eventual smaller (smart) rounding number (because a larger number is creating & suggesting false precision). -DePiep (talk) 12:47, 31 January 2019 (UTC)

9. Smart rounding now in the sandbox.

Step 1.: the template determines the "smart rounding" number of decimals (lowest of the elements present; Pb=1, F=9). CMM never returns more decimals (no false precision).

Step 2: the editor can add a number for |round=. CMM uses the lowest number of the pair (input number, smart number). So with F setting |round=5 leads to min(5, 9) is round=5. But with Pb setting |round=5 leads to min(5, 1) = 1.

Other options: |round=no => use smart number. |round=yes => use min(smart number, 2). |round=<blank>, default, smart => use smart number.

tests: see testcases. (e.g., case Pb: smart number=1). -DePiep (talk) 16:34, 31 January 2019 (UTC)

10. I've added {{Val}} to produce formatted numbers like 74.921595.

11. Deuterium: per NIST , its mass is 2.013553212745(40) u. Is there a reason or better source for the value now being 2.01355321275 g·mol⁻¹ (in sandbox: defunct /sandbox; smart_rounding number be 12?)? -DePiep (talk) 17:00, 31 January 2019 (UTC)

12. I think in the smart rounding list, |charge= should be present. What would be best number? 0.00054857990906999 says 17?.

The_Nth_User OK, gonne take a break now. Enough things to take a look at! Let me know what you think. We are nearing going live is my impression. -DePiep (talk) 17:04, 31 January 2019 (UTC)

@DePiep:

4. Considering the unlikeliness of someone entering |round=<blank> instead of just removing the |round parameter, while I think that fixing the problem would be nice, I don't think that it should be a priority or something that prevents the changes from going live.

6. It's probably better to use the template in that case. I figured that Wikipedia's built-in math functions would take both hyphens and minus signs when I made the change, but since it turns out they don't, it's better to use the template.

7. If the NIST gives the electron mass in moles per electron mass form, then it should be used in the templates in moles per electron mass form. I thought I remembered getting 1822.8884861915 from the infobox of Electron, but I just looked at the page and realized the number is 1822.8884845(14) (in electron masses per mole), so now I don't know where I got it. However, it's probably a good idea to update the electron mass in Electron and make it more accurate. Just make sure that you update the smart-rounding number if necessary. If you use -charge/1822.8884861921, it looks like the smart-rounding number should be ten decimal places, but 1/1822.8884861921=0.000548579909069993324576659 (I bolded the 14 (because 1822.8884861921 has 14 sig figs) significant figures.) would actually have a smart-rounding number of 17 (14 sig figs plus 3 zeros before the sig figs but after the decimal point. However, that shouldn't be a problem if the number was originally provided as moles per electron mass.

8. I agree with that, although it might be a good idea to put a warning in preview so editors trying to add false significant figures don't think that there's something wrong with the template.

11. If you find a better number for anything, feel free to update the molar mass and smart-rounding numbers.

12. I put the charge-smart rounding number at the end (so the smart-rounding number if there aren't any elements) because if no parameters are given, then nothing displays anyway.

Also, there are some other things that I thought of.

If the template outputs a negative result, which would be the case if someone entered a positive charge and no other parameters or entered a charge large enough to cancel out the molar mass of any element (e.g. {{chem molar mass|H=1|charge=+2000}}). I think that a preview warning should display in this case, but if the warning is ignored, what should happen? Similarly, what should happen if the input for any of the parameters is fractional?

New feature request (see section #Enthalpy of formation below)

Also, earlier, I mentioned that the mass change from the enthalpy of formation and energy-mass equivalence would probably be insignificant. However, it's best to make sure. For sodium fluoride, the enthalpy of formation is −569.0 kJ/mol (taken from Standard_enthalpy_of_formation#Inorganic_substances), Mass–energy_equivalence#Practical_examples gives that 1kg=89,875,517,873,681,764J, and the molar mass of sodium fluoride can be calculated to be 41.98817244 g/mol (I'm assuming that mass change due to enthalpy of formation is negligible.). In this case, the mass change due to enthalpy of formation is −569.0kJ/1mol * 1,000J/1kJ * 1kg/89,875,517,873,681,764J * 1,000g/1kg = −0.00000000633097882, which looks significant because 41.98817244 - 0.00000000633097882 = 41.98817243366902118, which rounds to 41.98817243. However, the unrounded molar mass is 41.988172443, and 41.988172443 - 0.00000000633097882 = 41.98817243666902118, which rounds to 41.98817244 (because the atomic mass of sodium is to eight decimals places in g/mol). However, because it was close, let's try another example. The molar mass of fluoride disregarding mass change due to enthalpy of formation is 18.998403163 g/mol + 0.000548579909070 g/mol = 18.998951742909070 g/mol, which rounds to 18.998951743 g/mol. According to the infobox of Fluoride, the enthalpy of formation is −333 kJ/mol. This means that the mass change due to enthalpy of formation is −333kJ/1mol * 1,000J/1kJ * 1kg/89,875,517,873,681,764J * 1,000g/1kg = −0.00000000370512469 g/mol. The mass of fluoride adjusted for mass change due to enthalpy of formation is 18.998951742909070 g/mol - 0.00000000370512469 g/mol = 18.99895173920394531 g/mol, which rounds to 18.998951739 g/mol. Because this is different from 18.998951743 g/mol (39 vs. 43), the mass change due to enthalpy of formation is significant for fluoride. While we now have a concrete example of a substance whose enthalpy of formation makes a significant difference in its molar mass, and there are other potential substances (like sodium phosphide, cesium fluoride, hexafluorophosphate, phosphorus pentafluoride, phosphorus trifluoride, and all of the allotropes of phosphorous that the atomic mass of phosphorus was not calculated from) for which this might also be the case, I doubt that there are more than a dozen substances for which the molar mass is significantly affected based on the current values for molar mass that we know. However, I think that we should include enthalpy of formation in {{chem molar mass}} for two reasons: The enthalpy of formation should at least be accounted for on the six or so substances where it makes a significant difference, but just putting the values in those infoboxes directly without a proper template is bad for multiple reasons, like in case the atomic masses for any of the elements are updated or the fact that uncited molar masses with so many decimal places that differ from what the template provides, even slightly, would likely be replaced with the template. As scientists continue to make more precise measurements, the atomic masses for at least some of the elements will likely be updated in the coming years and decades. I think that the appropriate thing to add to the template would be {{#expr: +1,000,000*{{{DeltaHform|0}}}/89,875,517,873,681,764 }} (assuming that the enthalpy of formation is given in kJ/mol), and I doubt that we would have to update the rounding for enthalpy of formation (but then again, I doubted that it would even make a difference). What do you think? Care to differ or discuss with me? The Nth User 01:06, 3 February 2019 (UTC)

@DePiep: I just put your suggestions #7, #11, and #12, along with my dependence upon the enthalpy of formation, in. What do you think? Care to differ or discuss with me? The N^th User 04:21, 6 February 2019 (UTC)

Saw that, hope I am not interfering with your edits right now?! I am documenting this NIST number in Template:Chem molar mass/calc charge documentation. I changed the number (rm the (16) uncertainty), and will us "15" decimals as smart round number (=in case only charge is is entered or tested.

Will also do: if no atoms/charges entered at all, value=0 will not show (returns blank). No input, no output. -DePiep (talk) 04:29, 6 February 2019 (UTC)

For the mass of the electron, when you typed 17 for the smart-rounding number, I assumed that you were counting the digits at first because I didn't see that you had provided another number different from the one in the link. I think that the best way would be to include uncertain digits in the calculations but not in the rounding, but I'm willing to do it another way if that's what Wikipedia policy says is right. Care to differ or discuss with me? The N^th User 04:49, 6 February 2019 (UTC)

For the charge mass: we should the source you linked (NIST). I documented that in the {{Chem molar mass/calc charge}} documentation page (see the '2014 CODATA' reference). But I did not implement in sandbox because you are editing so I stay out of the way. Sandbox may not be correct yet.

Now, one can not add the "(16)" uncertainty to the end as you did, that's incorrect (for starters, this 16 has same decimal position as the "70", not shifting two to the right). We just truncate the 16 unused. Uncertainty calculation requires delta-squares maths; nice in Lua scripting. Given the number as I documented it, it has 15 decimals so our smart round number should be 15 IMO. Charge can be added to the smart switch-list. That leaves the "14" smart number for no-input; but no-input (value=0) should return blank I guess. -DePiep (talk) 05:04, 6 February 2019 (UTC)

Are you suggesting that we create an even more comprehensive rounding algorithm for the next set of updates? Care to differ or discuss with me? The N^th User 05:11, 6 February 2019 (UTC)

@DePiep: I just changed the smart-rounding calculation in the version in my userspace. (The Pythagorean sum means that I take the square root of the sum of the squares, so the Pythagorean sum of x, y, and z would be sqrt(x²+y²+z²).) I'm thinking that we could put this in in the next round of updates. What do you think? Care to differ or discuss with me? The N^th User 02:40, 8 February 2019 (UTC)

Not in this change, so I did not research now. (BTW, the change in oxygen you made is incorrect, correct CIAAW values are here). -DePiep (talk) 08:36, 8 February 2019 (UTC)

I think that it makes logical sense for the molar mass to be inside the range given. The precision is specified separately in the template, so I don't see a problem with adding extra digits to the molar mass part. If you still object, I'll change it back. Care to differ or discuss with me? The N^th User 02:45, 9 February 2019 (UTC)

Also, if the molar mass of deuterium (as an example) has a two-digit uncertainly (You gave the value as 2.013553212745(40) g/mol.), then why do we treat it as accurate to 12 decimal places and not 11 (because the last significant figure is typically guessed)? Care to differ or discuss with me? The N^th User 05:21, 6 February 2019 (UTC)

Indeed, better use 11 decimal places. Changed that in sandbox. -DePiep (talk) 08:36, 8 February 2019 (UTC)

The enthalpies are not part of this improvement, but a new feature). Introducing this will delay going live. I strongly suggest to postpone this. -DePiep (talk) 04:40, 6 February 2019 (UTC)

@DePiep: We can remove the enthalpy of formation part for now. Besides that, what else needs to be done before we can go live? Care to differ or discuss with me? The N^th User 04:49, 6 February 2019 (UTC)

(ce) (also, looks like the enthalpies can be automated, so not by input, see your example fluorine). -DePiep (talk) 04:53, 6 February 2019 (UTC)

What exactly do you mean by this? Do you mean that they can be put in by the Chembox if the enthalpy feature goes live, or are you referring to something else? By the way, I removed the enthalpy feature. Care to differ or discuss with me? The N^th User 04:59, 6 February 2019 (UTC)

(off-topic: you wrote "[per] infobox of Fluoride, the enthalpy of formation is −333 kJ/mol.", so we don't need to input that just read it from a list, similar to the weights). -DePiep (talk) 05:09, 6 February 2019 (UTC)

It's just that you've asked for a source previously, so I figured that I should be safe and provide it right away to avoid potential confusion. Care to differ or discuss with me? The N^th User 05:14, 6 February 2019 (UTC)

(I do not understand the backgrounds for enthalpy calculations yet, so better ignore my points. That said: I thought 'if the enthalpy value depends on the element (like fluorine), we can encode that value for F as we did with atomic weight for F. this way it is not needed as user input') -DePiep (talk) 05:47, 6 February 2019 (UTC)

(ec) reply to your replies, by number, more orderly:

re re 4. |round=<blank>: rounding best defaults to "use smart", because this is the best rounding principle we have. It trumps previous default "round 2 decimals". This option may not be used by editors that often, but one can use it nicely in templates (like {{Chembox}}). Could already be the case in current live situations (eg, Chembox has input, not rounded, now show dflt 2 decimals; will show 4 smart ones. Is OK/responsible). When this goed live, we should not introduce errors or uinexpected output.

re re 6. OK, we use subtemplate for charge not code it all in the main template (done).

re re 7. NIST charge value: that's the one then. See this documentation on what exactly we will mplement.

re re 8: yes, smart round number cannot be enlarged ever (no more decimals rounding than smart). But giving Preview message: maybe not. When this calculation is in the infobox ({{Chembox}}), it will appear every preview even if the editor is working on something else. Better: document it well, editors setting "|round=" should read the doc anyway.

re re 11, 12: we'll add the charge smart number to the main template, make the final number "0" --should not occur anyway--, and we'll apply: "when no input, nothing is shown"; actually implementd as "when value=0 ...".

re enthalpies: new subject, we'll develop this after this rounding is live (new feature, new talksection).

re "what else needs to be done": apply these changes, rm enthalpy for now, test all this. Also: check which parameters would break/change current behaviour, which effect? (especially |round=). I expect that new form=better, so we have safety in this (not breaking articles).

PubChem warning: I have discovered that PubChem uses different atomic weights (and so does Wikidata, see test table). So the molar mass calculated by PubChem may be wrong too. While PubChem is called an RS and is often used for molar mass values. We may encounter issues with this in articles (questions by chem editors). -DePiep (talk) 05:48, 6 February 2019 (UTC)

Discovered: input |O=1/2 works ;-) -DePiep (talk) 11:29, 6 February 2019 (UTC)

Added to testcases: input variants like ref and unit. Error checks. fraction input. -DePiep (talk) 11:34, 6 February 2019 (UTC)

@DePiep: [moved enthalpy issue to section below, per topic DePiep (talk) 07:25, 7 February 2019 (UTC)]

3*re #11: Should there be a comment in the template to remind editors who change the electron mass value to also update the decimal count in the main template?

re PubChem: I've also noticed that molar masses can vary a little from site when making chemboxes, which is why I typically leave that field blank and let Wikipedia calculate it for itself. Any digit significance that all of the sites have in common can also be provided by the template. Care to differ or discuss with me? The N^th User 02:27, 7 February 2019 (UTC)

re discovered: I actually mentioned that earlier (Use the find function to search for the word fractional.) along with negative inputs and insanely positive charges. I'll put in a boolean to test for things like this, but should {{chem molar mass|charge=+1}} return the molar mass of a positron?

re added: Which units are included? Also, I assume that the template auto-converted if a unit besides g/mol is entered. Care to differ or discuss with me? The N^th User 02:27, 7 February 2019 (UTC)

All "enthalopy" now below.

no IMO, that notion should be from documentation alredy, plus good template editing. I'll track this one. We could add a check to the testtable. BTW, that atomic weight changes will happen in "my" {{Infobox element/symbol-to-saw}} dataset primarily, that's where all articles read it. I only recognise CIAAW publications. Ideallicy (and Wikidata intention), is that this CMM reads the values from there.

PubChem: I trust this new version over PubChem by now, but we should convince chem editors that PubChem is not a RS in this...

Input integers and fraction: so fractions are not possible (not even in chem formula)? I think the numerical checks should be done by a special template (and that categorises). Maybe return error instead of mod() rounding (to inform the editor, not hide the error), and categorise.

Over all: let's not add this number checking now. First see what it does with the smart rounding. Once stable in articles & Chembox & Drugbox, we can refine the checks.

units: see next subsection (other parameters).

Propose: new remove number checks, remove testsettings, go live. -DePiep (talk) 07:46, 7 February 2019 (UTC)

@DePiep: re Input integers and fraction: I believe that that's what my changes did. If there was a non-integer input or something, the template would output something along the lines of Error: malformed input.

re Over all: I'll probably add the number checking to my test template in my userspace, then we can move it from there to the template sandbox after we go live with the changes. Care to differ or discuss with me? The N^th User 00:59, 8 February 2019 (UTC)

Afterthought: we can introduce the g-vs-kg check & option later, aka smart unit handling. In a next version, not now. -DePiep (talk) 07:55, 7 February 2019 (UTC)

Oh, and I want |charge=+1 in there for testing purposes. When used in article, it be so (IMO no need to forbid this). -DePiep (talk) 08:05, 7 February 2019 (UTC)

Going live

I have made the edits as discussed above. Please take one more look at the testcases and base table with /sandbox check. Some testsettings are active (more feedback). Errors? -DePiep (talk) 11:34, 6 February 2019 (UTC)

The Nth User I have boldly revertesd your today's edits (all re number checking) [7], because we are in final testing mode before going live. Introducing new features would set us back to the start of the changes: discuss, try, test, improve: delayuinbg the introduction. There is no harm in postponing separate issues. Also, it prevents complicating instead of simplifying the change process.

So I request to check once more for errors in the current sandbox version (use testpages already linked). If none, I'll put it live tomorrow. -DePiep (talk) 08:03, 7 February 2019 (UTC)

Check articles (using TD monthly error report, and its page lists links):

[8] (10800 articles, 5600 having |H=)

Infobox drug (6700 articles, 5900 having |H=)

-DePiep (talk) 14:04, 7 February 2019 (UTC)

No more errors reported. Removed testsettings. Made edit request. -DePiep (talk) 09:06, 8 February 2019 (UTC)

todo: {{Chembox Properties}} (charge, catname), {{Infobox drug}} (to check)

Other parameters

• Removed |catname= from documentation etc.: unused (for errors, see Category:Articles with erroneous molar mass calculations (0)).
• I've added parameter checking and tracking category Category:Pages using Chem molar mass with unsupported parameters (0). -DePiep (talk) 12:39, 1 February 2019 (UTC)

• Units (documentation, to be):

1. When some |unit=kg/mol is used, it is added as is, always ("by the editor").

2. When |fixed= is used, no unit is added to this (could be in it already).

3. When |sortable= is used, no unit is added by the template (expected: put in top of table column).

4. When value is calculated, unit g/mol is added by template.

5. There is automatic no conversion from g to kg.

(re The_Nth_User) -DePiep (talk) 07:53, 7 February 2019 (UTC)

References

References

Template-protected edit request on 8 February 2019

Please put all sandbox code into live template, twice:

Template:Chem molar mass/sandbox → Template:Chem molar mass (diff)

Template:Chem molar mass/format/sandbox → Template:Chem molar mass/format (diff)

Changes: add option to enter |charge=, updated number values, improve rounding by using decimal places.

Testcases: /testcases and table here. Discussed & consensus: #above. DePiep (talk) 09:05, 8 February 2019 (UTC)

Done -- /Alex/₂₁ 05:42, 9 February 2019 (UTC)

Enthalpy of formation

Useful links: Template talk:Chem molar mass/articles having chembox enthalpy of formation

User:The Nth User/Molar mass test
User:The Nth User/Molar mass test/testcases

Above, in #Next_step:_improve_rounding, The_Nth_User proposed to introduce enthalpy calculation in this template (CMM). Here the topic is forked into a separate, new feature. Original proposal:

Also, earlier, I mentioned that the mass change from the enthalpy of formation and energy-mass equivalence would probably be insignificant. However, it's best to make sure. For sodium fluoride, the enthalpy of formation is −569.0 kJ/mol (taken from Standard_enthalpy_of_formation#Inorganic_substances), Mass–energy_equivalence#Practical_examples gives that 1kg=89,875,517,873,681,764J, and the molar mass of sodium fluoride can be calculated to be 41.98817244 g/mol (I'm assuming that mass change due to enthalpy of formation is negligible.). In this case, the mass change due to enthalpy of formation is −569.0kJ/1mol * 1,000J/1kJ * 1kg/89,875,517,873,681,764J * 1,000g/1kg = −0.00000000633097882, which looks significant because 41.98817244 - 0.00000000633097882 = 41.98817243366902118, which rounds to 41.98817243. However, the unrounded molar mass is 41.988172443, and 41.988172443 - 0.00000000633097882 = 41.98817243666902118, which rounds to 41.98817244 (because the atomic mass of sodium is to eight decimals places in g/mol). However, because it was close, let's try another example.

The molar mass of fluoride disregarding mass change due to enthalpy of formation is 18.998403163 g/mol + 0.000548579909070 g/mol = 18.998951742909070 g/mol, which rounds to 18.998951743 g/mol. According to the infobox of Fluoride, the enthalpy of formation is −333 kJ/mol. This means that the mass change due to enthalpy of formation is −333kJ/1mol * 1,000J/1kJ * 1kg/89,875,517,873,681,764J * 1,000g/1kg = −0.00000000370512469 g/mol. The mass of fluoride adjusted for mass change due to enthalpy of formation is 18.998951742909070 g/mol - 0.00000000370512469 g/mol = 18.99895173920394531 g/mol, which rounds to 18.998951739 g/mol. Because this is different from 18.998951743 g/mol (39 vs. 43), the mass change due to enthalpy of formation is significant for fluoride.

While we now have a concrete example of a substance whose enthalpy of formation makes a significant difference in its molar mass, and there are other potential substances (like sodium phosphide, cesium fluoride, hexafluorophosphate, phosphorus pentafluoride, phosphorus trifluoride, and all of the allotropes of phosphorous that the atomic mass of phosphorus was not calculated from) for which this might also be the case, I doubt that there are more than a dozen substances for which the molar mass is significantly affected based on the current values for molar mass that we know. However, I think that we should include enthalpy of formation in {{chem molar mass}} for two reasons:

1. The enthalpy of formation should at least be accounted for on the six or so substances where it makes a significant difference, but just putting the values in those infoboxes directly without a proper template is bad for multiple reasons, like in case the atomic masses for any of the elements are updated or the fact that uncited molar masses with so many decimal places that differ from what the template provides, even slightly, would likely be replaced with the template.
2. As scientists continue to make more precise measurements, the atomic masses for at least some of the elements will likely be updated in the coming years and decades.

I think that the appropriate thing to add to the template would be {{#expr: +1,000,000*{{{DeltaHform|0}}}/89,875,517,873,681,764 }} (assuming that the enthalpy of formation is given in kJ/mol), and I doubt that we would have to update the rounding for enthalpy of formation (but then again, I doubted that it would even make a difference). What do you think?

— Care to differ or discuss with me? The N^th User 01:06, 3 February 2019 (UTC)

There are at least three ways to conceptualize how the enthalpy of formation affects the change of mass. I'm using an exergonic reaction as an example, but the same logic can also be applied to endergonic reactions.

• One can simply equate the loss of energy (specifically chemical potential energy) to the loss of mass as per mass–energy equivalence.
• One can account for the lost mass by equating it to the mass of the emitted photon(s).
• One can think of the electrons having less mass when they are in lower-energy orbitals.

Also, the enthalpy of formation is not a simple function of the elements (In fact, isomers can have different enthalpies of formation.), so the enthalpy of formation would have to be input individually for each substance.

3*re #4: I actually have an idea for an even more comprehensive smart-rounding system which I plan to beta-test (along with the enthalpy of formation) in User:The Nth User/Molar mass test. For elements where the uncertainty is not specified, what should I assume it to be? Care to differ or discuss with me? The N^th User 02:27, 7 February 2019 (UTC)

@DePiep: I got the enthalpy formation part to work in my userspace testcases, but for the two allotropes of phosphorus, the test template displays an error message. I have no idea why this is happening because the template doesn't have a single < character besides for the beginning of comments. Can you look at it and figure out what's causing the problem? Care to differ or discuss with me? The N^th User 00:11, 10 February 2019 (UTC)

@DePiep: I figured out the problem for the allotropes of phosphorus (They used a different character as a minus sign.) and fixed it, but when playing around with the rounding, I noticed another problem: H₂S outputs 34.075220716525 g·mol−1 even though none of the addends are to more than three decimal places, and O₃ and NaCl output 47.998176000005 g·mol−1 and 58.439500000235 g·mol−1, respectively, which raises the question of whether or not extremely quantities are also added to other numbers but not noticed because they are rounded off. Is this just the result of the non-integer rounding (which I am leaving that way because it is what exposed/created these bugs), or is there another problem in the code? Care to differ or discuss with me? The N^th User 02:08, 11 February 2019 (UTC)

quick replies:

re "For elements where the uncertainty is not specified, what should I assume it to be?" Standard atomic weights (aka relative atomic mass) are defined by CIAAW. Source is (formally published "2013"), with elements updated in "2015" and "2017" (updated biannually only). The source has various numbers for a single element: see table 1, table 2, table 3 (interval or single number value; abridged value; conventional value; enwiki uses the "short formal" value, that is a combination of these tables). The source does not say anything about instable elements; enwiki uses most stable isotope for these (mass number, an integer. eg plutonium has m.s.i. 244) for these.

Those isotope mass numbers have no uncertainty (read plutonium: 244(0)). Otherwise when an uncertainty is missing, read it being (1). So fluorine, abridged says "18.998" which is defined to mean 18.998(1). But note: these fluorine examples we do not want to use in mass calculatrion, becasue it is rounded beforehand which is bad practice.

Error message containing a "<": when the number is not a number (eg, has text or bad punctuation), an error is returned. The error message may start with a "<span>" tag (internally, for example to make the error message text show in red), so that is what you see. In short: probably a bad number input.

re H₂S values: will take a look. Is not related to this enthalpy I guess?

Next rounding improvements: not in this thread.

-DePiep (talk) 08:53, 11 February 2019 (UTC)

• FYI, [these] are articles that use |DeltaHform= in {{Chembox}}. Unfortunately, {{Chembox}} cannot reuse this input in section Thermochemistry in section Properties. -DePiep (talk) 09:57, 11 February 2019 (UTC)

• That never occurred to me, but now that I have pointed it out, I see four potential options:
  1. Completely restructure {{chembox}} (would require a massive overhaul and fixing every single page that uses it and is therefore essentially out of the question)
  2. Some complicated piece of code that might not even be possible
  3. Adding the thermochemistry parameter to the Properties section as well (which could be done with a bot)
  4. Not using the enthalpy of formation for calculating the molar mass

Considering that there are already compounds which have been shown that the mass change associated with the energy difference due to enthalpy of formation of makes a significant difference in their molar mass, I think that option 3 would be the best. Care to differ or discuss with me? The N^th User 05:16, 12 February 2019 (UTC)

Oh, not a big issue. For now {{Chembox Properties}} could get the new parameter (same or different name). It's just: the value has to be entered twice, cannot reuse it. There are some 673 articles using this. Once stable, we can ask a bot to do this doubling. When Chembox is rebuild, the single parameter can be used. -DePiep (talk) 07:37, 12 February 2019 (UTC)

FYI, I have created Template talk:Chem molar mass/articles having chembox enthalpy of formation (link is also in top of this section).

Also, a list of units & values used in this parameter (quite diverse!) -DePiep (talk) 08:17, 12 February 2019 (UTC)

Should we put in code to detect which unit the enthalpy of formation is inputted in or require a standard unit? There are pros and cons to each, and I'm wondering if there should be a different parameter for each unit, like what {{chembox}} does with the parameters for the boiling point. Care to differ or discuss with me? The N^th User 04:54, 13 February 2019 (UTC)

We must strive to have a well-defined unit, this unit being "kJ/mol" since you proposed that. We could consider adding parameter named |DeltaHform_kcalpmol= to enter by unit kcal/mol and then convert internally to kJ/mol. As for stripping excess input text: difficult, and there are also value ranges ("5.5--6.2") and uncertainties ("−1226(4) kJ/mol").

Best way to go: you work with a straight kJ/mol value (=single number) here. Later on we can add a helper function that reads that number from complicated input, and feeds the right number it into your calculation. So assume |DeltaHform= to be a single number with (invisible) unit kJ/mol. OK? -DePiep (talk) 11:04, 13 February 2019 (UTC)

Yes, kilojoules per mole is fine. Let's just remember to mention it in the documentation when this goes live. Care to differ or discuss with me? The N^th User 05:00, 15 February 2019 (UTC)

References

D

NIST says for D:

• 2.01410177812(12) [9]
• 2.013553212745(40) u [10]

• This template uses: 2.01355321275 g·mol⁻¹

-DePiep (talk) 20:42, 10 February 2019 (UTC)

Rounding and uncertainty issues

Useful links: User:The Nth User/Molar mass test/testcases, User:The Nth User/Molar mass test

Thread to raise issues with rounding after we added Smart rounding to this template. [11]

• [c/p from other thread]:

  I figured out the problem for the allotropes of phosphorus (They used a different character as a minus sign.) and fixed it, but when playing around with the rounding, I noticed another problem: H₂S outputs 34.075220716525 g·mol−1 even though none of the addends are to more than three decimal places, and O₃ and NaCl output 47.998176000005 g·mol−1 and 58.439500000235 g·mol−1, respectively, which raises the question of whether or not extremely quantities are also added to other numbers but not noticed because they are rounded off. Is this just the result of the non-integer rounding (which I am leaving that way because it is what exposed/created these bugs), or is there another problem in the code? Care to differ or discuss with me? The N^th User 02:08, 11 February 2019 (UTC)

Test live template:

H₂S → 33.07 g·mol⁻¹

O₃ → 47.997 g·mol⁻¹

NaCl: → 58.44 g·mol⁻¹

Will take a look at your sandbox. -DePiep (talk) 09:16, 11 February 2019 (UTC)

Cannot debug your code because ../sandbox is in use in mainspace by accident. -DePiep (talk) 09:53, 11 February 2019 (UTC)

I fixed that. In the future, you may make such fixes yourself; I put the template in my userspace because we were about to go live, not to discourage other users from making improvements. Care to differ or discuss with me? The N^th User 05:16, 12 February 2019 (UTC)

(Moved from #Enthalpy of Formation)

re re "For elements where the uncertainty is not specified, what should I assume it to be?" It turns out that besides the elements without any stable isotopes, the standard atomic mass of each element either has explicitly specified uncertainty or is a range. My system for my template was using the standard atomic weight, unless it was given as a range, in which case I used the short formal weight, for the mass values. (The uncertainty was the uncertainty given in the standard atomic mass, unless that was a range, in which case I used the difference between the short formal atomic weight and the bound of the range that was farther from it.) The one exception to this was oxygen because its short formal weight was not inside the range given by its standard atomic weight, so I used 15.9994 for the weight and 0.00037 for the uncertainty. Care to differ or discuss with me? The N^th User 05:16, 12 February 2019 (UTC)

re Those isotope mass numbers: Thank you for telling me that. I have removed those elements from the uncertainty calculations accordingly. Care to differ or discuss with me? The N^th User 05:16, 12 February 2019 (UTC)

re Error message: Yes, it turns out that the problem was that the character that was serving as a minus sign for the enthalpies of formation for the allotropes of phosphorus was not a hyphen. I fixed it by inserting find-and-replace #invoke functions. Care to differ or discuss with me? The N^th User 05:16, 12 February 2019 (UTC)

re re H₂S values: No; I think that it's related to the rounding, and I'll move this to the appropriate section. I didn't even specify the enthalpy of formation for that test, so I know that the enthalpy can't be what's causing the problem. The rounding is also behaving weirdly for other compounds; I'm getting numbers like 47.998176000005 and 58.439500000235.

My first source for this calculation is Possolo (2018). It describes:

1. When A_r(E) is an interval, the most correct molar weight is an interval (see 2.).
2. Go from uncertainty to probablilistic.
3. Simples calculation, CO₂ (par 6.1). See equation (8) wrt uncertainty u. It also used the straight interval width of oxygen and carbon (both have interval A_r value).
4. Says nothing about instable elements (where we use m.s.i. mass number).
5. enwiki: Template:Standard atomic weight of the elements lists the most recent values CIAAW publishes.
6. Don't know how to extend this to enthyalpy uncertainty. -DePiep (talk) 09:26, 12 February 2019 (UTC)

1. I had to convert all of the elements' molar mass either into value-uncertainty form or lower bound-upper bound form. I chose the latter because it's much better for calculating Pythagorean uncertainty combinations.
2. The probability of the value being in that interval is dependent on the number of standard deviations, and for all positive a, b, and k, k*sqrt(a²+b²)=sqrt((ka)²+(kb²)), so as long as all of the original uncertainties are to the same probability.
3. While that is the case, the overwhelming majority of elements do not have molar masses provided as an interval, and I had to put the molar masses in the same form in order to combine them in the template. Calculating the interval width would require specifying the lower and upper bound for each element because for some elements where the molar mass is provided as an interval (notably lithium, sulfur, and argon), the conventional molar mass is not at the center of the interval, and oxygen's conventional molar mass is not even inside its interval.
4. Should I find the atomic weights for those isotopes instead? I figured that if that were correct, that's what the IUPAC would do.
5. If you found a discrepancy between my template and that list, feel free to change it. The one exception is oxygen, which I changed because the conventional/short formal mass wasn't even in the standard interval.
6. If you mean that you want 100% certainty calculation (assuming that the molar masses are within the given intervals of uncertainty to 100% confidence), specifying the molar mass as an interval form is actually preferable, especially because of elements like lithium, oxygen sulfur, and argon. I could put that in if you want. Care to differ or discuss with me? The N^th User 04:54, 13 February 2019 (UTC)

re 4: I have finished adding the isotope mass values to the template.

re 6: I'll probably add interval uncertainty tomorrow or the day after that. Care to differ or discuss with me? The N^th User 05:00, 15 February 2019 (UTC)

@DePiep: I added calculations for the lower and upper bounds to the template, but I forgot that technetium and promethium are below the elements with stable (or nearly stable) isotopes, so the masses for technetium–uranium are staggered. Basically, the masses are correct, but the elements aren't. I could probably fix it with the help of a speadsheet and a bunch of find-and-replace functions with wildcards, but I what to know whether or not you have a more efficient method first. Care to differ or discuss with me? The N^th User 01:13, 17 February 2019 (UTC)

Actually, I thought of a more efficient method using purely spreadsheet functions, so it's fixed now. Care to differ or discuss with me? The N^th User 03:56, 17 February 2019 (UTC)

• re your current version. Let's check helium (a single-value atomic weight)

(0{{{He|0}}} * 4.002602) with u=(2) as in 4.002602(2).

your uncertainty term: ({{{He|0}}}*0.000002)^2 +

Possolo (2018), following 6.2 and 6.3 on carbondioxide and ammonium nitrtate (for standard weights, not the more informative material sources): says "u²(He_n) = n²(0.000002)^2" (by terms and products the same so far as yours are)

Then you are supposed to deduct the uncertainty from main value (decimal position-wise), right? I'll have to take a look at your calc re this. -DePiep (talk) 09:47, 12 February 2019 (UTC)

Shouldn't you take the square root from the uncertainty total? That is, inside like {{#expr: 1 - ln(SQRT(...)) excercise? -DePiep (talk) 09:52, 12 February 2019 (UTC)

Is done, see the ^0.5 code. -DePiep (talk) 10:08, 12 February 2019 (UTC)

re my note about C and O, and paragraph 6.1: I guess we should use the interval for u², as is shown right below formula (8) in there. -DePiep (talk) 11:05, 12 February 2019 (UTC)

I don't know what you mean by formula (8). This page currently only has 6 sections, citation 8 is in the Going live section, which doesn't have anything pertaining to uncertainty calculations, and searching the source code for an anchor for something along the lines of Formula_8 yielded no avail. Care to differ or discuss with me? The N^th User 04:54, 13 February 2019 (UTC)

User:The_Nth_User I'm referring to source Possolo (2018), below in references and this pdf. It is by a CIAAW workgroup to describe exactly the uncertainty-problems we are discussing. That is the recipe we should use here IMO.

In its section "6.1 Carbon dioxide" is described how M_r (molar mass) is calculated. It uses atoomic weights as we do (minor note later), and does square u-values and atom-counting (the 2 in CO₂) just like you already do.

In that 6.1 is a formula line labeled "(8)". That is where I read preferred u-calculation.

One note: for u it uses the interval-width, not a uncertainty number we know as "(n)" (that is for carbon: abs([12.0096 − 12.0116]) = 0.002.

(The pdf has a distraction: it introduces industrial sample sources, that is with very small uncertainties; it follows that generic sample sources as we do with atomic weights have a very large uncertainty).

So now my question is: can you find all this in the pdf, and do you agree this pdf is the way to follow? -DePiep (talk) 10:17, 13 February 2019 (UTC)

Yes, I was able to follow it and find everything. Care to differ or discuss with me? The N^th User 05:00, 15 February 2019 (UTC)

• See your testcases and debug feedback. It appears that rounding requires an integer. (See code here:)

number = 1.234567

round=2: {{#invoke:math|precision_format|1.234567|2}} → 1.23 -- OK

round=2.2: {{#invoke:math|precision_format|1.234567|2.2}} → 1.2366763951812 --???

round=2.7: {{#invoke:math|precision_format|1.234567|2.7}} → 1.2350673729657 --???

Can you take a look? I'll leave it for today.

-DePiep (talk) 10:29, 12 February 2019 (UTC)

Sorry, may look chaotic but I'm c hecking the source calculation. We also might need another rounding re the u value...-DePiep (talk) 20:17, 12 February 2019 (UTC)

What do you mean by this. Do you mean another rounding equation, another rounding method, changing the code in {{Chem molar mass/format/sandbox2}}User:The Nth User/Molar mass test/format (moved), or something else? Care to differ or discuss with me? The N^th User 04:54, 13 February 2019 (UTC)

I have made them visible. The |precision= input (parameter 2) input is our smart round number. When that has decimals, like 2.2 or 2.7, rounding becomes unpredicted (huge number of decimals). So I say: "the (smart) round number should be an integer". Ithink the ceil function you mention below will does that. -DePiep (talk) 10:24, 13 February 2019 (UTC)

You already mentioned this early on :-) : "Is this just the result of the non-integer rounding?" (Nth_user @ 02:08, 11 February 2019 (UTC)). So the answer is: yes, the non-integer rounding number caused it. -DePiep (talk) 10:53, 13 February 2019 (UTC)

I originally removed the ceil function (thereby making most of the rounding values nonintegers) to see what would happen with the eventual plan of specifying the uncertainty depending on the part after the decimal point (e.g. round=1.7 results in 1.23(2), but round=1.4 results in 1.23(4)), but after I saw that it revealed another bug, I decided to leave it in until the other bug was fixed so we wouldn't forget about it. Care to differ or discuss with me? The N^th User 04:54, 13 February 2019 (UTC)

I do not understand the connection between non-integer rounding number and uncertainty added (eg, in your example "round=1.7 results in 1.23(2)"). Is there a math I should try to understand, or will you go using ceil() and discard this connection? -DePiep (talk) 10:53, 13 February 2019 (UTC)

I modified the format subpage so that it can handle non-integers and specify uncertainty now. Care to differ or discuss with me? The N^th User 05:00, 15 February 2019 (UTC)

Calculating Interval notation

About calculating molar mass when Ar is in interval notation [ ]. Involves source Possolo (2018)

The_Nth_User. I'm lost. Which calculus are you striving at? Why |mode=, while that is element-determined? And I don't have the time nor ambition to improve this template through wikicode (not Lua) code. Also, there should be much, much better and thorough testing. Errors are spreading all around in the /testccases. This is not the route to go. -DePiep (talk) 19:18, 17 February 2019 (UTC)

I was under the impression that you wanted me to calculate the intervals of uncertainty, so I put that in. Originally, I accidentally matched some of the elements to the wrong atomic weights, but I figured out how to fix that. As for the testcases, User:The Nth User/Molar mass test/testcases looks fine. ARe you talking about something else? Care to differ or discuss with me? The N^th User 06:04, 18 February 2019 (UTC)

I have not been able to study the se changes (plus the new parameters like |mode=). Yes I think we should use those interval widths per the source I mentioned (and the interval halfway value as the atomic weight then?). I'ts just that it is tough to check the code, and I have little time. -DePiep (talk) 06:19, 18 February 2019 (UTC)

|mode= is just to allow the ability to control whether uncertainty mode or interval mode is expressed. I have the interval built around the elements whose molar masses are given in value-uncertainty form, but for elements where A_{r, standard} is an interval, I used the conventional atomic weight (except for oxygen and thallium because their conventional atomic weights weren't inside the intervals). Also, there are some other things that I'd like to discuss with you:

• For the most stable isotope of technetium, I used technetium-98 because 98 is given for technetium at Template:Infobox element/symbol-to-saw. However, Isotopes of technetium states that technetium-97 has a slightly longer half-life, but the two half-lives each have low enough precision such that technetium-98 could actually be the most stable isotope. Should we use the atomic mass for technetium-98 because it's what's listed at Template:Infobox element/symbol-to-saw, technetium-97 because its half-life listed at Isotopes of technetium is slightly longer, simply average the two because there's no way to know which actually has the longer half-life, use a weighted average of the two atomic masses dependent on the probability for each that it has the longer half-life based on the current precision, or even use technetium-99 because its half-life is only one order of magnitude less and (more importantly) its natural abundance is listed as trace, while the natural abundances for each of technetium's other isotopes are listed as synthetic.
• For User:The Nth User/Molar mass test, I recently realized that you created a separate parameter for the uncertainty squared, but when I updated the atomic weight and uncertainty for elements without a stable isotope, I didn't see it, so it remained unchanged. In the future, let's try to prevent forks like this by using a template, which I did when I realized what happened, to make the code shorter and only require one change.
• Technetium (99mTc) sestamibi is a good example of a compound that must contain a specific isotope of an element, in this case technetium. The atomic mass of technetium-99m is higher than that of technetium-98, so I think that we should add {{{99mTc}}} to the template for molar mass calculations involving that specific isotope, as well as other isotopes that occur in compounds that specify that particular isotope (e.g. SeHCAT uses a specific isotope of selenium, selenium-75, for pharmaceutical purposes, it would be inappropriate to use an atomic weight near 16 for oxygen in oxygen-heavy water or doubly labeled water, we should add tritium for tritiated water, and I'm wondering whether for semiheavy water, we should specify that the hydrogen atom that is not deuterium is protium.), to improve the accuracy of the calculations.

What do you think about each? Care to differ or discuss with me? The N^th User 21:15, 18 February 2019 (UTC)

Avout the intervals. We should completely incorporate paragraph 6.1 of Possolo, nor not at all (detail: we can skip all "specific samples" and "industrial production": about when the samples are not just terrestial averages. That is, when the material is from sources more specified than A_{r, standard} is defined).

While paragraph 6.1 uses the interval width, it also does subsequent calculations referring to monte carlo and GUM. It does not just use "conventional, abridged" (single) value for Ar, nor the metric average of the interval. -DePiep (talk) 09:12, 20 February 2019 (UTC)

Since section 6.1 uses a 95% certainty interval and combines uncertainty using a Pythagorean sum, do you mean

References

• Possolo, Antonio; van der Veen, Adriaan M. H.; Meija, Juris; Hibbert, D. Brynn (2018-01-04). "Interpreting and propagating the uncertainty of the standard atomic weights (IUPAC Technical Report)". doi:10.1515/pac-2016-0402. Retrieved 2018-09-23.

More ParserFunction errors

For the past couple of days, some pages using the {{Chembox}} infobox have been popping up in Category:ParserFunction errors (the mainspace articles Oxalate, Thiocyanate, and Thionine at the moment, though some user sandboxes are also affected). The error message is popping up in the "Molar mass" parameter, so I thought this may have something to do with the recent changes made to this template, or perhaps something is malformatted in those particular articles. Since I don't know enough about template coding and usage to begin to troubleshoot the problem, could someone with the requisite knowledge look into the matter? Deor (talk) 18:38, 12 February 2019 (UTC)

Thanks for this clear and useful report. I'll take a look. -DePiep (talk) 19:50, 12 February 2019 (UTC)

Category:Articles with erroneous molar mass calculations (0) says 4 now. -DePiep (talk) 19:51, 12 February 2019 (UTC)

Cause: |Formula_Charge= is recently being used to calculate molar mass more correctly, using this {{Chem molar mass}} indeed.

Now for example in Oxalate, that parameter had a reference added like |Formula_Charge=-2<ref>...</ref>

 Done Solved: for the ref, use parameter |MolarMass_ref= [12], so that the charge is a plain number only.

Todo: check the category. -DePiep (talk) 20:05, 12 February 2019 (UTC)

Done: fixed Thiocyanate, Thionine, Clofilium, Complanine: cannot be |Formula_Charge=+, must be |Formula_Charge=+1 . -DePiep (talk) 20:13, 12 February 2019 (UTC)

Many thanks. I've just fixed Nostocarboline and Trithionic acid in accordance with your suggestions above. New instances will probably be appearing for a while as the queue catches up with the problematic infoboxes. Deor (talk) 14:51, 13 February 2019 (UTC)

• I am informed that in the formula, we do not write the "1" in "+1":

Chemical formulas with a +1 (or -1) charge are not written C₂₀H₁₈NO₄⁺¹ but C₂₀H₁₈NO₄⁺. Berberine Will change the template. -DePiep (talk) 09:02, 15 February 2019 (UTC)

Should I also change User:The Nth User/Molar mass test, or are you changing {{Infobox drug}} and the other templates that use {{chem molar mass}} instead of {{chem molar mass}} itself? Care to differ or discuss with me? The N^th User 01:13, 17 February 2019 (UTC)

This template should accept bare input "+" &tc. (because that is legal and userfriendly input for {{Chem}}), so I'll add that this calculates as expected. -DePiep (talk) 18:59, 17 February 2019 (UTC)

 Done. Deor: |Formula_Charge=+ must be accepted because this is the way the empirical chem formula knows/shows it (now template {{Chem molar mass}} accepts & calculates the bare "+", "-"). -DePiep (talk) 20:10, 17 February 2019 (UTC)

Testcases overview

1. Live template:

{{Chem molar mass}}

{{Chem molar mass/calc_charge}}

{{Chem molar mass/format}}

There are two sets of sandbox development:

2. Test in Template namespace:

Template:Chem molar mass/sandbox(edit talk links history)

Template:Chem molar mass/format/sandbox(edit talk links history)

Template:Chem molar mass/calc charge/sandbox(edit talk links history)

Template:Chem molar mass/testcases(edit talk links history) (testcases)

3. Test in Userspace User:The_Nth_User:

User:The Nth User/Molar mass test (the main template)

User:The Nth User/Molar mass test/format (formatting)

{{Chem molar mass/calc charge}} (same as live version, not being developed)

User:The Nth User/Molar mass test/testcases (testcases)

-DePiep (talk) 11:30, 13 February 2019 (UTC)

Note to User:The_Nth_User: you can use your own template set now, separate our edits. At the moment, your /format page returns the green debug info (the other one is reddish). I can change that debugging code for you if you want to. Of couse I will steal all ideas from your pages ;-) -DePiep (talk) 11:37, 13 February 2019 (UTC)

I wouldn't view that as stealing, considering that I chose to contribute my ideas to Wikipedia. The only reason that I even put in my userspace was because I couldn't use the template sandbox because we were about to go live. In fact, now that we've done the first set of updates, you may move what I have to the template sandbox now if you want. Care to differ or discuss with me? The N^th User 05:00, 15 February 2019 (UTC)

re "stealing": we should add proper WP:attribution ("who made the edits"). That is an important issue in Wikipedia copyright. -DePiep (talk) 19:14, 17 February 2019 (UTC)

That's fine. Please let me know if you copy my version to Template:Chem molar mass/sandbox. Care to differ or discuss with me? The N^th User 06:04, 18 February 2019 (UTC)

• I have created User:The Nth User/Molar mass test/testtable/row that uses your sandbox version. Used in User:The_Nth_User/Molar_mass_test/testcases#Test_per_element. Just to help with testing, no changes to your versions. Ask if you need more help. -DePiep (talk) 10:04, 20 February 2019 (UTC)

1. Elements where the uncertainty digit is one too high
   • Fluorine
   • Aluminum
   • Manganese
   • Iodine
   • Lanthanum
   • Gold
   • Uranium
2. Elements where the uncertainty number is more than one too high
   • Rhodium
   • Cesium
   • Terbium
   • Holmium
   • Thulium
3. Elements where a zero is added to the end of the value and the uncertainty number is changed from one to ten
   • Silicon
   • Potassium
   • Titanium
   • Vanadium
   • Gallium
   • Strontium
   • Yttrium
   • Niobium
   • Molybdenum
   • Palladium
   • Indium
   • Antimony
   • Cerium
   • Praseodymium
   • Europium
   • Dysprosium
   • Lutetium
   • Tungsten
   • Rhenium
   • Lead
   • Bismuth
   • Protactinium
4. Elements where the uncertainty in uncertainty mode is zero but the two bounds in interval mode are different
   • Technetium
   • Promethium
   • Polonium through actinium
   • Everything after uranium (although I'm wondering whether or not there could have been a typo for roentgenium due to the similarity of the bounds)

I have hunches for each. #1 and #3 are probably due to a rounding error, #2 could be due to differences between the source that I got the values from and Template:Infobox element/symbol-to-saw, and #4 might be because of some leftover code from when there was no uncertainty for unstable elements. I'll look into it. Care to differ or discuss with me? The N^th User 03:28, 21 February 2019 (UTC)

I got rid of that code that I thought was messing up the uncertainty for nonstable elements—and somehow that broke all of the uncertanity-mode testcases. I can't figure out how to fix it, so can you please take a look? Care to differ or discuss with me? The N^th User 04:18, 21 February 2019 (UTC)

Future development (March 2019)

1. I think this template, in wikitext base, is quite sophisticated but cannot be developed very much more. We need the right algorithms, and Lua.

2. The algorithms to calculate molar mass are from stantard atomic mass are essential (s.a.w., as defined by {{CIAAW2016}}, Possolo (2018) mainly).

There are three input forms: elements with s.a.w in interval [min, max] form, those with 1.2345(uncertainty) form, and istable elements we use most-stable-isotope (m.s.i.) value.

We must get those three algorithms first.

3. Then, that calculation better be done in Lua not wikitext.

4. Personally, I don't have time to figure this ouit so I don't make promises on presence (activity) here. Pinging is OK of course.

5. I also state, even today enwiki is more trustworthy than Wikidata is re CMM :-) -DePiep (talk) 20:41, 13 March 2019 (UTC)

Attribution: lastest and great improvement to this CMM template was by The_Nth_User: introducing 'lowest number of decimals', internally knows as 'smart number'. -DePiep (talk) 22:08, 13 March 2019 (UTC)

@DePiep:

re 2: I don't think that it's necessary to do things separately for elements without a stable isotope because the masses for the particular isotopes are available.

re 3: I want to have a working version here first so I won't be going to the people who code LUA with nothing.

re 4: I plan to ping you when I think I'm done so you can check it. Care to differ or discuss with me? The N^th User 22:12, 13 March 2019 (UTC)

re 2, ??? no algorithm? I advise: get the three algorithms first. Even programming this template will be ok. Even /sandbox coding. -DePiep (talk) 22:29, 13 March 2019 (UTC)

But aren't there only two algorithms, one for uncertainty and one for intervals? Care to differ or discuss with me? The N^th User 22:50, 13 March 2019 (UTC)

A third one for non-stables (Tc, Sg). Not by CIAAW/CIAAW formally, but used in calculations. Didn't you know? (or, why did you edit their values at all?) -DePiep (talk) 23:09, 13 March 2019 (UTC)

Wouldn't using the isotopic masses be more accurate than the mass number? Care to differ or discuss with me? The N^th User 23:34, 13 March 2019 (UTC)

I don't know. See WT:ELEMENTS. Very good isotope peeople there. -DePiep (talk) 23:36, 13 March 2019 (UTC)

I just created a new section. It's probably not worth worrying over too much, though. Care to differ or discuss with me? The N^th User 23:43, 13 March 2019 (UTC)

NOOO! Molar weight calculations are very important. (It's just: I don't have time). Also, Wikidata allows Pubchem for source, which is baaad. -DePiep (talk) 23:49, 13 March 2019 (UTC)

Yes, but I highly doubt that any of these elements occur in more than a few compounds for which there are Wikipedia articles about. Most unstable elements probably don't have any Wikipedia articles about their compounds, so which molar mass the template uses doesn't matter. Care to differ or discuss with me? The N^th User 23:57, 13 March 2019 (UTC)

Whatever. Are you distracted again? Algorithms first. -DePiep (talk) 00:02, 14 March 2019 (UTC)

Yes. I am currently editing Pnictogen#Compounds, as well as doing things outside Wikipedia. I apologize for the long response times. Care to differ or discuss with me? The N^th User 00:39, 14 March 2019 (UTC)

I meant to say "distracted" as in: 'going into details', not ínto RL'. -00:42, 14 March 2019 (UTC)~

I still think that making sure that the proper molar mass is used for these elements, most of which probably don't have any compounds on Wikipedia, is more unnecessary that trying to figure out whether or not we need to worry about getting the molar masses exactly right for these elements. Care to differ or discuss with me? The N^th User 00:58, 14 March 2019 (UTC)

Documentation (changes)

• See Template:Chem molar mass/doc/sandbox(edit talk links history): new documentation

Changes (to be documented)

• Using algorithm to correctly use uncertainty. Per Possolo (2018):

Standard atomic weights (data): per Meija (2016) and later (CIAAW). The unrounded values are used!

Meija, Juris; et al. (2016). "Atomic weights of the elements 2013 (IUPAC Technical Report)". Pure and Applied Chemistry. 88 (3): 265–291. doi:10.1515/pac-2015-0305.

• Instable element, using "Most stable isotope": do not use mass number, but actual isotope mass (when available).

For example: Fr, francium:

223 g·mol−1 (current)

223.0197350(26) g·mol−1 (new)

-DePiep (talk) 09:07, 6 April 2019 (UTC)

References

Tests (April 2019)

See

Chem molar mass/sandbox (edit · t · history · diff · links · /test · Source · e · t · hist · links · /subpages · /doc · /doc edit)

Many template calls, so split pages:

{{Chem molar mass/testcases}}

{{Chem molar mass/testcases/elements1-60}} -- elements

{{Chem molar mass/testcases/elements61-118}} -- elements

{{Chem molar mass/testcases/charges}} -- charged molecules |charge=

Charge

• See /charges: {{Chem molar mass|Cl=1|N=1|charge=+}}

Looks like |charge=+ does not work any more in the sandbox, input "+" should be read as "+1". "+" is valid input because in the formula, one writes "+" not "+1". Same for "-". -DePiep (talk) 08:40, 6 April 2019 (UTC)

Elements

• It appears that yttrium (E39) has an extra zero, also in its uncertainty. This is not an error (by statistics math), we assume. But we'd like to prevent it. -DePiep (talk) 08:56, 6 April 2019 (UTC)

Same for: Nd (E41), Cs (E55), Pr (E59), Ym (E69), Bi (E83), Pa (E91). -DePiep (talk) 08:59, 6 April 2019 (UTC)

• The value for a single atom (e.g., testing |Al=1) should return the standard atomic value & uncertainty. This is a simple round-trip test. However, in some cases the uncertainty changes. See elements testpages, there is a column with the basic s.a.w. data.

See: 13 Al, 25 Mn, 45 Rh, 55 Cs, 65 Tb, 67 Ho, 69 Tm, 79 Au.

-DePiep (talk) 09:23, 6 April 2019 (UTC)

What happened was that the uncertainty would always show as (1) because of some changes that I had made to Template:Chem_molar_mass/format/sandbox. I have removed the bug by undoing the changes, but now we either have to figure now how to adjust the uncertainty when the user manually specifies a round that is different from the smart round or disable the capability to manually enter a round. Care to differ or discuss with me? The N^th User 01:10, 20 April 2019 (UTC)

The Possolo paper examples

See . The paper details the algorithm for elements with simple uncertainty (brackets) and interval notation ([a, b]).

Possolo points out that when using 'industrial '(=more specific) materiel sources, the uncertainty is reducesd impressively. However, this is not the aim of this template.

Examples by Possolo: NOTE: as of today, the formulas may be incorrect (see wikitext). Today=19:45, 28 April 2019 (UTC)~

This section is not complete yet, but very relevant. Because it tests the Possolo algorithm against the template(/sandbox). -DePiep (talk) 19:45, 28 April 2019 (UTC)

CO2 (§ 6.1)

Carbondioxide

CO2
Possolo	44.00940 (72)
{{Chem molar mass}}	44.009 g·mol−1
sbox	defunct /sandbox

Borax (§ 6.2)

Borax

Na2B4O7·10H2O
Possolo	()
{{Chem molar mass}}	201.21 g·mol−1 (?)
sbox	defunct /sandbox (?)

or

Na2[B4O5(OH)4]·8H2O
Possolo	()
{{Chem molar mass}}
sbox	defunct /sandbox

Ammonium nitrate (§ 6.3)

Ammonium nitrate

NH4NO3
Possolo	80.0438 (87)
{{Chem molar mass}}	80.043 g·mol−1 (?)
sbox	defunct /sandbox}}

Testosterone (§ 6.4)

Testosterone

C19H28O2
Possolo	()
{{Chem molar mass}}	288.431 g·mol−1
sbox	defunct /sandbox

todo

(todo) -DePiep (talk) 21:42, 6 April 2019 (UTC)

(blank)

Possolo	()
{{Chem molar mass}}
sbox	defunct /sandbox

reflist

References

Template-protected edit request on 19 October 2023

Change technetium's mass number from 98 to 97, as ⁹⁷Tc is its most stable isotope. Nucleus hydro elemon (talk) 08:00, 19 October 2023 (UTC)

 Not done: please provide reliable sources that support the change you want to be made. Maybe we could start with an explanation with a citation at Technetium. – Jonesey95 (talk) 22:25, 19 October 2023 (UTC)

Non-standard molar mass notation

Why does this template output the non-standard molar mass unit notation "g·mol⁻¹" rather than the standard "g/mol" that is used pretty much everywhere? Nosferattus (talk) 08:06, 2 July 2024 (UTC)

@DePiep: Maybe you would know. Nosferattus (talk) 08:09, 2 July 2024 (UTC)

DePiep is not able to participate for now. It's a good question. I'll look into the history and see if I can find a previous discussion or related MOS. DMacks (talk) 12:14, 2 July 2024 (UTC)

@DMacks: One weird thing is that the documentation incorrectly says that the default unit notation is "g/mol", although it used to say "g·mol⁻¹". So maybe there was a plan to change it to "g/mol", but no one ever changed it. "g·mol⁻¹" is sometimes used in the literature, but not nearly as often as "g/mol", and frankly it just seems to obfuscate the meaning for no good reason (other than to look more "scientific"). Can we change it? Nosferattus (talk) 19:14, 2 July 2024 (UTC)

I agree "g/mol" is more common for chemists. The other is possibly more common for physicists. Can you link the diff for the doc-change you found? DMacks (talk) 03:54, 3 July 2024 (UTC)

Note: this affects the display in both the chembox and the drugbox. I'll ping those top-level template-talkpages. DMacks (talk) 04:01, 3 July 2024 (UTC)

"g/mol" is more commonly used and is also used in CAS and Pubchem but "g·mol⁻¹" is also used widely in textbooks. I am leaning towards noting both for the template. Ramos1990 (talk) 05:45, 3 July 2024 (UTC)