ENCODING - Editorial

editorial
, , , , ,
102

It’s because of the lines:

# define ll long long
...
# define int ll

This makes it impossible to write

int main()

as normal as that would expand to

long long main()

which is a compiler error, so int32_t is used as a workaround.

1 Like
103

Oh i see, thanks btw

1 Like
104

Can anyone explain or send links about these lines and this #pragma … I read about this on the net but I’m not finding any hard data

105

Its related to some compiler optimizations.

1 Like
106

does it become fast ?

107

Instead of answering that, I’d tell you that a codeforces blog tells all details about this :wink:

1 Like
108

Okay Thanks @vijju123, i will try to identify the states::thinking:…

109

for ease. Easy to replace int with typdef int long long int.

1 Like
110

@vijju123 tell me please :slight_smile:

111

Well, I wanted you to google it yourself to get it, but here you go-

There was also a pretty nice explanation as comment by MrDindows but I cannot find it atm.

1 Like
112

thanks for answering all my questions :wink: :+1:

113

I can’t understand the line equal_next=(equal & next_digit>vec[idx]), shouldn’t it be (equal & digit>vec[idx])?

114

We are seeing if after placing next digit what is the state of equal.

115

You said I can request for an unapproved editorial of CHGORAM and SYNBAC from you. How do I do that?

1 Like
116

Please upload CHGORAM, I’ve been searching for a plausible solution for over a week now, Or you could just submit your own code with few comments first, and later add an editorial. So we could think about the solution in the mean time

1 Like
117

There’s a Video Editorial for CHGORAM here:

and, though people are probably sick of me posting it by now, here’s my fully-documented submission (highly-commented code, plus high-level, Editorial-style overview). Not been proof-read :slight_smile:

https://www.codechef.com/viewsolution/25937827

4 Likes
118

Did you not take part in yesterday’s Cook-Off?

119

No, I’m a slow, slow old man and there’s no way I’d be able to compete with all you young whipper-snappers :slight_smile: Long Challenges only, for me!

2.5 hours for 5 questions? I’d spend longer than that agonizing over variable names XD

4 Likes
120

:smiley: but you seem to be a good problem solver, would have given us ‘young whipper-snappers’ a good competition. Anyway, I know you are one of the Competitive Programmers who writes very clean code, probably a habit you carried over from your experience as developer(saw your LinkedIn profile). So, you are an asset to the community. Nevertheless, see you in September Long and hitting 4 or higher star this time.

3 Likes
121

Thanks for the very kind words :slight_smile: I’m a very inconsistent problem solver - I’m quite often stumped for a long time over surprisingly simple things (coming from Hackerrank, it was a real eye-opener seeing what problems were classified as “Easy” here :)) - this is really not a good recipe for success with short challenges :slight_smile:

Anyway, while I’m here - I’d like to say how much I love the long-form format here - so much less stressful than Hackerrank, where in their equivalent (the “Week of Code”) you still only have one day to solve a challenge (if you want full marks on it), plus they have the “Additional Testcases” which just add to the pressure! I couldn’t believe it when I saw that you had a full 10 days to solve all the challenges here. It’s great :slight_smile:

4 Likes