I disagree with the timestamptz advice. I tend to use timestamp (without the timezone), this forces me to use UTC everywhere, so I'm not even tempted to use anything else. I work in fintech, and so far whenever i saw someone storing datetimes with an associated time zone, it always ended with a disaster.
`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.
afaik before the final sampling, every "next" token has a probability, so theoretically it could select the 10 most likely tokens (based on some kind of sampling algorithm), but you'd end up with exponentially many output-sequences, so nobody does that.
I think the point the poster above was making is that it doesn't predict a phrase or anything like that - just the single next token. So all 10 or 1000 or whatever number of tokens you want are each individually candidates for the single next token, not a sequence of 10 or 100 next tokens. If you wanted to create multiple possible seuqneces, you'd then feed each of the 10 tokens to the network in the initial state, and extract the next token (or 10 next tokens) from that one, than revert back and feed another single one of the 10 tokens, etc.
Sort of! My impression is that LISP is a little more powerful than what we're building up in the article. I wanted to focus on a few specific aspects (like first-class cross-environment imports and serializing continuations) but I'd ofc expect all of that to be expressible in LISP.
It's fun to theorize about an alternate universe where JavaScript has a LISP-like syntax (Brendan Eich originally wanted "Scheme in the browser"[1], so this isn't so far-fetched!). Indeed, `interpret` sounds like a LISP macro that can "partially evaluate" code (so someone else, ie. the browser can continue to evaluate it).
Because of the company VPN, I usually teleport to Israel, and I have absolutely no idea how to change the language on a right-to-left layout with a Hebrew alphabet...
~6 years ago I've created a lib to convert any text into the image and decode it back.
Each symbol char code is converted into the hex color and placed on the specific x & y. Brackets, curly brackets, colons, semicolons, or other statements like function, class are highlighted with their own color.
Just for fun
- convert source code into the image
- apply filters
- decode image back into the code
- WOW! the code is refactored kekw
Today, for some reason, I decided to convert the source code of the React and Vue into the art-code images and place it as the NFT tokens on the opensea platform
In case if something will be sold — I will spend all proceed to support open source developers
reply