I am curious why #8589 Add a real/integer number ‘format’ attribute to EditTextWidget is flagged as a new feature but #4230 Add min, max, step, value attribute for numbers to the EditTextWidget is closed and marked as “not planned” when the two feature requests are similar in nature and ostensibly the latter is easier to implement.
See this comment [IDEA] add a 'format' attribute to EditTextWidget (and maybe others) · Issue #8589 · TiddlyWiki/TiddlyWiki5 · GitHub – Which contains the description of something we do not have at the moment. So it is a “newfeature”
The label “newfeature” means it describes something new. It does not say it will be implemented that way. It’s an idea / a feature request atm.
If would need an “actionable” flag, to be considered to be a request for a PR.
The linked comment basically rejects the OP. Add HTML5 attributes support to the EditText widget · Issue #4230 · TiddlyWiki/TiddlyWiki5 · GitHub
The input element has 22 or more different usecases, which are significantly different. We do not want them to be configured in one “monster” widget.
We currently have different widgets, that should do 1 thing well. That’s much easier to understand, use and maintain that way.
Respectfully, the reason why I am asking about the closing of feature request #4230 is because there is barely any support for the displaying, formatting and data entry of numbers in TW.
To me, this is rather shocking that I have to develop my own TW widgets just to be able to format a number as a currency, or format it with 5 significant decimal places, or to limit the modifying of a number field so it only fall within the range of 1 and 100. Shouldn’t these really basic functionality be part of the TW5 core?
Yes, it should … But - The main problem with numbers is “precision”.
As a user I expect that calculations, especially with currencies are precise up to the n-th decimal.
eg: 0.1 + 0.2 = 0.3
If you calculate this in the JS console you get 0.30000000000000004 – Surprise, surprise - …
That’s because the number encoding format format, which is used in JS. It has problems to calculate fractional values.
I think that’s a problem. IMO even if we “visualise” numbers up to the n-th decimal point, internally we would need to calculate with the maximum precision. Only formatting / show the numbers with “n” decimals. So there is a difference between formatting and calculating.
For additions and subtractions, we probably could handle this with a naive math library. But as soon as we start to add divisions into the mix we may end up “adding” rounding errors.
So if users would start to “print bills”, we would get complaints about rounding errors. TW is no spreadsheet app. But that’s what will be expected.
So every 5$ calculator can do math better than standard JS can, because they where developed for exactly that reason. eg: A scientific calculator (from Sharp) may be good in converting numbers into different formats. Binary, Octal, Hex and Decimal … but it may be weak in calculating mortgage rates, where HPs really shine. … Depending on the use-case.
As a user, I personally would expect TW to be good for both examples and as a bonus I would like to be able to convert cm to inches and vice versa … Or even more basic what 1.000 means for a German user.
To be good for all use-cases we probably would need to include a math library which would account for an other 700kByte of core size. – But does every user need it?
Sadly, if users need to “configure” their own “math” they know the usecase and will optimise it. … At least they are aware of the problems – and as sad as it is. It is not our fault, if something is wrong.
Just some thoughts
-m
Agreed, and I think there are some relatively simple changes that we could do to fix a lot of this.
I think this would be a fairly easy extension of the format operator. Since in 5.4.0 we’re no longer limited to ancient versions of JS, we could use Intl.NumberFormat to offer formatting of numbers in a great variety of formats, including all major currency schemes. There is some complexity in the second parameter to the NumberFormat constructor, and I don’t see a better option than allowing a JSON string for it, but someone might be able to offer a better alternative.
This could be handled with an optional parameter to the round operator , a precision that defaults to 0, and has the simple implementation of replacing the current round operator in $:/core/modules/filters/math.js with something like this:
exports.round = function(source,operator,options) {
var result = [],
precision = $tw.utils.parseNumber(operator.operand) || 0;
source(function(tiddler,title) {
result.push($tw.utils.stringifyNumber(Math.round(10 ** precision * $tw.utils.parseNumber(title)) / 10 ** precision));
});
return result;
};
This is not perfect of course, but would likely be enough for most financial or scientific uses. For instance
[[3.141592653589793]round[0]]: 3
[[3.141592653589793]round[1]]: 3.1
[[3.141592653589793]round[2]]: 3.14
[[3.141592653589793]round[3]]: 3.142
[[3.141592653589793]round[4]]: 3.1416
[[3.141592653589793]round[5]]: 3.14159
[[3.141592653589793]round[6]]: 3.141593
[[3.141592653589793]round[7]]: 3.1415927
[[3.141592653589793]round[8]]: 3.14159265
[[3.141592653589793]round[9]]: 3.141592654
[[3.141592653589793]round[10]]: 3.1415926536
and to @pmario’s point, most IEEE 754 rounding errors won’t show with reasonable precision values:
[[0.1]add[0.2]round[]]: 0
[[0.1]add[0.2]round[1]]: 0.3
[[0.1]add[0.2]round[2]]: 0.3
[[0.1]add[0.2]round[3]]: 0.3
[[0.1]add[0.2]round[4]]: 0.3
[[0.1]add[0.2]round[5]]: 0.3
[[0.1]add[0.2]round[6]]: 0.3
[[0.1]add[0.2]round[7]]: 0.3
[[0.1]add[0.2]round[8]]: 0.3
[[0.1]add[0.2]round[9]]: 0.3
[[0.1]add[0.2]round[10]]: 0.3
[[0.1]add[0.2]round[11]]: 0.3
[[0.1]add[0.2]round[12]]: 0.3
[[0.1]add[0.2]round[13]]: 0.3
[[0.1]add[0.2]round[14]]: 0.3
[[0.1]add[0.2]round[15]]: 0.3
[[0.1]add[0.2]round[16]]: 0.3000000000000001
[[0.1]add[0.2]round[17]]: 0.30000000000000004
[[0.1]add[0.2]round[18]]: 0.30000000000000004
[[0.1]add[0.2]round[19]]: 0.30000000000000004
[[0.1]add[0.2]round[20]]: 0.30000000000000004
The EditTextWidget already had a huge number of attributes; I don’t think adding min, max, and step would be unreasonable. I don’t know the core team’s notion of allowing unknown attributes to simply pass through from the widget to the DOM node, but this widget seems like a good candidate for that. Alternatively, we could easily add a dedicated EditNumberWidget.
I think the three suggestions above would go a long way to making it easier to deal with numbers. I really doubt any but a tiny number of users would need complex numbers, an expression parser, or symbolic computations.
That strikes me as something more likely to belong in a plugin, but I could easily see an official plugin that offered a great number of useful conversion constants and a few conversion operators/functions:
[[12]convert:length:in:cm[]] <!-- yields `30.48` -->
[5]convert:area:km^2:ac[]] <!-- yields `1235.5269073358` -->
I assume forms on German websites use entry fields designed for the German number style, but I don’t know how to accomplish that. I don’t see anything in <input type="number"> to handle that. How is it accomplished currently? Or do numeric input boxes simply use the current locale for that?
2 Likes
As @Scott_Sauyet already demonstrated in his reply above, your concerns about exposing the inaccuracy of javascript numbers has already existed in TW for a long time via the filter operators that do math operations.
That said, this javascript precision issue is inherent in the ECMAScript 2025 standard used by all modern web browsers. It is not just TW that has this issue. It is every single website and web application. I do not believe it is the onus of TW to solve this math precision issue.
Me! Me! Over here! Me! Me!
“And the prize goes to Stephen Teacher. Don Pardo, please tell him what he’s won.”
"That’s right Alex, Stephen is our big winner tonight! Stephen, look over here behind the curtain; you won the Riemann Zeta Vacuum!. Built with a sturdy Gamma Function motor, this will clean your numbers for a lifetime.
"You also win a lifetime of new novels from Fermat’s Last Fiction. Every month you will receive a book with the investigations of Inspector Euler, the swashbuckling adventures of Isaac New Tonne, the political intrigue that Madame Curious gets into, and so many more.
"And that’s not all! You’ll also receive Albert Einstein’s Book of Siblings, Grandparents and Second Cousins: Relativity for the Rest of Us. And there’s more! You’ll receive a copy of the Fine Man Admonitions, Hawking’s Guide to Raptors, and a one-year membership in frozen food delivery from Cold Fusion!
“And of course, you also get your very own TW math plugin… some assembly required!”
I know there are likely to be users of each of these tools. I’ve used complex numbers and matrix multiplication once in a wiki, but they were easy enough to implement that I didn’t seek out a big tool for them. Although I now work as a programmer, my degrees are in mathematics, so math is near and dear to my heart, but I still think that most of this belongs in a shared plugin, if even that.
re: Add HTML5 attributes support to the EditText widget · Issue #4230 · TiddlyWiki/TiddlyWiki5 · GitHub
Although I don’t fully agree with the decision to reject this addition to the $edit-text widget parameters, I do understand the underlying intent to avoid adding yet more complexity to an already overly complex widget implementation.
Nonetheless, the desire for the abiility to render a “numeric range text input control” still persists even more than six years after the issue was originally posted on GitHub. So, I’d like to suggest an alternative change that is considerably less complex and perhaps more likely to be accepted…
The $range widget currently provides the ability to set a tiddler field or index to a numeric value with a specified min, max, and increment, defaulting to min=1, max=100, increment=1.
In the TWCore $:/core/modules/widgets/range.js code, the RangeWidget.prototype.render() method “hard codes” the DOM element’s type attribute to “range”:
this.inputDomNode.setAttribute("type","range");
If this attribute could be optionally set to “number”, this would permit rendering of a numeric range text input control. To achieve this, it only requires two simple changes:
-
In
RangeWidget.prototype.render(), change the aforementioned line to:
this.inputDomNode.setAttribute("type",this.type); -
In
RangeWidget.prototype.execute(), add the following line:
this.type = this.getAttribute("type","range");
Once these two changes are applied, this will permit people to write:
<$range type="number" field="..." min="..." max="..." increment="..."/>
Note that the change to the widget code will not affect any existing uses of <$range ...> since it defaults to type="range" when the parameter is not specified. In addition, if this wikitext is used in an older TiddlyWiki, the type="number" parameter is simply ignored and the rendered control will degrade gracefully to display a slider as before.
Thoughts?
-e
1 Like
I love the simplicity of this change, but I’m a big fan of tools that do one job only and do it well, so I’d prefer a NumberWidget or EditNumberWidget. Because they would be so similar, perhaps both this one and RangeWidget could be factored to use a common implementation that receives the type separately.
The main objection to combining them is that a range element is not designed for precision, but to give the user the easy ability to choose an approximate point on a range. The endpoints are essential, and a default step is chosen if none is supplied. For a number entry, in contrast, the endpoints are optional, and, while a default step is chosen, users can override with whatever precision they like. (In an input with type number, minimum of 2, maximum of 3, and step of .01 nothing prevents the user from directly entering 2.718281828, although any up and down arrows clicks would reduce the precision back to .01.)
They are designed for different jobs. I’d prefer to have different tools.
1 Like