211–220 of 239 posts
Earlier quoted context omitted.
Then future downvotes won't affect your karma. Who cares? The max amount of karma loss is 4 points, we can afford to eat our downvotes like adults.
Huh. I thought the minimum comment score was -4 (which would make the maximum amount of karma loss 5 , since each comment starts at 1 point), but I didn't know if that was a cap on karma loss or just a cap on comment score.
Earlier quoted context omitted.
Can you read the article a little more closely? > - MiniMax can't fit on an iPhone. They asked MiniMax on their computer to make an iPhone app that didn't work. It didn't work using the Apple Intelligence API. So then: * They asked Minimax to use MLX instead. It didn't work. * They Googled and found a thread where Apple Intelligence also didn't work for other people, but only sometimes. * They HAND WROTE the MLX code…
Emptied out post, thanks for the insight! Fascinating the claim is Apple Intelligence doesn't work altogether. Quite a scandal. EDIT: If you wouldn't mind, could you edit out "AI rage enthusiast" you edited in? I understand it was in good humor, as you describe yourself that way as well. However, I don't want to eat downvotes on an empty comment that I immediately edited when you explained it wasn't minimax! People w…
Earlier quoted context omitted.
No it wasn't. A hardware defect so disastrous that it affects floating point computation on the neural engine, yet so minor that it does not affect any of the software on the device utilizing that hardware is exceedingly improbable. The conclusion, that it was not the fault of the developer was correct, but assuming anything other than a problem at some point in the software stack is unreasonable.
> The conclusion, that it was not the fault of the developer was correct, but assuming anything other than a problem at some point in the software stack is unreasonable. Aah, the old "you're holding it wrong" defense.
Earlier quoted context omitted.
That’s certainly an improvement - but why can’t I modify a previous expression? Or tap to select previous expressions? What I want is something like a repl. I want to be able to return to an earlier expression, modify it, assign it to a variable, use that variable in another expression, modify the variable and rerun and so on.
I think on the numworks you can use the arrow keys to pull up an old expression. I think it would be really cool if someone built out an interpreted, nicely rendered calculator language/repl that could do variables and stuff. Might be an interesting idea
I think there was a calculator like this about a decade ago released for macos, but I can't remember what it was called. Brilliant little piece of software. I assume most people didn't understand it, and it slowly disappeared.
Does it bother anyone else that the author drops "MiniMax" there in the article without bothering to explain or footnote what that is? (I could look it up, but I think article authors should call out these things).
Earlier quoted context omitted.
From a debugging point of view, the author's conclusion was still completely reasonable given the evidence they had
No it wasn't. A hardware defect so disastrous that it affects floating point computation on the neural engine, yet so minor that it does not affect any of the software on the device utilizing that hardware is exceedingly improbable. The conclusion, that it was not the fault of the developer was correct, but assuming anything other than a problem at some point in the software stack is unreasonable.
All neural accelerator hardware models and all neural accelerator software stacks output slightly different results. That is a truth of the world.
The same is true for GPUs and 3d rendering stacks too.
We don't usually notice that, because the tasks themselves tolerate those minor errors. You can't easily tell the difference between an LLM that had 0.00001% of its least significant bits perturbed one way and one that had them perturbed the other.
But you could absolutely construct a degenerate edge case that causes those tiny perturbances to fuck with everything fiercely. And very rarely, this kind of thing might happen naturally.
Earlier quoted context omitted.
No it wasn't. A hardware defect so disastrous that it affects floating point computation on the neural engine, yet so minor that it does not affect any of the software on the device utilizing that hardware is exceedingly improbable. The conclusion, that it was not the fault of the developer was correct, but assuming anything other than a problem at some point in the software stack is unreasonable.
Nah. All neural accelerator hardware models and all neural accelerator software stacks output slightly different results. That is a truth of the world. The same is true for GPUs and 3d rendering stacks too. We don't usually notice that, because the tasks themselves tolerate those minor errors. You can't easily tell the difference between an LLM that had 0.00001% of its least significant bits perturbed one way and one…
>And very rarely, this kind of thing might happen naturally.
It is not a question of rarity, it is a question of the stability of the numerical problem. Luckily most of the computation in an LLM is matrix multiplication, which is s extremely well understood numerical problem and which can be checked for good condition.
Two different numerical implementations on a well conditioned problem and which requires much computation, differing significantly would indicate a disastrous fault in the design or condition of the hardware, which would be noticed by most computations done on that hardware.
If you weigh the likelihood of OP running into a hardware bug, causing significant numerical error on one specific computational model against the alternative explanation of a problem in the software stack it is clear that the later explanation is orders of magnitude more likely. Finding a single floating point arithmetic hardware bug is exceedingly rare (although Intel had one), but stacking them up in a way in which one particular neural network does not function, while other functions on the hardware run perfectly fine, is astronomically unlikely.
Earlier quoted context omitted.
Nah. All neural accelerator hardware models and all neural accelerator software stacks output slightly different results. That is a truth of the world. The same is true for GPUs and 3d rendering stacks too. We don't usually notice that, because the tasks themselves tolerate those minor errors. You can't easily tell the difference between an LLM that had 0.00001% of its least significant bits perturbed one way and one…
You are correct that implementations of numerical functions in hardware differ, but I do not think you correctly understand the implications of this. >And very rarely, this kind of thing might happen naturally. It is not a question of rarity, it is a question of the stability of the numerical problem. Luckily most of the computation in an LLM is matrix multiplication, which is s extremely well understood numerical pr…
It is a bug in MLX that has been fixed a few days ago: https://github.com/ml-explore/mlx/pull/3083
Earlier quoted context omitted.
That's the least of the problems with using an iPhone.
So exactly what problems do most people have with iPhones that could be solved with Android.