Skip Navigation

User banner
InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)UL
Posts
7
Comments
605
Joined
8 mo. ago

  • The point you are missing is the "had to".

    The sketchy company didn't have to pay the creators for it because it was available via different means.
    They would have had to, if they couldn't find it otherwise.

    Of course, in that case, they would have "borrowed" it from libraries and such, but then again, the premise is that they had to, which is not being fulfilled in your example.

  • I feel like, in the long run, this is going to be a good thing.

    Hopefully:
    Consumers will realise the problems with streaming platforms and those who pirate will realise the importance of supporting the studios they like.
    Then there will be less people using the streaming services and more people buying copies directly from the studio.

    All that remains is studios using a service that P2Ps directly to the customer's computer, bypassing all the wasted Blu-ray plastics.
    I am going to, once again, give the example of Steam game soundtracks, which I can keep wherever I want and listen to, using whichever software I want.

  • Replace the pink car with a bicycle an A is suddenly not being in the mood to yield anymore.

    I was going straight once and had to go back in and do a full turn (180° + 360°) because of that.

  • A few minutes after posting this, I realised that it actually showed the entry that you selected in the above view.

    So, it was a HTML browser widget and it was white because everything that shows HTML has a FFFFFFacepalm background by default.

    I need to fix that background colour. Or I will end up keeping that thing hidden forever.

  • Yeah. I once had to do stuff to code that had bit-fields like that and after a while, realised (by means of StackOverflow) that that part is UB and I had to go with bitwise operations instead.

  • I watched too much of power rangers on TV as a child.
    As a result, I don't find the anime enjoyable.

    Even though the premise was fun, I just couldn't tolerate it enough to feel the fun.

  • DIY Tape Drive:

    • Keep the core-rings remaining from sticky tapes that you use.
    • When you are about to finish your fourth, save some tape
    • Peel the remaining tape and encircle 2 of the core-rings
      • Do the same with the other 2 core-rings and remaining tape
      • You might want the amount of tape used to be same for both the pairs
    • Connect core-rings to the axle of your choice
  • coding

    Jump
  • Your silly joke was on Programmer Humour. You might find geeks and nerds here.

    Overthinking is our ikigai.


    Now get out of line and continue with further analysis of the 'un'

  • coding

    Jump
  • The thing is that 'un' is different from stuff like 'not', 'non' and the likes, because it is not just denying the referred word but saying that the effect of the referred word was reverted somehow.

  • coding

    Jump
  • You put the double 'un' but forgot the double 'dead'.

    Oh, I didn't realise you were actually catching the thing mid statement.


    Still:

    • A dead un-dead would be a re-dead, not very alive
    • Considering the 2x dead person is still capable of commenting, I would assume it came back after re-death and is now in some other condition.
  • Nice stuff.

    I got sold on the :

    EOF does not consume less space than "5"

    because, even though the space taken by the filesystem is the fault of the filesystem, one needs to consider the minimum information requirements of stating starts and ends of files, specially when stuff is split into multiple files.

    I would have actually considered the file size information as part of the file size instead (for both the input and the output) because, for a binary file, which can include a string of bits which might match an EOF, causing a falsely ended file, would be a problem. And as such, the contestant didn't go checking for character == EOF, but used the function that truly tells whether the end of file is reached, which would, then be using the file system's file size information.

    Since the input file was a 3145728 bytes and the output files would have been smaller than that, I would go with 22 bits to store the file size information. This would be in favour of the contestant as:

    1. That would be the minimum (hyh) number of bits required to store the file size, making it as easy as possible for the contestant to make more files
    2. You could actually go with 2 bits, if you predefine MiB to be the unit, but that would make it harder for the contestant, because they will be unable to present file sizes less than 1 MiB, and would have to increase the file size information bits

    On the other hand, had the contestant decided to break the file between bits (instead at byte ends), instead of bytes (which, from the code, I think they didn't) the file size information would require an additional 3 bits.


    Now, using this logic, if I check the result:

    From the result claimed by the contestant, there were 44 extra bytes (352 bits) remaining.

    22 bits for the input file size information 22*219 bits for the output file size information because 219 files

    so the contestant succeeds by 352 + 22 − (22 × 219) = −4444 bits. In other words, fails by 4444 bits.

    Now of course, the output file size information might be representable in a smaller number of bits, but to calculate that, I would require downloading the file (which I am not in the mood for.
    And in that case, you would require additional information to tell the file size bits. So;

    • 5 bits for the number 22 in the input
    • 5 bits for the size of the file size information (I am feeling this won't give significant gains) and rest of the bits as stated in the first 5 bits, as the file size bits
      • you waste bits for every file size requiring more than 16 bits to store the file size information
      • it is possible to get a net gain with this, as qalc says, log(3145728 / 219, 2) = (ln(1048576) − ln(73)) / ln(2) ≈ 13.81017544

    But even then, you have 352 + 5 + 22 − (5 + (14 × 219)) = −2692 for the best case scenario in which all output file sizes manage to be under 14 bits of file size informations. More realistically, it would be something around 352 + 5 + 22 − ((5 + 14) × 219) = −3782 because you will the the 5 bits for every file, separately, with the 14 in this case, be a changing value for every file, giving a possibly smaller number.


    If instead going with the naive 8 bit EOF that the offerer desired, well, going with 2 consecutive characters instead of a single one, seems doable. As long as you are able to find enough of said 2 characters.
    After going on a little google search, I seem to think that in a 3MiB file, there would be either 47 or 383 (depending upon which of my formulae was correct) possible occurrences of the same 2 character combination. Well, you'd need to find the correct combination.

    But of course, that's not exactly compression for a binary file, as I said before, as an EOF is not good enough.