QWEN CHAT Hugging Face ModelScope DEMO DISCORD
Scaling Reinforcement Learning (RL) has the potential to enhance model performance beyond conventional pretraining and post-training methods. Recent studies have demonstrated that RL can significantly improve the reasoning capabilities of models. For instance, DeepSeek R1 has achieved state-of-the-art performance by integrating cold-start data and multi-stage training, enabling deep thinking and complex reasoning.
Our research explores the scalability of Reinforcement Learning (RL) and its impact on enhancing the intelligence of large language models.
> Which is larger, 9.21or9.1999999999?
<think>
Okay, so I need to figure out which number is larger between 9.21and9.1999999999. Hmm, letme think about
how decimal numbers work. Both of these numbers start with9. So the whole number part is the same. That means
the difference must be in the decimal parts.
First, I'll write them out to compare digit by digit after the decimal point. Let's see:
- 9.21 can also be written as9.2100000000if we add more zeros to make the same number ofdecimal places.
- The other number is9.1999999999, which has a lot of9s.
Now let's compare each digit one by one after the decimal:
First digit after the decimal: both have 2and1? Wait, no. Wait, hold on. Letme check again.
Wait, 9.21is9 point 21, right? So first decimal place is2, second is1. The other number is9.1999999999,
so the first digit after the decimalis1, then the rest are 9s.
Wait a minute, that's different. Wait no: hold on. Let me write them aligned properly:9.2100000000
vs.
9.1999999999
Now comparing digit by digit after the decimal point:
First digit (tenths place): 2 vs. 1. Oh! Here's the key difference. The first number has a 2 in the tenths
place, while the second one has 1 there. Since 2is greater than 1, that means 9.21is already larger just
based on the tenths place.
Wait, but maybe I made a mistake here? Letme confirm again.
Yes, 9.21is equivalent to9and21 hundredths, which can be thought ofas9 + 0.2 + 0.01 = 9.21.
Alternatively, breaking into tenths: the first decimal digit is tenths, so 0.2is two tenths.
The other number is9.1999999999, which has one tenth (the '1' in the tenths place) followed by nine
hundredths and so onwith all those 9s. But even if the following digits are high, once the first differing
digit is smaller, that determines it's smaller.
So since the tenths place of9.21is2 vs. 1in the other number, 9.21is larger regardless of the subsequent
digits.
Alternatively, maybe I can subtract them to see which is bigger?
Letme compute 9.21 minus 9.1999999999:
First, write 9.21as9.2100000000Subtracting:9.2100000000
-9.1999999999
=0.0100000001
So the result is a positive number (0.0100000001), which means 9.21is larger by that amount.
Therefore, 9.21is indeed larger than 9.1999999999.
</think>
The number 9.21is larger than 9.1999999999.
**Step-by-Step Explanation:**
1. **Align the Decimals:** Write both numbers with the same number ofdecimal places for easier comparison:
- 9.21 becomes **9.2100000000**
- The other number is **9.1999999999**
2. **Compare Digit by Digit:**
- **Tenths place (first digit after the decimal):**
- 9.2100000000 has a **2**.
- 9.1999999999 has a **1**.
- Since **2 > 1**, 9.21is already larger at this point.
3. **Verification by Subtraction:**
- Subtract the smaller-looking number from the other:
```
9.2100000000
- 9.1999999999
--------------------
0.0100000001
```
- The result is positive (**0.01…**), confirming **9.21** is larger.
**Conclusion:**
9.21is the larger number because its tenths place (2) exceeds that of9.1999999999 (1).
Even the 7B version of Deepseek-R1 thinks less, doesn’t second guess itself, and comes back with the correct answer:
<think>
First, I need tocompare the two numbers: 9.21and9.1999999999.
Both numbers have the same integer part, which is9.
Next, I'll look at their decimal parts:
- The first number has a decimal part of0.21.
- The second number has a decimal part of approximately 0.20 (since there are many trailing nines after the decimal point).
To make an accurate comparison, it's helpful to express both decimals with the same number of places.For9.21, I can write it as9.210...
For9.1999999999, it remains approximately 9.20when considering several decimal places due to the trailing nines.
After comparing both numbers up to a reasonable number ofdecimal places, it's clear that 9.21 is greater than 9.1999999999.
</think>
Yeah mine does not do this, here are the toggles I have on mine which might make a difference
<think>
Alright, let me figure out which number is bigger between 9.21 and 9.1999999999. Hmm, okay. Both numbers start with 9. so the whole number part is the same. The difference must be in the decimal parts.
First, I’ll write them down to compare digit by digit after the decimal point:
9.21 is the same as 9.2100000000 if we extend it to match the same number of decimal places.
9.1999999999 has more 9s in its decimal places.
Starting from the first decimal digit:
The tenths place: both have 2 and 1 respectively. Wait, no—hold on. Let me check again.
Wait a second, maybe I messed up. Let’s parse each number correctly:
For 9.21:
Tenths place (first after decimal): 2
Hundredths place: 1
The rest are zeros beyond that if we need more places.
For 9.1999999999:
Tenths place: 1
Then, the hundredths is 9, followed by all those 9s up to the tenth decimal digit?
Wait, actually let me clarify the positions properly. Let’s write both numbers with enough decimals:
9.21 can be written as 9.2100000000
9.1999999999 is already given.
Comparing digit by digit after the decimal point:
Tenths place: 2 vs. 1 → Here, 9.21 has a higher tenths digit (2 > 1).
Since the first differing digit at the tenths place is already larger for 9.21, there’s no need to look further into the other decimal places because even if all subsequent digits in 9.199… are 9s, they can’t overcome the difference in the tenths place. For example:
The first number has 0.2 in tenths vs the second having only 0.1. The rest of the decimals add up to less than 0.01 for the second number (since it’s 0.09 + 0.009 etc., which sums to 0.09 repeating, approaching but never reaching 0.1).
Therefore, even with all those trailing 9s in 9.199…, its value is still less than 9.2 (since it’s like 9.1 plus almost 0.1 but not quite), so 9.21 is larger.
</think>
The number 9.21 is larger than 9.1999999999.
Here’s why:
Compare the tenths place (first digit after the decimal):
9.21 has a 2 in the tenths place.
9.1999999999 has a 1 in the tenths place.
Since 2 > 1, 9.21 is already larger at this stage. Even though 9.1999999999 continues with many 9s afterward, they cannot overcome the difference caused by having only 1 in the tenths place compared to the 2 in 9.21.
Settings don’t really matter if you’re comparing two models side by side, and yes I see the same indecision in your reply.
.model ollama:qwq:32b
> Which is larger, 9.21or9.1999999999?
<think>
Okay, let's see... I need to figure out which number is bigger between 9.21 and 9.1999999999. Hmm, both numbers start with 9. So the first digit after the decimal point is important here.
Starting with the first number, 9.21. That's straightforward—it's nine and twenty-one hundredths. The digits after the decimal are 2 and 1.
The second number is9.1999999999. This looks like it's nine point one followed by a bunch of 9s. Let me write them out to compare digit by digit.Letme line them up:
9.21000000009.1999999999
Wait, right? Because 9.21is the same as9.2100000000if we add more decimal places. So now comparing each digit after the decimal:
First digit after the decimal: both have 2 vs. 1. Wait no—the first number's first decimal digit is 2, and the second one's first decimal digit is 1? Wait wait, hold on.
Wait, actually, letme check again. The first number is9.21. So breaking it down:
- The integer part is9.
- Decimal parts: tenths place is2, hundredths is1, andthen the rest are zeros if we go further.
The second number is9.1999999999. Let's see:
- Integer part also 9.
- Tenths place: 1 (since it's .1...), then the next digits are all 9s up to the 10th decimal place?
Wait, so tenths digit of first number is2 vs. second one's tenths digit is 1? That already would make the first number larger because 2 is bigger than 1 in the tenths place.
But maybe I'm miscounting the places? Let me confirm.For9.21: The first decimal digit (tenths) is2, second (hundredths) is1, then zeros beyond.
For9.1999999999: Tenths place is1, hundredths is9, andtheneach subsequent digit up to the 10th decimalis also 9.
So when comparing the two numbers:
At the tenths place:
- 9.21 has a 2
- 9.199... has a 1
Since 2 > 1in the tenths place, that means 9.21is larger right there. The digits after that don't even matter because the first differing digit (the tenths) already determines it.
But maybe I should think if there's another way. Suppose someone might confuse the number of decimal places? Like thinking that more 9s make it closer to 9.2? Wait, but 0.1999999999 is actually equal to 0.2 when rounded to one decimal place because 0.1999999999... recurring would be exactly 0.2, but here the second number has finite decimals—it's not an infinite series.
Wait a second—wait, 0.1999999999is just under 0.2, right? Because if you have infinitely many 9s after 0.1..., then it equals exactly 0.2. But in this case, the number given is9.1999999999with only ten decimal places (assuming that's how it's written). Let me count the digits after the decimal for the second number:
After the decimal, starting from first digit:
1 (tenths), then nine more 9s? Let's see: 9.1 followed by 9, so total of 10 decimal places?
Yes, "9.1999999999" has 10 digits after the decimal. So that's tenths digit is 1, and then nine more 9s in hundredths to ten-billionths or whatever.
Therefore, comparing with9.21 (which is9.2100000000), the first difference is at the tenths place: 2 vs. 1. Therefore 9.21is bigger.
Alternatively, if someone thought maybe converting both to the same number ofdecimal places? Let's see:9.21 can be written as9.2100000000
Comparing term by term:
First digit after .: 2 vs 1 → 2is bigger. So yeah, definitely.
Alternatively, subtract them to see the difference?
Calculate 9.21 - 9.1999999999 = ?
Let's do that subtraction:9.2100000000
-9.1999999999
= 0.0100000001
Which is a positive number, so yes, 9.21is larger by approximately 0.01 (exactly 0.0100000001).
Therefore the answer should be that 9.21is larger.
</think>
The number 9.21is larger than 9.1999999999.
**Step-by-Step Explanation:**
1. **Compare the integer parts:** Both numbers have an integer part of9, so move to the decimal parts.
2. **First decimal place (tenths):**
- 9.21 has a tenths digit of **2**.
- 9.1999999999 has a tenths digit of **1**.
Since \(2 > 1\), the number 9.21is already larger at this point. The remaining digits donot need to be compared further.
3. **Verification via subtraction:**
- Subtracting \(9.1999999999\) from \(9.21\) gives:
\[
9.2100000000 - 9.1999999999 = 0.0100000001
\]
The positive result confirms that \(9.21\) is indeed larger.
**Answer:** 9.21is larger than 9.1999999999.
> .copy
> .info
model ollama:qwq:32b
temperature 0.7
top_p 0.9
use_tools null
max_output_tokens null
save_session null
compress_threshold 4000
rag_reranker_model null
rag_top_k 5
dry_run false
function_calling true
stream true
save true
keybindings vi
wrap auto
wrap_code false
highlight true
light_theme false
Ultimately what matters is whether it gets the correct answer or not. It’s interesting that yours wasn’t able to do the strawberry test while mine did it with very short thinking cycle.
Ultimately what matters is whether it gets the correct answer or not.
That’s… not true at all. It had the right answer, to most of the questions I asked it, just as fast as R1, and yet it kept saying “but wait! maybe I’m wrong”. It’s a huge red flag when the CoT is just trying to 1000 monkeys a problem.
While it did manage to complete the strawberry problem when I adjusted the top_p/top_k, I was using the previous values with other models I’ve tested and never had a CoT go that off kilter before. And this is considering even the 7B Deepseek model was able to get the correct answer for 1/4 of the vram.
It’s true for me. I generally don’t read through the think part. I make the query, do something else, and then come back to see what the actual output it. Overall, I find it gives me way better answers than I got with the version of R1 I was able to get running locally. Turns out the settings do matter though.
I’m running locally as well. It just seems to second guess itself constantly, it’s painful to watch.
atlas@abyss ----------- OS: Bedrock Linux x86_64 Kernel: Linux 6.12.13_1 Uptime: 9 days, 9 hours, 2 mins Packages: 1379 (xbps) Shell: zsh 5.9 Display (M32QC): 2560x1440 @ 60 Hz in 31" [External] Display (M32QC): 2560x1440 @ 60 Hz in 31" [External] Terminal: kitty 0.39.1 CPU: AMD Ryzen 7 7800X3D (16) @ 5.05 GHz GPU: AMD Radeon RX 7900 XTX [Discrete] GPU: AMD Raphael [Integrated] Memory: 20.20 GiB / 62.02 GiB (33%)> Which is larger, 9.21 or 9.1999999999? <think> Okay, so I need to figure out which number is larger between 9.21 and 9.1999999999. Hmm, let me think about how decimal numbers work. Both of these numbers start with 9. So the whole number part is the same. That means the difference must be in the decimal parts. First, I'll write them out to compare digit by digit after the decimal point. Let's see: - 9.21 can also be written as 9.2100000000 if we add more zeros to make the same number of decimal places. - The other number is 9.1999999999, which has a lot of 9s. Now let's compare each digit one by one after the decimal: First digit after the decimal: both have 2 and 1? Wait, no. Wait, hold on. Let me check again. Wait, 9.21 is 9 point 2 1, right? So first decimal place is 2, second is 1. The other number is 9.1999999999, so the first digit after the decimal is 1, then the rest are 9s. Wait a minute, that's different. Wait no: hold on. Let me write them aligned properly: 9.2100000000 vs. 9.1999999999 Now comparing digit by digit after the decimal point: First digit (tenths place): 2 vs. 1. Oh! Here's the key difference. The first number has a 2 in the tenths place, while the second one has 1 there. Since 2 is greater than 1, that means 9.21 is already larger just based on the tenths place. Wait, but maybe I made a mistake here? Let me confirm again. Yes, 9.21 is equivalent to 9 and 21 hundredths, which can be thought of as 9 + 0.2 + 0.01 = 9.21. Alternatively, breaking into tenths: the first decimal digit is tenths, so 0.2 is two tenths. The other number is 9.1999999999, which has one tenth (the '1' in the tenths place) followed by nine hundredths and so on with all those 9s. But even if the following digits are high, once the first differing digit is smaller, that determines it's smaller. So since the tenths place of 9.21 is 2 vs. 1 in the other number, 9.21 is larger regardless of the subsequent digits. Alternatively, maybe I can subtract them to see which is bigger? Let me compute 9.21 minus 9.1999999999: First, write 9.21 as 9.2100000000 Subtracting: 9.2100000000 -9.1999999999 =0.0100000001 So the result is a positive number (0.0100000001), which means 9.21 is larger by that amount. Therefore, 9.21 is indeed larger than 9.1999999999. </think> The number 9.21 is larger than 9.1999999999. **Step-by-Step Explanation:** 1. **Align the Decimals:** Write both numbers with the same number of decimal places for easier comparison: - 9.21 becomes **9.2100000000** - The other number is **9.1999999999** 2. **Compare Digit by Digit:** - **Tenths place (first digit after the decimal):** - 9.2100000000 has a **2**. - 9.1999999999 has a **1**. - Since **2 > 1**, 9.21 is already larger at this point. 3. **Verification by Subtraction:** - Subtract the smaller-looking number from the other: ``` 9.2100000000 - 9.1999999999 -------------------- 0.0100000001 ``` - The result is positive (**0.01…**), confirming **9.21** is larger. **Conclusion:** 9.21 is the larger number because its tenths place (2) exceeds that of 9.1999999999 (1).Even the 7B version of Deepseek-R1 thinks less, doesn’t second guess itself, and comes back with the correct answer:
<think> First, I need to compare the two numbers: 9.21 and 9.1999999999. Both numbers have the same integer part, which is 9. Next, I'll look at their decimal parts: - The first number has a decimal part of 0.21. - The second number has a decimal part of approximately 0.20 (since there are many trailing nines after the decimal point). To make an accurate comparison, it's helpful to express both decimals with the same number of places. For 9.21, I can write it as 9.210... For 9.1999999999, it remains approximately 9.20 when considering several decimal places due to the trailing nines. After comparing both numbers up to a reasonable number of decimal places, it's clear that 9.21 is greater than 9.1999999999. </think>Yeah mine does not do this, here are the toggles I have on mine which might make a difference
<think>
Alright, let me figure out which number is bigger between 9.21 and 9.1999999999. Hmm, okay. Both numbers start with 9. so the whole number part is the same. The difference must be in the decimal parts.
First, I’ll write them down to compare digit by digit after the decimal point:
9.21 is the same as 9.2100000000 if we extend it to match the same number of decimal places.
9.1999999999 has more 9s in its decimal places.
Starting from the first decimal digit:
Wait a second, maybe I messed up. Let’s parse each number correctly:
For 9.21:
For 9.1999999999:
Wait, actually let me clarify the positions properly. Let’s write both numbers with enough decimals:
9.21 can be written as 9.2100000000
9.1999999999 is already given.
Comparing digit by digit after the decimal point:
Since the first differing digit at the tenths place is already larger for 9.21, there’s no need to look further into the other decimal places because even if all subsequent digits in 9.199… are 9s, they can’t overcome the difference in the tenths place. For example:
The first number has 0.2 in tenths vs the second having only 0.1. The rest of the decimals add up to less than 0.01 for the second number (since it’s 0.09 + 0.009 etc., which sums to 0.09 repeating, approaching but never reaching 0.1).
Therefore, even with all those trailing 9s in 9.199…, its value is still less than 9.2 (since it’s like 9.1 plus almost 0.1 but not quite), so 9.21 is larger. </think>
The number 9.21 is larger than 9.1999999999.
Here’s why:
Since 2 > 1, 9.21 is already larger at this stage. Even though 9.1999999999 continues with many 9s afterward, they cannot overcome the difference caused by having only 1 in the tenths place compared to the 2 in 9.21.
Final Answer:
\boxed{9.21}
Settings don’t really matter if you’re comparing two models side by side, and yes I see the same indecision in your reply.
.model ollama:qwq:32b > Which is larger, 9.21 or 9.1999999999? <think> Okay, let's see... I need to figure out which number is bigger between 9.21 and 9.1999999999. Hmm, both numbers start with 9. So the first digit after the decimal point is important here. Starting with the first number, 9.21. That's straightforward—it's nine and twenty-one hundredths. The digits after the decimal are 2 and 1. The second number is 9.1999999999. This looks like it's nine point one followed by a bunch of 9s. Let me write them out to compare digit by digit. Let me line them up: 9.2100000000 9.1999999999 Wait, right? Because 9.21 is the same as 9.2100000000 if we add more decimal places. So now comparing each digit after the decimal: First digit after the decimal: both have 2 vs. 1. Wait no—the first number's first decimal digit is 2, and the second one's first decimal digit is 1? Wait wait, hold on. Wait, actually, let me check again. The first number is 9.21. So breaking it down: - The integer part is 9. - Decimal parts: tenths place is 2, hundredths is 1, and then the rest are zeros if we go further. The second number is 9.1999999999. Let's see: - Integer part also 9. - Tenths place: 1 (since it's .1...), then the next digits are all 9s up to the 10th decimal place? Wait, so tenths digit of first number is 2 vs. second one's tenths digit is 1? That already would make the first number larger because 2 is bigger than 1 in the tenths place. But maybe I'm miscounting the places? Let me confirm. For 9.21: The first decimal digit (tenths) is 2, second (hundredths) is 1, then zeros beyond. For 9.1999999999: Tenths place is 1, hundredths is 9, and then each subsequent digit up to the 10th decimal is also 9. So when comparing the two numbers: At the tenths place: - 9.21 has a 2 - 9.199... has a 1 Since 2 > 1 in the tenths place, that means 9.21 is larger right there. The digits after that don't even matter because the first differing digit (the tenths) already determines it. But maybe I should think if there's another way. Suppose someone might confuse the number of decimal places? Like thinking that more 9s make it closer to 9.2? Wait, but 0.1999999999 is actually equal to 0.2 when rounded to one decimal place because 0.1999999999... recurring would be exactly 0.2, but here the second number has finite decimals—it's not an infinite series. Wait a second—wait, 0.1999999999 is just under 0.2, right? Because if you have infinitely many 9s after 0.1..., then it equals exactly 0.2. But in this case, the number given is 9.1999999999 with only ten decimal places (assuming that's how it's written). Let me count the digits after the decimal for the second number: After the decimal, starting from first digit: 1 (tenths), then nine more 9s? Let's see: 9.1 followed by 9, so total of 10 decimal places? Yes, "9.1999999999" has 10 digits after the decimal. So that's tenths digit is 1, and then nine more 9s in hundredths to ten-billionths or whatever. Therefore, comparing with 9.21 (which is 9.2100000000), the first difference is at the tenths place: 2 vs. 1. Therefore 9.21 is bigger. Alternatively, if someone thought maybe converting both to the same number of decimal places? Let's see: 9.21 can be written as 9.2100000000 Comparing term by term: First digit after .: 2 vs 1 → 2 is bigger. So yeah, definitely. Alternatively, subtract them to see the difference? Calculate 9.21 - 9.1999999999 = ? Let's do that subtraction: 9.2100000000 -9.1999999999 = 0.0100000001 Which is a positive number, so yes, 9.21 is larger by approximately 0.01 (exactly 0.0100000001). Therefore the answer should be that 9.21 is larger. </think> The number 9.21 is larger than 9.1999999999. **Step-by-Step Explanation:** 1. **Compare the integer parts:** Both numbers have an integer part of 9, so move to the decimal parts. 2. **First decimal place (tenths):** - 9.21 has a tenths digit of **2**. - 9.1999999999 has a tenths digit of **1**. Since \(2 > 1\), the number 9.21 is already larger at this point. The remaining digits do not need to be compared further. 3. **Verification via subtraction:** - Subtracting \(9.1999999999\) from \(9.21\) gives: \[ 9.2100000000 - 9.1999999999 = 0.0100000001 \] The positive result confirms that \(9.21\) is indeed larger. **Answer:** 9.21 is larger than 9.1999999999. > .copy > .info model ollama:qwq:32b temperature 0.7 top_p 0.9 use_tools null max_output_tokens null save_session null compress_threshold 4000 rag_reranker_model null rag_top_k 5 dry_run false function_calling true stream true save true keybindings vi wrap auto wrap_code false highlight true light_theme falseUltimately what matters is whether it gets the correct answer or not. It’s interesting that yours wasn’t able to do the strawberry test while mine did it with very short thinking cycle.
That’s… not true at all. It had the right answer, to most of the questions I asked it, just as fast as R1, and yet it kept saying “but wait! maybe I’m wrong”. It’s a huge red flag when the CoT is just trying to 1000 monkeys a problem.
While it did manage to complete the strawberry problem when I adjusted the top_p/top_k, I was using the previous values with other models I’ve tested and never had a CoT go that off kilter before. And this is considering even the 7B Deepseek model was able to get the correct answer for 1/4 of the vram.
It’s true for me. I generally don’t read through the think part. I make the query, do something else, and then come back to see what the actual output it. Overall, I find it gives me way better answers than I got with the version of R1 I was able to get running locally. Turns out the settings do matter though.