Template talk:Convert/Archive March 2015

cents per mile/km

Is there a way to utilize $/mi to get cents per mile? Having visited a couple articles on toll roads recently, there are times when I would like to say "14 cents per mile (8.7¢/km)" rather than "$0.14 per mile ($0.087/km)". –Fredddie™ 05:56, 2 March 2015 (UTC)

Sorry, no. I'll have a look at what would be involved but I'm worried that someone would then want to convert $/mi to cent/mi or cent/km. The problem is that $ is treated in a special way and is not a unit that can be converted. Your suggestion would need a unit that can sometimes be "cent" or "cents", and sometimes be a symbol. Meanwhile, does WP:MOS say anything about a symbol for cent? Also, when people ask for a new unit we ask that they provide a couple of links to where it would be used. It sounds like you have that well in hand, but please give a link so I can see exactly how it would fit. Johnuniq (talk) 06:20, 2 March 2015 (UTC)

Fredddie, the $ is used like this:

• {{convert|10|$/mi|$/km}} → $10 per mile ($6.2/km) Y
• {{convert|10|$/mi|$/km|$=€}} → €10 per mile (€6.2/km) Y

A "cent" (is that "$cent"?) does not work out well:

• {{convert|10|$/mi|$/km|$=cent}} → cent10 per mile (cent6.2/km) N

Is why a cent does not fit.-DePiep (talk) 08:39, 2 March 2015 (UTC)

Added "$/mi" to documentation, units. -DePiep (talk) 08:53, 2 March 2015 (UTC)

@Johnuniq: "Meanwhile, does WP:MOS say anything about a symbol for cent?" If it's not at MOS:CURRENCY, I doubt there's any guidance in MOS on this. However, see Currency symbol § List of presently-circulating currency symbols:

• ¢: A centesimal subdivision of currencies such as the US dollar, the Canadian dollar, and the Mexican peso.
• c: Preferred by currencies such as the Australian, New Zealand, South African cents; the West African CFA centime; and the divisions of the euro.

See also Cent (currency) § Symbol. —sroc 💬 13:31, 2 March 2015 (UTC)

Some notes: how would we diff between say US$-¢ and CAD-¢? And, some practical usages would help. I can only think of actual practice (in sources) to use cents as a unit, that could be a reason to use them in articles. -DePiep (talk) 14:12, 2 March 2015 (UTC)

Here are links to the articles in which I was using $/mi:

• Interstate 95 in Delaware#Tolls
• Pennsylvania Turnpike#History

From what I can tell, the MOS is silent about dollar/pound/euro subdivision symbols, though the article on currency symbols linked from the MOS does include ¢ for cents. –Fredddie™ 18:30, 2 March 2015 (UTC)

@DePiep: ¢ should come after the value and not before.

{{convert|10|cents/mi|cents/km}} → 10 cents/mi N

{{convert|10|¢/mi|¢/km}} → 10 cents per mile (6.2 ¢/km) N

{{convert|10|pence/mi|pence/km}} → 10 pence/mi N

{{convert|10|cent/km|cent/mi|$=€}} → 10 cents per kilometre (16 ¢/mi) N

^These are some examples of potential usage. –Fredddie™ 22:30, 2 March 2015 (UTC)

Thanks for the comments. I have put a trick into Module:Convert/extra which can be used now. It defines unit cent and alias ¢ (so ¢ is equivalent to cent). There is no cents or penny or pence, and I cannot see a good way of handling symbol c so Sroc's above information will have to wait until it's needed and someone can think of a reasonable syntax. It would be better to avoid making unit c (for cent with symbol c) because we use uppercase C for °C and it would be too confusing if a simple typo like {{convert|23|c}} merely converted 23 cents to 23 cents (which is all a cent can be converted to).

@Fredddie: DePiep knows that cent goes after the unit—he was just illustrating how "currency" works in convert, and what is special about $.

The situation now is that unit cent exists but can only be converted with itself. However, it can be used in automatic per units.

• {{convert|14|cent}} → 14 cents (14 ¢)
• {{convert|14|cent/mi}} → 14 cents per mile (8.7 ¢/km)
• {{convert|14|cent/sqmi}} → 14 cents per square mile (5.4 ¢/km²)
• {{convert|14|¢/cm3|¢/in3|abbr=on}} → 14 ¢/cm³ (230 ¢/in³)

