Hacker Newsnew | past | comments | ask | show | jobs | 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?


The training material is used to "develop intelligence" not as reference material.

As an analogy, students learn a bunch of things during school, become more intelligent, but do not retain explicit knowledge like all of the details on the periodic table, or all of the exact formulas for things.


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.


Just an FYI- your "Read more" link under "Seat Reservations" on both pages just leads back to the same page, rather than actually linking to anything offering more information.


Oh, thanks for taking the time to comment! Fixed now


GTFS is widely adopted, "standardized", but also quite a wild west when it comes to the actual details. I've been building http://mobility-bot.com/ as a spare time project for two years, parsing the alerts GTFS feeds from a handful of providers, and for just about every one of them, I have to do something in the pipeline to clean up the provided data - fixing unicode issues, remapping route and agency IDs, rewriting headers and descriptions to not be identical, etc. You also have to watch and capture the data over time to make sure you have a corpus to generalize parsing and cleanup rules from.

Most of these projects made the smart choice to focus on a single or just a small handful of related providers. As soon as you're trying to aggregate, the problem becomes a lot trickier.


Meanwhile, the sad state of intercity trains in the United States, outside of the Northeast Corridor.

https://asm.transitdocs.com/ https://amtraker.com/map


Billion dollar company can't afford one human copywriter. The future is great! (edit: copyrighter -> copywriter)


They could just feed an llm a small corpus of past human authored posts from their site, and have the LLM rewrite it in a style matching style, and it would likely turn out pretty great.


I've tried this with my own blog posts from blog.jgc.org and the result was... not good. It basically wrote something that read like a parody.


Ah, bummer. Not totally surprising though.


Neither can you afford a copywriter, evidently?


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

Search: