https://www.codingame.com/training/medium/gravity-centrifuge-tuning
Send your feedback or ask for help here!
https://www.codingame.com/training/medium/gravity-centrifuge-tuning
Send your feedback or ask for help here!
Gravity Centrifuge Tuning is very instructive. I suggest everyone to read the titles of the tests to get a clue.
There is one test that is at odds with the puzzle description though. The âConstraintsâ section states that âN > 0â, but the âWait, what?â test sets N to 0. Itâs probably easier to amend the constraint. If you solve it before the text is changed⌠be aware of that.
I have just updated the constraints section.
Thanks for your carefulness.
Hihi,
If you finished the puzzle âGravity Centrifuge Tuningâ (Coding Games and Programming Challenges to Code Better)
would you mind explaining me the calcul method since i dont get it !!
From what i understood the âtumbles potentialâ of each bit is:
0 ->1
10 ->1+1=2
100 â 1+2=3
1000 â 2+3=5
10000-> 3+5=8
100000 â 8+5=13
and so on.
So, for the input 9, i guess that the output should be 9=8+1(1001) but the testcase expect me to answer 21(10101) ??!!
I am a bit lost âŚ
Thanks for your help !!
Have a look at the name of that testcase
Beautiful puzzle. I enjoyed it a lot
Zeckendorf can indeed be proud
Kudos to the puzzle writer. Very very elegant.
Hi, Iâm trying to solve this puzzle with javascript
,
Any clue how to manage the integer overflow?
Seems there is no BigInt()
library (on spidermonkey compiler), how Iâm supposed to save N
(number of tumbles) like on the last test:
"Zeckendorf would be proud of you"
?
Even if somehow I managed to work on itâs string representation, and find the binary bitstream
(as string), how I can convert the bitstream to octal without overflow?
You are correct that this is much harder in some languages due to the lack of bignum support . For the conversion at the end you can work a single character at a time - every 3 binary bits is one octal character.
Well ok itâs harder (and honestly, why would you use such languages when there are alternatives available? I digress), but I take offense at the âmuch harderâ distinction: if your algorithm is sound, you donât need any of the âhardâ operations, and you can trivially implement them all on a string or bitfield or whatever.
Thatâs supposed to be way easier than the initial conversion from decimal to your internal representation, whatever it is.
You donât think itâs a bug that I canât use BigInt()
? (there is BigInt()
in node
but not in spidermonkey
).
How is it possible to find the N
tumbles if I canât reach the number due the overflow?
You can see that the puzzle starts with var N = BigInt(readline());
example:
But you get
Errors
ReferenceError: BigInt is not defined
at Answer.js.null on line 6
Iâll try explain the problem:
The way Iâm trying to solve is building N
, from then is just binary
to octal
.
but I canât get to N
(in node.js
I can) due the overflow.
I see three ways do solve that:
I donât get the point with this âoctalâ conversion.
And the following extra rule just add more to the confusion:
Damaged Gravity Centrifuges
The Gravity Centrifuge youâve got access to has a cooling issue that hasnât been fixed yet. On your damaged Gravity Centrifuge, if two consecutive bits in the bitstream are set, the twin inertial drive overheats and burns down.
So donât do that.
As far as I understand the solution is to insert a â0â bit between each pair of â1â consecutive bits, Am I right ?
Any help will be greatly appreciated
Itâs not strictly needed to understand it to solve the puzzle. Itâs just there as an extra optimization enabler⌠for those who see it.
No, no, thatâs not the idea Itâs not an âextra ruleâ to confuse people, itâs there as an additional constraint to the allowed solutions. (as a problem setter, I needed because without it I canât have a unique validator output).
See it this way: among the possible solutions to the problem, only output one that wouldnât overheat.
For people who are not into maths, âmediumâ difficulty can be misleading.
This puzzle is based on a theorem and a method youâll have to lookup if you donât know it already. Trying to come up with a solution by trial and error is a total waste of time.
The needed keyword is hidden somewhere. Look closely and youâll find it.
Once the trick is found, 98% of the code is already done.
How disappointingâŚ
I really enjoyed this one.
There was a potential greedy solution but I didnât try it cause I thought that it wasnât guaranteed to work all the time so I went for a systematical recursive search.
And then I checked others solutions and saw that most of them used the greedy solution I was thinking of.
So I wondered if it was luck or not, if the greedy solution was always successful, and ended up demonstrating that it was indeed always successful.
Itâs always nice to see that an intuitive solution has actually solid foundations.