Using neural nets for signal background separation was pretty standard in ~2012 when the Higgs discovery was published. Was also pretty standard for CDF + DZero papers that came out before the LHC turned on.

https://arxiv.org/abs/1207.7214 - The original ATLAS Higgs discovery paper uses neural nets to identify photons. It also uses a neural net b-tagger to improve the H->WW signal to noise ratio.

https://arxiv.org/abs/1303.0763 - used neural nets extra tt+jets noise https://arxiv.org/abs/1503.05066 - used neural nets for signal/background separation.

Yep, you’re right about this. I worked on some of these things, but for the actual analysis it was generally all cut-based.

> actual analysis

Um, I believe I have linked you to "actual analysis" where techniques used are more exotic than boosted decision trees.

I stand to be corrected :) I knew about the tt stuff, but I had no idea about the 7 TeV photon analysis! Every day is a school day :)

>Thankfully, for folks all in on the Apple ecosystem, it should be pretty decent of an experience.

How many people are for now and forever more all in on the Apple ecosystem. You never have to login on another non Apple device ever?

This describes most non-techy people I know who are 20~ years older than me (unless they're 40+ years older than me and only using a laptop to check their email).

Step away from HN, and there are probably a lot of people who only use their phone to access the Internet. Smartphone brand loyalty seems to be strong, too.

I don't know, I find:

>AT TIME ZONE 'UTC' converts the data type from timestamptz to timestamp

surprising and a foot gun. Asking for at a timezone stripping the timezone makes no sense to me. Having `AT TIME ZONE 'UTC'` produce a timestamptz at +0:00 seems not insane.

Yes, the SQL syntax is full of misnomers. I agree it should have more hazard tape around it.

The type qualifier "with timezone" doesn't mean it stores a timezone with it! It means the input is interpreted with timezone offset, producing an unambiguous moment on the timeline. You can then compare all such values with a total ordering. But, these stored values do not preserve any offset/locale information. You can't ask "what was the offset of this timestamp when it was input?" That denormalized locale information is stripped when it is interpreted.

The naive type (without timezone) really means that the timezone information is absent and the interpretation is to be deferred. You have to supply timezone information before it can be resolved to the timeline. This is what the implicit coercion is doing in PostgreSQL, mixing in either the session or server timezone offset.

The above is further complicated in that PostgreSQL will supply an implicit (session or server) timezone during interpretation of the input for timestamp with time zone. And conversely, it will ignore timezone or offset even if present in the input for a naive timestamp! I think both of these would be better off handled as type/input errors in a strict mode.

The poorly named "(ts)::timestamptz at time zone 'tz'" construct is the inverse of the input transform that takes a naive timestamp and the given timezone to produce the known moment.

The other sad bit is that all of this is naive about the difference between UTC, TAI, and Unix time standards. There is ambiguity in postulating any future time, since the exact presence of leap seconds is not yet determined.

Exactly. OP meant that it has permission to do anything, hence "admin".