Hamurabi Challenge

Dear Friends and Colleagues!

Here comes 225-th problem - HAMURABI. It is to be solved in Scheme too, but don't get alarmed - for simple solution you probably won't need more than few lines of code.

However it is a Challenge - and hopefully I still remember how create them and haven't fouled something. Still there are a lot of ways to make mistakes (as runner and checker for this problem are significantly larger than minimal solution) - so if you suspect something is wrong - please, tell at once!

It may happen the challeng won't appear very clever - but it is a bit different from most others - you couldn't know the input data on which your solution is executed. So you probably may create your own code to train your solution. Feel free to suggest if any clarifications are needed.

P.S. to those who may reach 225 solved problems - it may happen your "banners" will appear temporarily broken as they are not updated for new level. This is going to be fixed, hopefully in few days.

IMPORTANT UPDATE (at 08:40 UTC March 9)

I'm very sorry, but scoring formula for this problem was changed (simplified). Thanks to sontran for showing that scoring with "extra points" was inadequate. Really it doesn't make sense to award the ruler with no land and people - at the same time such approach made challenge hardly interesting at all :)

"Solved" status wasn't changed, but "bests" were reset to minimum. Please, resubmit your solutions. Excuse me once more for not well-polished problem.

That was funny while it lasted. Btw the "simulator" at the top of the page still uses old scoring system.

Yep. Sorry for spoiling the fun :)

This reminds me ot topcoder marathon where some fellow detected "presence of automobile" in a picture simply by calculating amount of blue over all pixels. For some reason this was enough to get 2-nd place :)

Thanks for hint - changed scoring in simulator!

I think the area part should be "area*2/30".

Hm... the idea behind it is that every acre yelds 3 bushels on average, and then 20 bushels are enough to feed 1 person during a year. Similarly the grain/25 should ensure there are resources to feed the people during a year (and to leave something to sow). To sum up - these conditions should potentially allow survival even if harvest fails in the upcoming year.

However please feel free to suggest changes if something is quite wrong in these considerations!

Hi!

I'm sorry for such situation! Well, I'm afraid there are some issues which make it confusing:

• you redefined (min ...) which is a built-in - and as it is also used by "driver" code, the latter becomes a bit hacked and breaks at some place;
• regretfully when it breaks it drops some error message into output but doesn't set error exit code (thanks for this finding - I'll try to fix this behavior later);
• if I change your definition (and its usage) to (min-x ...) the code runs less or more well, but rather slowly, at last it seemingly hangs after about 40+ calls, I'm yet trying to figure out the reason

The last issue may present difficulty as the running time of solution in a server sandbox is limited to something about 3mln loops of interpreter - roughly one second. I should add this information somewhere too, sorry for missing it.

There is a function eval-count (non-standard) to check this internal counter:

(display (advisor 105 667 12460 20 '()))(newline)

(display (eval-count))(newline)

it gives a value of about 15 mln for this single call :(

I'll be back when find out the reason of "eventual freezing". Sorry for such difficulties.

min was built-in

btw if I may suggest, you probably want to call min on existing list (not expanded to arguments) - they have apply function for this:

(apply min mylist)

got error 255 (bad syntax or args on call)

Yep, I noticed your chain of submission and trying to figure out the reason "in parallel".

It seems your function breaks with some very special input:

(display (advisor 130 990 1980 18 '()))(newline)

I got "cdr: argument 1 must be: pair"

Though I still haven't come to root-cause.

Definitely error reporting is yet to be improved, sorry for this inconvenience once again.

Ah, that is not a particular interest :)

Just a weak attempt to work around limitations of site and find new ways.

Sorry bit too much words further, but perhaps someone who reads it by chance may had some more ideas to share.

We historically use "judge by answer" approach for accepting solutions, right - similar to ProjectEuler which was an inspiration. This is different from most programming sites (e.g. TopCoder and CodeForces), where one submits code which is executed on server. Advantage is low cost (under $200/year) and hence certain immunity to circumstances (and opportunity to program in any language, as language doesn't matter).

However this bereaves us of some types of tasks. When "challenges" were introduced, they necessary had constant and known input, thus relying on fact that tasks are so calculation-tough it is not probable they would be perfectly solved soon.

However, few problems are really "run on server" - those in BF and Asm4004. This allowed to create few challenges of different kind. However due to languages being very limited they were in "Hugi Compo" style, and I couldn't come up with more real problem solvable in them.

So the options are: either find some other interpreter fit for our "low-grade" infrastructure, or deploy proper sandbox on VPS. The second is not completely impossible - for another $200/year there are options of 2GB/2core VPS - enough to start with. But it means tending a dozen or more compilers, implementing waiting queues etc. There are ready solutions also (e.g. Sphere engine) but prices are more "enterprise-oriented".

Thus I was looking lazily for some more "general-purpose" language and interpreter which doesn't require extra needs to guarantee controllable execution. There was idea about some version of BASIC (but I judged it may cause even more pain and aversion), some trimmed version of Python (but I haven't found yet best way to trim it), more extravagant choices like Forth and Focal were considered briefly :) And thus Scheme was just one in the list. I initially thought it is a very bad idea, as it means people need to try unfamiliar language. However at some point I found that Python for example is similarly unfamiliar for those who get used to C++, so it would be trouble with any "chosen" language. So it raised to state of "poor" idea from "very bad" and I decided to try :)

There is still some minor advantage for single language which could be employed in future (not yet 100% sure how). Namely - possible challenges of other types - when people write code to compete one against other, e.g. "robot battles" - in form of tanks shooting each other, or spaceships infesting planets. We shall see...