"settecento" can be read as "seven hundred" in Italian; gramps is proposing to use a more specific word as a tag for Italian art from the 1700s. Of course, 700 is not 1700, hence the "drop 1000 years". The prefix seventeen in Italian is "diciassette-" so perhaps "diciasettecento" would be more accurate for the 1700s. (settecento is shorter, though.)
Hope this clarifies. Not to miss the forest for the trees, to reiterate, the main takeaway is that it may be better to define and use a specific tag to pinpoint a sequence of events in a given period (e.g. settecento) instead of gesturing with something as arbitrary and wide as a century (18th century art).
It is a waste of time to continue to try to develop a power one does not have.
Manipulating (e.g. "people who down vote [sic] refuse to believe"), spreading fear (e.g. "[mind manipulation occurs on] an 'industrial' scale"), and inflating one's own ego (e.g. "I am a renegade of thought control") contribute little to the discussion of this article.
Very interesting paper! Proposes (with lower bound of 1.3% chance) that the solar system may have passed through a local interstellar cloud, which would have caused the heliosphere to shrink to smaller than the orbit of the earth (0.22 au) some 2-3 mya. This may have affected the Earth's atmosphere and climate. Scroll down for some cool illustrations of a simulation showing how the heliosphere would have been tiny with an elongated tail in a denser interstellar medium. There's also a map showing the interstellar cloud relative to the trajectory of the solar system.
If you're looking for the same sort of walled-garden corporate-degen vibe, try reddit? They even have nested conversations, like on Hacker News! /s
But seriously, Discourse is good forum software. You can self-host it or pay for a hosted instance. An example instance is IRLO, https://internals.rust-lang.org
There's a big number of things you can search for, but it's a finite number. There are certainly people interested in curating resources for their specific niche in exchange for curated resources in other niches, across the entire internet. Perhaps through a social web of trust. We need a new search engine resistant to sybil attacks. One that takes the social aspect of searching—connecting you with the relevant experts—into account.
Oh that's cool! Interested to see where your research leads. Could you drop me a link to where the interaction net → cuda compiler resides? I skimmed through the HVM2 repo and just read the .cu runtime file.
Edit: nvm, I read through the rest of the codebase. I see that HVM compiles the inet to a large static term and then links against the runtime.
Fala Taelin, nice work! Does HVM2 compile interaction nets to e.g. spirv, or is this an interpreter (like the original HVM) that happens to run on the GPU?
I ask because a while back I was messing around with compiling interaction nets to C after reducing as much of the program as possible (without reducing the inputs), as a form of whole program optimization. Wouldn't be too much harder to target a shader language.
Edit: Oh I see...
> This repository provides a low-level IR language for specifying the HVM2 nets, and a compiler from that language to C and CUDA
HVM
I was talking about traversing an interaction net to recover a lambda-calculus-like term, which can be lowered to C a la lisp in small pieces with minimal runtime overhead.
Honestly the motivation is, you are unlikely to outperform a hand-written GPU kernel for like ML workloads using Bend. In theory, HVM could act as glue, stitching together and parallelizing the dispatch order of compute kernels, but you need a good FFI to do that. Interaction nets are hard to translate across FFI boundaries. But, if you compile nets to C, keeping track of FFI compute kernel nodes embedded in the interaction network, you can recover a sensible FFI with no translation overhead.
The other option is implementing HVM in hardware, which I've been messing around with on a spare FPGA.
For the curious, "do be do be do" is a seminal paper in the literature on algebraic effects that introduces frank, quirky little language that has algebraic effects but not handlers, at least in the traditional sense.
Traditionally, an effect handler is an interpreter for a stream of commands, conforming to a specific interface. Generally, handlers surface in languages as a sort of generalized try/catch mechanism, that receive a "callback" to resume the "exception" that produced the command. In frank, not so.
Frank is based around the idea of operators, which generalize functions with the capability of interpreting multiple streams of commands. A plain function can be seen, in fact, as the special case of an operator that interprets no commands.
Operators are organized around ports and pegs. Pegs are the set of side effects that a computation needs. Each port is an offer to extend that set for downstream callers. Instead of building up a union of effects that each function needs, Frank propogated ambient ability inwards. Operators can then be composed based on the ports and pegs they offer.
operator: <port>X → [peg]Y
This works partially because operators are shallow handlers and not deep handlers. Handlers interpret commands: if the handler itself is in scope when interpreting a command, then the language is said to have deep handlers. Frank has shallow handlers, meaning that commands are interpreted in an environment without the handling operator present. Shallow handlers give greater control to the programmer with respect to how commands are interpreted: operators can propagate ambient ability, or choose not to.
(This is a bad explanation because you already need to know what I'm talking about to understand what I'm talking about, but oh well.)
My one critism of frank is that the effect model is kinda hard for the working programmer to understand. I can explain Koka effects as "exceptions plus multiple resumption". I don't really have a categorical phrase for frank, and that's its innovation. This isn't so much a criticism but a plea for the pedagogical ramp to this research to improve.
do be do be do.
If you're still curious, check out the compiler github repo:
And if anything is wrong in the above explanation, please correct me, because we all benefit from Cunningham's Law in the end. Allow me to be the fool.
Hope this clarifies. Not to miss the forest for the trees, to reiterate, the main takeaway is that it may be better to define and use a specific tag to pinpoint a sequence of events in a given period (e.g. settecento) instead of gesturing with something as arbitrary and wide as a century (18th century art).