Hacker News Reader

Comment by withinboredom | Hacker News Reader

I think you’ve missed a few things.

- not everywhere uses a decimal, some uses the comma and a decimal for thousands. Using a number input, these things are handled for you.

- this seems highly specific for a SPA and not server-side

- “e” is a valid part of a number, I don’t understand why you have issues with it.

View on HN

'“e” is a valid part of a number, I don’t understand why you have issues with it.'

That's a very programmer-centric take. A very, very programmer-centric take. The use of "e" for exponent in scientific notation is a very computer-oriented take on the problem. Such other places as you may have seen it used are leaks from the computer representation. Nobody else sees numbers that way; scientific notation is generally written as 3.278·10³⁶ (only with better superscripts), which is how it is taught in schools for the most part. There are many contexts where I would say it is not a valid part of a number, because I don't expect my users to know scientific notation, let alone an idiosyncratic rendering of it used only for historical reasons in certain niches of the programming world.

I'm pretty sure it's just 'calculator notation' and not a leak from the computer representation, but rather done because of the limited space available (at least on older calculators).

I'm doubtful of this claim. My guess is that the 1.234E-8 type notation originates in floating-point input and output on computers.

This Fortran IV manual (early-mid 1960s, https://www.math-cs.gordon.edu/courses/cs323/FORTRAN/fortran...) lists the same exponential notation, but with capital E for REAL's and capital D for double's.

This pre-dates the first hand calculator I know of, the early HP's from 1968. These machines used the same notation as the HP-35 pictured below (https://www.hpmuseum.org/rpnvers.htm#num).

The HP-35 calculator came out in 1972. According to the page below, the scientific notation used is of the form

1.234-8

i.e., without the E (see the second row of the gallery).

https://vintagecalc.com/hp-35-red-dot/

Just a couple of data points.

> The use of "e" for exponent in scientific notation is a very computer-oriented take on the problem. Such other places as you may have seen it used are leaks from the computer representation. Nobody else sees numbers that way;

It’s a pain in the arse to write, though, which is why quite a lot of scientists and engineers use e even though they don’t know anything about programming and are very, very far from being CS people.

I don’t know anyone who would enter 310^8 naturally in an input field (besides, using for multiplication itself comes from ancient technological limits, but nobody uses the proper multiplication sign either).

So yes, you need to support e for scientific notations in any input field that can be used for large or small numbers.

> scientific notation is generally written as 3.278·10³⁶ (only with better superscripts), which is how it is taught in schools for the most part.

That’s how we write it in LaTeX and our reports, articles, and such. And presentations if you’re lucky. But again, nobody writes that if presentation does not matter enough to go through the hassle. Certainly not in plain text where you’d have to use Unicode characters, at which Windows is completely incompetent.

Perhaps, but the notation didn't exist before it was invented as part of the Fortran language.

your use of asterisk for multiplication has screwed up the formatting because two asterisks get interpreted as indicating italics

Oops, sorry

I have used a calculator before, and I would expect most users to have used one before too.

> I have used a calculator before, and I would expect most users to have used one before too.

A _scientific_ calculator? Because many cheap calculators will just overflow and not use the scientific notation.

You severely overestimate the... amount of data people retain from school (to put it in nice terms).

Even within the privileged US, you can't expect people to remember obscurities of calculator notation.

I’d hope so, it’s basically taught in the 2nd grade (group 4 here), along with how to read and write and it seems people still remember that ok. Google is also immensely helpful if people forget how to read numbers. /s

I guess the point is, you can parse it and output it in whatever format is appropriate, regardless of how it is stored.

States are also taught in schools and yet many people think New Mexico is outside the US.

If you are creating software for engineers, that's a fair assumption to make (that will understand what an exponent is). The public at large? Absolutely not.

That is a convention only commonplace on graphical calculators and modern scientifics with formatted infix entry. A traditional scientific just shows an exponent in a reserved display location.

A large segment of older adults have never used them.

I’ve been seeing it since I was a child on everything from cheap little eight digit calculators to expensive calculators with rolls of paper to graphing calculators.

> 3.278·10³⁶

As a Brit that looks really weird. I'd expect 3·278×10³⁶.

Brits use middots as decimals?

We call them decimal points. Most software uses full stops (aka periods, because that's what's on the keyboard), but decimal points are normal in typeset and handwritten maths.

yea and more! they use low-dot (period) when multiplying variables, and Roman digit for 1, and does not use the "-rd" ending names for the power of 1000: milliard, billiard…

> Using a number input, these things are handled for you.

That's not my experience. I used a number input field for actual numbers (i.e. amounts of currency), but on some phones (specifically Samsung phones), it would show up with a full stop for decimal points (even though the locale was explicitly set to one with commas for decimal points), and users were unable to enter decimal numbers on Samsung phones.

Unfortunately, the handling of the number input field is extremely browser/OS dependent.

Eventually, I decided to go for text input, with numeric for inputmode, and simply interpret both "." and "," as decimal points (not permitting the user to use thousand separators, but few people would do that for input anyway). A bit awkward, but it worked.

Note: Using text and inputmode=numeric did not technically solve the issue of Samsung phones persistently showing the wrong keypad, but the JavaScript interpretation was the real solution to the problem.

When you say "on Samsung phones" do you mean the native Samsung web browser, or any browser on a Samsung phone? Like does this happen on Firefox or Chrome on the Samsung phone?

I will admit, my testing was limited to the native Samsung web browser and to a capacitor made native app, where the problem occurred. It is very possible that Firefox and Chrome on the phone would behave as expected, but I never tested them, since users were experiencing the problem with the other versions of the app, and I needed to find a solution.

Initially, I thought it was a problem with converting a React app to a native app with capacitor, but I tried the same Android app on a different (non-Samsung) Android phone and it did not have the problem (iOS similarly did not have the problem, both web and native version).

Just read the article. A big part of the article that I can summarize is I don't set the requirements, someone else does. Every project is different. You might be fine with just integers. However I've been tasked with much more complicated requests.

There may be exceptions but I guarantee you in most cases the product manager doesn't want the letter e.

My app was built with Rails, and if you enter the value "3.9e3" which represents the number 3900, Ruby will simply use the number 3 and toss the rest of the value away. Do you really want to add special functionality on the back end to covert that value into the actual value? I surely would not.

Also plenty of people use javascript without it being a Single Page Application. Keenforms is not a SPA, we use React for certain pages, but I wanted to keep server side rendering. Using Javascript is not exclusive to SPAs.

(int) ‘3.9e3’ gets parsed correctly in php, perhaps use a language built for the web and not a general purpose language, or a framework that knows how to parse exponential notation? It sounds like Rails doesn’t understand how software works.

I’ve also been messing with forms for twenty-something years, and I’ve never run into these sorts of problems but I understand the problems you are facing, especially after googling these problems and their solution in regards to Rails. I’ve heard it’s a productive language, but when you have to solve such simple problems, maybe not?

Sorry, I don’t mean to bash on your chosen language which is probably how this is coming across. I’m genuinely intrigued by these stack overflow answers.

"Completely change you application stack and learn a new language so you can parse 3.9e3" is not really an option for most people.

thank you so much for this

Just because you didn't run into these problems doesn't mean they don't exist. The clients I do work for have very complicated requirements and expect a lot of dynamic interactions from the forms they pay for. It could be a non profit trying to determine if a new client's family qualifies for federal benefits based on family size and income level. It could be a gas pipeline company trying to calculate how much natural gas they can deliver on a 60 day contract during summer months versus winter months. It could be calculating the medication dosage per body weight for a pharmaceutical company. There was the life insurance example which I mentioned in the article.

Ruby will parse "3.9e3" properly. However Ruby on Rails param parser tries to prevent bad data from entering the system. So the e gets sliced off. There are things that you can do to prevent data from being entered that way.

However like I mentioned in the article and commented on multiple times its not always my choice. And overwhelmingly the product managers and stake holders I interact with would prefer to not see numbers submitted in scientific notation form. There's no reason why you would want to submit your age like that. It's highly unlikely anyone would need a product quantity value in that format.

And maybe most importantly the people who pay tell me all the time they don't want it. Does that make sense?

3.9e3 is equivalent to 3900 in the same way that 3,900 is equivalent to 3900.

So, Ruby’s number parsing is garbage I guess. Hopefully it at least does this properly for floats?

With ROR it might be transformed via the params parser. If you enter the code below in plain old Ruby environment, like irl or the console, it will properly parse it;

"3.9e3".to_f => 3900.0

Something happens when submitting web based params. I'd be curious to see what other back end languages and frameworks do.

This is what happens:

"3.9e3".to_i => 3

and

Integer("3.9e3")

raises "invalid value for Integer()". Really, nothing to see here. Ruby just doesn't treat "3.9e3" as a valid string for an integer (which arguably is correct IMHO)

Some countries use a comma as the decimal point. So it's not obvious to everyone that 3,900 == 3900

> “e” is a valid part of a number, I don’t understand why you have issues with it.

I think people would have fewer issues with it if the browser transparently converted it, either on entry or when calling .value. It's a somewhat obscure case that's easy to get wrong.

For example if I enter 104e4 into a number input with ID test, I get these results in Chrome/Edge:

> $("test").value

'104e4'

> parseInt($("test").value)

104

> parseFloat($("test").value)

1040000

> $("test").value - 0

1040000

Same with decimal points. It's a weird foot-gun because the solution is only half-there.

If you know you're dealing with a number, use `.valueAsNumber` instead of `.value`. Value is a string per the specification, but `.valueAsNumber` does what you expect (for datetime there is also `.valueAsDate`).

The form is submitted to the server using `value`, not `valueAsNumber`. Or maybe you'd prefer all forms to be submitted using JavaScript instead of just using <form action>?

That is up to the developer. Most devs I know prefer to intercept the submit event, convert the form to a JSON object and send the JSON to the server. However if you don’t want to intercept the submit event, then it is up to your server to parse the eccentric inputs, the browser will send them (almost) as is (almost, as in it will consider the locale, e.g. 13,37 will be sent as 13.37 for some locales).

It depends on what you are using on the back end. So for the record my own app's back end is Ruby on Rails.

If you enter the value "3.9e3" which represents the number 3900, Rails param parser will simply use the number 3 and toss the rest of the value away. Do you really want to add special functionality on the back end to covert that value into the actual value? Most of us would not.

I'd be curious to see how other languages and frameworks handle this issue but the e for many of us is a real problem. Most people aren't even aware of it, and learn the hard way.

That's the Javascript's "everything is a single type, but we use types for polymorphism" footgun, and it's a way more general problem than this. Anyway, every JS developer has been harmed by it and knows about it.

Knowledge is knowing "e" is a valid part of a number. Wisdom is knowing your users probably didn't enter their phone number as a power of 10.

A phone number isn't a number, it's a string of digits. It should not use a number field.

It's not even just digits, it can also start with +.

If I understand correctly. JavaScript itself didn't even think '111,2' is a proper float number. Only decimal point is allowed. So by using it, your input already bugged out. The number input is just wild and it did not support transform the input to a proper number for you.

> to a proper number

A proper number is 123.456,78 in large parts of Europe. If I can't put that into your number control when my browser locale is set to Dutch, your custom number input has failed as much at the broken input we're talking about.

It's not just the specific separators, of course; in India such a number is often written like 1,23,456.78 for example, grouping numbers entirely different. Don't assume everyone is American.

> JavaScript itself didn't even think '111,2' is a proper float number. Only decimal point is allowed. So by using it, your input already bugged out.

I may be misunderstanding the gist of your comment, but surely the only "bugged out" behavior would be to try and call parseFloat on the value of the input directly without accounting for localization. Why should JavaScript's number representation affect whether or not I can enter numbers in the way I do everywhere else? The browser offers an API[1] for displaying numbers in a specific locale after all, though it's annoying that you either have to hack something together using Intl.DateTimeFormat.prototype.formatToParts or use a third party library in order to parse them.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

If you use a locale where commas are decimals and use number input, it is a decimal in the code. I have my computer and phone set to en-NL, which has that style of numbers.

- this seems highly specific for a SPA and not server-side

How would you expect users to enter numbers on the server?

form method = ‘POST’ and a submit button. Usually.

A SPA is calling a backend as well... and the backend (SPA or not) still needs to handle the number locale (comma versus decimals), unexpected 'e', etc. Not sure what about this is a JS problem.

FWIW, I’ve never seen an ‘e’ from a number input on the PHP side, probably because it is parsed correctly. I’ve also never seen it from ‘.valueAsNumber’ on the js side either, except rendering big/small numbers but the internal representation was still correct. Using IntlFormat solved that problem IIRC. If you are passing it around as a string, then I imagine it’s a bigger problem.

so... with a number input?

A text input, with form validation / processing done server side, like we've been doing since the 90's.

We've been doing simple JS-based number inputs since the 90s!

Reply on news.ycombinator.com