Each unit has to have a default output, and cent uses itself as its default. I will update Module:Convert/makeunits which currently rejects attempts to do that because it would normally be an error. Johnuniq (talk) 23:27, 2 March 2015 (UTC)

de-punctuate multiple output

For converting say km to mi and nmi, normal output is 99km (99mi; 99nmi)
I don't want brackets, so I can get rid of with |disp=x | , giving 99km 99mi; 99nmi
But I don't want the semicolon either. How to get rid of? Couldn't see anything in the doc.--Unbuttered parsnip (talk) mytime= Wed 00:05, wikitime= 16:05, 10 February 2015 (UTC)

I could think of this construct, using the "converted output only":

{{convert|99|km|mi|abbr=on|disp=x| }} {{convert|99|km|nmi|disp=out}} →

99 km 62 mi 53 nmi

-DePiep (talk) 16:22, 10 February 2015 (UTC)

Is there an example where this would be used? Is it in a table? There is disp=comma but I just noticed that it is unhelpful with an output combination:

• {{convert|99|km|mi nmi|abbr=on|disp=comma}} → 99 km, 62 mi, 53 nmi

When I next upload to the sandbox I will fix that so the output is "99 km, 62 mi, 53 nmi" (two commas, not comma + semicolon). Johnuniq (talk) 23:04, 10 February 2015 (UTC)

Is this for /doc? (I prefer not t o spend extra time). -DePiep (talk) 00:54, 25 February 2015 (UTC)

This semicolon was a bad idea from the onset (I don't remember whose bad idea it was but it wasn't one of mine). Semicolons have a set of specific grammatical meanings which do not include what we're using them for here. Anyhow, enough of that. What would be nice is a disp option which would remove everything, perhaps something like this.

{{convert|99|km|mi|abbr=on|disp=clear}} → 99 km 62 mi 53 nmi

This could be used in conjunction with some sort of parameters to insert text/code (as with {{convert/f}} but we could think of better names than x1, x2, etc.). Jimp 23:04, 4 March 2015 (UTC)

footnote to indicate source units when flip function is used.

I will phrase this as a proposal but my question is mainly: "How hard would this be to do?"

Flipping is used when the source value is not in the 'primary' units being used in an article. The following code produces the following output but does not indicate to the reader that the source value was not reported in the primary units.

{{convert|5|ft|m|order=flip}} gives 1.5 metres (5 ft)

The object of the proposal is to make apparent to the reader that the value reported in parenthesis is the actual value reported in the source. The proposal is to replicate something similar to the following.

The elivation at Buna strip was 1.5 m (5 ft^§)

Note

§ Value given in source document.

The actual note could be manually inserted and need not be created by coding. It would only appear once, regardless of how many times the note symbol appeared in the text. More complicated coding could (of course) auto generate the code but the simple solution is for it to be manually inserted. The symbol could be either pre-defined or user nominated. In the first proposal, there would be an additional argument, the operation of which would be linked to the 'flip' function. Possible coding could be:

{{convert|5|ft|m|order=flip|note=on}} for a predefined note symbol

{{convert|5|ft|m|order=flip|note='symbol'}} where 'symbol' is a user defined symbol

A more flexible alternative would allow the note symbol to be attached to either 'primary' units or the 'converted' units in the text on the presumption that the symbol would be attached to one or the other but not both in a particular article. in this case, the argument 'note' could be replaced by 'pnote', if the note symbol is to attach to the primary unit; or, 'cnote', if it were to attach to the reported converted units. In this case, the argument would act quite independent of the flip function.

To conclude, this is primarily to ask about the ease and practicality of the proposal from a programming perspective. Of course, the proposed parameter names are only suggestions. Cinderella157 (talk) 10:30, 4 March 2015 (UTC)

As a detail: when one does correctly source the whole paragraph (with the 5ft-fact in that source), how good/bad is that? Can we say: well referenced? -DePiep (talk) 10:52, 4 March 2015 (UTC)

I would say that any statement of a specific measurement, time or date, even if in paraphrased text is a critical piece of information that must be substantiated by a citation. Conversely, any referencing is only as good as the 'originator' and relies on the integrity of the author/editor making the attribution. What I propose dose not occur 'automatically', but must be consciously enacted. As with any citation, it is only as good as the author making the attribution. Cinderella157 (talk) 11:37, 4 March 2015 (UTC)

