Template talk:Numtext

From Wikipedia, the free encyclopedia

Contents

[edit] Examples

Examples


[edit] Less than satisfactory results

[edit] Current code

Template code as of 13 Mar 08


[edit] Rounding down

Currently the documentation for the template includes the following statement.

As per the Wikipedia Manual of Style, numtext will at most return two words for any given integer. This means it will round down to the nearest two-word integer.

This is presented more or less as a premise and conclusion. However, one might question how the latter follows from the former. Why, for example, not round up? Are we doing justice to 28,000 by returning twenty thousand when it's actually 40% greater than this?

The documentation page does contain a hint.

For example, one could write either: Wikipedia has {{NUMBEROFUSERS}} users.
Wikipedia has 7,297,625 users.

or

Wikipedia has over {{numtext|{{NUMBEROFUSERS:R}}}} users.
Wikipedia has over seven million users.

So we should write over in front of the template whenever we're dealing with big numbers. Even still, over six million hardly does justice to 6,999,999. Then what happens when one more user joins? We get over seven million ... 7,000,000 is not over seven million it is seven million.

Wouldn't it be nice if the template called a spade a spade? Don't rely on the user to stick in an over, an over which may be a bit of a strech or may even be plain wrong. Let the template recognise the number it's dealing with an return something sensible. Jɪmp 02:07, 13 March 2008 (UTC)

[edit] Hundreds of thousands

Worse things still when inputting numbers, x, in the range 103n + 3 > x ≥ 103n + 2 for n = 1, 2 or 3 ...

Let's suppose there's a mass exodus of users from Wikipedia, let's say about 90% of accounts are deleted leaving about six hundred thousand of us ... but six hundred thousand, that's three words. The documentation page promises us rounding down to the nearest two-word number. Well, we are spared over ninety thousand but what we do get is ... nonsense. Sorry, there's no better word for it. Similar strife is install when we reach one hundred million until we get to one thousand million (yeah, call it one billion if you must) and again when we reach one hundred thousand million.

For numbers in the range above, the digit in the units position is taken (equivalent to rounding the input number down to the nearest interger, then taking last digit, mathematically (floor (x)) mod 10); if this is zero, the template returns nothing, otherwise the template spells this number out putting a hyphen in front. So, {{numtext|665230}} & {{numtext|665230.9}} give nothing whilst {{numtext|665231}} & {{numtext|665231.9}} give -one. Jɪmp 02:07, 13 March 2008 (UTC)

I fixed it.--Patrick (talk) 13:00, 13 March 2008 (UTC)

[edit] Performance with respect to template limits

[edit] 12 Mar 08 test (old version)

The performance of this template with respect to the various parameters that limit the amount of data that can be included into a page was tested in WT:SAND yesterday. Results were dependent on input but of those tested they fell into the following ranges.

NewPP limit report
Preprocessor node count: 50–100/1000000
Post-expand include size: 20–90/2048000 bytes
Template argument size: 20–60/2048000 bytes
#ifexist count: 0/500

Generally the preprocessor node count was equal to a + 2x⁄10m and the post-expand include size was b + cn, where x was the input integer, m its order of magnitude, n was the number of characters (letters, hyphens & spaces) in the output and a, b and c were some constants dependent on the type of number in question.


Details about the results of the 12 Mar 08 test (which may well bore you to tears) are hidden below.


