84 karma · joined February 29, 2024
It seems to me that a mathematician is in a much better position than a lay person to construct prompts and engage with an LLM in a way that results in a new mathematical result. If he could work with Claude to obtain the counterexample but I cannot, that highlights the importance of the prompt engineering from the person, and their knowledge to do so. I'd be surprised that he was the first person to ever prod Claude to work on that particular problem.
Since they don't elaborate on the prompts or method that yielded the result, I'm unable to assume it was a fully AI driven approach. From that lens, I find the framing disingenuous.
Incidentally, I have a Remarkable 2 and as of this weekend an m4 iPad air. Maybe I'll test this one out and see what the landscape for running models on iOS looks like.
0) https://tinkeros.github.io/WbTempleOS/Doc/DolDocOverview.htm... 1) https://hackmag.com/security/templeos
I think the complaints in this thread are not in the spirit of HN. Let's do better.
I'm using this specifically in the context of concepts/features that are hard to explain/sell without some working visual or prototype, but which aren't immediately evident needs or features requested by our users. Some of them go nowhere, but I think the net result is an increased ability for me to get my experiments from the "lab" to production.
https://github.com/nodejs/node/pull/61478
https://blog.platformatic.dev/why-nodejs-needs-a-virtual-fil...
I don't really see the troubleshooting/customization as annoying. It's not much different than learning to program. At first you don't have any intuition for patterns or ways to solve problems, but given time, you start to identify them and know how to work on it unaided. For many distros or operating systems more broadly, it's the same thing. When in doubt, I head to the Arch wiki or more rarely the forums, then I'm good to go.
I'm not really after some integrated LLM or Copilot 365 for Linux experience when it comes to using my computer.
I'm confident if I had stayed on my meds that I would have been far more academically successful in high school and beyond. I pushed to get off Adderall as a kid because I started to feel like a zombie on it, but maybe my parents could have instead helped me to find a treatment that was better suited for me or adjust my dosage.
- ŋjajs 議; 'discuss' - ŋjət 仡; 'powerful' - ʔjup 邑; 'city' - ʔjək 億; '100 million' - ʔjəks 意; 'thought' - ʔjek 益; 'increase' - ʔjik 抑; 'press down' - jak 弈; 'Go' - ljit 逸; 'flee' - ljək 翼; 'wing' - ljek 易; 'change' - ljeks 易; 'easy' - slek 蜴; 'lizard'
0. https://en.wikipedia.org/wiki/Y%C7%92u_bi%C4%81n_d%C3%BA_bi%...
My personal blog that until recently was mostly reviews on lox bagels. I yanked out the bagel reviews for now to focus on programming topics, but need to write up some worthwhile posts.
I work on an internal app for an insurance company that allows viewing and editing insurance product configuration data. Stuff like what coverages we offer, what limits and deductibles apply to those, etc. We have built out a very very detailed data model to spell out the insurance contract fully. It has over 20 distinct top-level components comprising an "insurance product". The data generated is then used to populate quoting apps with applicable selections, tie claims to coverage selections, and more.
Ultimately these individual components have a JSON representation, and the "power user" editor within our app is just a guided JSON editor providing intellisense and validation. For less technical users, we have a "visual editor" that is almost fully generated from our schema. I thought perhaps this article referred to something like that. Since our initial release, a handful of new top-level components have been added to the schema to further define the insurance product details. For the most part, these have not required any additionally coding to have a good experience in our "visual editor". The components for our visual editor are more aligned to data types: displaying numbers, enums, arrays, arrays of arrays, etc, which any new schema objects are likely to be built from. That also applies to nested objects i.e. limits are built from primitives, coverages are built from limits. Given user feedback we can make minor changes to the display, but it's been very convenient for us to have it dynamically rendered based of the schema itself.
The schema is also versioned and our approach ensures that the data can be viewed and edited regardless of schema version. When a user checks out a coverage to edit it, the associated schema version is retrieved, the subschema for coverages is retrieved, and a schema parser maps properties of the schema to the appropriate React editor components.
p.s. These patterns might be commonplace and I'm just ignorant to it. I'm a backend dev who joined a new team that was advertised as a backend gig, but quickly learned that the primary focus would be a React Typescript app, neither of which I had any professional experience with.
They are a friendly and welcoming community maintaining a rental network in the US for the different types of violas da gamba. They have a strong interest as an organization in funding the continued scholarship, performance, and community for these forgotten instruments. It was very cool. I've since gotten my hands on a rental bass viol, though I haven't had as much time for it as I'd like.
My commute time has more than doubled since they closed and sold my office for a hefty sum of money. As a result of multiple offices converging to one, there are insufficient seats for the number of employees actually assigned to my office; hence, "hotdesking".
I'd wager that maybe a third of the total employees assigned to the office could be present at any one point in time, so unless they purchase some additional properties, we're at a stalemate with the twice a week RTO. Most days over 90% of the desks, sometimes over 99% are taken in the building, requiring reservation weeks in advance through a seat reservation app.
I have no direct teammates in the office and no two members of my 10 person team work in the same office (or state).
Many people export their org file based blogs to HTML and then publish them, but my thought would be to skip that and instead provide a path for eww to directly render org files, cutting out my html export stopgap.