Блог пользователя OmaeWaMouShenDeiru

Автор OmaeWaMouShenDeiru, 10 лет назад, По-английски

Hello codeforces community I wanna learn how to use Fread Fwrite for faster I/O.

If you have any useful example, I will be thankful :D.

  • Проголосовать: нравится
  • +3
  • Проголосовать: не нравится

»
10 лет назад, # |
  Проголосовать: нравится +27 Проголосовать: не нравится

Don't. Really. If a contest requires you to use anything beyond scanf/printf (with some tricks, maybe) to get AC, then the contest is wrong.

  • »
    »
    10 лет назад, # ^ |
      Проголосовать: нравится +6 Проголосовать: не нравится

    There are a few contests where you have "best answer" type questions. i.e. the better your answer is to the actual answer, the higher is your score. In these cases, one would like to have fast I/O and fast precomputation to have more time for the actual searching in the solution space.

    Also, for deterministic problems, it might help to optimize our codes(mainly in codechef problems) especially if we have a code that will surely pass with enough optimizations.

    • »
      »
      »
      10 лет назад, # ^ |
      Rev. 2   Проголосовать: нравится +3 Проголосовать: не нравится

      But if you really need to desperately optimize constants, I/O should take negligible time. In challenge problems especially, these don't have large input data.

      I've come across a single problem where you needed faster I/O than printf/scanf, in all my life. It was CEOI 2012, practice session problem 1. The problem was trivial, but the time limit was set so low that it was impossible to read the input in time. It was an organizers' failure.

  • »
    »
    10 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    my friend, I'm just trying to learn as much as I can, It is not a mistake. And if it was permissible to use them then way not. Thanks any way :)

  • »
    »
    10 лет назад, # ^ |
      Проголосовать: нравится +13 Проголосовать: не нравится

    A contest might not require that, but maybe if you don't find the intended algorithm, you might be able to squeeze an optimized suboptimal solution through.

    • »
      »
      »
      10 лет назад, # ^ |
        Проголосовать: нравится +3 Проголосовать: не нравится

      You can just read my comment above. One does not simply squeeze through with a suboptimal solution by taking down the I/O time from scanf/printf to fread/fwrite. It'd need really, really large data (which rules out basically all challenge problems and many binary-scored ones) and a suboptimal solution that'd be very close to the time limit.

      Instead of that, why not learn more useful tricks like reserve(), bitsets, clever ways to use sqrt-decomposition or try to optimize the algorithms you've memorized? Better yet, why not solve problems and only try to learn this after you've encountered a problem where optimizing I/O was really one of the best last steps to take?

      • »
        »
        »
        »
        10 лет назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится

        Why not do all that and have a fast I/O implementation? It's not like that would be a huge cost. There's just nothing wrong about it, contrary to what you seem to suggest

        • »
          »
          »
          »
          »
          10 лет назад, # ^ |
          Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

          ಠ_ಠ

          It's not like that would be a huge cost.

          Pile up "not a huge cost" many times, and it starts making a difference. It does matter, actually.

          How much time would it take you, anyway? About as much as solving a medium difficulty (considering difficulty from the reader's point of view) problem or trying to solve it, reading the editorial and coding a working solution afterwards, maybe?

          From my experience, I/O difficulties beyond scanf/cin are practically non-existent, while dumb mistakes are rather frequent (they comprise the majority of my failed solutions lately, like a typo in a constant in my solution of 418B - Хитрый Гена — try to calculate the place and points difference caused by that typo). From that POV, it's better to try and eliminate an even rarely occuring small mistake.

          An excellent example is CodeChef SEP13, MLCHEF. I made a small mistake that could only be seen on few large inputs — I numbered the vertices as in the input and not in pre-order numbering, once. Finding it was an incredible pain in the ass, but now, I'm watching out for the numbering I'm supposed to use. It took probably longer than learning fI/O, but damn did it pay off!

          • »
            »
            »
            »
            »
            »
            10 лет назад, # ^ |
            Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

            Your anecdotical evidence does not really support your point. Of course it is more rewarding in the long term to get better at algorithms and solving problems. However using getchar and coding up a custom integer parsing routine (or just copying it from somebody else, because you're not doing it for learning purposes anyway) is a matter of minutes. That's what I meant with "low cost".

            Nobody disagrees with your opinion that there is a lot more important stuff to do.

            • »
              »
              »
              »
              »
              »
              »
              10 лет назад, # ^ |
                Проголосовать: нравится 0 Проголосовать: не нравится

              I thought the OP wanted to learn how to use them, so "not for learning purposes" sounds like an oxymoron here.

              Also, that's the point of view I considered — copypasting and using pre-written code in contests is the working option here, but there's no point in this question being asked then, unless the OP doesn't know how to google stuff.

      • »
        »
        »
        »
        10 лет назад, # ^ |
          Проголосовать: нравится +3 Проголосовать: не нравится

        Im not attending to use them in codeforces problems and contests But i solved problems on UVA and time limit was really bad, even when i used faster I/O operations like reading numbers using getchar()

        • »
          »
          »
          »
          »
          10 лет назад, # ^ |
            Проголосовать: нравится 0 Проголосовать: не нравится

          Yes, and that's the problem. Even if you use fast I/O, that won't make your code fast enough to make a difference — most of the time. That's why I'm saying this is not a good idea.

  • »
    »
    10 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    Actually, one of such wrong contests was SEERC-2013, where input was from binary file and its size was about 100M of integers (square matrix 10000*10000). And yes, time limit was only 0,5 sec.

    • »
      »
      »
      10 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится

      Was the memlimit 64 MB? :D

      That wouldn't fit into the time limit at all, no? That's like the CEOI I mentioned — the problem setters had a moment of immense stupidity. These situations should be avoided, not prepared for.

      • »
        »
        »
        »
        10 лет назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится

        No, memory limit was 512 MB;) I was also very surprised, but one of contestants told that fread() worked about 0,2 sec... Unfortunately, some problems in SEERC are prepared by Romanian problem setters which don't have a lot of experience...

»
10 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

They say that the best way to learn something is to do it. For a start you could implement reading and writing ints by just using getchar() and putchar(). Write it, test it, compare the speed to the standard I/O methods. Then you can step it up and replace getchar()/putchar() with your own I/O buffers through the use of fread()/fwrite(). Again test it, see how different buffer sizes behave, compare this to using getchar()/putchar() in conjunction with setvbuf().