I think this is good enough: 1.5 m (5 ft)^[1] for example. (footnote and refnote should be after the last punctuation). This can be a regular ref then, or a regular fn: 1.5 m (5 ft)^{[note a]} It does not note that the feet is the original size. Does it have to? If required, the note itself can say so. As with translations, the transition should not matter. If I am right in this, {{convert}} can add little or nothing to the fn-adding. All this can be said too when the note is ate the end of a sentence, or paragraph.^[2] -DePiep (talk) 19:08, 4 March 2015 (UTC)

I think there would need to be a MOS discussion about the general idea before an investigation of what convert might do. Using flip relies on WP:CALC which says that converting units is acceptable as a routine calculation. At any rate, it is possible to get close to the desired effect:

• The elevation was {{convert|5<ref>My mother told me this.</ref>|ft|m|order=flip}}. → The elevation was 1.5 metres (5 ft).

References

Johnuniq (talk) 09:04, 5 March 2015 (UTC)

Good MOS base, but there is also WP:REF. I don't think we should promote this ref option, for the obvious reason of bad ref-formatting (or is it bad punctuation?). This is not to say that your mother is not a RS; I know this because my mother said the same ;-) . -DePiep (talk) 09:11, 5 March 2015 (UTC)

Thanks for the feedback. The object was to create a note that was to be read in conjunction with a reference and a single note that would avoid multiple occurrences of notes with the same text appearing. The example interjecting the reference between the value and the units would certainly be bad form. I had not considered superscripts in units and a note adjacent to these could be slightly confusing, so placing the note outside the parentheses would be better. In this case, my question becomes mute. The desired effect can easily be achieved manually. This does not make the note explicit to the contents of the parentheses (the reason for my enquiry) but the note can be modified to accommodate this. Thanks again. Cinderella157 (talk) 23:27, 5 March 2015 (UTC)

Fathom symbol revert

A few weeks ago someone changed the symbol for fathom to ftm. I checked Fathom which supported the claim about ftm, and there was no objection at a discussion. However, the article has now been changed to remove ftm, and that drew my attention to Talk:Fathom#Abbreviation "ftm" where there has been an objection to the claimed symbol since June 2010. Now that I've noticed that I plan to restore the fathom unit to how it was so it will always show "fathom" and never "ftm". Any thoughts? I'm doing other cleaning up of units and will post about that in due course, and plan to make this change with the others. Johnuniq (talk) 09:26, 16 March 2015 (UTC)

I understand there is no stable definition (sourced) for symbol 'ftm'. So I guess it should go. There is no reason to add speed to the change (no enforced update): it is not a fatal or misleading error. -DePiep (talk) 09:53, 16 March 2015 (UTC)

Julian days

Would it be possible to let {{Convert}} handle conversion between Julian days and normal dates with formatting options taking into account, e.g. JD 2457000.5 ←→ 2014-12-09 or 9 December 2014? --JorisvS (talk) 21:17, 21 March 2015 (UTC)

I don't think so—there are too many weirdnesses when dealing with dates, and it would be better to use templates/modules dedicated to the task. I did a bit of work in the area with Module:Age (not related to Julian days), and something like that could be extended, if needed. However, it is likely that existing templates already do what is required although I don't know anything about them. See {{JD}} and what it mentions, including Category:Date-computing templates. If something is needed and no one is available, I might be able to help, but I'm busy elsewhere so nothing would happen for a while. Johnuniq (talk) 01:38, 22 March 2015 (UTC)

More rounding options?

I've found it quite handy to have several choices of values to round to (e.g. 5, 10, 15 etc.) for various contexts. But in some cases this does not work, e.g. {{convert|24|in|mm|round=50}} produces "24 inches (600 mm)" (i.e. rounding to 50 has no effect). Why does this happen? Archon 2488 (talk) 22:40, 16 March 2015 (UTC)

Sorry, only round=5 and round=25 are supported. Because there are thousands of broken converts (with options like abr=on instead of abbr=on), the convert template does not tell the module to warn about errors in options. Therefore, round=50 is silently ignored. Supporting more rounding would be easy. What is needed? Johnuniq (talk) 23:35, 16 March 2015 (UTC)

