Template talk:Calculator

Feature requests at Template talk:Calculator/feature requests

Develop of this tool

Was funded by Wiki Project Med and is taking place primarily at mdwiki:Template:Calculator. If you have suggestions for improvements or which to join in the efforts please reach out. Doc James (talk · contribs · email) 00:07, 26 September 2024 (UTC)

Text appears out of table

Text appears outside, before table: "Add a calculator widget to the page. Like a spreadsheet you can refer to other widgets in the same page." Uwappa (talk) 18:18, 17 October 2024 (UTC)

Right align fallback?

Float fallback text right so it is in the same spot as the calculator would have been? Uwappa (talk) 08:16, 19 October 2024 (UTC)

new parameter: Tabindex?

Could input fields have a tabindex parameter?

This would be useful at Template:Body_roundness_index/sandbox:

• tab from height in cm to waist in cm
• tab from height inches to waist inches.

Uwappa (talk) 10:28, 20 October 2024 (UTC)

tabindex is not something that is allowed in normal wikitext (except for the special value 0). It can also globally affect the tab order for the entire page, which can be quite confusing if the calculator is in the middle of the page. I'm a bit reluctant to add things that cannot be done in normal wikitext without clear consensus from technical editors. Bawolff (talk) 22:06, 29 October 2024 (UTC)

OK, I'll cancel request.

Funny: request is outdated.

Trashed all unit related input today.

Now unitless height and unitless waist are nicely next to each other. Uwappa (talk) 22:14, 29 October 2024 (UTC)

ifLower, ifLowerOrEqual, ifEqualOrGreater, ifGreater?

It is currently possible to use a max followed by ifEqual to derive:

• ifLower
• ifBelowOrEqual
• ifEqualOrGreater
• ifGreater

This works but is a bit troublesome. How about adding the 4 functions above, with parameters similar to the current ifequal? Uwappa (talk) 12:57, 23 October 2024 (UTC)

There is a new version of gadget that adds these (I used ifless and ifgreater). Just waiting for an iadmin to update the gadget. Bawolff (talk) 06:50, 30 October 2024 (UTC)

ifPositive is confusing

The current name ifPositive is confusing, as it yields true for zero. Uwappa (talk) 08:16, 23 October 2024 (UTC)

not?

It is currently possible to have a not function on a boolean using opposite = 1 - boolean. It looks a bit incomprehensible in the code. How about adding a not function? Uwappa (talk) 10:09, 23 October 2024 (UTC)

There is a new version of gadget that adds these. Just waiting for an iadmin to update the gadget. Bawolff (talk) 06:50, 30 October 2024 (UTC)

and?

It is currently possible to have a AND function on two booleans using both = boolean1 * boolean 2. It looks a bit incomprehensible in the code. How about adding a and function?

I have not yet run into an 'or' situation yet, but that is likely to happen sooner or later. Uwappa (talk) 10:09, 23 October 2024 (UTC)

There is a new version of gadget that adds these . Just waiting for an iadmin to update the gadget. Bawolff (talk) 06:50, 30 October 2024 (UTC)

Could a set of radio buttons be processed as one variable?

The Calculator implementation of radio buttons is different than I expected:

• A collection of HTML radio buttons that share the same name are like one variable, the value of the selected radio button.
• Each HTML radio button has its own value and a boolean, true if checked
• Only one radio button of a set can have the selected status. Selecting one automatically deselects all others.
• The set of radio buttons work like one input field, yield one value, the value of the checked radio button.

The calculator radio buttons do generate HTML radio buttons, but with some severe limitations:

• Individual radio buttons can have a value 1 for checked, 0 for unchecked.
• Individual radio buttons can not have an own value, independent from the checked status
• There is no variable for the set of radio buttons.
• It is possible to uncheck all radio buttons using formulas.

Suggestion:

