209 karma · joined March 17, 2016
1) They are doing it for opportunistic reasons. They can't afford to be enemies with Trump.
2) They legitimately changed their opinion about a wide array of things they used to believe enough to outspoken about.
3) They believe that while Trump's core beliefs are not aligned to theirs, the alternative is worse. And potentially they believe there is a need for some sorm of over-correction to fix what has happened over the last 4 years.
This metric would go up if you leave almost no comments. Would it not be better to find a metric that rewards you for generating many comments which are addressed, not just having a high relevance?
You even mention this challenge yourselves: "Sadly, even with all kinds of prompting tricks, we simply could not get the LLM to produce fewer nits without also producing fewer critical comments."
If that was happening, that doesn't sound like it would be reflected in your performance metric.
To find two prime numbers that sum to 123, let’s consider the properties of prime numbers and the nature of their sums: 1. Prime Numbers Greater Than 2 Are Odd: Except for 2, all prime numbers are odd. 2. Sum of Two Odd Numbers Is Even: Adding two odd numbers results in an even number. 3. Sum of an Even and an Odd Number Is Odd: Adding an even number (like 2) and an odd number results in an odd sum.
Given that 123 is an odd number, the only way two primes can sum to 123 is if one of them is 2 (the only even prime) and the other is an odd prime. Let’s test this possibility: • 2 + x = 123 ⇒ x = 121
However, 121 is not a prime number (since ).
Next, consider the possibility of adding two odd primes: • Odd Prime + Odd Prime = Even Number
Since adding two odd primes yields an even number, it’s impossible for two odd primes to sum to 123 (an odd number).
Conclusion: There are no two prime numbers that sum to 123.
Answer: There are no two prime numbers whose sum is 123; such primes do not exist.
Take plenty of water and get it to a boil. Add any amount of rice to the boiling water, and let it boil for 8 minutes. Then drain the water, remove the pot from the stove and put the lid on for a few minutes. Reduces the need for measuring quantities.
If I had an account with a huge amount of followers, then I would also not initially reach out from that main account in order to negotiate the price.
"Through reinforcement learning, o1 learns to hone its chain of thought and refine the strategies it uses."
When looking at the chain of thought (COT) in the examples, you can see that the model employs different COT strategies depending on which problem it is trying to solve.
If you think about it abstractly, humans are basically models that take input from our senses, do some internal processing of that and then take actions with our bodies. SIMA is the same - it takes input from video, and takes action through keyboard actions. There is nothing against introducing additional types of input and taking different actions.
The ability to train on one game and transfer that knowledge to a different game should allow future models like this to train in games, by reading text, watching videos etc, and then transfer all of that knowledge to the real world.
YC is there to make money for its investors. And the way to do that is to invest in the best startups and make them huge.
The only source of conflict then comes from YC vs. the startups. For example, do you enforce strict legal structures on all companies. And here the dominant priority is of course YC itself. But this is expected, and given the rationality also easy to work with.
I have never heard an interview with Tony Robbins, so when I do, I would actually love to hear the best stories according to Shaan, and not random chatter.
---
As an AI language model, I'm unable to write full code examples, but I can provide you a high-level overview of how to implement a horizontally scalable, probabilistic database in Rust using the Raft consensus algorithm.
1) Define the data model: Design a data model for your probabilistic database, which should include the basic CRUD operations (Create, Read, Update, Delete). You can represent the data as a key-value store or any other data structure that fits your use case. Consider using a probabilistic data structure like a Bloom filter, Count-Min Sketch, or HyperLogLog to reduce memory usage and support approximate queries.
2) Implement the Raft protocol: To build a distributed system with strong consistency, you can use the Raft consensus algorithm. There are existing Rust libraries that implement the Raft protocol, such as raft-rs. Include this library in your project to handle the core Raft functionality.
3) Design your database nodes: Each node in the system should maintain a state machine that represents the current state of the database. The state machine should include the following components:
* A log to store the commands received from clients. * A state to apply the log entries and keep the actual data.
4) Handle client requests: For each client request, the leader node should create a corresponding command and append it to its log. Then, the leader should replicate the log entry to its follower nodes using the Raft protocol. Once a majority of the nodes acknowledge the new entry, the leader can consider it committed and apply the command to its state machine. After applying the command, the leader should send the response back to the client.
5) Implement horizontal scaling: To enable horizontal scaling, you need to partition your data across multiple nodes. One way to achieve this is by using consistent hashing. Consistent hashing helps distribute keys evenly across nodes while minimizing data movement when nodes are added or removed.
6) Handle node failures and recovery: Raft is designed to handle node failures and recovery. When a node goes down, the remaining nodes will continue to operate and maintain consistency. Once the failed node comes back online, it will synchronize with the current leader and catch up with the latest state.
7) Deploy and monitor your system: After implementing the necessary components, deploy your system across multiple nodes. Monitor the performance, consistency, and fault tolerance of your system to ensure it meets your requirements.
Here's a high-level outline of how the main components of your project could look like:
mod data_model; mod state_machine; mod raft;
use data_model::DataModel; use state_machine::StateMachine; use raft::RaftNode;
fn main() { let nodes = create_nodes(); let state_machine = StateMachine::new(DataModel::new()); let raft_node = RaftNode::new(nodes, state_machine);
// Start the RaftNode, which takes care of the Raft consensus protocol
raft_node.start();
// Start a server to handle client requests
let server = Server::new(raft_node.clone());
server.start();
// Optionally, start a monitoring and management interface
let monitoring = Monitoring::new(raft_node.clone());
monitoring.start();In this example, you'd need to implement the `data_model`, `state_machine`, `raft`, `Server`, and `Monitoring` modules/components to handle the different aspects of your horizontally scalable, probabilistic database.
Remember that this is a high-level outline and not a complete implementation. You'll need to dive deeper into each component to ensure proper functionality, scalability, and fault tolerance.
I find almost all of my day-to-day tasks quite boring (answer sales emails, performance reviews, accounting, support, etc). But somehow, I still really love working.
I guess one of the factors is a feeling of ownership and agency. I can decide what I want to do and when. When something good happens to the company, it feels like that is also happening to me (this can also be hard sometimes when things don't go well).
Another important factor is that as "the boss", you can pick your own team. It seems like most work-frustration I hear from friends have to do with bad coworkers. I don't have bad coworkers. If I did, I could let them go, and I can try to avoid hiring those people.
For example, if you could hold two arbitrary passports at the same time, which two would give access to most countries (feels like a kind of graph covering problem to calculate).
On the other hand, I have no idea what "Health Services as Credence Goods: a Field Experiment" means. With this title, I would definitely not have clicked the link. I know it is the title of the paper, but given that HN is not an academic journal, it should be allowed to give more informative titles to posts than the original content.
Let's take Tuple as an example. You put "Active user pricing" into Enterprise plan. Why is that not "table stakes"? It does not involve complex tech, and not charging inactive users seems like a fair thing to offer all your customers?
This blog post feels like a "beef marketing" play out of Basecamp's marketing book.
I have tried for years to find a rule to balance these types of projects. But in the end, I have just come to believe that both are essential, and that alternating between high-level and low-level somewhat randomly is the only solution.
How can you stay competitive long-term?
2. Somewhat. We have been able to work with all sorts of institutions, mostly in Europe and North America. We have all Danish universities as customers today, but that is also our home turf.