Template talk:Calculator
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 (I used ifless and ifgreater). 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:
- 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.
- 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.
- 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.
- The value of the set variable equals the value of the selected radio button.
- Radio buttons can have a default value, just like other types.
- 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.
- A (hidden) radio button can provide a (default) value of NAN until a valid set value is set.
- 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.
- 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.
- 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.
- 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.
- 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)
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)
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)
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
- the cursor is automatically at
waistheight 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)
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)
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?
- 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)
Use template multiple times
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:
- It can be a feature too, 2 calculators sharing fields.
- I'll cancel the question. Uwappa (talk) 22:08, 29 October 2024 (UTC)
