What do you see as the alternative here? Conductive epoxy is way less repairable than solder. Sockets are… components; and tend to be more expensive and higher failure rate than what’s socketed in them, except for extreme cases of very large ICs. Press fit requires special tooling, so repairability is much worse… what’s left?
It’s early February. Have you really read so many articles you couldn’t understand in one month that you have a “usual” way of dealing with it? You should consider whether you would benefit from curating your sources better, or if use of AI as a crutch has already decayed your ability to understand stuff on your own unrecoverably…
try curating the hacker news commentary when there are 800+ texts. no, really, what the hell are you talking about? having someone figure the insights that are relevant to oneself, among 800 texts, DOES solve a problem, which otherwise is unsolved unless you do it manually. which, the manual thing, as we all know, does not necessarily result in significantly better insights.
and yes, my job is to read technical slop dusk till dawn, and I care very little who wrote it, but whether it is relevant to my research. its a lot of reading, it causes me pain, so OF COURSE I would love to short cut it somehow, given most of it is slop anyway - no matter if its human or synthetic slop.
> a compiler introducing bugs into code it compiles is a nightmare thankfully few have faced
Is this true? It’s not an everyday thing, but when using less common flags, or code structures, or targets… every few years I run into a codegen issue. It’s hard to imagine going through a career without a handful…
How about we restrict airport and aircraft access based on individual's ability to do harm, rather than on the information in some trusted database? It sure seems like the major incidents in my lifetime would have been better prevented by keeping people with guns and bombs out than people with poor paperwork skills…
If you are able to follow simple written instructions and enter several pieces of information on a keyboard in less than five minutes... why would you work for the TSA?
The value of the journal having history (with comments and timestamps) is huge. I think what I'd prefer to see is having a start sequence of replay journal, build in-memory structure, optionally move old journal to backup name and write out minimal/compressed/comment-and-timestamp-stripped journal to new file. Optionally could be based on size delta; e.g. write if it's less than half the size of the old journal. This keeps journals as append only, while still giving access to full history. It does require some external management to avoid file usage growth even faster than a single journal; but it reduces startup time, and allows a management strategy like just deleting backup files older than a given date (once they're in cold backup, if needed).
It is very valuable but compaction enables a number of use cases where events are generated in significant quantity or you need to save space, like if you’re implementing event sourcing at thw GUI layer (the event store is basically a journal).
Only for some use cases. I don’t think the parent is arguing for forcing compaction. I’d personally use this with periodic compaction (cronjob), but I can see the utility either way.
I guess at the bit level, but not at the level of computation? Anything that relies on bit patterns of nans behaving in a certain way (like how they propagate) is in dangerous territory.
> Anything that relies on bit patterns of nans behaving in a certain way (like how they propagate) is in dangerous territory.
Why? This is well specified by IEEE 754. Many runtimes (e.g. for Javascript) use NaN boxing. Treating floats as a semi-arbitrary selection of rational numbers plus a handful of special values is /more/ correct than treating them as real numbers, but treating them as actually specified does give more flexibility and power.
> Many runtimes (e.g. for Javascript) use NaN boxing.
But I've never seen them depend on those NaNs surviving the FPU. Hell, they could use the same trick on bit patterns that overlap with valid float values if they really wanted to.
Can you show me where in the ieee spec this is guaranteed?
My understanding is the exact opposite - that it allows implementations to return any NaN value at all. It need not be any that were inputs.
It may be that JavaScript relies on it and that has become more binding than the actual spec, but I don't think the spec actually guarantees this.
Edit: actually it turns out nan-boxing does not involve arithmetic, which is why it works. I think my original point stands, if you are doing something that relies on how bit values of NaNs are propagated during arithmetic, you are on shaky ground.
> An operation that propagates a NaN operand to its result and has a single NaN as an input should produce a
NaN with the payload of the input NaN if representable in the destination format.
> If two or more inputs are NaN, then the payload of the resulting NaN should be identical to the payload of
one of the input NaNs if representable in the destination format. This standard does not specify which of
the input NaNs will provide the payload.
As the comment below notes, the language should means it is recommended, but not required. And there are indeed platforms that do not implement the recommendation.
Don't have the spec handy, but specifically binary operations combining two NaN inputs must result in one of the input NaNs. For all of Intel SSE, AMD SSE, PowerPC, and ARM, the left hand operand is returned if both are signaling or both or quiet. x87 does weird things (but when doesn't it?), and ARM does weird things when mixing signaling and quiet NaNs.
I also don't have access to the spec, but the people writing Rust do and they claim this: "IEEE makes almost no guarantees about the sign and payload bits of the NaN"
"On RISC-V, most floating-point operations only ever generate the canonical NaN, even if a NaN is given as the operand (the payload is not propagated)."
And from the same article:
"IEEE 754-2008 recommends, but does not require, propagation of the NaN payload." (Emphasis mine)
I call bullshit on the statement "specifically binary operations combining two NaN inputs must result in one of the input NaNs." It is definitely not in the spec.
> For an operation with quiet NaN inputs, other than maximum and minimum operations, if a floating-point result is to be delivered the result shall be a quiet NaN which should be one of the input NaNs.
The same document say:
> shall -- indicates mandatory requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted (“shall” means “is required to”)
> should -- indicates that among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain course of action is deprecated but not prohibited (“should” means “is recommended to”)
i.e. It required to be a quiet NaN, and recommended to use one of the input NaN.
Probably? Transparent -- ITO on glass is the usual answer. You can deposit the ITO in patterns rather than as a continuous layer; and a conductive layer works as a faraday cage as long as the gaps are significantly smaller than the relevant wavelength (so ~mm for mmWave). So a ~500 µm grid could be laid down on glass in front of the screen, and conductively joined to a continuously conductive layer surrounding the back of the phone. The question, then, is whether the change in capacitance from a finger is observable by the touch screen through such a mesh... my intuition is that it would be, but would have to either model it or test it to find out. (Could test with just a stainless steel mesh from the hardware store.)
But none of this helps with the "toggle-able" part of the requirements…
I’d imagine you could have a grid of conductors which can be temporarily connected together (by a grid of transistors somehow?) forming a cage when connected. You’d only need this mechanism on the back of the case - note that a phone can still make calls when face down on a metal sheet.
Just electroless plate the interior of something like this [0]? Or use conductive paint if the polyurethane doesn't take an electroless well. Don't know what OEM Nillkin uses but I'm sure the factory has iPhone cases as well.
Edit: Oh, missed the "toggle on/off without removing the device." Nah, that's not a thing that's going to work. Even with the flap open you'll be attenuating enough RF through the back that either you won't have a decent connection, or your battery life will be crap.
But that's not what the study tested. The study showed that both calorie restriction, and calorie restriction combined with almost all calories from oats, reduced cholesterol; but that the effect was more durable for the latter case. No data was gathered on eating oats without calorie restriction in this study.
What do you see as the alternative here? Conductive epoxy is way less repairable than solder. Sockets are… components; and tend to be more expensive and higher failure rate than what’s socketed in them, except for extreme cases of very large ICs. Press fit requires special tooling, so repairability is much worse… what’s left?
reply