It would appear that the {{#switch:}}s used in the code contributed considerably to the preprocessor node count with that contribution increasing the further down the list the desired output was. Note: x⁄10m corelates to the position in the switch list of this output. Jɪmp 06:07, 13 March 2008 (UTC)

ifexist count seems 0.--Patrick (talk) 11:33, 13 March 2008 (UTC)
Yes, the template has no {{#ifexist:}}s. Jɪmp 14:38, 13 March 2008 (UTC)

[edit] 13 Mar 08 test (Patrick's version)

Your recent edits, Patrick, should have an effect on the preprocessor node counts. Specifically, they should decrease significantly for inputs in the range 100 > x > 0 but inrease slightly for everything else. This is due to the corresponding code's being higher up in the {{#switch:}} list. Jɪmp 14:56, 13 March 2008 (UTC)


New test results (13 Mar 08)


As predicted, the changes in node count were observed and were consistant with an additional two counts for every step down the {{#switch:}} list. Jɪmp 15:51, 13 March 2008 (UTC)

[edit] 14 Mar 08 test (Jimp's version)

I have just eliminated the alternative codings for capitalistion. Testing with input of 1 showed a reduction in preprocessor node count from 64 to 60 without effecting any of the other parameters. Note that the number of alternative codings eliminated was four. Jɪmp 16:08, 13 March 2008 (UTC)
Replacing the {{#switch:}} with an {{#ifeq:}} results in a saving of one node count (on testing with input 1). Jɪmp 16:15, 13 March 2008 (UTC)
Naming the parameter has no effect on the limit report. Jɪmp 16:23, 13 March 2008 (UTC) ... Note the only transclusions which called for capitalisation were on the doc page, these have been fixed. Of course, the new syntax was not simply for the sake of testing. Jɪmp 16:26, 13 March 2008 (UTC)
Going through a redirect has no effect either. Jɪmp 16:36, 13 March 2008 (UTC)
Using subpages instead of the {{#ifeq:}} increased preprocessor node count by one for input 1 uncapitalised — we are worse off. However, with caps=on the opposite is true.
  • Preprocessor node count was reduced from 70 to 67/1000000
  • Post-expand include size was reduced from 35 to 32/2048000 bytes
  • Template argument size was reduced from 56 to 49/2048000 bytes
Also ther has been created the option to bypass the main page and go directly to the subpage you want.
  • Results for {{numtext/capsoffdown}}
    • Preprocessor node count: 55/1000000
    • Post-expand include size: 23/2048000 bytes
    • Template argument size: 45/2048000 bytes
  • Results for {{numtext/capsoffdown}}
    • Preprocessor node count: 60/1000000
    • Post-expand include size: 29/2048000 bytes
    • Template argument size: 46/2048000 bytes
This will be useful if the template is to be called by another template. Furthermore, the settings of more than one parameter can be combined into one suptemplate page name as done on {{convert}}. Jɪmp 18:03, 13 March 2008 (UTC)


14 Mar 08 test results


[edit] 18 Mar 08 test (new len & subtemplate array)

I've just replaced {{len}} with a new subtemplate, {{numtext/len}}, which was designed with the requirements of this template specifically in mind. This allowed a simplification of the template code. Two {{#expr:}}s and one {{#ifexpr:}} were eliminated.

The new version has been tested. There seems to be a reduction in preprocessor node count as a result, particularly for numbers between 1 & 100 (the preprocessor node count is down by about 5 or 6 for n s.t. 1 ≤ n < 100 and by about 1 for n s.t. 100 ≤ n). Jɪmp 05:12, 18 March 2008 (UTC)


18 Mar 08 test results with the three number {{#switch:}} subtemplates


A second major change was made yesterday. The {{#switch:}} function subtemplates, {{numtext/1-9}}, {{numtext/10-19}} and {{numtext/1-90}}, were replaced with an array of twenty-seven single-number subtemplates. This resulted in a reduction in preprocessor node count, post-expand include size and template argument size. Note also that with the {{#switch:}}s preprocessor node count increased as you went from 1s to 9s, 10s to 19s & 10s to 90s. This was eliminated. Jɪmp 02:56, 19 March 2008 (UTC)


18 Mar 08 test results with the array of single-number subtemplates


[edit] 19 Mar 08 test (reintroducing an {{#expr:}})

Comparison of template argument sizes before and after the introduction of {{numtext/len}} are very unfavourable with an increase of about 240 bytes. The two lens are not that vastly different so where was this coming from? On introducing the new len the template code was simplified. As noted above, two {{#expr:}}s and one {{#ifexpr:}} were eliminated. The second of these {{#expr:}}s along with the {{#ifexpr:}} were inside a switch, the parser should not have expanded them unless len returned 1 or 2, but the 240-byte increase seemed not to care what len said. Was this increase due to the elimination of the first {{#expr:}}? This first {{#expr:}} was added back to the template. The result was a reduction in template argument sizes back to pre-{{numtext/len}} levels. It can be thus seen that template-code simplification is not necessarily a positive thing in and of itself. I suspect that the extra template code lead to a reduction in HTML code, and that that's what counts. However, a new problem surfaced. {{#expr:}} returns E notation for numbers, ±10n, where n ≥ 12 or n ≤ −5. This put the upper limit lower than the ninety billion (90,000,000,000,000) promised in the doc page. The problem was solved by first dividing by 1000. Jɪmp 03:54, 19 March 2008 (UTC)


19 Mar 08 test results (reintroducing an {{#expr:}})


Template argument size is back down to something acceptable again. An interesting pattern can be observed: template argument size drops off to 1000 & then goes up again. It looks like this size is dependant on the number of digits sent to len. Thus for input less than 100 the new version is slightly worse in this area than the old one but does better for larger numbers. Jɪmp 05:30, 19 March 2008 (UTC)

[edit] 24 Mar 08 test (subtemplate-ladder & reconstructed old version)

The template has again been restructured. The subtemplate {{numtext/len}} and the main {{#switch:}} has been replaced with what you might call a "subtemplate-ladder". It's a much more complicated structure than before but there has been a benifit in terms of template limits (as can be seen below).


24 Mar 08 test results (subtemplate-ladder)


It could be argued that the small gain with respect to template limits is hardly worth the significant increase in complexity of the template code. However, there was more to the restructuring of this template than simply squeezing under limits. There has been paved a way for aditional options and further extension of the range—without impact on these limits, something impossible with the old structure. Indeed the range has been extended from 1–9×1014 to 0–9×1017. Jɪmp 07:27, 24 March 2008 (UTC)

For a more full comparison, the old version of the template was reconstructed and tested in the sandbox using templates X8 and X9. Also tested was the original version with links to Billion/Trillion & 1000000000 (number)/1000000000 (number). Jɪmp 08:09, 24 March 2008 (UTC)


24 Mar 08 test results (reconstructed old version)


[edit] Speedy deletion of subtemplates

The following have been tagged for deletion as lacking content.

Template:Numtext/8th (edit|talk|history|links|watch|logs)
Template:Numtext/12th (edit|talk|history|links|watch|logs)

Were they not part of something larger this would make sense but this is not the case. They are needed for {{numtext}} to function fully ... oh, yeah, I'm introducing ordinals too ... I'm up to twelfth ... (smerks) ... Jɪmp 08:42, 25 March 2008 (UTC) Done: use ord=on. Jɪmp 09:02, 25 March 2008 (UTC)

Plurals are now working too, use pl=on. JIMp talk·cont 06:15, 5 June 2008 (UTC)