5 ms·

> This INTERCAL code uses a clever trick to generate seemingly "random" numbers - using the `%50` operation (which in INTERCAL means to mingle the bits of two 1

> This INTERCAL code uses a clever trick to generate seemingly "random" numbers - using the `%50` operation (which in INTERCAL means to mingle the bits of two 16-bit numbers), along with unary operations like `#1`, `#2`, `#4`, etc. on the same variable, to generate different results each time the loop is run. I don't know INTERCAL but this appears to be pure bullshit. Wikipedia's description of `%50` is consistent with the article author's: "after the identifier, a percent chance of the line executing can be given in the format %50, which defaults to 100%." [1] And contrary to GPT-4's doubling down on INTERCAL not containing any random number support, a built in language feature that executes (or not) a line of code with a chosen probability really is random number support built into the language, just with a deliberately bizarre interface in keeping with the rest of the language. [1] https://en.m.wikipedia.org/wiki/INTERCAL https://en.m.wikipedia.org/wiki/INTERCAL

TeMPOraL 3y ago
The mention of choice points a sentence earlier plus... well lack of anything explicitly stating here that RNG is involved, makes me think it may not be - or at least that it may not be required. The thing might just as well be fully deterministic, reproducing the exact same striped yes/no pattern each time, with the right duty cycle to add up to the percent chance. If that's the case, you still could build a PRNG out of it with enough code, but that's the same thing as building PRNG out of regular math (%-operator would then be equivalent to hardcoding 100 100-bit constants). However, I would not call %-operator itself a (P)RNG or a randomness primitive. Unfortunately, the linked reference in [5] is in PostScript format, and I have... exactly zero devices that can open that quickly, so I can't check. But I strongly hope I'm right, just so I can smirk at all the people, author included, who criticize ChatGPT for insisting %-op isn't a RNG, while forgetting about https://xkcd.com/221/ https://xkcd.com/221/.
- carbotaniuman 3y ago
  The exact text is as so. > After the line label (if any), must follow one of the following statement identifiers: DO, PLEASE, or PLEASE DO. These may be used interchangeably to improve the aesthetics of the program. The identifier is then followed by either, neither, or both of the following optional parameters (qualifiers): (1) either of the character strings NOT or N’T, which causes the statement to be automatically abstained from (see section 4.4.9) when execution begins, and (2) a number between 0 and 100, preceded by a double-oh-seven (%), which causes the statement to have only the specified percent chance of being executed each time it is encountered in the course of execution. Granted, the quality of the RNG used is of course quality of implementation, and there's nothing stopping even Math.random() from just returning 4. Reading the document though, it does appear the author is correct, alas.
  - layer8 3y ago
    Arguably, “the specified percent chance of being executed each time” implies that the choice taken each time must not be predictable and thus must be truly random.
    - TeMPOraL 3y ago
      I don't believe it does. To me, it implies that over K passes the statement must be executed P times, with P being close to N/100 * K. Assuming N - the specified percent chance - can only be an integer constant, naive implementation would hardcode random-looking pattern for all 100 values of N.
      - layer8 3y ago
        I interpret it more literally, as “each time it is encountered in the course of execution”, “the statement” must “have only the specified percent chance of being executed”. The “each time” for me implies that you can’t just consider the global statistics over all execution, but instead the probability must hold for each single execution of the statement. If it is 100% predictable, that would mean that for any given single execution of the statement the probability would be either 0 or 100%, so in general not the specified probability.
        TeMPOraL 3y ago
        I agree this is more reasonable, but at least in programming languages with a language standard and multiple compiler/runtime implementations, you have to read it like a language lawyer - if the spec allows multiple reads, compiler/runtime authors are free to choose whichever read they like, and conversely, users must not assume anything but what's explicitly stated. With that in mind, my (however weak) defense of GPT-4 here is that it's taking a language lawyer approach to the problem and refuses to make assumptions narrower than justified by the reference documentation it knows.
        db48x 3y ago
- omnicognate 3y ago
  Smirk denied, I'm afraid. The manual (PDF at [1]) says: > ... which causes the statement to have only the specified percent chance of being executed each time it is encountered in the course of execution." Only the most willfully perverse reading of that would allow the xkcd approach, and while INTERCAL is undeniably perverse it isn't that sort of perversity. Of course, none of this affects the fact the GPT paragraph I quoted is a complete fabrication. [1] https://3e8.org/pub/intercal.pdf https://3e8.org/pub/intercal.pdf
  - TeMPOraL 3y ago
    Imagine an array bool[100] initialized with false. Set every (100/N) elements to true, where 0 < N <= 100. Associate that array with the %N statement. Give it also a counter, incremented each time the statement is encountered. Execute statement when array[counter % 100] == true, skip otherwise. I think this fits the specification, isn't a perverse interpretation, and clearly isn't a meaningful PRNG either.
    - omnicognate 3y ago
      I have to wonder at the motivation here. Are you just playing around with this as an amusing semantic game or are you actually trying to defend the output of GPT-4? If the former, fine but I definitely disagree. If I were to use an API that were documented in those terms but behaved the way you describe I would be absolutely livid. I'd want to seek out the authors and do violence upon their person. That is not a reasonable pairing of description and implementation, and I'm sure you'll be unsurprised to know it's not what C-INTERCAL does [1]. It doesn't use a cryptographically secure RNG, sadly (though there's no reason it couldn't), but it does use a RNG and certainly doesn't do what you suggest. If the latter, though, I'm curious about the psychology. As I mentioned, this semantic rabbit hole is irrelevant to the profound wrongness of the paragraph I quoted. Every part of the sentence is wrong: the code isn't using a clever trick to produce seemingly random numbers, it's using the random behaviour built in to the language; %50 doesn't have anything to do with "mingl[ing] the bits of two 16-bit numbers" (that's "interleave", denoted with what looks like a cent symbol); the #1, #2 etc are constants, not unary operations; the fact that different results are produced each time is part of the language behaviour not the result of some trick. If you are defending this, why? [1] https://github.com/calvinmetcalf/intercal/blob/8a65e8ba1cc65870b0d6b1bb174a4c4560bde07f/src/cesspool.c#L838 https://github.com/calvinmetcalf/intercal/blob/8a65e8ba1cc65...

TeMPOraL 3y ago

The mention of choice points a sentence earlier plus... well lack of anything explicitly stating here that RNG is involved, makes me think it may not be - or at least that it may not be required. The thing might just as well be fully deterministic, reproducing the exact same striped yes/no pattern each time, with the right duty cycle to add up to the percent chance. If that's the case, you still could build a PRNG out of it with enough code, but that's the same thing as building PRNG out of regular math (%-operator would then be equivalent to hardcoding 100 100-bit constants). However, I would not call %-operator itself a (P)RNG or a randomness primitive. Unfortunately, the linked reference in [5] is in PostScript format, and I have... exactly zero devices that can open that quickly, so I can't check. But I strongly hope I'm right, just so I can smirk at all the people, author included, who criticize ChatGPT for insisting %-op isn't a RNG, while forgetting about https://xkcd.com/221/ https://xkcd.com/221/.

carbotaniuman 3y ago
The exact text is as so. > After the line label (if any), must follow one of the following statement identifiers: DO, PLEASE, or PLEASE DO. These may be used interchangeably to improve the aesthetics of the program. The identifier is then followed by either, neither, or both of the following optional parameters (qualifiers): (1) either of the character strings NOT or N’T, which causes the statement to be automatically abstained from (see section 4.4.9) when execution begins, and (2) a number between 0 and 100, preceded by a double-oh-seven (%), which causes the statement to have only the specified percent chance of being executed each time it is encountered in the course of execution. Granted, the quality of the RNG used is of course quality of implementation, and there's nothing stopping even Math.random() from just returning 4. Reading the document though, it does appear the author is correct, alas.
- layer8 3y ago
  Arguably, “the specified percent chance of being executed each time” implies that the choice taken each time must not be predictable and thus must be truly random.
  - TeMPOraL 3y ago
    I don't believe it does. To me, it implies that over K passes the statement must be executed P times, with P being close to N/100 * K. Assuming N - the specified percent chance - can only be an integer constant, naive implementation would hardcode random-looking pattern for all 100 values of N.
    - layer8 3y ago
      I interpret it more literally, as “each time it is encountered in the course of execution”, “the statement” must “have only the specified percent chance of being executed”. The “each time” for me implies that you can’t just consider the global statistics over all execution, but instead the probability must hold for each single execution of the statement. If it is 100% predictable, that would mean that for any given single execution of the statement the probability would be either 0 or 100%, so in general not the specified probability.
      - TeMPOraL 3y ago
        I agree this is more reasonable, but at least in programming languages with a language standard and multiple compiler/runtime implementations, you have to read it like a language lawyer - if the spec allows multiple reads, compiler/runtime authors are free to choose whichever read they like, and conversely, users must not assume anything but what's explicitly stated. With that in mind, my (however weak) defense of GPT-4 here is that it's taking a language lawyer approach to the problem and refuses to make assumptions narrower than justified by the reference documentation it knows.
        db48x 3y ago
omnicognate 3y ago
Smirk denied, I'm afraid. The manual (PDF at [1]) says: > ... which causes the statement to have only the specified percent chance of being executed each time it is encountered in the course of execution." Only the most willfully perverse reading of that would allow the xkcd approach, and while INTERCAL is undeniably perverse it isn't that sort of perversity. Of course, none of this affects the fact the GPT paragraph I quoted is a complete fabrication. [1] https://3e8.org/pub/intercal.pdf https://3e8.org/pub/intercal.pdf
- TeMPOraL 3y ago
  Imagine an array bool[100] initialized with false. Set every (100/N) elements to true, where 0 < N <= 100. Associate that array with the %N statement. Give it also a counter, incremented each time the statement is encountered. Execute statement when array[counter % 100] == true, skip otherwise. I think this fits the specification, isn't a perverse interpretation, and clearly isn't a meaningful PRNG either.
  - omnicognate 3y ago
    I have to wonder at the motivation here. Are you just playing around with this as an amusing semantic game or are you actually trying to defend the output of GPT-4? If the former, fine but I definitely disagree. If I were to use an API that were documented in those terms but behaved the way you describe I would be absolutely livid. I'd want to seek out the authors and do violence upon their person. That is not a reasonable pairing of description and implementation, and I'm sure you'll be unsurprised to know it's not what C-INTERCAL does [1]. It doesn't use a cryptographically secure RNG, sadly (though there's no reason it couldn't), but it does use a RNG and certainly doesn't do what you suggest. If the latter, though, I'm curious about the psychology. As I mentioned, this semantic rabbit hole is irrelevant to the profound wrongness of the paragraph I quoted. Every part of the sentence is wrong: the code isn't using a clever trick to produce seemingly random numbers, it's using the random behaviour built in to the language; %50 doesn't have anything to do with "mingl[ing] the bits of two 16-bit numbers" (that's "interleave", denoted with what looks like a cent symbol); the #1, #2 etc are constants, not unary operations; the fact that different results are produced each time is part of the language behaviour not the result of some trick. If you are defending this, why? [1] https://github.com/calvinmetcalf/intercal/blob/8a65e8ba1cc65870b0d6b1bb174a4c4560bde07f/src/cesspool.c#L838 https://github.com/calvinmetcalf/intercal/blob/8a65e8ba1cc65...