In Javascript, Math.random() produces a float value between 0 and 1, so I multiply by 1000 and round it to get a larger integer. The value %2 == 0 is a non-library way of performing isEven() on the random integer (value % 2 is 0 if even, 1 if odd, and the ==0 makes it return a boolean). When used in the if statement, it’s essentially a coin flip.
does javascript not allow you to interpret integers as booleans in a conditions directly? seems it’d be simpler to just do math.round(math.random()), which should still get you true (1) or false (0) in equal likelihood. or am i missing something?
Yes sure. Code is logical stepwise. By including the “only if” it implies that other stuff is taken into account, which it isn’t at that moment in code.
I mean, I don’t need to extend the implications of an IF statement. It already does exactly what it says.
Anyway fuzzy logic does exist for people who want “sometimes if”. It’s useful in certain cases. I’ve only ever considered it in music production, where things very often get to the point of complexity where it makes a (sometimes) useful difference.
In normal parlance, “if and only if” rules out that something could also happen as a result of other circumstances. EG, if you fall out of a plane, you will lose your glasses. But there are other conditions that would lead to the same result.
In code, the alternative would be to have a different if statement that executes identical code. Or *cough* you could use a jump instruction to execute literally the same code.
what would be the alternative? to always execute if the condition is true, but sometimes execute it even when false, for funsies?
Hey, I like a little chaos in my codebase 😆
const funsies = () => (Math.round(Math.random() * 1000) % 2 == 0) if ( condition || funsies() ) { // do the thing }
Wait, why the the *1000 or mod 2? Won’t that give a 50\50 chance or the same as Math.round(Math.random).
No shade, and I may be wrong myself I am very tired
Probably to make the fractional random value between 0 and 1 to become an integer so that you can divisibility check for even with mod 2
is this AI?
Nope. I’m staunchly against “AI”. If the code sucks, it’s because I wrote bad code.
Edit: Oh, or did you mean is that how “AI” works?
deleted by creator
In Javascript,
Math.random()
produces a float value between 0 and 1, so I multiply by 1000 and round it to get a larger integer. Thevalue %2 == 0
is a non-library way of performingisEven()
on the random integer (value % 2
is 0 if even, 1 if odd, and the==0
makes it return a boolean). When used in theif
statement, it’s essentially a coin flip.does javascript not allow you to interpret integers as booleans in a conditions directly? seems it’d be simpler to just do math.round(math.random()), which should still get you true (1) or false (0) in equal likelihood. or am i missing something?
It’ll give you 1 ~= true or 0 ~= undefined, but I typically use Typescript which prefers actual booleans to boolean-ish
huh. interesting. i wonder what number it’s actually storing for false then?
The “only” part implies exclusivity, which may be false, because other things might run the code anyway.
IF “I can see the sun” THEN “It’s day.”
Nothing wrong about that. However if we make it exclusive:
IF AND ONLY IF “I can see the sun” THEN “It’s day.”
That’s obviously wrong. I can actually not keep the day away by sitting with closed eyes in my mothers basement with the curtains shut.
“Only if” might make sense in a legal contract, but there’s no way a piece of code can stop other pieces of code from calling the same functions.
But that’s not how if statements in code work. So what you’ve said isn’t wrong, but the premise of this meme is completely off
Yes sure. Code is logical stepwise. By including the “only if” it implies that other stuff is taken into account, which it isn’t at that moment in code.
I mean, I don’t need to extend the implications of an IF statement. It already does exactly what it says.
Anyway fuzzy logic does exist for people who want “sometimes if”. It’s useful in certain cases. I’ve only ever considered it in music production, where things very often get to the point of complexity where it makes a (sometimes) useful difference.
In normal parlance, “if and only if” rules out that something could also happen as a result of other circumstances. EG, if you fall out of a plane, you will lose your glasses. But there are other conditions that would lead to the same result.
In code, the alternative would be to have a different if statement that executes identical code. Or *cough* you could use a jump instruction to execute literally the same code.
deleted by creator
Brb, making a truly “if” statement function in my products code base for funsies.