October 2018

[EdH]

Originally Posted by Batalov

Found one!

Good work!

Once again, I am trying to overcome poor code with more cores, (even though that approach failed for the bonus in July). I still have a few days. (Yep, I kept thinking that in July, too.)


Edit: I have written and compiled my program with debug under Code::Blocks in C++ and am running it via ./<program> in a linux terminal. It seems that I have read that you can break in with CTRL+C, check variable values and then continue the program from where it was interrupted. Is this possible without running it under something like GDB?

[Dr Sardonicus]

Originally Posted by Batalov

Found one!

Congratulations!

I've pretty much drawn a blank on this one.

Yes, I understand what the question is. I simply had no practical insight into the problem. I did devise an approach which in theory, could generate sets of any number of points with the required properties, but saw no way to write code that would implement the approach.

To me, the most interesting thing about the problem was that the sets in question could be translated by any vector [a, b] with integer coordinates, or multiplied by any 2x2 matrix with determinant 1 or -1, and the resulting set would define triangles with the same areas as the original set.

Beyond the restrictions already described in this thread, I will mention that the area of the smallest rectangle containing the set is at least twice the area of any triangle in the set.

[uau]

Originally Posted by EdH

Edit: I have written and compiled my program with debug under Code::Blocks in C++ and am running it via ./<program> in a linux terminal. It seems that I have read that you can break in with CTRL+C, check variable values and then continue the program from where it was interrupted. Is this possible without running it under something like GDB?

No, unless your program implements explicit signal handlers, CTRL+C will kill the process and there will be nothing left to inspect. CTRL+Z can be used to temporarily stop a program without killing it, but that doesn't help with inspecting variables. Without running the program under gdb or some other debugger (or later attaching gdb to a program that has been started separately) there's no way to inspect its internal state. How would you even attempt to do that without a tool?

[EdH]

Thanks uau. That's what I expected. I guess the stop and restart using CTRL-Z was what I had seen, but didn't know if there may have been a way to interrogate variables.

[science_man_88]

Originally Posted by EdH

Thanks uau. That's what I expected. I guess the stop and restart using CTRL-Z was what I had seen, but didn't know if there may have been a way to interrogate variables.

print the variable names and values ?

[EdH]

Originally Posted by science_man_88

print the variable names and values ?

Too much overhead to print thousands per second (or check for the passage of thousands to trigger printing), and I'd only want to do a spot check once in a while.

[Batalov]

Apparently there exist a solution with S<=567 (?!).

[petrw1]

Originally Posted by EdH

Too much overhead to print thousands per second (or check for the passage of thousands to trigger printing), and I'd only want to do a spot check once in a while.

Keep a counter and just print every xMillion iterations?

Or "watch" for a key-press and print out only then "on-command"

[bsquared]

Originally Posted by Batalov

Apparently there exist a solution with S<=567 (?!).

There is nothing on the web site still, or did you find that?

[Batalov]

Hit 'refresh', I guess. A pair of solvers have an asterisk (and they ain't me :-( )

[petrw1]

Originally Posted by Batalov

Hit 'refresh', I guess. A pair of solvers have an asterisk (and they ain't me :-( )

I see you and I see a pair of solvers with an "*" but nothing on the page that says what earned the "*"