There is a very prominent "show always / show on demand / disable completely" button, which you can choose and is respected indefinitely from that point on. That's orders of magnitude better than anything else, and really the best you can do short of refusing to use any AI at all.
> They provided a better and more cash efficient solution for passengers. That is enough.
They burned half a billion dollars a month of VC money at their peak to undercut taxis across the world; in quainter times this used to be called "dumping", now it's just the standard way of doing business. All the while basically flaunting the law with their whole "we're just a platform connecting people who happen to drive a car with people who happen to want to go some place, it's totally not a taxi guys". No regulations, no expensive licenses or professional certifications, no need even for a minimum wage or basic social security or insurance or any kind of protection. Amazing!
Essentially the same in spirit as Airbnb, only this latter had far more destructive consequences than screwing over taxi drivers.
Most businesses require sunk costs or debts, and it's also often what is required for new ideas take place in an established market. Whether they burn VC money or the bank's money to gain a foothold, is immaterial.
Uber did a great thing here and made a product that people like more, for less money. More drivers, way more global availability, more customers, and better cars, all while being cheaper. That is a quintessential success story.
If people liked taxis more, they'd use them. But taxis are still shit and the only reason we use them is because of the taxi cartel bullying weak city governments into restricting Ubers.
And yet somehow Uber and Lyft (and Waymo) in San Francisco are still usually cheaper (inflation-adjusted) than what taxis used to cost 15 years ago here.
I agree that dumping is generally bad, and perhaps laws against it should have been enforced against Uber. But the taxi system deserved to be destroyed. They sucked, and there was really no political/business way out of that system other than someone violating regulations on "what is a taxi" until it stuck. I'm not a "means justify the ends" guy in general, but in this case I think it worked out how it should have.
It's one of several issues with the design of IEEE floats, unfortunately. I wish we could start thinking more seriously about a new design, to complement if not replace IEEE in the long term. Posits are an example https://github.com/andrepd/posit-rust
Your repo has a link to the standard[0], which might interest some people. It makes me unreasonably happy to know that this was funded out of Singapore.
The IEEE floats do not have any serious design issue. They are much better than any other floating-point formats that have ever been used.
There have been many examples of badly designed floating-point numbers, e.g. those used by the IBM mainframes and those used by the DEC minicomputers. In both cases, minimizing the costs for computer vendors was prioritized over the properties needed by the end users.
In scientific and technical computations, a constant relative error over the entire range of the numbers is optimal.
Only logarithms would be better than IEEE floats, but the addition and subtraction of numbers stored as logarithms is too slow, so the IEEE floating-point numbers are a compromise between the speed of multiplication and the speed of addition.
Posits redistribute the relative error over the range of numbers, increasing the precision of numbers close to unity by reducing the precision of numbers far from unity. This is a property that may seem desirable for input data and output data, but it is extremely undesirable for the intermediate values that are generated in computations.
Even for input data and output data, in engineering there are many characteristic values of parts used in manufacturing, such as electronic components, where constant relative errors are needed over a range greater than 10^9 or even greater than 10^12 (e.g. the values of standard resistors, with a given tolerance, may vary from milliohms to gigaohms and those of standard capacitors from femtofarads to farads; it would not be acceptable to represent such nominal values as posits, with a tolerance depending on the nominal value).
There may exist some applications where this is useful, but all such applications are among those that need low precision numbers, of 32 bits or less. So 16-bit or even 32-bit posits might be useful in certain circumstances, but it is pretty certain that 64-bit or bigger posits will always be inferior to IEEE floating-point numbers.
The problem is that while the IEEE floating-point numbers are either optimal or at least acceptable in almost all applications, the fact that posits might be better only in certain special applications makes unlikely that the development of dedicated fast hardware for them can be worthwhile.
Even if some applications might indeed like a better precision for numbers close to unity, for those applications posits must contend not only with floating-point numbers but also with fixed-point numbers, which do not need any special hardware and they can be implemented in any standard CPU with a simple software library.
Fixed-point numbers have even better precision than posits for numbers close to unity, but posits have a greater range, where their precision drops quickly towards the extremities of the range.
So the application domain of posits is squeezed between those of floating-point numbers and those of fixed-point numbers, leaving a very small number of applications where posits are optimal.
I am not aware of any application that would justify the additional cost for posit-processing hardware. I think that the only chance for posits would be if someone would show that some posit format is better for certain ML/AI/LLM computations than narrow FP formats like BF16, FP8, FP4.
That will be the only use case that could find people willing to pay enough money for the design of posit-processing hardware, in some kind of NPU for training or for inference.
Like I have said, for technical/scientific computing posits are much inferior to FP64, graphic applications are happy with FP32 and FP16 and they do not have any reason for a change, while the applications that need high precision around unity are happy with fixed-point numbers and they also do not have any incentive to change.
Ahahaha, I'm sorry but that's just a ridiculous thing to say. "The IEEE floats do not have any serious design issue. They are much better than any other floating-point formats that have ever been used". Really?? x)))
It's obvious that IEEE floats have several issues: low precision, excessive dynamic range, underflow to 0 causing infinite loss of precision (ditto for overflow), denormals, non-portability, lack of a total order, redundancy of NaN bit patterns, poor scaling to low precision... I can go on! Whether you regard those as relevant or as unimportant, or perhaps as unavoidable, is your opinion. But they do exist!
To re-iterate: claiming that IEEE floats are superior to any existing or proposed alternative is a claim you can attempt to make, although I disagree with it. But claiming "IEEE floats do not have any problems whatsoever" is simply not a good-faith conversation...
> In scientific and technical computations, a constant relative error over the entire range of the numbers is optimal.
What do you possibly mean by "optimal"? For instance, inference on a neural network using a 16-bit (or even 8-bit!) posit type tailored to the distribution of the weights in that neural network can yield better results than with 32-bit floats! Obviously floats are not "optimal" in any possible conceivable situation (neither are posits "more optimal" than floats in any conceivable situation).
Even in "traditional" HPC applications, like weather modelling, experiments have shown 16-bit posits to be acceptable replacements for 32 or even 64-bit computations.
> Like I have said, for technical/scientific computing posits are much inferior to FP64
Repeating something does not make it true :) Like I have said, 32 and 16-bit posits can replace 64 and 32-bit floats in many important applications (obviously not all). HPC and ML workloads are largely memory-bound nowadays; halving the number of bits can yield a doubling of performance, roughly speaking.
> it is pretty certain that 64-bit or bigger posits will always be inferior to IEEE floating-point numbers.
> The problem is that while the IEEE floating-point numbers are either optimal or at least acceptable in almost all applications, the fact that posits might be better only in certain special applications
You assert this repeatedly as dogma, without proof x) I don't get it, do you have a dog in this race somehow? Bizarre.
In fact, the simplest way to see that this is wrong is to consider a "posit"-like format with no regime bits, but with otherwise the same structure: twos-complement representation, no underflow or overflow, deterministic rounding, a quire. This format is essentially an improved version of an IEEE float, without most of its warts, but still a constant relative error (actually constant, unlike IEEE with its subnormals!), similar hardware encode/decode implementations, etc.
>It's obvious that IEEE floats have several issues: low precision, excessive dynamic range, underflow to 0 causing infinite loss of precision (ditto for overflow), denormals, non-portability, lack of a total order, redundancy of NaN bit patterns, poor scaling to low precision... I can go on!
From your list of supposed defects, only one can be considered a defect, i.e. that there are too many NaN values. However there is a justification for this, because using less values as NaNs would have required more expensive hardware for detecting which operands are NaNs.
> low precision, excessive dynamic range
This is a single item, because choosing the dynamic range determines the precision and vice versa.
Contrary to your claim, a greater dynamic range was one of the greatest improvements of the IEEE 754 format over the earlier FP formats, like that of IBM and that of DEC.
With a lower dynamic range, overflows in intermediate computation results become extremely frequent and unavoidable. This was a major problem before Intel 8087 and the IEEE 754 standard. The dynamic range of the IEEE FP64 format is great enough to make overflows very unlikely in typical technical/engineering computations, and this is a very desirable property.
> underflow to 0 causing infinite loss of precision
I do not know why you have written this false statement, but there exists no such thing in the IEEE standard for floating-point arithmetic.
Underflows have only 2 standard behaviors, they either generate exceptions that must be handled by the programmer or they generate denormal numbers, which minimize the loss of precision. It is impossible to have "infinite loss of precision" on underflows in a standard-conforming processor.
> ditto for overflow
Overflows have 2 possible standard behaviors, they can generate either exceptions or infinities. Both possible behaviors allow the programmer to detect that there is a bug in the program, which must be fixed. There exist no methods of handling overflow that can avoid the loss of precision (when using fixed-length numbers), so the only thing that can be done, and it is done by the standard, is to ensure that the user is made aware that an overflow happened.
> denormals
Denormals are an optional feature of the standard, like infinities and NaNs. They can be completely avoided by enabling the underflow exception.
Denormals offer a choice to the programmer, to avoid handling the underflow exceptions. If the programmer chooses to use denormals, they minimize the loss of precision when underflows happen.
> non-portability
Huh ?!
The IEEE FP numbers are the most portable FP format known in history. Before this standard, every computer-making company had their own FP formats that were incompatible. The conversion of numeric data between different computers was a very complex problem.
Now this is far in the past. Even if some processors, mainly GPUs, do not support all features of the standard, at least the numeric formats are everywhere the same so no conversions are required.
> poor scaling to low precision
This has nothing to do with the IEEE standard. Any kind of floating-point numbers must scale poorly towards very low precision, because when very few bits are available for the complete number, then even fewer bits can be used for the significand and for the exponent, which makes difficult the tradeoff between precision and dynamic range.
Even so, the IEEE standard FP16 format has adequate precision and dynamic range for its main application, which is storing color component values in pixels, in graphics and video applications.
For ML/AI applications, where even lower precision is desired, 8-bit to 4-bit floating-point numeric formats have become preferred to fixed-point numbers, despite the "poor scaling" of floating-point numbers to low precision.
It should also be noted that when FP numbers are scaled to low precision the use of denormals becomes absolutely necessary for avoiding the loss of precision around zero. That is why more than a decade before the IEEE 754 standard, denormals were used in the 8-bit floating-point numbers used to encode audio samples in digital telephony, in USA/Japan and in Europe (mu-law and A-law). Denormals were used first in computing by Intel 8087, but they were already established in low-precision floating-point numbers.
So all your list contains no defect of the IEEE standard floating-point numbers, especially not in comparison with other FP number formats.
The only point that is specific to the IEEE format and about which one could argue regarding some specific application is the choice of the dynamic ranges, which for FP64 and FP128 are greater than those used in the older FP formats, which had been in use before 1980.
I have started using computers with IBM mainframes and DEC minicomputers, so I have practical experience with those older formats.
Switching to IBM PCs with 8087 and their successors was a great improvement by eliminating the problem of overflows. On older computers, in order to avoid overflows it was frequently necessary to introduce well chosen scale factors in various formulae and equations. The necessity of handling those scale factors removed much of the advantage that floating-point numbers have over fixed-point numbers. Floating-point numbers were invented precisely to free the programmers from the chores of having to deal with scale factors.
For solving practical engineering problems, like the design of electronic devices or integrated circuits, the dynamic range of IEEE FP64 numbers is good and any of the dynamic ranges of older FP formats (like also the dynamic range of IEEE FP32 numbers) is insufficient.
I think the problem is people prefer to solve immediate problems affecting themselves (or their close kin) rather than long-term or indirect improvements, and education is the long-term project if there ever was one: magically improve things tomorrow, and you will only start to see the effects in 20 years.
I don't know how it is in your place, but where I'm from governments have — at least for the last 15 years — governed exclusively with a max horizon of 4 years (the time until the next elections). Everything is quick-fixes or patches that kick the can down the road. It's very hard to convince people to care and vote for you if you promise to show results over the next generations, vs if you bump up pensions next year or something.
Basically, to give a different example, that's in essence why you the response to "traffic is abysmal" is "we will widen the urban highways cutting through the city" rather than "we will implement a plan to actually redesign our city away from car-exclusiveness".
Agree with technology being over-used for the sake of it. A visualisation/exploration of some math concept in Desmos can be invaluable, infinitely better than fiddling with diagrams on paper. Solving a calculus exercise on an ipad instead of paper adds exactly zero value. A smart teacher will know to use the first but not the second.
I will just say whiteboard > blackboard. I get allergies just thinking about it x)
I strongly agree with your basic idea but I am currently studying maths part-time and for me personally, I love using an iPad for writing maths because of cut/paste and the ability to drag things around to make space on the page. It really helps me to do things in a way that’s clear. When I do things with pencil and paper I spend a huge amount of time erasing things, crossing out, adding little caret and then squeezing little extra bits that I forgot earlier between two lines “…and f is continuous on [-1,1]…” etc.
I used to hate writing on the ipad but the thing that was transformational for me was a “paperlike”[1] screen protector, which makes the surface feel a lot nicer to write on.
I sincerely don't get the point of a post like this. You buy a Framework for repairability, flawless Linux support, ability to tinker, etc. Yes it would be extra nice if on top of everything it also had a faster CPU and a higher-density screen for cheaper than the aggressively priced entry model of corporation with the literal deepest pockets in the world. But is that a realistic complaint? I swear I don't get it.
reply