I've often caught myself thinking that it would be handy to have "round=10" or "round=50" for example – although I worked out that using the "-1" option (for decimal places, perhaps something of a hack) is a usable workaround for rounding to the nearest 10 (useful when sigfig won't work because your unrounded outputs would have different lengths, e.g. 73 and 112). But I think round=50 and perhaps round=0.5,0.25 options would be useful – as it is, you can get paradoxes where your rounding will work as desired if you're converting a number in inches to centimetres (because you can round to 5 cm) but not millimetres (no equivalent option for 50 mm). Likewise, sometimes when converting feet to metres, you can produce unnatural rounding such as 8 ft --> 2.4 m (when converting an estimate, this gives the false impression of 0.1 m precision, when an actual estimate in metres would likely not be precise to more than the nearest 0.5 m). Archon 2488 (talk) 00:33, 17 March 2015 (UTC)

I'm a bit uneasy about 0.5 and 0.25 because I'm not sure that people would really think that 12.5 meant that some kind of rough rounding had occurred—my feeling is that 12.5 means not 12.4 and not 12.6. I guess 50 could be useful. Perhaps 10 would be a convenience (and clearer for other editors than |-1), but that makes me worry that people would want 100 and 1000 and so on. Any other thoughts? Johnuniq (talk) 09:34, 17 March 2015 (UTC)

Perhaps a dumb question, but why is it a worry that people might want 100, 1000 etc? Another approach would be different syntax, making it clearer what the number means (i.e. it means the figure, counting right from the decimal point, where rounding occurs). As is, it's just a number on its own.

Speaking for myself, I think for example "0.5 m" would be understood most readily as "half a metre" rather than "not 0.4 or 0.6 m". Likewise, "2.5 km" seems to me not to mean something like "2500 metres as opposed to 2400". But the convert template gives no easy option to fix {{convert|1+1/2|mi|km}}; it displays as "1+1⁄2 miles (2.4 km)" which is the kind of bad rounding I was wanting to avoid: in this case I think 2.5 km is a far more appropriate rounding. Archon 2488 (talk) 19:13, 19 March 2015 (UTC)