1. Change the current parameter 'name' for radio buttons to 'setid'. Yes this is different from 'name' in HTML, so be it. The concept of an 'id' is too important in the Calculator world.
2. The setid will be an id, for an automatically generated new variable type: radioset. There is no way to explicitly define a radio set. It is automatically derived from its radio buttons. The setid will be the id of the set variable. That id can be used just like for any other type. For radio buttons the setid (current name) is mandatory, so each radio button is always part of a set, which always has at least one member. This is similar to several labels for one checkbox.
3. Change the concept of value for radio buttons. Forget the current concept of a boolean for checked status. Instead, individual radio buttons have a numeric value, just like the other types. Several radio buttons within a set can have the same value, just like two other variables can share the same value. Values of radio buttons can be used in other formulas, even when the radio button is not checked.
4. The value of the set variable equals the value of the selected radio button.
5. Radio buttons can have a default value, just like other types.
6. One radio button can be the 'default' for its set, when its setDefault parameter equals 1. The radio buttons default value will make the radio buttun selected so its own default value will be the default value of the set. A set variable always has a value. If no default value is given, the first radio button is selected.
7. A (hidden) radio button can provide a (default) value of NAN until a valid set value is set.
8. The set variable can be set with a formula, just like other types. But the implementation is different, [[Polymorphism_(computer_science)|like polymorphism in Object Oriented Programming. A formula will only yield effect if that value equals the value of its radio buttons. It will check that radio button, automatically deselecting other radio buttons within the set. Such a selected radio button will update the value of the set variable, which mimics the behaviour of other variable types. It will be like an automatically generated formula at work that copies a value from one variable to another.
9. When a set formula does not match a value of any of its radio buttons, that formula value is lost. This allows value validation. It is impossible to use an unknown value for a set value.
10. Each radio button will still have a checked status, which is irrelevant to the Wikipedia editor. But the checked status is still available in HTML so CSS can use that :checked status to hide and show fields. The checked status is also available for javascript, but this is limited to personal user pages, business as usual on Wikipedia.
11. Radio buttons can have formulas too. That will always set the value of the radio button, even if not checked. Only if the radio button is currently checked, the value is copied to the set variable.
12. For the Wikipedia editor, programing set variables will be just like any other type. Its value can be used and set with formulas.

In short this will

• allow radio buttons to have numeric values which can be used in formulas
• allows value validation, invalid formula results values will be trashed, have no effect
• introduces easy use of mutually exclusive values.

It will be just too easy to implement concepts like NICE WHtR health risk levels in a Body Roundness Calculator

• show always one health level risk,
• with only 3 texts possible: 'no increased health risks', 'increased health risks' and 'further increased health risks'.
• texts shown and hidden by CSS, reacting to :checked status of hidden radio buttons, which define allowed values 0, 0.4, 0.5 and 0.6
• and one radio button defining the et variable default to 0.4 for 'no increased health risks'.

Uwappa (talk) 19:46, 24 October 2024 (UTC)

ifBetween?

How about an ifBetween function? — Preceding unsigned comment added by Uwappa (talk • contribs) 21:35, 24 October 2024 (UTC)

There is a new version of gadget that adds these. Just waiting for an iadmin to update the gadget. Bawolff (talk) 06:53, 30 October 2024 (UTC)

bug, propagation limit exceeded?

Current workaround for "is WHtR between 0.4 and 0.5" requires a lot of formulas, which might cross some propagation limit.

• OK when crossing from 0.49 to 0.5.
• OK when going from WHtR 0.48 to 0.49 (default height 178, waist up from 87 to 88), no change in WHtR versus NICE limits.
• OK when going from 0.49 down and back up to 0.49 again, same story, no cross of NICE limit
• also OK when crossing from 0.49 to 0.5. The checkbox for 'greater than 0.4' does not change value.
• NOK when going from WHtR 0.5 down to 0.49, range above 0.5 does no longer apply, triggering a sequence of formula propagation as "between 0.4 and 0.5" must be reevaluated if going below 0.5.

See Template:Body_roundness_index/sandbox#Bug:_risk_text_does_not_show_for_88

Template_talk:Body_roundness_index#Sandbox_Bug:_risk_text_does_not_show_for_88 for list of propagated formulas.

Uwappa (talk) 21:35, 24 October 2024 (UTC)

This is fixed in the newest version of the gadget. Just waiting for an iadmin to update the gadget on wikipedia. Bawolff (talk) 06:53, 30 October 2024 (UTC)

Wow, ha ha ha, those are the best bugs, which have already been solved. I will hide the hidden fields again. Uwappa (talk) 07:29, 30 October 2024 (UTC)

style= for debugging hidden fields?

The current style argument allows a CSS style specific to one element, which generates a style= parameter in HTML.

Could all types have a new argument called "class". Such a parameter will generate a class= parameter in HTML.

This can be useful for debugging, e.g. class=public for fields that should always be publicly visible class=protected for fields that developers want to see during debugging.

A developer could change the visibility of protected fields by changing the definition in the CSS file:

.protected {opacity

0.5;}

the element is visible during debugging, distinguishable from public fields

.protected {display

none;}

the normal setting, protected fields not publicly visible

Uwappa (talk) 02:59, 25 October 2024 (UTC)

This is fixed in the newest version of the gadget. Just waiting for an iadmin to update the gadget on wikipedia. Bawolff (talk) 06:53, 30 October 2024 (UTC)

The idea is similar to tr.protected in Template:Body_roundness_index/sandbox/bmi.css which applies to a whole row of protected fields, not requiring a style= parameter for one specific element. — Preceding unsigned comment added by Uwappa (talk • contribs) 02:59, 25 October 2024 (UTC)

Autofocus parameter?

Could one element have the default focus, which generates the HTML autofocus for none or just one element?

Example

Body roundness calculator

Units	Metric	Imperial
Height	160 cm	5 ft 3 in
Waist	72 cm	28 in
WHtR	0.45
BRI	2.46

:

• the cursor is automatically at waist height in cm
• In a application for medics the height and waist would have values from a database.
• The height of people does not change often, the waist is the variable than people can impact
• The reader will play with several waist sizes to find a healthy waist size
• the majority of the world uses the metric system.

The GP would just have to input one thing: current waist. That would require 2 keystrokes, about 200-300 milliseconds each, so max total time required: 0.6 seconds. Uwappa (talk) 07:39, 25 October 2024 (UTC)

Though that might work on a dedicated calculator page, if it's on a general article, that disables scrolling the page using the arrow keys, page up/down or space (which I find more efficient than the mouse).

In this particular example, the field which automatically gets focus should be first, i.e. Waist is on top. cmɢʟee⎆τaʟκ 21:01, 25 October 2024 (UTC)

Sorry, I was wrong, will update the example.

The height must be the focus, as that will be the first input. And yes, that is the first field for the exact reason you mentioned.

But after that the user will enter current waist size, play with waist sizes till the healthy waist size is found. Uwappa (talk) 02:39, 26 October 2024 (UTC)

I'm a bit nervous about allowing autofocus in a wikitext template. Autofocusing elements can often be unwanted and might have accessibility concerns. At the very least I think this would require consensus on some technical forum. Bawolff (talk) 22:02, 29 October 2024 (UTC)

OK, understand.

autofocus may also scroll the page when opened and cause conflict if multiple input fields request autofocus.

Will cancel request. Uwappa (talk) 22:11, 29 October 2024 (UTC)

And yes, a workaround, a simple deep link to a field, for example to

Body_roundness_index#calculator-field-heightfeet

• only one focus for one field possible
• different focusses possible, with different hyperlinks on different pages
• no clash with other deeplinks possible

Uwappa (talk) 17:49, 30 October 2024 (UTC)

Dynamically change numeric template parameter?

Request cancelled.

Probably possible already with current calculator after all, see User_talk:Cmglee#Dot_embedded_in_3_divs?

Uwappa (talk) 08:52, 27 October 2024 (UTC)

Prototype posted at: Template_talk:Body_roundness_index#Moving_dot_on_graphic_for_version_5.0? with:

• a silhouette iso red dot
• NICE health risk level below silhouette

Uwappa (talk) 06:24, 28 October 2024 (UTC)

This is largely not possible. However the newer version of the gadget (not yet live) does allow getting calculator values in CSS with var() which might open up new opportunities here. Bawolff (talk) 06:54, 30 October 2024 (UTC)

This has been a puzzle that is going through my mind for weeks.

And... Don't be fooled by 'moving'. It will be just like the unit input fields used to be in the BRI calculator: several available in the dom, only one showing at the time.

That would give a crazy amount of checkboxes for all positions of dots in the chart for every (x,y) combination, but I think there is a solution to that, with still many dots, but a limited number of checkboxes see:

[User_talk:Cmglee#Position_silhouette_to_cm_accuracy_by_split_to_m,_dm,_cm?]

And no not sure if this will work. It will be for a future version of BRI calculator. No worries yet, but good hopes. Cancelled request. Uwappa (talk) 07:27, 30 October 2024 (UTC)

Probably an impossible request, but still, maybe somebody else does see a solution.

Have a new field type called 'parameter', which can change the value of a numeric template parameter.

The parameter only works in templates, immediately after a '=', for example:

| x = {{calculator|id=graphHorizontal|type=parameter|default=385|formula=waist/123+4}}

The 'parameter' type is very much like a 'plain' type but:

• Generates no HTML around it, just its value
• Knows some 'magic' trick to change the value in the generated HTML, despite it can not have any 'own' HTML around its value as identificationfor javascript.

Example, a dynamic red dot on a BRI chart that moves as height or waist input changes (no, the dot below does not):

Height 178 Waist 155 BRI 13.0210

This would be based on the following wikicode: {{Superimpose | base = Body_roundness_index_graph.svg | base_width = 500px | float = Red pog.svg | float_width = 10px | x = {{calculator|id=x|type=parameter|default=385|formula=waist/12 +34}} | y = {{calculator|id=y|type=parameter|default=90|formula=height/56-7}} }} Height {{calculator|id=height|type=number|size=5|default=178|min=140|max=200}} Waist {{calculator|id=waist|type=number|size=5|default=155|min=50|max=180}} [[Body_roundness_index|BRI]] {{calculator|id=bri|default=13.0210|type=plain|decimals=4|formula=364.2-365.5×pow(1-(pow(waist/6.28318,2)/pow(0.5×height,2)),0.5)|NaN-text=Please come back after birth}}

This looks like impossible to me, but might work with:

• only in combination with SVG charts, where elements have and id equal to the id of the calculator parameter field?
• specific templates only that superimpose objects on images?

• Template:Annotated_image
• Template:Location map+
• Template:Superimpose

• all numeric parameters in all templates?

Uwappa (talk) 14:03, 25 October 2024 (UTC)

That would be ideal but I'm unsure if it's possible without reworking much of Mediawiki. For instance, use the browser's Inspector (usually F12) to inspect these popular templates. The parameter given is often buried deep in the DOM hierarchy, which would be difficult for Calculator to reach into. cmɢʟee⎆τaʟκ 21:04, 25 October 2024 (UTC)

Yes, exactly, buried deep in the DOM without any identifcation as it is just fixed text at the moment. But... for this example an update of template Superimpose would probably suffice. Uwappa (talk) 03:01, 26 October 2024 (UTC)

@Uwappa: A limited version of this should be possible now

Height 178 Waist 155

The code is a little complex, but could probably be made into a template. Bawolff (talk) 13:03, 11 November 2024 (UTC)

Wooooohaaaaa! Uwappa (talk) 14:34, 11 November 2024 (UTC)

user:Bawolff, do I understand this correctly:

1. Compute x and y in hidden variables
2. use those x and y as parameters in CSS to position the dot?

Is that all?

Where is the complex bit that needs simplification? Uwappa (talk) 14:40, 11 November 2024 (UTC)

Yes that is pretty much it. I just meant some of the html could maybe be hid behind a template. I made {{Calculator-superimpose}} for that purpose. Bawolff (talk) 14:54, 11 November 2024 (UTC)

My mind is now to busy with the usability tests for version 4.

Eager to jump on this one, but resisting the temptation.

User:Bawolff, what you can do for version 4:

• don't change the user interface, as that will f*** up the usability tests, slow me down.
• simplify the complex stuff under the hood using new calc field types
• that will give me an example of working code
• update the calc documentation. Provide examples of code and result
• Go and ask medics: what about below 0.4 WHtR? Where is the danger zone at the low end of the WHtR scale? Where is Anorexia_nervosa. Where is Emaciated? What is lowest WHtR of living human? WHtR 0 is dead for sure, ashes to ahses, but where is the border between life and death, the skinny counterpart of morbid obesity, morbid skinny?

What you can do, preparing version 5:, with the moving dot

1. Use chart that shows both WHtR and BRI, with WHtR colours. Ask user:Cmglee to cooperate
2. draw a horizontal thin, semi transparent line at current height of dot, easy to see where it hits green WHtR values
3. Make height a vertical slider along the y-axes
4. Make waist a horizontal slider along the x-axes

Feel welcome to use Template:WaistHeightRatio_to_BodyRoundnessIndex_converter

It will be just too deadly... Uwappa (talk) 15:55, 11 November 2024 (UTC)

Use template multiple times

Body roundness calculator

Units	Metric	Imperial
Height	160 cm	5 ft 3 in
Waist	72 cm	28 in
WHtR	0.45
BRI	2.46

Body roundness calculator

Units	Metric	Imperial
Height	160 cm	5 ft 3 in
Waist	72 cm	28 in
WHtR	0.45
BRI	2.46

The current documentation claims: "You can use this template multiple times on a page to make input widgets, with some of the widgets having formulas based on other widgets, like a spreadsheet."

If widgets of several calculators share a common id, only the last widget works, which due to a flow right, may seem the first one.

I am not sure what the solution should be. Uwappa (talk) 03:42, 26 October 2024 (UTC)

The doc just means you can use the {{Calculator}} template multiple times (with different ids), not that you can repeat ids.

If the template was entirely made with lua, i guess you could try and generate a random number and append it to all calculator ids within the template. If this really becomes an issue, the gadget could maybe be changed to look for some container div, and scope the calculator widgets within the container, so that separate templates don't interfere with each other. Bawolff (talk) 21:57, 29 October 2024 (UTC)

Not an issue for now. I came across it on pages that had these two during development:

Please select in your preferences: Enables javascript Calculator template to see a working calculator.

WHtR to BRI converter

pi = π	3.141592653589793
${\text{BRI}}=364.2-365.5{\sqrt {1-{\Big (}{\frac {\text{waist}}{\;\;\pi \;\;\times \;\,{\text{height}}}}{\Big )}^{2}}}$	3.3588109427631707
${\text{WHtR}}={\frac {\text{waist}}{\text{height}}}$	0.5
Waist	80
Waist diameter = Waist / pi	25.464790894703256
Height	160

Please select in your preferences: Enables javascript Calculator template to see a working calculator.

1805118131.890
Body Roundness Calculator 100Body roundness Calculator 5.0Body roundness Calculator 5.0AI?AI?StructureStructure
Dimensions	Height	Waist
	180 +10 190cm≈6′3″ +3  183cm≈6′0″ +2  182cm≈5′12″ +1  181cm≈5′11″ 180cm≈5′11″ -1  179cm≈5′10″ -2  178cm≈5′10″ -3  177cm≈5′10″ -10 170cm≈5′7″	81 +50 131cm≈51.575″ +40 121cm≈47.638″ +30 111cm≈43.701″ +20 101cm≈39.764″ +10 91cm≈35.827″ +5 86cm≈33.858″ +4 85cm≈33.465″ +3 84cm≈33.071″ +2 83cm≈32.677″ +1 82cm≈32.283″ 81cm≈31.890″ -1  80cm≈31.496″ -2  79cm≈31.102″ -3  78cm≈30.709″ -4  77cm≈30.315″ -5  76cm≈29.921″ -10 71cm≈27.953″
Roundness	0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0
Waist-to-height ratio (WHtR)	81/180 ≈= 0.450.45 ≈ 0.45 WHtR Waist for height 180cm, 5′11″ 1.00 1.00 180cm≈70.866″ 0.900.90 162cm≈63.780″ 0.800.80 144cm≈56.693″ 0.700.70 126cm≈49.606″ 0.600.60 108cm≈42.520″ 0.500.50 90cm≈35.433″ 0.450.45 81cm≈31.890″ 0.400.40 72cm≈28.346″ 0.300.30 54cm≈21.260″
rounded bounded silhouette index, hidden	5
silhouette index, hidden	5.876404494382022
hidden	<0.4 >=0.4	>=0.5	>=0.6
hidden	0.4 01	0.4494 0| 0.4494 0 7290108
Health risks	0 0.6 ≤ WHtR0.6 ≤ 99: further increased health risks 0 0.5 ≤ 99 < 0.60.5 ≤ WHtR < 0.6: increased health risks 1 0.4 ≤ WHtR < 0.50.4 ≤ 0.45 < 0.5: no increased health risks 0 WHTR < 0.499 < 0.4: Unspecified

• Template:WaistHeightRatio_to_BodyRoundnessIndex_converter
• Template:Body_roundness_index/sandbox

It can be a feature too, 2 calculators sharing fields.

I'll cancel the question. Uwappa (talk) 22:08, 29 October 2024 (UTC)

I implemented a scoping thing in the newest version of gadget (not yet live). If you put all the calculator widgets inside a div with class calculator-container, then they will be compartmentalized to that div. Bawolff (talk) 06:55, 30 October 2024 (UTC)

Great, that should be in the documentation for everybody to know! Uwappa (talk) 07:17, 30 October 2024 (UTC)

I'm just waiting on an IAdmin to update the gadget. I don't want to confuse people with info on stuff that isn't live yet, and sometimes there can be a bit of a delay for editprotected requests to gadgets to be processed. Bawolff (talk) 20:42, 30 October 2024 (UTC)

No worries, current live version does not have the problem.

And the sandbox version will take some more time to mature.

Did you see the sweet autofocus workaround? Uwappa (talk) 20:48, 30 October 2024 (UTC)

Can the result of a calculation be automatically used as input of another calculation?

'some of the widgets having formulas based on other widgets, like a spreadsheet' suggests that the result of a calculation can be used as input of an other calculation without manual copying. How can this be done? - Patrick (talk) 23:57, 15 January 2025 (UTC)

It should just work. If a widget has both an id and a formula, then that id can be used in other formulas.

The only gotchas is that formulas are only recalculated after first user interaction (so you still need to provide a default value), and formula loops are not allowed Bawolff (talk) 05:15, 16 January 2025 (UTC)

Can you give an example? I tried

{{calculator|id=a|default=2|size=14}} +1 = {{calculator|id=b|formula=a+1|default=3|type=plain}}

{{calculator|id=b|default=2|size=14}} +1 = {{calculator|id=c|formula=b+1|default=3|type=plain}}

(see User:Patrick/calculation)

but that does not seem to work. - Patrick (talk) 06:47, 16 January 2025 (UTC)

you need each field to have a unique id. I'm not clear on what you are trying to do here - do you want the second b to always be updated from the first calculation but not editable by the user? Do you want the b field to update anytime someone edits a, but also allow user to change b to something else if they feel like it (without affecting a)? Do you want either b or a to be updatable and for them to adjust each other based on the value of the other? All of these should be possible but require different syntax.

If you just want b to update and not be user editable you can do the following:

{{calculator|id=a|default=2|size=14}} +1 = {{calculator|id=b|formula=a+1|default=3|type=plain}}

{{calculator|formula=b|readonly=1|default=3|size=14}} +1 = {{calculator|id=c|formula=b+1|default=4|type=plain}}

To make:

2 +1 = 3

3 +1 = 4

If you want editing a to adjust b, but b to still be adjustable by the reader, you can do something like:

{{calculator|id=a|default=2|size=14}} +1 = {{calculator|id=b|formula=a+1|default=3|type=plain}}

{{calculator|id=b2|formula=b|default=3|size=14}} +1 = {{calculator|id=c|formula=b2+1|default=4|type=plain}}

To make:

2 +1 = 3

3 +1 = 4

If you want editing a to adjust b and editing b to adjust a, you can do something like

{{calculator|id=a|formula=b-1|default=2|size=14}} +1 = {{calculator|formula=a+1|default=3|type=plain}}

{{calculator|formula=a+1|id=b|default=3|size=14}} +1 = {{calculator|id=c|formula=b+1|default=4|type=plain}}

To make:

2 +1 = 3

3 +1 = 4

Bawolff (talk) 07:17, 16 January 2025 (UTC)

Thank you very much. My intention was the first option ('like a spreadsheet'), but the other two are also interesting. - Patrick (talk) 08:31, 16 January 2025 (UTC)

Decimal comma

Result of a usability test:

• Knowledgable, high IQ, paramedic tried to enter 4,5 as WHtR value, with a decimal comma. Goal: Have optimal waist computed by calculator, the question to be answered. The smartphone did not allow it, usability test aborted, failure to reach goal.
• Managed to avoid a 'rapid dental rearrangement', paramedic refused to measure waist as that would be a waste of time, not relevant. To know the optimal healthy waist, the input of a height and WHtR 4,5 should suffice. Eh... That paramedic nailed it... The idea of using a decimal dot did not occur, as a dot is a thousands-separator in the local way of formatting numbers.
• type=number field did not show spin buttons as expected by mobile simulation for Wikipedians. So, paramedic could not use spin buttons to step up/down with steps of 0.025.
• for type=number there was a numeric keyboard on bottom part of display, no cursor up down buttons to step up/down WHtR values.

I am not sure how to solve this.

1. It is probably something specific to the browser on the smartphone and depending on language settings. Other smartphones may show spin buttons
2. Other language settings may allow a decimal comma, don't know much about smartphones myself. Stubbornly refuse to have one.
3. I am not sure what would have happened when hitting a cursor-up or cursor-down field. Those keys did not exist on the shown numerical keyboard.
4. I've asked smartphone users how they normally enter numbers with decimals on other websites. No one has been able to give me an answer yet, inputting numbers with decimals seems very exceptional.
5. Use a text field? Hmm, that take away the nice spin buttons? And... that allows a comma, but the values seems a NaN for numbers, just to add to the confusion.
6. Create a tailored solution with JavaScript? Hmm, that might work, but will create a learning curve, something new to learn for this application only, which will be confusing as it will be specifically work on this application only, cause confusion, create more trouble than it tries to solve.

I myself refuse to own a smartphone, find the user interface utterly repulsive, a flawed design.

1. It is madness to waist half the precious screen real estate showing a keyboard
2. It is madness to throw away the excellent touch of human fingers. A good physical keyboard provides tactile feedback to the finger tips, confirming a speed typist that a key has been pressed successfully, no need to look at the screen, touch suffices, allowing extremely fast Touch_typing.
3. It is madness to have the fingers blocking the view to the screen. You can't even see what you're doing. Great... no visual feedback either. You have to remove your finger to see if the keypress succeeded.
4. There was no audio feedbaci for a successful key press. What a mess. Smartphones were meant for 'consuming', browsing, not for serious work, input values.

I do have a solution in mind, which is a redesign of smartphone hardware

1. put the Touchpad at the BACK of the damned thing.
2. Use the strong thumb, ring finger, pink, to hold the damn thing. Have 2 excellent fingers, index and middle finger available for moving the mouse with high precision.
3. One hand will suffice, other hand can be used to do other things
4. It will allow the comeback of the mouse pointer, just like on a laptop with a touchpad. Move the mouse while looking at the screen, nobody looks at the touchpad, so why not have it at the back?
5. Moving the mouse pointer will allow the comeback of tooltips, a great way and fast way to explore things, e.g. learn: "What does WHtR stand for"?
6. a screen hit can be a click, where it now is a silly jump of the cursor

This is not going to happen before December or any time soon. Uwappa (talk) 22:53, 6 November 2024 (UTC)

Lost values after back from sidestep to WHtR

Result of usability test:

1. test subject did not know WHtR, clicked on WHtR Field prompt using smartphone. No alternative available as tooltips on mouseover do not exist in the mobile world.
2. quickly understood the WHtR concept, o just a simple ratio, just from scanning the lede text
3. went back to calculator and continued input of value for WHtR, not realizing that the height input was trashed as it 'refreshed' to default value.

I am not sure this is a calculator problem, might be a generic flow of smartphone browser, don't know. Uwappa (talk) 23:02, 6 November 2024 (UTC)

Step at a time displays

In case anyone is interested, here are some experiments with trying step at a time instruction (Based on suggestions from Dimitri131 and Cmglee):

• User:Bawolff/euclidean
• User:Bawolff/math_steps

A major issue right now is that abusing <label> as a button is not accessible, but that can probably be fixed in the next version of the gadget. I'd be curious if anyone has any ideas for other places where such an approach would be useful. Bawolff (talk) 16:24, 12 November 2024 (UTC)

I also experimented with making a demo of Bubble sort at User:Bawolff/bubble Bawolff (talk) 19:14, 21 November 2024 (UTC)

Sorry, but bad news: The step by step disclosure slows down. I do not like it at all.

• It requires clicks to go to the next step, with each step requiring a circle of:

observe, interpret, learn, think, act,

observe, interpret, learn, ...

• The slowest parts will be the "act" steps, action of hands, moving and clicks.
• It burdens short term memory. What was I seeing before this click? What has changed?
• There is no option to go back to a previous step.
• It is slow Sequential_access, like a Cassette_tape

Alternative:

Let the eyes do the work, just like steps 1, 2, 3 in at Body_roundness_index#Calculation

1. No clicks, no hand action required, the quick eyes can do all the work
2. No burden of short term memory
3. easy to look back at previous step.
4. Fast Random access possible, e.g. immediately go to step 3.

An Eye fixation requires 233 milliseconds, interpretation, learning and thinking are lightning fast (close to zero milliseconds), no hand action required (so zero milliseconds). So looking at three steps will be less than 1 second. Uwappa (talk) 06:48, 5 December 2024 (UTC)

Unclear error message

First: Holy shit this is based. 11/10, would calculate again.

Second: User:Closed_Limelike_Curves/sandbox/calculator#Stationary_examples isn't working. Checking the JS gives the very obscure error message "Expected term". Any idea what's up? – Closed Limelike Curves (talk) 20:14, 4 December 2024 (UTC)

I have no idea what I did, but it mostly works now. – Closed Limelike Curves (talk) 00:49, 6 December 2024 (UTC)

The only issue I have left is that the defaults are broken—they don't "propagate". So if I write:

{{calculator|id=a|default=2|size=2}} * {{calculator|id=b|default=2|size=2}} = {{calculator|type=plain|formula=a*b|size=2}}

the right-hand side doesn't appear until the user updates a or b:

2 * 2 =

Any way to fix this @Doc James? – Closed Limelike Curves (talk) 01:05, 6 December 2024 (UTC)

Will check to see if Brian can add this functionality. Doc James (talk · contribs · email) 03:14, 6 December 2024 (UTC)

The "expected term" error means that the formula was invalid in some way - e.g. a missing parenthesis or something like that. (The phrase "term" here comes from the somewhat obscure thirteenth definition from wikt:term). I agree its a pretty bad error message.

The original idea was that the right hand side would also have a default. This allows for a fallback if javascript is disabled. So for example, you can write {{calculator|id=a|default=2|size=2}} * {{calculator|id=b|default=2|size=2}} = {{calculator|type=plain|formula=a*b|size=2|default=4}}. Alternatively you can use {{calculator ifenabled}} which allows you to set alternative text for non-js users/printing, and will make defaults propogate, e.g. {{calculator ifenabled|refreshonload=true|enabled={{calculator|id=a|default=2|size=2}} * {{calculator|id=b|default=2|size=2}} = {{calculator|type=plain|formula=a*b|size=2}}|disabled=text to show if js disabled}} makes

2 * 2 =

text to show if js disabled

Bawolff (talk) 03:33, 6 December 2024 (UTC)

Hmm, seems not to work with tables—see User:Closed Limelike Curves/sandbox/calculator. – Closed Limelike Curves (talk) 22:02, 6 December 2024 (UTC)

@Closed Limelike Curves Hmm, i think that is something more general to do with tables in template parameters. It seems easiest just to substitute the template and use a <div> directly. I made an edit to your sandbox to show you what i mean [1] Bawolff (talk) 22:59, 6 December 2024 (UTC)

Oh my gosh this is perfect, thank you so much! – Closed Limelike Curves (talk) 02:11, 8 December 2024 (UTC)

passthru example?

Is there really an example of passthru in Template:Calculator-hideifzero? I can not find it. Uwappa (talk) 12:04, 7 December 2024 (UTC)

The template is an example of passthru, in that it creates a passthru widget. The code of the template has data-calculator-type="passthru" in it. Bawolff (talk) 16:37, 8 December 2024 (UTC)

Minor feature requests

I'll use this for minor/mild feature requests: ones I'd like to have, but I can live without.

1. Log scales! On highest averages method#stationary calculator, it would be super useful if the step size could multiply the value by a fixed percentage (e.g. 10%) instead of incrementing by a fixed quantity.
2. Rank inputs—ability to order outcomes from best to worst. (For some voting rule demonstrations.)

– Closed Limelike Curves (talk) 16:46, 22 December 2024 (UTC)

For 1 - I assume you mean the step size of the arrows in the widget when using a number type input. For those we use the web browser's native implementation, so we don't have a lot of control over it. HTML5 does not support logrithmic stepping [2] so we can't do much there. It is possible to make your own button using {{calculator button}} that increase by a percentage but it would probably be hard to make that look as good. e.g. 123 ↑↓ (This is somewhat of a bad attempt, its probably possible to do better, with more effort)

For 2 - its sort of possible right now if you have a fixed number of candidates, just very convoluted. e.g. You can do a bunch of nested ifgreater() formulas, and rearrange things with CSS order property if using grid or flexbox layout. (an example would be {{Bubble sort demo}}) but it is really not very pleasant. My understanding is what is desired here is to have a bunch of rows in a table that dynamically change order based on calculator things. Sounds like an intersting thing to think about for the future. Bawolff (talk) 01:27, 3 January 2025 (UTC)

Its kind of hard to keep track of which feature ideas are open, so i created a specific page for that Template talk:Calculator/feature requests and added the table thing. Bawolff (talk) 01:55, 3 January 2025 (UTC)

Bitwise binary operations?

It might be helpful to add a calculator to the BIT predicate article, where the relevant formula (in C/C++/Java/Python syntax) is (i>>j)&1. However, these operations do not appear to be available in the calculator, and even if they were available there are issues with interference between the operator symbols and Wikitable syntax (especially also for the vertical bar bitwise-or operator). Any ideas? Hacking something together using division by pow(2,j) instead of right-shift and mod 2 instead of & 1 appears likely to be numerically unstable and error-prone, and wouldn't generalize to other formulas needing bitwise binary operations. —David Eppstein (talk) 02:00, 17 January 2025 (UTC)

Sounds like a reasonable thing to add. I'll add it to the next version. I didn't add them originally as it didn't seem like something that was needed, but that sounds like a reasonable use case. I think its best to give them function names instead of using the c-like operator syntax. As far as numerical stability goes, keep in mind that the underlying type is still going to be a double, so it will act a little different than a 64 bit int for numbers > 2⁵³-1.Bawolff (talk) 04:45, 17 January 2025 (UTC)

As an addendum, I'm planning to add it to the next version using javascript's definition of these functions (bitwise AND, NOT, XOR, OR, left shift, right logical shift, right arithmetic shift, and clz [number of leading 0 bits]). JS defines them as working on 32 bit integers, will that be sufficient for your purposes? Bawolff (talk) 15:38, 25 January 2025 (UTC)

Probably. —David Eppstein (talk) 17:19, 25 January 2025 (UTC)

 Done (i still need to update the docs, but there are now functions like 'bitand', 'bitor', 'bitxor', 'bitnot', 'bitleftshift', 'bitlogicrightshift', 'bitarithrightshift'. Bawolff (talk) 21:50, 27 January 2025 (UTC)

And i think i just realized that i mixed up arithmetic and logical shift. Bawolff (talk) 01:13, 28 January 2025 (UTC)

Which is fixed now Bawolff (talk) 13:01, 29 January 2025 (UTC)

Dividing and then dividing

For some reason

X/2/5/3

seems to give a different answer than

X/(2*5*3)

120	X
	X/2/5/3
	X/(2*5*3)

The second one is correct. The first seems to be multiplying by 5 instead of dividing. Wizmut (talk) 15:26, 17 January 2025 (UTC)

oh, that is an embarassing bug. It looks like the associativity is wrong. I.e. it is going from right-to left and interpreting 120/2/5/3 as 120/(2/(5/3)) which is incorrect. I'll fix in next version. Bawolff (talk) 21:40, 17 January 2025 (UTC)

Data table that switches units

I have made this as a proof of concept, based on the table currently at List of South American countries by area. As far as actually using it in list articles, I would be a little concerned about maintainability, because a lot of the lists have different sources for each row and require updates from lots of different users, who might be put off by all the markup. But it's pretty slick and looks better on small screens.

1 Metric
0 Imperial

Location	% total	Area km2mi2
South America	100%	17,830,1996,884,275
Brazil	48%	8,510,3463,285,862
Argentina	16%	2,796,4271,079,706
Peru	7%	1,285,216496,224
Colombia	6%	1,141,748440,831
Bolivia	6%	1,098,581424,164
Venezuela	5%	929,690358,955
Chile	4%	756,102291,932
Paraguay	2%	406,752157,048
Ecuador	1%	257,21599,311
Guyana	1%	214,96983,000
Uruguay	1%	173,62667,037
Suriname	0.9%	163,82063,251
French Guiana (France)	0.5%	83,53432,253
Falkland Islands (UK)	0.1%	12,1734,700

Wizmut (talk) 10:40, 20 January 2025 (UTC)

Hm it seems to break with all the other templates on this page, but does work in a sandbox. Wizmut (talk) 11:00, 20 January 2025 (UTC)

The page hit a max number of calculators limit. Putting it inside 'calculator-container' div fixed it. Bawolff (talk) 11:14, 20 January 2025 (UTC)

Better arithmetic

This really needs to use arbitrary precision - sure, floating point can give reasonable results in some cases, but pretty much every online calculator these days uses arbitrary precision (e.g., the ones in Google, Bing, OmniCalculator, etc.). Playing around with the Kelvin page, I had to significantly round the results to avoid issues like 100001 K corresponding to 180001.80000000002 °Ra. It is worth considering a full symbolic math library, but I could not find a reasonable equivalent of SymPy in JavaScript. However, there are many arbitrary-precision JavaScript libraries - c.f. comparison. From looking I would say Decimal.js (directly or as wrapped by math.js) would be most suitable. These libraries are not as good as SymPy where one can specify the precision of the result and the calculations automatically increase precision accordingly, but setting the working precision to 100 digits or so is probably more than sufficient for anybody's needs, and I think compiling SymPy to WASM would be overkill. Mathnerd314159 (talk) 17:52, 20 January 2025 (UTC)

While I understand how this might be useful, that also adds a lot of extra code, so probably not something I'm going to add support for, at least not right now. Perhaps we could revisit it once things have settled down a bit and it becomes more clear how important something like decimal.js would be. Bawolff (talk) 13:11, 21 January 2025 (UTC)

Lua implementation?

A lua implementation of the calculator template would be good to have so that modules can avoid using frame:preprocess on a set of {{calculator}} instances.

If this is created, the sub-templates can then be defined in terms of the module, which is likely more maintainable than the wikimarkup which has become quite hard to read in some cases (eg. Calculator-hideifzero). – SD0001 (talk) 18:08, 20 January 2025 (UTC)

I agree, this sounds like a good idea. Bawolff (talk) 13:05, 21 January 2025 (UTC)

I have made a start on this at Module:Sandbox/SD0001/Calculator. Sample uses in Module:Sandbox/SD0001/Tabbed window and Module:Sandbox/SD0001/Chess3. Feel free to move it to Module:Calculator if the design looks alright to you. – SD0001 (talk) 17:38, 29 January 2025 (UTC)

Looks good to me. As far as the design of it goes, I think its easier to see what is a good design after it gets some use, but so far looks good to me. Bawolff (talk) 20:50, 30 January 2025 (UTC)

Boolean value of radio buttons doesn't always match their selection state

Maybe this is a duplicate of this request, but I think this is a simpler issue. Visually, only one radio button in a set can be selected at a time; however, there are situations in which multiple buttons in a set can have the value TRUE. For example:

1 any
0 P

Entering a value in the number field sets the second radio button to TRUE, but this does not cause the first radio button to become FALSE, even though it is deselected. To make the first botton go FALSE requires giving it a formula (e.g. the NOT of the second button). This does not align with my (possibly naive) expectation that only one button in a named set may be TRUE, and any time one becomes TRUE, all others become FALSE. —swpb^{T • beyond • mutual} 16:12, 24 January 2025 (UTC)

Previously we mostly had radio buttons in the other direction (i.e. they trigger other fields, not other fields triggering them), so this was a bit of an oversight. I plan to improve radio buttons in the next version to fix this. They're also be able to have a specific value (If a formula sets them they will have that value, but if a human sets the button, then it will have its defined value), as well as a way to get the value of the radio group as a whole. Bawolff (talk) 15:34, 25 January 2025 (UTC)

 Done Bawolff (talk) 21:48, 27 January 2025 (UTC)

Thanks! —swpb^{T • beyond • mutual} 20:27, 28 January 2025 (UTC)

No support for unary - ?

a: 1

-a: -1

-1*a: -1

a*-1: -1

Negating through unary - appears to not work. Is this intended? Based5290 :3 (talk) 19:50, 24 January 2025 (UTC)

This will be added in the next version. Bawolff (talk) 08:51, 25 January 2025 (UTC)

 Done Bawolff (talk) 21:48, 27 January 2025 (UTC)

hideIfZero or showOnlyIf?

Moved from Template talk:Calculator-hideifzero § hideIfZero or showOnlyIf?

 – – SD0001 (talk) 04:17, 31 January 2025 (UTC)

Suggestion: Rename hideIfZero to showOnlyIf

It will make the code easier to understand, get rid of avoid the mental effort to negate the negative.

Recode the current hideIfZero statements while there are not many around yet. Uwappa (talk) 04:56, 17 December 2024 (UTC)

Hmm. I have no strong opinions on the name. I suppose if we leave a redirect behind we could have both. ShowIfTrue might be another choice. Bawolff (talk) 12:56, 31 January 2025 (UTC)

Decimals parameter for number fields?

Is displaying number entry fields to a certain amount of decimal places possible? You can force them to only display a certain amount of decimal places by rounding it, but that also changes the actual value of the field and messes with any further calculations:

a = = 1/b (rounded to 1 decimal place)

b = = 1/a (rounded)

a*b = (rounded)

If a is set to 3, then b is set to 0.3 and a*b=0.9 even though b=1/a so a*b should equal 1. What I'd like to be able to do is have b actually equal 0.3333333 etc. while still displaying it as 0.3 in the field so the extra decimal places don't get ugly. Benp02007 (talk) 02:56, 2 February 2025 (UTC)

This will be added in next version Bawolff (talk) 04:56, 8 February 2025 (UTC)

@Benp02007  Done. You should now be able to use the decimals parameter Bawolff (talk) 08:27, 8 February 2025 (UTC)

e.g.

a = = 1/b (rounded to 1 decimal place)

b = = 1/a (rounded)

a*b = (rounded)