Technology
This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.
Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.
Rules:
1: All Lemmy rules apply
2: Do not post low effort posts
3: NEVER post naziped*gore stuff
4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.
5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)
6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist
7: crypto related posts, unless essential, are disallowed
view the rest of the comments
I'm running locally as well. It just seems to second guess itself constantly, it's painful to watch.
Even the 7B version of Deepseek-R1 thinks less, doesn't second guess itself, and comes back with the correct answer:
Yeah mine does not do this, here are the toggles I have on mine which might make a difference
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.
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.
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.
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.