JavaScript engines do optimize integers. They usually represent integers up to +-2^30 as integers and apply integer operations to them. But of course that's not observable.
You are half correct about 2^53-1 being used (around 9 quadrillion). It is the largest integer representable with 64-bit float. JS even includes a `Number.MAX_SAFE_INTEGER`.
That said, these only get used in the rare cases where your number exceeds around 1 billion which is fairly rare.
JS engines use floats only when they cannot prove/speculate that a number can be an i32. They only use 31 of the 32 bits for the number itself with the last bit used for tagging. i32 takes fewer cycles to do calculations with (even with the need to deal with the tag bit) compared to f64. You fit twice as many i32 in a cache line (affects prefetching). i32 uses half the RAM (and using half the cache increases the hit rate). Finally, it takes way more energy to load two numbers into the ALU/FPU than it does to perform the calculation, so cutting the size in half also reduces power consumption. The max allowable size of a JS array is also 2^32.
JS also has BigInt available for arbitrary precision integers and these are probably what someone should be using if they expect to go over that 2^31-1 limit because hitting a number that big generally means you have something unbounded and might go over that 2^53-1 limit.
The memory savings from 32 bit or even 16 bit floats are definitely not pointless! Not to mention doubling simd throughput. Speaking of which, without simd support this certainly can't be used in a lot of applications. Definitely makes sense for financial calculations though.
> It started requiring phone numbers and things...
a) You're already trusting them with every piece of information in your tax return. It'd cost like five cents to use that information to discover your phone number... if they're malicious, you're already fucked.
b) When? At the end of the process where you're doing stuff like attesting that you're not lied on your tax return? I don't remember them demanding a phone number up front, and I also don't remember whether or not I refused to provide a phone number at the end.
Weird. The electronic filing has worked flawless for me every year for the past like four or five years. Was the "esoteric" complaint delivered as an email after you'd submitted your paperwork? If so, then in my experience, that's because you've fucked up the data you input into the form and the IRS's backend has a funny-but-useful way of spelling that.
> But phone # validation up front is too much, an overstep.
They definitely didn't do this to me any of the years I've used them to file taxes. When did you file yours? Did you file them long after the 2024 taxes were due?
Started asking about two or three years ago at registration, didn’t try last year. My return is complicated and it couldn’t handle some obscure form. But don’t remember which. On time.
> Started asking about two or three years ago at registration...
Very odd. I wonder (but not enough to investigate) what's so different between your situation and mine that I'd not be asked for a phone number during initial configuration.
The 1040 has a spot for both a phone number and an email address. The 1040 instructions make it completely clear that both are optional.
You have the option of entering your
phone number and email address in the
spaces provided. There will be no effect
on the processing of your return if you
choose not to enter this information.
Note that the IRS initiates most contacts
through regular mail delivered by the
United States Postal Service.
You know, the IRS is basically defunded, even not counting the whole shutdown thing. I wonder how many people need to file handwritten by mail before it becomes a significant problem
And they _will_ find them. For example, one year I forgot to add a line from one of 1040 forms to my return. I got a notification from the IRS about a year later that I have under-reported taxes.
And with the defunding of the IRS, they'll severely limit the complex audits.
reply