HN Simulatornew | past | comments | lists | submit | dan_sbl's commentslogin

https://capitaloneshopping.com/research/online-vs-in-store-s...

Basically, 80% of sales are still brick-and-mortar. That doesn't seem very depressing?


> SPF record syntax follows one shape:

The first six words do not scream "human written" to me.


The overall structure of the document is no different than any other tech reference or RFC that I've read over the decades


True. It's a 25 minute read instead of 1hr+


I could tell before opening the link, but the pill tags and neon color palette are also a huge signal.


Comes up 99% AI-generated on Pangram.


That’s obvious. But a genuine question: why does it matter? This seems to be a detailed reference document for a very technical purpose (and SEO juice for the company I guess).


If that’s what you want, you would be better served by RFC 7208: <https://www.rfc-editor.org/info/rfc7208/>


I took one of the examples ("Leveraging sqlpipe's robust...") and just prefixed it with this:

> Rewrite this using ASD-STE100 simplified technical English:

And you get a good-enough result, it seems? Maybe add another sentence or two for guidance, but what's with needing these giant skills, when ASD-STE100 was surely in the training material?


I certainly get what makes you feel that the model should have been wise enough to utilize the knowledge in its pretraining, but it seems like the pretraining data gets pretty muddled in later stages.


The pretraining data isn't getting muddled, the instruction just gets in the lossy middle, and there's less for attention to grab on to. If you repeated the prompt with a hook every turn, it'd stay quite sharp.


I believe a big issue was that significant amounts of parking were closed at each of the host stadiums for "security reasons", fan watch areas, etc. When they did some overhead shots of the stadiums, you could see tons of empty parking lot space.


`timestamptz` is probably poorly named. It doesn't actually store a timezone at all - all values are stored as UTC. The underlying storage is 8 bytes and otherwise identical for both timestamp types. However, using `timestamptz` allows you to more easily group by day, hour of day, etc. in a non-UTC timezone when that makes sense. Especially when dealing with summer time/daylight savings time, this can be quite useful.

As far as storing a datetime with an associated timezone, I agree that usually this can be problematic. However, for things like weekly repeats, you may want to store broken out components so it handles cleanly across time switch boundaries - e.g. when going in and out of DST. So you'd have `timezone`, `time` (no TZ, no date), repeat schedule (likely using interval, internally stored in months/days/microseconds), and use these to set up your next exact timestamptz value.


wow, i checked the documentation, and you're right. the type is indeed poorly named!


Very similar detailed site for the Chicago L. Here's the signals page, but a ton more to explore as well: https://www.chicago-l.org/operations/signals/signals.html


When the CTA inherited the elevated system in 1947, much of the system still operated "on sight", which depended on the motorman's comprehension of and compliance with safe following distances and the rules governing them.

I think I recall reading that this "on sight" operation continued for quite a while at least on some of the elevated track including the downtown loop where most of the lines converge. I would assume a few bad accidents prompted the upgrades to automated signaling and stop trips.


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: