Template talk:Order of magnitude

Improved version

{{editprotected}}

New parser functions allow for a very significant simplification of this template's (main-page) code. The current code is as follows.

{{Ordomag/+|{{#ifexpr:{{{1}}}<0|-}}{{{1}}}}}<noinclude>{{pp-template|small=yes}}{{documentation}}</noinclude>

Please replace it with the following revised code.

{{#expr:floor(ln(abs{{{1}}})/ln10)}}<noinclude>{{pp-template|small=yes}}{{documentation}}</noinclude>

There will be a number of benifits:

• a huge reduction in reprocessor node count, post-expand include size and template argument size;
• elimination of the need for the template's large array of subtemplates,
  • thus reducing the potential for vandalism or error;
• an almost five-fold increase in range from 10⁻⁶⁶ ≤ |x| ≤ 10⁶⁶ to 10^-324 ≤ |x| ≤ 10³⁰⁸ (according to testing)
• an easy-to-follow code that could help editors learn about the use of parser funtions.

JIMp _talk·cont 14:19, 3 June 2008 (UTC)

Done. Is there a sensible way to make it fail gracefully when not fed an input, or is an error message appropriate? Does this mean that the set of subtemplates can now be deleted? Happy‑melon 16:29, 3 June 2008 (UTC)

We could put the {{#expr:}} inside an {{#if:}} if need be. Is there anywhere transcluding this like that? If it's to get rid of the error message on the template page, then an <includeonly></includeonly> should be enough. {{Ordomag}} doesn't need the subpages any longer. However, there are a couple of other templates calling subtemplates directly so these can't be deleted yet. Please unprotect {{ordomag/+}} and {{ordomag/0}} so that they can be {{db-author}}ed once those other templates are fixed. JIMp _talk·cont 21:00, 3 June 2008 (UTC)

There was an error in the new code. It seems to be some kind of rounding error.

• 10⁹ => {{#expr:floor(ln(abs1000000000)/ln10)}} => 8
• 10¹² => {{#expr:floor(ln(abs1000000000000)/ln10)}} => 11
• 10¹⁵ => {{#expr:floor(ln(abs1000000000000000)/ln10)}} => 14
• 10¹⁸ => {{#expr:floor(ln(abs1000000000000000000)/ln10)}} => 17
• 10²³ => {{#expr:floor(ln(abs100000000000000000000000)/ln10)}} => 22

I've added a new subtemplate to check for and correct this error.

• 10⁹ => {{ordomag|1000000000}} => 9
• 10¹² => {{ordomag|1000000000000)}} => 12
• 10¹⁵ => {{ordomag|1000000000000000)}} => 15
• 10¹⁸ => {{ordomag|1000000000000000000}} => 18
• 10²³ => {{ordomag|100000000000000000000000}} => 23

JIMp _talk·cont 08:46, 4 July 2008 (UTC)

Error in this template

This template incorrectly shows hyphens where minus signs belong. Thus:

10^-300

instead of this:

10⁻³⁰⁰

I clicked on "edit" to correct this, but there's just some code that I couldn't follow. Can anyone attend to this? Michael Hardy (talk) 02:33, 10 October 2008 (UTC)

You mean the documentation, right? I've fixed it. If you meant the actual template output, the hyphen as a minus sign is intentional: it's to be used in other templates. JIMp _talk·cont 05:08, 11 October 2008 (UTC)

Parentheses are needed to handle additions

{{editprotected}}

WARNING: The change below probably affects almost all articles using Template:Convert, so it will trigger reformatting over 250,000(?) articles. It can wait until a slow day on Wikipedia, such as a Friday night, Saturday or Sunday. There is no hurry on this. -Wikid77

14-Feb-09: The template must use parentheses around {1} before the division with 10^{2}, so that parameter1 can allow an expression of addends (such as 100+2+3); the proper coding should use parentheses before division, as: ( {{{1}}} )/10^{{{2}}}. Also, set the category [Category:...].

The contents of the template should be the following 3 lines:
{{#expr:{{{2}}}+( ( {{{1}}} )/10^{{{2}}}>=10)}}<noinclude>
[[Category:Subtemplates of Template Convert]]
</noinclude>

When working properly, the current results, below, will match the expected:

• Expected: {{ordomag/x|1000+2|3}}   gives:   3
• Currently: {{ordomag/x|1000+2|3}}   gives:   {{Ordomag/x|1000+2|3}}

• Expected: {{ordomag/x|2+1000|3}}   gives:   3
• Currently: {{ordomag/x|2+1000|3}}   gives:   {{Ordomag/x|2+1000|3}}

• Expected: {{ordomag/x|56000+2|4}}   gives:   4
• Currently: {{ordomag/x|56000+2|4}}   gives:   {{Ordomag/x|56000+2|4}}

• Expected: {{ordomag/x|2+56000|4}}   gives:   4
• Currently: {{ordomag/x|2+56000|4}}   gives:   {{Ordomag/x|2+56000|4}}

• Expected: {{ordomag/x|88+0.002|1}}   gives:   1
• Currently: {{ordomag/x|88+0.002|1}}   gives:   {{Ordomag/x|88+0.002|1}}
• Currently: {{ordomag/x|88.002|1}}   gives:   {{Ordomag/x|88.002|1}}

For each case, the amounts of Expected & Currently should match: with the same result whether for 1000+2 or 2+1000. The correct calculation requires parentheses "( )" be used around parameter {1} to handle any addends in the input number, such as in "1000+2". -Wikid77 (talk) 11:52, 14 February 2010 (UTC)

 Done after checking the jobqueue. (The 3 db servers combined had a jobqueue of around 2780 jobs before deploying this change). —TheDJ (talk • contribs) 23:56, 14 February 2010 (UTC)

Zero handling

{{editprotected}} Can the changes in the sandbox be copied over which fix the handling of the 0 parameter. Thanks -- WOSlinker (talk) 18:04, 18 August 2010 (UTC)

Thanks, WOSlinker - you have proven yourself an über-templater! I second his motion - please note that this problem is live at {{convert|0|F}} -> 0 °F (−18 °C) in Refrigerator. Wnt (talk) 18:10, 18 August 2010 (UTC)

 Synced. Has it solved the problem? HJ Mitchell | Penny for your thoughts? 20:44, 18 August 2010 (UTC)

Yes, it's working now. Thanks -- WOSlinker (talk) 21:14, 18 August 2010 (UTC)

Since when was the order of magnitude of zero zero? JIMp _talk·cont 17:34, 19 August 2010 (UTC)

Well, -9, -1, 1 and 9 are all 0, so is there a reason for it not to work for 0 as well? -- WOSlinker (talk) 18:10, 19 August 2010 (UTC)

• {{ordomag|-9}} value is 0
• {{ordomag|-1}} value is 0
• {{ordomag|0}} value is 0
• {{ordomag|1}} value is 0
• {{ordomag|9}} value is 0

Yes, but

• {{ordomag|0.1}} value is -1
• {{ordomag|-0.01}} value is -2
• {{ordomag|0.001}} value is -3
• {{ordomag|-0.0001}} value is -4

Still, a text return like "-∞" may well break something... and I'm glad to be rid of big red error messages for 0°F. Wnt (talk) 01:31, 20 August 2010 (UTC)

Changes have been made at {{Getprecision}} to better handle zero values, so if 0 is a problem here, the change could be reverted so that 0 errors as before, and Convert 0°F would still work. -- WOSlinker (talk) 10:31, 20 August 2010 (UTC)

Nine hundred, three hundred, one hundred, zero hundred (zero hundred is zero so the order of magnitude would be two) ... I'm missing something ... ninety, thirty, onety, zeroty (zero's ord'o'mag is one) ... missing something again ... nine, three, one, zero ... wait ... nine-tenths, three-tenths, one-tenth, zero-tenths ... no ... zero-hundreths ... zero-thousandths ... -millionths ... no. None of these make sense. Zero doesn't go with the hundreds not because "zero hundred" is silly but because you'd be skipping the tens but it doesn't go with the tens either because you skip the ones. Why should it go with the ones when that skips the tenths? Similarly it doesn't belong with the tenths either, nor with the hundredths, thousandths, millionths, etc.

As a number approaches zero its order of magnitude approaches negative infinity so if the order of magnitude of zero is to be defined at all, it must be -∞ not 0. If 9 km, 8 km, ... 2 km and 1 km are all on the same order of magnitude, how about 0 km (exactly 0 km)? If 9 mm, 8 mm, ... 2 mm and 1 mm are all on the same order of magnitude, how about 0 mm? Exactly 0 km is 0 mm, same thing, same order of magnitude but 1 km and 1 mm are out by a factor of one million.

If the error message was breaking another template, the problem was with the other template (I'd thought {{convert}} was fine in this respect) and this solution is just a band-aid.

Plugging in some very small numbers (of the form 0.000...0001) the template gives -321, -322, -323, -324, , , ... (negative numbers give similar results) i.e. it's broken from about 10⁻³²² to −10⁻³²². I say don't test for zero, test for this problem range, and don't return zero return something like −322 or −323.

JIMp _talk·cont 10:10, 21 September 2010 (UTC)

Of course, I'm just ranting. Yes, we want "0 °C" or "0 °F" to be considered to be of the same order of magnitude as "1 °C" or "1 °F" (as opposed to "10^-∞ °C" or "10^-∞ °F"). It's better to have a useful template which pretends that the order of magnitude of zero is zero than one which is useless because it recognises that the order of magnitude of zero is -∞. As for the problem 10⁻³²²-to-−10⁻³²² range, I guess it's not likely that we'll get this input (I'm Heisenberg would agree) ... and if we ever do, let's deal with it then. It's better to have a template that doesn't waste effort (don't worry about performance they say ... they've got rock in their heads) checking for input that will never come. JIMp _talk·cont 06:35, 3 August 2011 (UTC)

Reducing the expansion level depth

Wikid has come up with a new way of dealing with the truncation error. The new code avoids the need for the correction subtemplate {{order of magnitude/x}} and thus cuts the depth from seven to four. The new code is now in place. A very very slight dissadvantage has been discovered: as we approach 1 the new code fails earlier (somewhere between 0.99999999999997 and 0.99999999999998) giving 0 (as opposed to -1) whereas the old code was good until a little closer to 1 (failing somewhere between 0.99999999999999994 and 0.99999999999999995). This is not likely to cause trouble. JIMp _talk·cont 23:48, 26 September 2012 (UTC)

The fudge factor which was introduced to counter the truncation error becomes insignificant for larger/smaller orders of magnitude (over 100 or under −100) and the template has been returning 299 for 1E300. Thus I tried bumping the fudge factor up a notch for these numbers in the sandbox. The sandbox version now correctly gives 300 for 1E300. I'm putting the new code (as follows) in.

{{#expr:floor((ln(abs({{{1|0}}}) )/ln 10)+1E((abs{{{1|0}}}>1E100 or abs{{{1|0}}}<1E-100)-14))}}

JIMp _talk·cont 23:12, 11 November 2012 (UTC)