> acquired a warrant IMO to compel the valid, non-destructive PIN be given over.
Compelling a PIN, even with a warrant, is legally questionable. Courts have held that it is a form of 'testimony' because it's compelling you to disclose something you know, while some state courts have ruled the opposite way.
In all likelihood the government wouldn't push it in this instance, to avoid creating any sort of precedent.
The problem will be aftermarket car alarms. There used to be a car that parked on the street near my apartment that would go off ever time a bus went by it.
Yes, the trick is having a "ground-truth" KB it can link to, and trying to avoid citogensis from happening. I'm not sure if it's a technique that's every going to scale because of that.
I don’t think this is correct, as we’re talking about all online discourse being influenced by AI, and you don’t know what to trust anymore, rather than generating AI output yourself (which is what you are referring to).
In this context, it would mean building a knowledge base the model can link to that is considered authoritative. So maybe the LLM is has some slop in it's training, and that causes it to try and output some junk, but if it can't match it to it's verified ground-truth KB it doesn't end up outputting it.
The problem is figuring out what is the authoritative sources.
Before value classes this would always be false. The only time comparing Integer objects with == could be true is if Integer object was create by going through Integer.valueOf (or obviously if they were the same object reference.) By default the cached values where -127 to 127, but that is tuneable at runtime.
It could also be true if the instances were created through auto-boxing (e.g. arrayList.add(10); arrayList.add(10); arrayList.get(0) == array List.get(1) //would return true, but false if you used 1000 instead of 10).
Yes, because auto-boxing is just compiling to Integer.getValue under the hood, the bytecode for Integer.getValue(1) and ((Integer) 1) is the same. They'll both compile to something like:
it's easier to remember that it originated from the Byte range, where all bytes could be kept in. Character didn't have negative values so it did [0-128) instead. Long and Short are the same as Byte.
Years before the autoboxing/Integer.valueOf() caching stuff (and before generics), (I) used to have IntegerProvider that did similar stuff to higher ranges. Personally, I have considered autoboxing on integers net-negative for Java
She's excellent and her stuff has made it to the front page many times. I love seeing her work come up and I imagine many others here feel the same way.
Fair enough. I didn't know what was supposed to be objectionable about her personally until your last comment made me do some Googling. Bleh.
To be honest, I feel like I still don't really know much about who she really is or what real political work she's doing recently, if any. And I kinda don't wanna know anyway; I don't wanna play political blacklist enforcer.
