A place to air possible concerns or difficulties in understanding ProjectEuler problems. This forum is not meant to publish solutions. This forum is NOT meant to discuss solution methods or giving hints how a problem can be solved.

Forum rules
As your posts will be visible to the general public you
are requested to be thoughtful in not posting anything
that might explicitly give away how to solve a particular problem.

This forum is NOT meant to discuss solution methods for a problem.

In particular don't post any code fragments or results.

Don't start begging others to give partial answers to problems

Don't ask for hints how to solve a problem

Don't start a new topic for a problem if there already exists one

The wording used for a problem description is reviewed thouroughly in all its details by several people (at least three), before a problem is published, to make sure it is fully accurate and prevent any misunderstanding.

What you see is what you have to work with.

When you assume something, you risk being wrong half the time.

Hey, I have a question about 224... I solved 223 but it took me almost half an hour to compute the results (my algorithm is identical to that used by others, code optimized by some methods, and I use external modules for some mathematical functions that are very efficient). Python, yes. 224 is not very different - I know exactly how to solve it and it will probably work fine if I give it like, say, 7 hours. Is there something I missed or is this problem supposed to be more demanding from the computer than 223?

Okay, I've solved it. There's a really smart solution (and I found that solution in a VERY dumb way), and there actually is a semi-smart solution that I didn't think of, but this semi-smart solution is much more difficult to find than the semi-smart solution for 223.

That is strange, for (a+b+c) <= 10000 I get 13651. That is, I haven't found a solution yet, and certainly not an efficient one.
I suppose nobody can give me a hint?
Edit: ah, I used a < b < c instead of a <= b <= c. Now I have 13656 too. But still too slow to get anywhere near 25.000.000 .

Let us call an integer sided triangle with sides a <= b <= c barely acute if the sides satisfy a^2 + b^2 = c^2 + 1.

So, if a = 1then I get approximately 12.5 million positive results*: 1^2 + b^2 = c^2 + 1, with b = c. Also a = 1 is not excluded in the description, so how can 10^4 be 13,656?

I have written 2 pieces of code for problem 223.
I get two different answers , for the perimeter limit = 100.000 I get :
val1 = 168921 , val2 = 168676
EDIT : I also get val3 = 168350 when I try to optimize.

Can you please tell me which one is correct ?
Thanks.

I have written 2 pieces of code for problem 223.
I get two different answers , for the perimeter limit = 100.000 I get :
val1 = 168921 , val2 = 168676

I can't find my code for this problem right now.
What you could do is have your computer compare the triangles generated by the two methods until you find one that is counted by method 1 but not by method 2. It is easily checked whether that is a valid almost right-angled triangle or not, so you then know see whether method 1 falsely includes it or method 2 falsely excludes it. The same then goes for your optimized method.