("Perhaps a dumb question" - don't say that. If you write a serious, thought-about question, it can't be dumb. And good editors will answer just as serious. Beware of bad editors, they don't ;-) ). -DePiep (talk) 00:06, 26 March 2015 (UTC)

Radio frequencies (m to kHz)

Would it be possible to convert medium-wave frequencies expressed in meters to kilohertz? There's a conversion website and I don't need to do it often, but it would be helpful to be able to use {{Convert}}. Thanks and all the best, Miniapolis 22:31, 15 March 2015 (UTC)

Please provide some examples of what you would like to type, and the wanted output. For simplicity, one opening and closing brace would be fine:

{convert|12|???} gives ???

There are hundreds of unused units (I'm currently investigating whether it would be worth simplifying the gigantic list of units by removing some of them), so would you please identify a couple of examples (in articles) where this would be used. Johnuniq (talk) 00:45, 16 March 2015 (UTC)

I'd like to {convert|434|wavelength|???}, where ??? is the frequency in kilohertz. It comes up "unknown unit", and didn't work either when I used "m" instead of "wavelength". There are two examples in Cyprus Broadcasting Corporation I've already converted with an external converter, and although frequencies in wavelengths are less-commonly used than in previous decades, they pop up often enough that a converter would be handy; all I know is the general rule that the longer the wavelength, the lower the frequency. Miniapolis 14:11, 16 March 2015 (UTC)

Sounds like a good idea for electromagnetic waves in general. For example Infrared has conversions between wavelength and frequency. It's another example of an inverse relationship.

{convert|700|nm|thz} could give something like: 700 nanometers (430 THz). The units are different though, nm are length, and Hz are dimensionless (because the constant, c is dimensioned).GliderMaven (talk) 01:13, 16 March 2015 (UTC)

Hertz is not actually dimensionless, it has the dimension of inverse time. This would be the equation to use.

fλ = c

where f is the frequency (e.g. 430 THz), λ is the wavelength (e.g. 700 nm) & c is the speed of light.

Jimp 06:12, 16 March 2015 (UTC)

{Convert} is to change units within the same dimension. So area into area (only, expressed differently). This request is a about applying a formula, to return a different dimension. Similar: say I'd like to input the radius of a circle, asking {convert} to return the area (from length to area). The question then is whether we want to add that (unlimited) class of formulas to {convert}. Another consideration is that a short return text could be incomplete. eg, "700 nanometers (430 THz)". Somehow one wants to see the formula referred to in the result: "700 nanometers wavelength (equals 430 THz cycles)". This is not to deny the request beforehand, be we should consider the implications of this new route. -DePiep (talk) 06:42, 16 March 2015 (UTC)

No, Hertz is not a length: [1]. -DePiep (talk) 10:34, 16 March 2015 (UTC)

I remain unconvinced about whether this can be used in articles, but mucking around with GliderMaven's invert seemed to good an opportunity to pass up, so I have put another abuse of convert in Module:Convert/extra:

The following used fixed wikitext so it will be retained regardless of the current unit definitions. Johnuniq (talk) 09:40, 17 March 2015 (UTC)

• {{convert|1.234|kHz|Hz}} → 1.234 kilohertz (1,234 Hz)
• {{convert|1.23e6|mHz|kHz}} → 1.23×10⁶ millihertz (1.23 kHz)
• {{convert|1|Hz|0}} → 1 hertz (299,792,458 m)
• {{convert|300|MHz}} → 300 megahertz (1.00 m)
• {{convert|30|PHz|nm}} → 30 petahertz (10.0 nm)
• {{convert|299,792,458|m|Hz|0}} → 299,792,458 metres (1 Hz)
• {{convert|300|m|MHz}} → 300 metres (1.00 MHz)
• {{convert|700|nm|THz}} → 700 nanometres (430 THz)
• {{convert|15|furlong|kHz}} → 15 furlongs (99 kHz)

LOL! It seems to work. I'm inclined to agree with DePiep, but hey, it's fun. Johnuniq (talk) 10:40, 16 March 2015 (UTC)

OK, for reason of LOL I'll allow it a few days in there :-). By the way, when traveling from UK to US taking your electric shaver, don't forget your mains plug converter because it is 1.55 km vs. 2.91 mile. -DePiep (talk) 10:58, 16 March 2015 (UTC) -hardcoded the demo.-DePiep (talk) 09:50, 17 March 2015 (UTC)

And {{convert|434|m|kHz}} works beautifully; thanks very much! All the best, Miniapolis 14:11, 16 March 2015 (UTC)

Nooooo!. I have to revert, out of article space and to be safe: out of /extra. -DePiep (talk) 14:26, 16 March 2015 (UTC)

No, I think this should definitely be supported. The current convert lacks even converts between different Hz, kHZ, MHz etc, and so far I've looked at only a few articles, all of them have converts between frequency and wavelength. infrared, microwave, longwave, Shortwave radio. The fact that the units are wrong internally for hertz means very little, it's fixable if it ever becomes an issue later, but at the moment I'm thinking it probably won't. It would also be nice to support rpm, rps, and that would be pretty easy to do at the same time.GliderMaven (talk) 14:37, 16 March 2015 (UTC)

Probably rpm and Hz are convertable through {convert}, but Hz is not a length. As I described, 1/time does not convert to length. Adding this would break the {convert} base. -DePiep (talk) 14:47, 16 March 2015 (UTC)

In precisely what way could it break? c=f lamba is a valid equation in all circumstances; so there's no user visible downsides.GliderMaven (talk) 15:18, 16 March 2015 (UTC)

It breaks correct writing, it breaks {convert} basic premise to convert units. Basically {convert} says correctly like: "1.6 km = 1 mile". But in the Hz <--> m thing, this is not valid: "1 Hz = 0.5 m" (irrespective of the numbers) because the dimensions (length vs. per-time) are not the same. (maybe we need a template {calculate} for this). -DePiep (talk) 15:26, 16 March 2015 (UTC)

(←) I spoke too soon; it worked here, but not in the article. No worries; I can use the external converter for the odd instance. Thanks again and all the best, Miniapolis 15:40, 16 March 2015 (UTC)

This is probably a job for a different template. Like DePiep says, conversions between different dimensions are counter to the whole idea and would quickly bring confusion (though mpg to l/100 km etc. are kind of exceptions). This is why barrels to tonnes was never brought into this template. Were this added, it wouldn't be long before someone would want to convert frequency to wavelength but for sound waves. Jimp 16:03, 16 March 2015 (UTC)

Or a new switch like |calc=yes could be added, which opens this new class of workings for the editor. A good way of writing (formatting) is needed then too. And a logic for "what physical relation [function] do you want to use between the units you mention?" This allows co-using the impressive unit-base and input paring etc. But through a sub-module I'd say, to keep the design sound. -DePiep (talk) 16:18, 16 March 2015 (UTC)

No, and with all due respect you're overinterpreting the 'length' and '1/time' stuff. At the very bottom this tool simply does ratio conversions of numbers. The 'length' and '1/time' stuff is so the user can't convert completely ridiculous things, like volumes into furlongs per fortnight; things that seriously don't make any sense like that. If it wasn't for the 'length' stuff you would be able to ask convert to do it, and it would come up with a conversion that would operate, but would be complete garbage.

In this case the conversion is perfectly valid in the physics. It's very much like the equation F=ma. Is that a dimensionally correct equation??? No!!! On the left it's Force, and on the right it's mass metre per second squared. Dimensional analysis only takes you so far, and these are good examples of the limits of it.GliderMaven (talk) 18:41, 16 March 2015 (UTC)

The problem is that if we add this one, hundreds of other calculations can claim a place. Then we end up with an unordered set of unit-combinations (as Hz, m) without a decent way to shift sensible pairs from nonsensicals. And then we are to document it, to make it useful for editors. Next: the dimensional analysis makes a lot of sense (btw, in F = ma the force F can be in Newtons ie kg⋅m/s². m⋅a also produces kg⋅m/s², so the dimensions are the same left and right Y). Already today {convert} requires same-dimension for both units to prevent mistakes. This is part of what brought {convert} this far in its aim. From this base, {convert} also can handle compositions like "yield in $ per acre" consistently. And such cases can easily be added to the option list, because it's base is systematic. That system is: dimensions. OTOH, as I wrote possibly Johnuniq seems an option to extend this module with calculations. -DePiep (talk) 19:04, 16 March 2015 (UTC)

You're claiming thin end of the wedge. There's no evidence at all that that's likely to happen. What are all these hundreds supposed to be??? If there really was clamouring for scores of exceptions that clamour would be on this page; and 14 years into Wikipedia, I'm simply not seeing it. I mean, it's a valid question, whether that could happen, but the answer seems to be no, this is just a rare exception. Dimensional analysis does work fairly well, with only the odd exception; not hundreds.GliderMaven (talk) 19:37, 16 March 2015 (UTC)

I oppose the (ab)use of the convert macro for application of actual physics formulae. While the correctness of a conversion of units is independent of context, the application of a formula is typically not, making that usage conceptually different and prone to misunderstandings. For example, the "conversion" between frequency and wavelength must assume a wave velocity, and I see the speed of light mentioned in this regard. But then someone will naively use that "conversion" for signal transmission in copper (or how about accustic waves in water). And then you say, 'no, this "conversion" (implicitly) assumes speed of light in a vacuum'. But then what about all other wavelength and frequency relations? It is just a bad idea.

And a "conversion" involving (but not explicitly stating) Newtons 2nd law will be soon enough handy for someone who happens to write about relativistic speeds. So if you must play with this, come up with a differently and aptly named macro, and stop adding to the complexity of the convert macro. Please. Lklundin (talk) 20:04, 16 March 2015 (UTC)

PS. To all those who have so much extra energy in relation to unit conversion: Help bring about the end to the non-SI systems in the last couple of non-metric countries. That will truly help to simplify the convert macro. Thanks in advance. Lklundin (talk) 20:07, 16 March 2015 (UTC)

The other wavelength conversions which could (really only) theoretically be needed depend on temperature and similar, so they're very unlikely to be needed; but electromagnetism is fundamental to, and constant within... the universe... and so is likely to, and actually already does appear on dozens of article pages in manual form already.GliderMaven (talk) 00:44, 17 March 2015 (UTC)

I did not respond because I would be repeating myself and others. I think going into the "thin edge" would be another repetition off track more or less. I oppose this addition, I have said why. I reverted GM's re-introduction. -DePiep (talk) 08:35, 17 March 2015 (UTC)

• This approach. Johnuniq, would it be possible to create a new module (by someone else) that uses chunks of module:Convert? That could be unit handling (data page, prefixes, per-options, ...), number handling, but not the convert-setup structure number_unit_in (number_unit_out)? (to calc and return functions, like the radiowave asked here, handling related values is a major new aspect). Visions? -DePiep (talk) 08:45, 17 March 2015 (UTC)
• Miniapolis, GliderMaven, Jimp. When we are not restricted by {convert}, how would the result look like? We know the numbers of course, eg being "700 nanometers or nm", and "430 THz". How to write that inline, in an infobox, in extense? Suggestions:

700 nanometers (or 430 THz)

700 nanometers (equals 430 THz)

430 THz (⇔ 700 nm)

430 THz (⇔ 700 nm, by c) -- long form

Might need List of mathematical symbols ↔⇔≡.

-DePiep (talk) 09:09, 17 March 2015 (UTC)

I would suggest keeping it simple, i.e. "430 THz (700 nm)". If it's not clear enough from context, a fancy symbol which we define on this page isn't going to be of much use. Jimp 04:50, 19 March 2015 (UTC)

• Can we please keep convert relatively crisis-free? There was no need to revert my edit at Module:Convert/extra, and certainly no reason to revert GliderMaven's—there is no emergency. For anyone who hasn't noticed, GM has an excellent understanding of physics, and if he thinks there is no problem, there really is no problem. Others might not like it, but there is no technical problem (I know enough basic physics to understand that).

  The fundamental issue is that the number of cases where a simple convert would produce useful wording would be rare. The closest I can find is at Radiation#Microwave which, for example, includes "lower boundary at 1 GHz (30 cm), and the upper around 100 GHz (3mm)", and convert could handle that. However, other cases (I've lost where I found this) such as "from 300 GHz to 30 THz (1 mm - 10 μm)" would not be amenable to convert which cannot switch units in a range. I've also seen other cases where the text includes several words to express the conversion, and convert would be not help there, except with clumsy use of disp=out.

  Convert prevents nonsense results such as converting kilograms to feet, and it would not permit kilograms to be converted to hertz. Rather than debating whether it would be heretical to convert meters to hertz, efforts should focus on finding text in articles where convert could reasonably be used. If there are several places, the hertz unit should be retained—it's not wrong. If these places don't exist (as I suspect), there is no need for a hertz unit and we don't have to squabble. Johnuniq (talk) 09:23, 17 March 2015 (UTC)

Calling this a "crisis" is quite useless. It's just a talkpage discussion not yet closed. re "GM has an excellent understanding of physics" - well, that in itself is not an argument. I already explained (corrected) their "F = m · a" note wrt dimensions (which, without me claiming authority, is quite to the point in itself). Then Johnuniq, I reverted you because you initially added with with a "it's fun" notion, with which I agreed ('see, even this seems to work'); I reverted when GM announced it would go live in articles. Anyway, this thread did not conclude then or now. And I am still missing a greater design for these situations, where you describe designs & criteria for future function additions. As you well know, the potentional list of requirements is enormous. (I remember recent sections here about Mach and valuta conversion, which treaded in the same issue). Then there are the serious areas of how to note it, how to document it, how to prevent nonsense usage. Without a solid design base, we'll end up with a set of incidental options that re-introduce the pre-2014 (markup code) situation: yes it is there, and none can find it or use it. -DePiep (talk) 09:48, 17 March 2015 (UTC)

"GM announced it would go live in articles" - really I wrote that? I kinda think I would have remembered. I thought we were discussing it; whereas you apparently think that character assassination and revert warring other people's edits is more important.GliderMaven (talk) 16:39, 19 March 2015 (UTC)

I wrote that because of And {{convert|434|m|kHz}} works beautifully; thanks very much! which was actually by User:Miniapolis, not by you (which does not matter for my point, and incidentally illustrates that I was on content and not after you). re "apparently think that character assassination" - nothing apparent. But if you allude to my F=ma note, you can read that again and see that I was responding to the authority claim Johnuniq entered. With that I replied (or tried to) that authority in itself, which I did not judge upon, is not an argument in this issue. I did not state that you wave calculation was wrong or off in any sense. Now if you can find time to read other contributions here, you might find various routes and suggestions that could solve this quest. -DePiep (talk) 17:37, 19 March 2015 (UTC)

(arbitrary break)

My take on this is that it's basically a unit conversion with a dimensionful conversion factor (actually physicists sometimes take c to be dimensionless, in natural units, but that is a separate topic). Whether it goes into the convert template or another template is kind of academic, although personally I'd prefer to have all the conversions in one place, so to speak. It's annoying to go hunting for the template that does what you want, and I think that situation is more likely to cause frustration to our editors than having a dimensionful conversion formula, which makes perfect sense in context. I'm not sure whether WP has a genuine need for a template to apply other physics formulae. Archon 2488 (talk) 10:36, 17 March 2015 (UTC)

• Let me restart. I can see Jimps point that writing "430 THz (700 nm)" is OK (and its inverse, and with |abbr=off: all the smart {convert} options fit to print). In almost any context, i.e. radio wave prose and tables/infoboxes, this does not introduce misunderstanding and is common notation.

I'd like to read, especially from Johnuniq, some long term vision on how to handle these dimension-changes in general, when added. As said, such a vision could involve sound notation patterns (eg with Mach, which is not as simple as radio waves), documentation setup, parameter changes/addition, optional link to the formula, etc. -DePiep (talk) 12:01, 20 March 2015 (UTC)

Also researching this option. Could make possible {radiowave}. -DePiep (talk) 12:17, 20 March 2015 (UTC)

... the answer is positive! I now have the idea, and a broad brush, to add a parameters like |function=wave, |function_parameter1=c. Then we can create:

[[Template:Radiowave]]

{{#invoke:Convert|convert|function=wave|function_parameter1|c}}

Especially the major parameter |function= could lead to sub-modules (to keep it organized), and take care of non-convert formatting aspects (write at-value, add extra text not easily done in basic convert, provide an optional link to the formula page, ...). -DePiep (talk) 19:20, 20 March 2015 (UTC)

My another proposal. Johnuniq, if we re-add this single option for now & speedily [2], can you 'promise' that in the future we won't be tied to it? (possibly, then you will have to revisit all pages using this through the dumps - no category or WLH is available). You can re-add it to /extra then. It is low-cost for you, today. -DePiep (talk) 22:33, 25 March 2015 (UTC)

It looks like the OP (Miniapolis) has left the issue, and I would still like to see examples of text in articles where this unit could reasonably be used. Above I mentioned that my efforts to find such examples had very limited success, so I think we can let this section be archived for reconsideration if anyone wants to take it up again. Johnuniq (talk) 01:39, 26 March 2015 (UTC)

The primary point is that in wireless, frequency and wavelength are used interchangeably to denote station/channels. Old radios are marked very clearly with both. It absolutely is a type of units conversion. The same is done in optics; they use mostly wavelength, but frequency is interchangeable as well.GliderMaven (talk) 02:51, 26 March 2015 (UTC)

I think Miniapolis did not loose interest but was chased away - partly by me ;-).

As a radio topic, I guess there are places around: Frequency, Radio waves (and WLH's).

So I propose to add Hz<->m to the /extra data set, without much ado. In the future we can cleanup issues by backtracking usages. The profits of this phenomenon are quite obvious, and it could use the great unit-handling (eg SI prefixes). -DePiep (talk) 18:39, 26 March 2015 (UTC)

Ok, I reapplied it, pending further discussion. Microwave ovens can use 2.4 gigahertz (12 cm) conversions at the moment.GliderMaven (talk) 01:48, 27 March 2015 (UTC)

Potential dimension-changed additions

This section it for possible additions to {Convert} that are dimension-changing (such as radiowaves). By intuition I say that Mach-like topics belong here too, so we add them (Mach is more of an "at-x-feet-height" issue). This list is intended to be positive: just add sensible options you have, no need to burn down anything. It will help us all to get an overview of issues involved.

Notation setup suggestion: any function starts with a bullet (*) and bold name, further notes then can be indented. Helpful links are welcome: formula's article, [[Template talk:Convert/Archive]], xl, demo article. No need to define or discuss the details for now I'd say. Let's get inspiration & overview. -DePiep (talk) 19:48, 20 March 2015 (UTC)

• Radio wave
• Sound wave (gas)
• Fluid wave (water)
• Mach

(todo: link to recent discussion, here) -DePiep (talk) 19:50, 20 March 2015 (UTC)

• Size to area (circle, football field)

Millions

Hello. In Pizza#Cheese, I got the numbers with strings of zeros to instead display as "X million" and "X billion", but how do I get the converted numbers to do the same? Thank you.--ɱ (talk · vbm) 18:03, 30 March 2015 (UTC)

You can use |e6kg|abbr=off (see https://wiki.riteme.site/w/index.php?title=Pizza&oldid=654245829#Cheese). Jimp 22:01, 30 March 2015 (UTC)

Awesome, thanks.--ɱ (talk · vbm) 22:15, 30 March 2015 (UTC)

No worries. Jimp 22:36, 30 March 2015 (UTC)

Superfluous NOWIKI off tag

Am I correct in thinking that there is a superfluous NOWIKI-off tag in the section Template:Convert#Enforced line break? --Boson (talk) 22:08, 9 March 2015 (UTC)

yes. Frietjes (talk) 23:52, 9 March 2015 (UTC)

rm from /doc. -DePiep (talk) 08:22, 10 March 2015 (UTC)