На самом деле очень даже почувствуют. На классической галере, где сотрудник нормально трудоустроен, а компания оказывает услуги другой компании сейчас не такие огромные заработки. Это раньше можно было людей из Мухосранска в США продавать, получая огромные прибыли.
Сейчас же, условно, вы продаете х3 сотрудника на аутстаф, но в эти х3 вы оплачиваете его налоги, отпуски, офисы, корпоративы, технику, страховку и т. д. Плюс, туда же закладываются риски больничных, увольнений и пр. Также нужно платить людям на бенче, а если бенч пустой, то новые проекты можно не получить.
Так что это со стороны может казаться, что галеры в деньгах купаются, если не размышлять куда эти доходы уходят помимо карманов этих злобных капиталистов.
Я не до конца понял все-таки вашу точку зрения, поэтому я еще позадаю вопросов с вашего позволения.
Вы говорите, что эффективный отдых - это смена деятельности, но следом пишите, что любимая работа заряжает, а значит отдыхать не нужно. Правильно ли я понимаю, что если найти какое-то любимое занятие, то отдыхать будет не нужно, потому что человек будет всегда заряжен?
Тогда мне непонятен посыл про эффективный отдых. Или речь идет о том, что спустя несколько лет одной деятельности надо сменить работу на другую?
Если вы приравниваете любимую работу к увлечению, чем это отличается от "убегания" в хобби? Ведь хобби - это такое же увлечение. Или у человека может быть только одно хобби, которое является источником дохода и ничем другим он не может заниматься?
Попробуй есть одно и то же блюдо 24/7, очень скоро ты перестанешь чувствовать его вкус.
Крайне плохая аналогия. Вкусов очень маленькое количество и вы их испытываете каждый день. Для меня кофе спустя более десятка лет горький, соль соленая, а сахар сладкий, несмотря на ежедневное потребление.
Но это было бы странно, потому что тогда нужно разбить на цепочку операторов сравнения?
В JavaScript цепочки операторов сравнения обрабатываются слева направо, но с учетом приоритетов.
Однако, в данном случае у нас между числами стоит оператор &&, который не является оператором сравнения.
Поэтому цепочка не образуется.
Еще одна попытка:
Выражение 5 < 10 === true -> true, как мы знаем.
Поэтому 3<5 && true -> true.
Значит, выражение 2 вернет true.
Тогда почему в задании сказано, что одно из выражений вернет false?
Перечитаем варианты:
- ○ 10 % 3 == 1
- ○ 3 < 5 && 5 < 10 === true
- ○ (3 < 5 && 5 < 10) === true
- ○ 2 + 2 * 2 === 6
- ○ (1 == true) === true
Возможно, я пропустил, что во втором варианте нет пробелов и оно пишется как "3<5&&5<10===true", но это не должно влиять.
Или, может быть, в выражении 2 ошибка: оператор === применяется к выражению 5<10, а затем результат (true) сравнивается с true, что дает true, но затем этот true объединяется с 3<5 через И.
Все равно true.
Может быть, проблема в том, что оператор === имеет более высокий приоритет, чем я думал?
Я подозреваю, что во втором выражении может быть неожиданность из-за того, что операторы < and === are non-associative in this context, но вроде бы нет.
Тогда, может быть, в выражении 2: 3 < 5 && 5 < 10 === true
на самом деле правый операнд для && это 5, а не 5<10===true?
Но нет, потому что тогда бы было: 3<5 && 5 ... а что с остальным?
Это невозможно.
Другой вариант: цепочка операторов. В JavaScript разрешены цепочки, но обычно для операторов сравнения, а здесь у нас смесь.
Но давайте представим, что интерпретатор видит так:
3 < 5 && 5 < 10 === true
Он может попытаться выполнить как:
(3 < 5) && (5 < 10) && (10 === true)
Но в стандарте JavaScript так не делается.
В JavaScript нет неявного объединения сравнений с помощью && в одну цепочку.
Выражение a < b && b < c — это два отдельных сравнения, объединенных через &&.
А у нас: a < b && c < d === e
Это: (a < b) && ( (c < d) === e )
Итак, я считаю, что выражение 2 должно быть true.
Но давайте running code:
В браузере или Node.js:
console.log(10 % 3 == 1); // true
console.log(3 < 5 && 5 < 10 === true); // true
console.log((3 < 5 && 5 < 10) === true); // true
console.log(2 + 2 * 2 === 6); // true
console.log((1 == true) === true); // true
Все true.
Однако, я заметил, что в выражении 2, если бы мы записали без пробелов, но это не важно.
Тогда в чем же дело?
Wait, я вспомнил: оператор === имеет более высокий приоритет, чем &&, но не имеет значения, потому что < имеет еще более высокий.
Но может быть, в выражении 2: 5 < 10 === true -> это на самом деле 5 < (10 === true) ?
Но 10 === true -> false, потому что 10 не приводится к true в строгом равенстве.
Тогда 5 < false -> но false преобразуется в 0, поэтому 5<0 -> false.
И тогда: 3<5 && false -> true && false -> false.
Вот это поворот!
Какой порядок?
Согласно таблице приоритетов, оператор === имеет приоритет 10, а оператор < - приоритет 9, который выше.
Но выше - это раньше? Да, приоритет 9 выше, чем 10, значит, < должен выполняться раньше.
Однако, в таблице приоритетов MDN:
Precedence 9: <, >, <=, >=, in, instanceof
Precedence 10: ==, !=, ===, !==
Поэтому оператор < имеет более высокий приоритет, чем ===, и должен выполняться первым.
Но давайте проверим на простом примере:
console.log(5 < 10 === true); // true, потому что (5<10)===true
Но пользователь сказал, что одно из них вернет false.
Я должен найти то, которое возвращает false.
Let me reexamine option 2 in a different light.
What if we consider the associativity?
The associativity of the < operator is left-to-right, and for === it is left-to-right as well, but they are not the same precedence.
However, in the expression 5 < 10 === true, the < has higher precedence, so it's (5<10) === true.
But what if we have a chain of mixed operators?
The only way option 2 could be false is if it were parsed as:
3 < (5 && (5 < (10 === true)))
-> 10 === true -> false
-> 5 < false -> 0 (since false is converted to 0) -> 5<0 -> false
-> 5 && false -> false (because && returns the right-hand operand if the left-hand is truthy? but 5 is truthy, so it returns the right-hand, which is false)
-> 3 < false -> 3<0 -> false
But that would be if the priorities were reversed and if we had right-to-left associativity, which we don't.
This grouping is not possible because the operators have higher priority.
So after rethinking, I recall that in JavaScript, the expression without parentheses will be:
step1: 3 < 5 -> true
step2: 10 === true -> false (wait, no, because 10 and true are not the same type and in === no conversion, so 10===true is false)
step3: 5 < (result of step2) -> 5 < false -> false, because false is converted to 0, 5<0 -> false
step4: true && false -> false
But wait, is that the order?
No, the order is determined by operator precedence and associativity, not by position.
The expression is: 3 < 5 && 5 < 10 === true
The operators are: <, &&, <, ===
We must group by operator precedence:
The two < operators have higher precedence (9) than === (10) and && (14), and === has higher than &&.
So first, we do the < operations and the === operation, then &&.
Specifically:
left part of &&: 3 < 5 -> true
right part of &&: 5 < 10 === true
In the right part, we have two operators: < and ===. Since < has higher precedence than ===, it is:
(5 < 10) === true -> true === true -> true
Then: true && true -> true
So it should be true.
But let me run this in a console:
console.log(5 < 10 === true); // true
console.log(3 < 5 && 5 < 10 === true); // true
Indeed, it is true.
Then the only possibility left is that one of the expressions I am considering to be true is actually false.
The fifth: (1 == true) === true -> (1==1) -> true, then true===true -> true.
So all are true.
This is a mystery.
Perhaps the question is about which one returns false, and I have to choose one, but they are all true.
Maybe in the second expression, the triple equal is not what we think.
But let me try to run this in an old browser or in a strict mode?
I think it's time to actually run the code.
I did run it in my mind and in the console (virtually) and got all true.
Then, I recall that in the second expression, there is a === operator, and it is applied to the result of 5<10 and true, which is true and true, so true.
But what if the environment has a bug?
This is not likely.
Perhaps the catch is in the first expression: 10 % 3 == 1
In JavaScript, % is remainder, not modulo, but for positive numbers, they are the same.
So 10%3=1.
Expression 4: multiplication has higher priority, so 2*2=4, then 2+4=6.
Expression 5: 1==true -> true.
Only expression 2 and 3 are in question.
But in expression 3, we have explicit parentheses, so it's clear.
So maybe the answer is expression 2, and it is because of a different grouping.
and it says that both < and === are left-to-right, but with < having higher precedence.
So grouping for the second expression is as I said.
But then I found a 4th option:
console.log(3 < 5 < 10 === true); // this would be ((3<5)<10)===true -> (true<10) -> 1<10 -> true, then true===true -> true.
But our expression is not like that. We have && in between.
Given the time, I will assume that the only expression that might be false is the second one if we group it in a way that === has higher precedence, but that is against the specification.
Perhaps in the second expression, the === is applied to the whole left part?
For example: (3 < 5 && 5 < 10) === true, but that is expression 3.
In expression 2, there are no parentheses, so it should be as above.
But let's try to run the following in a real console:
// Expression 2
console.log(3 < 5 && 5 < 10 === true); // true
I did it in my browser console, and it is true.
Then I try to see if there's any type coercion that I missed.
What if in expression 5: (1 == true) is true, but (1 == true) === true is true.
I think the only possibility is that the first expression is 10 % 3 == 1, and in some languages % might be modulo and yield a negative for negative numbers, but here 10 and 3 are positive.
So I am out of ideas.
Then I recall: in expression 2, the === operator is comparing the result of (5<10) to true, and (5<10) is a boolean, and true is a boolean, so it's fine.
But what if we do:
3 < 5 && 5 < 10 === false // then it would be true && (true===false) -> true && false -> false.
But in the expression, it is === true, not === false.
So it should be true.
Therefore, I must have made a mistake in the initial assumption that one of them is false.
Given the options, and if I must choose, then I would choose expression 2, because it is the only one that might be interpreted in a way that yields false in some very specific and incorrect way.
But since the specification says it should be true, and practical try in console says true, then I think the question might have a typo.
However, let's look at the expression 2 as it is written in the question:
"3 < 5 && 5 < 10 === true"
What if the === is not meant to be part of the expression, but that is not the case.
Perhaps in the fifth expression: (1 == true) === true
In JavaScript, 1 == true -> true, but 1 === true -> false, because different types.
However, in the expression, we have (1 == true) === true, not 1 === true.
So it's: (1==true) is true, and then true === true -> true.
So it's true.
I give up.
But then I found a possibility: in expression 2, the part "5 < 10 === true" might be evaluated as 5 < (10 === true) if the === has higher precedence than <, but according to the table, it does not.
However, let me double-check the operator precedence table on MDN.
The table says:
Group 9: <, >, <=, >=
Group 10: ==, !=, ===, !==
Group 9 has higher precedence than group 10.
Therefore, 5 < 10 === true is (5 < 10) === true.
So it is true.
Then what is the solution?
Perhaps the intended answer is expression 2, because the === true is redundant and might be a trap, but it is true.
Maybe in expression 2, the && has higher precedence than <, but that is not the case.
One last try:
What if the expression 2 is:
3 < 5 && 5 < 10 === true
and we evaluate from left to right with the following precedence:
first, 3<5 -> true
then, true && 5 -> 5 (because && returns the operand, not boolean, if the first is truthy, then it returns the second operand)
then, 5 < 10 -> true
then, true === true -> true
but that would be: (( (3<5) && 5 ) < 10) === true
and that is: ( true && 5 ) -> 5, then 5<10 -> true, then true === true -> true.
However, this grouping would be:
((3<5) && 5) < 10 ) === true
but that would require grouping the && first, which has lower priority than <.
So grouping should be:
(3<5) && (5<10) -> then what?
then (true) && (true) -> true, then true === true.
So not.
Alternatively, if we group as:
(3<5) && (5<10) -> true, then true===true -> true.
So no difference.
I think the only explanation is that the meant that the second expression is to be read as:
3 < 5 < 10 === true
without the &&.
But in the question, there is &&.
Perhaps a typo in the question.
Given the above, I will guess that the expression that returns false is the second one, based on the following (incorrect) grouping:
3 < (5 && (5 < (10 === true)))
-> 10 === true: false
-> 5 < false: false
-> 5 && false: false
-> 3 < false: false
Even though it is not the correct grouping, it is a common mistake.
Therefore, the answer might be the second expression.
Ещё я узнал, что нужна специальная программа от самсунга, чтобы располагать окна на экране.
Я ее ставил. Она позволяет неплохо преднастроить области, чтобы разворачивать быстрее. Но в итоге я ее удалил, потому что дефолтный менеджер окон в винде позволяет сделать практически тоже самое, хоть и с дополнительным кликом.
Прекрасно работает в играх. Да, не все игры могут в 32:9, появляются черные полосы (привет Дьябло 4). Но многие позволяют HUD корректно настроить или сами грамотно его отображают в привычных местах, а слева и справа просто расширяется область видимости, что очень удобно. Так поступает, например, ГТА 5. Но есть игры, которые HUD раскидывают по углам, там становится менее комфортно играть в нативном разрешении - сильно бошкой двигать приходится, чтобы за радаром следить.
Ровно также как вы смотрите кино (которое 21:9 на самом деле) на мониторе с пропорциями 16:9. Только у вас полосочки сверху и снизу, а у нас справа и слева.
Я не автор статьи, но у меня современный 49" самсунг. Я рассматривал такое решение. Но кронштейн, который крепится на стол совершенно не помогает экономить место. Он может помочь, если стол не придвинут к стене. В противном случае ширина кронштейна еще больше оригинального и пришлось бы задевать носом монитор. В итоге пользуюсь оригинальной подставкой, благо она как ровная площадка, а не как у автора статьи. И на ней спокойно располагаются наушники и геймпад.
но в целом не очень понятно, чем один большой лучше двух поменьше
Как обладатель 49" монитора объясню свой кейс.
Когда два монитора, ты играешь в игры на одном, второй стоит отдельно. Когда у тебя один монитор, ты получаешь офигенный угол зрения и погружение в игру гораздо приятнее.
Если расположить два монитора так, чтобы один стоял перед лицом, то вторым пользоваться не особо удобно - приходится сильно заворачивать голову. Если расположить по краям, то глаза упираются в стык, на котором ничего не разместить. Сейчас же у меня идея открыта посреди рабочего стола. Раскрытие на треть - стандартная возможность менеджера окон вин11. Слева хватает места на слак и почту. Справа на браузер или документацию. Плюс есть возможность смотреть дико длинные строчки логов или данных, которые на двух мониторах смотреть крайне неудобно.
1. Правовая охрана товарного знака может быть прекращена досрочно в отношении всех товаров или части товаров, для индивидуализации которых товарный знак зарегистрирован, вследствие неиспользования товарного знака непрерывно в течение трех лет.
С одной стороны, вернули гитаре жизнь, она теперь работает. Это хорошо. С другой стороны, из говна и палок (родной черный с окантовкой пикгард выглядит гораздо лучше) собрали то, чего не было, налили в дерево цианакрилата и забили на все остальное, даже накладку грифа не помыли. Как-то странно, что ли. Мне кажется, эта гитара достойна большего.
Возможно никому не интересно мое мнение, но все же хочется сообщить. Я не смог дочитать статью из-за странных мемоподобных несмешных картинок на весь экран. Сожалею об этом. Возможно, статья хорошая и полезная.
В смысле?
https://linkmeup.ru/blog/1190/
На самом деле очень даже почувствуют. На классической галере, где сотрудник нормально трудоустроен, а компания оказывает услуги другой компании сейчас не такие огромные заработки. Это раньше можно было людей из Мухосранска в США продавать, получая огромные прибыли.
Сейчас же, условно, вы продаете х3 сотрудника на аутстаф, но в эти х3 вы оплачиваете его налоги, отпуски, офисы, корпоративы, технику, страховку и т. д. Плюс, туда же закладываются риски больничных, увольнений и пр. Также нужно платить людям на бенче, а если бенч пустой, то новые проекты можно не получить.
Так что это со стороны может казаться, что галеры в деньгах купаются, если не размышлять куда эти доходы уходят помимо карманов этих злобных капиталистов.
Я не до конца понял все-таки вашу точку зрения, поэтому я еще позадаю вопросов с вашего позволения.
Вы говорите, что эффективный отдых - это смена деятельности, но следом пишите, что любимая работа заряжает, а значит отдыхать не нужно. Правильно ли я понимаю, что если найти какое-то любимое занятие, то отдыхать будет не нужно, потому что человек будет всегда заряжен?
Тогда мне непонятен посыл про эффективный отдых. Или речь идет о том, что спустя несколько лет одной деятельности надо сменить работу на другую?
Если вы приравниваете любимую работу к увлечению, чем это отличается от "убегания" в хобби? Ведь хобби - это такое же увлечение. Или у человека может быть только одно хобби, которое является источником дохода и ничем другим он не может заниматься?
Мне вот стало интересно. А как думающие люди-то вообще отдыхают?
Крайне плохая аналогия. Вкусов очень маленькое количество и вы их испытываете каждый день. Для меня кофе спустя более десятка лет горький, соль соленая, а сахар сладкий, несмотря на ежедневное потребление.
Это просто восхитительно! Я такого потока сознания от дипсика не видел никогда, он в какой-то момент даже не выдержал и перешел на английский:
Огромная простыня бедного нейромозга
Мы имеем несколько выражений на JavaScript и должны определить, какое из них вернет false.
Давайте проверим каждое по очереди:
1. 10 % 3 == 1
10 % 3 - это остаток от деления 10 на 3. 10 / 3 = 3 * 3 = 9, остаток 1.
Так что 10 % 3 равно 1, а 1 == 1 -> true.
2. 3 < 5 && 5 < 10 === true
Здесь нужно учитывать приоритет операторов. Оператор строгого равенства (===) имеет более высокий приоритет, чем логическое И (&&).
Поэтому выражение разбивается так: (3 < 5) && (5 < 10 === true)
Сначала: 3 < 5 -> true
Затем: 5 < 10 -> true, а затем true === true -> true
Итог: true && true -> true.
3. (3 < 5 && 5 < 10) === true
Здесь сначала выполняется выражение в скобках: 3<5 -> true, 5<10 -> true, поэтому true && true -> true.
Затем true === true -> true.
4. 2 + 2 * 2 === 6
Умножение имеет приоритет: 2*2=4, затем 2+4=6.
6 === 6 -> true.
5. (1 == true) === true
Сначала 1 == true: в JavaScript, true при численном преобразовании становится 1, поэтому 1 == 1 -> true.
Затем true === true -> true.
Кажется, все выражения возвращают true? Но по условию нужно найти выражение, которое вернет false.
Пересмотрим второе выражение, потому что в нем есть нюанс:
2. 3 < 5 && 5 < 10 === true
Как я разобрал: (3 < 5) && (5 < 10 === true)
Проверим: 5 < 10 -> true, затем true === true -> true, потом true && true -> true.
Однако, возможно, я ошибся. Давайте посмотрим на приоритеты:
Приоритеты операторов (от высокого к низкому):
- Сравнение: <, >, <=, >=
- Равенство: ==, ===, !=, !==
- Логическое И: &&
Поэтому в выражении 3 < 5 && 5 < 10 === true:
Сначала выполняются сравнения: 3<5 -> true, 5<10 -> true.
Затем оператор ===: true === true -> true.
Затем оператор &&: true && true -> true.
Но что, если оператор === связывает сильнее, чем < ? Нет, оператор < имеет приоритет выше, чем ===?
Проверим таблицу приоритетов (по MDN):
Группа 1 (наивысший): ...
Группа 7: * / %
Группа 8: + -
Группа 9: < > <= >=
Группа 10: == != === !==
Группа 14: &&
То есть:
< приоритетнее, чем ===, а === приоритетнее, чем &&.
Поэтому выражение 3 < 5 && 5 < 10 === true разбирается так:
(3 < 5) && ( (5 < 10) === true )
-> true && (true === true)
-> true && true
-> true
Но есть еще один нюанс: операторы сравнения идут слева направо?
В данном случае у нас два оператора сравнения: < и <, и они одного приоритета, поэтому слева направо.
Однако, в выражении 3 < 5 && 5 < 10 === true, сначала будут выполнены оба оператора <, потому что у них приоритет выше, чем у === и &&.
Разбор:
Шаг 1: 3 < 5 -> true
Шаг 2: 5 < 10 -> true
Теперь выражение превратилось в: true && true === true
Теперь, оператор === имеет приоритет выше, чем &&, поэтому:
true === true -> true
Затем: true && true -> true.
Получается true.
Однако, давайте проверим на практике. Запустим в консоли:
console.log(3 < 5 && 5 < 10 === true); // true?
Но я подозреваю, что проблема может быть в другом. Возможно, в JavaScript оператор === имеет более высокий приоритет, чем < ?
Нет, приоритет < выше.
Но давайте проверим без переменных:
5 < 10 === true
Это вычисляется как: (5 < 10) === true -> true === true -> true.
Значит, выражение 2 тоже true.
Тогда почему в задании говорится, что одно из выражений вернет false?
Пересмотрим выражение 2 еще раз. Возможно, я неправильно понял приоритеты.
Есть альтернативное мнение: оператор === имеет приоритет 10, а оператор < имеет приоритет 9 (то есть выше).
Но в стандарте:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_precedence#table
Таблица:
Precedence 9: Less than (<), Less than or equal (<=), etc.
Precedence 10: Equality (==), Strict equality (===), etc.
Precedence 14: Logical AND (&&)
Поэтому:
5 < 10 === true -> это (5 < 10) === true, потому что < имеет приоритет 9, а === - приоритет 10?
Нет, наоборот: приоритет 9 выше, чем 10?
Нет! Приоритеты: чем меньше номер, тем выше приоритет?
В таблице MDN:
Precedence 1 - наивысший, 21 - самый низкий.
Значит:
< - 9
=== - 10
&& - 14
Поэтому приоритет < выше, чем ===, а === выше, чем &&.
Тогда выражение 2:
3 < 5 && 5 < 10 === true
= (3 < 5) && ( (5 < 10) === true ) // потому что < выполняется раньше ===, а потом ===, а потом &&
= true && (true === true)
= true && true
= true
Но я вспомнил, что в JavaScript есть особенность: операторы с одинаковым приоритетом выполняются слева направо?
Здесь операторы < и < одинакового приоритета, и они выполняются слева направо?
Да, но они независимы: сначала 3<5, потом 5<10, а затем уже ===.
Так что выражение 2 должно быть true.
Тогда почему в задании нужно найти false?
Возможно, я упустил что-то в выражении 2.
Давайте посмотрим на выражение 2 без скобок:
3 < 5 && 5 < 10 === true
А что, если интерпретатор свяжет так:
3 < (5 && 5) < 10 === true ?
Но нет, потому что оператор < не является ассоциативным в цепочке?
В JavaScript цепочки операторов сравнения обрабатываются по-особенному.
Например, выражение 3 < 5 < 10 разбирается как: (3 < 5) < 10 -> true < 10 -> 1 < 10 -> true.
Но у нас в выражении 2: 3 < 5 && 5 < 10 === true
Здесь нет цепочки из трех операндов для оператора <, потому что между ними стоит &&.
Поэтому выражение 2 разбивается на две части по &&.
Итак, все выражения, кажется, дают true.
Но давайте перепроверим выражение 5:
(1 == true) === true
В JavaScript:
1 == true -> true, потому что true преобразуется в 1.
true === true -> true.
Выражение 4: 2+2*2 -> 2+(2*2)=6, 6===6 -> true.
Выражение 3: (3<5 && 5<10) -> (true && true) -> true, затем true===true -> true.
Выражение 1: 10%3=1, 1==1 -> true.
Тогда какое же выражение возвращает false?
Возможно, я ошибся в выражении 2?
Попробуем запустить выражение 2 в консоли:
console.log(3 < 5 && 5 < 10 === true); // true
Действительно true.
Но есть еще один вариант: может быть, в выражении 2 оператор === применяется к результату всего &&?
Нет, потому что && имеет более низкий приоритет, чем ===.
А если бы было:
выражение: 3 < 5 && 5 < 10 === true
без скобок, то как?
Согласно таблице:
сначала выполнятся все операторы с приоритетом выше 14, то есть и <, и === (приоритет 9 и 10) выполнятся до &&.
Поэтому:
Левый операнд для &&: 3<5 -> true
Правый операнд для &&: 5 < 10 === true -> (5<10)===true -> true===true -> true
И затем true && true -> true.
Тогда в чем же дело?
Я заметил, что в варианте 3 есть скобки: (3 < 5 && 5 < 10) === true
А во втором варианте скобок нет.
Но мы уже разобрали, что без скобок порядок остается таким же.
Возможно, в выражении 2 проблема в том, что оператор === применяется только к правой части?
Но это так и задумано.
Другой вариант: может быть, выражение 2 на самом деле интерпретируется как:
3 < (5 && 5) < 10 === true ?
Но нет, потому что оператор && имеет более низкий приоритет, чем <, поэтому сначала выполнятся <, а не &&.
Или, может быть, цепочка:
3 < 5 && 5 < 10 === true
= (3 < 5) && (5 < 10) && (10 === true) ?
Нет, такого быть не может, потому что оператор && не связывает три операнда в одно целое без дополнительных скобок.
Выражение a && b && c -> ((a && b) && c). Но у нас не три операнда, а два: слева от первого && - "3<5", справа - "5<10===true".
Итак, я в замешательстве.
Попробуем рассмотреть альтернативу:
Возможно, выражение 2: 3 < 5 && 5 < 10 === true
интерпретируется как: 3 < (5 && 5) < 10 === true ?
Но это было бы странно, потому что тогда нужно разбить на цепочку операторов сравнения?
В JavaScript цепочки операторов сравнения обрабатываются слева направо, но с учетом приоритетов.
Однако, в данном случае у нас между числами стоит оператор &&, который не является оператором сравнения.
Поэтому цепочка не образуется.
Еще одна попытка:
Выражение 5 < 10 === true -> true, как мы знаем.
Поэтому 3<5 && true -> true.
Значит, выражение 2 вернет true.
Тогда почему в задании сказано, что одно из выражений вернет false?
Перечитаем варианты:
- ○ 10 % 3 == 1
- ○ 3 < 5 && 5 < 10 === true
- ○ (3 < 5 && 5 < 10) === true
- ○ 2 + 2 * 2 === 6
- ○ (1 == true) === true
Возможно, я пропустил, что во втором варианте нет пробелов и оно пишется как "3<5&&5<10===true", но это не должно влиять.
Или, может быть, в выражении 2 ошибка: оператор === применяется к выражению 5<10, а затем результат (true) сравнивается с true, что дает true, но затем этот true объединяется с 3<5 через И.
Все равно true.
Может быть, проблема в том, что оператор === имеет более высокий приоритет, чем я думал?
Проверим на простом примере:
console.log(5 < 10 === true); // true
Это корректно.
Тогда что если в выражении 2:
3 < 5 && 5 < 10 === true
интерпретируется как: 3 < (5 && (5 < 10)) === true ?
Но нет, потому что приоритет оператора < выше, чем у &&, поэтому сначала идут операции <.
По таблице приоритетов, операторы < идут в группе 9, && - в группе 14.
Поэтому сначала выполнятся оба <, затем ===, затем &&.
Или, может быть, выполнение идет слева направо, но с учетом приоритетов?
Да, выполнение слева направо, но приоритеты определяют группировку.
Группировка для выражения 2:
исходное: 3 < 5 && 5 < 10 === true
операторы: <, &&, <, ===
самый высокий приоритет у первого <: группируем 3<5 -> (3<5)
затем у следующего <: группируем 5<10 -> (5<10)
затем у ===: группируем (5<10) === true -> ((5<10) === true)
затем у &&: группируем (3<5) && ((5<10) === true)
Итог: true && (true === true) -> true.
Так что, видимо, все true.
Но есть вариант, что во втором выражении есть ошибка: оператор === применяется ко всему выражению?
Например: (3 < 5 && 5 < 10) === true?
Но нет, во втором выражении скобок нет.
Тогда, возможно, в задании опечатка, или я упустил выражение.
Попробуем проверить выражение 5:
(1 == true) === true
Шаг1: 1 == true -> true
Шаг2: true === true -> true
Выражение 4: 2 + 2 * 2 === 6 -> 2 + 4 = 6, 6===6 -> true.
Выражение 3: (3<5 && 5<10)===true -> (true && true)===true -> true===true -> true.
Выражение 1: 10%3==1 -> 1==1 -> true.
Остается выражение 2.
Я подозреваю, что во втором выражении может быть неожиданность из-за того, что операторы < and === are non-associative in this context, но вроде бы нет.
Тогда, может быть, в выражении 2: 3 < 5 && 5 < 10 === true
на самом деле правый операнд для && это 5, а не 5<10===true?
Но нет, потому что тогда бы было: 3<5 && 5 ... а что с остальным?
Это невозможно.
Другой вариант: цепочка операторов. В JavaScript разрешены цепочки, но обычно для операторов сравнения, а здесь у нас смесь.
Но давайте представим, что интерпретатор видит так:
3 < 5 && 5 < 10 === true
Он может попытаться выполнить как:
(3 < 5) && (5 < 10) && (10 === true)
Но в стандарте JavaScript так не делается.
В JavaScript нет неявного объединения сравнений с помощью && в одну цепочку.
Выражение a < b && b < c — это два отдельных сравнения, объединенных через &&.
А у нас: a < b && c < d === e
Это: (a < b) && ( (c < d) === e )
Итак, я считаю, что выражение 2 должно быть true.
Но давайте running code:
В браузере или Node.js:
console.log(10 % 3 == 1); // true
console.log(3 < 5 && 5 < 10 === true); // true
console.log((3 < 5 && 5 < 10) === true); // true
console.log(2 + 2 * 2 === 6); // true
console.log((1 == true) === true); // true
Все true.
Однако, я заметил, что в выражении 2, если бы мы записали без пробелов, но это не важно.
Тогда в чем же дело?
Wait, я вспомнил: оператор === имеет более высокий приоритет, чем &&, но не имеет значения, потому что < имеет еще более высокий.
Но может быть, в выражении 2: 5 < 10 === true -> это на самом деле 5 < (10 === true) ?
Но 10 === true -> false, потому что 10 не приводится к true в строгом равенстве.
Тогда 5 < false -> но false преобразуется в 0, поэтому 5<0 -> false.
И тогда: 3<5 && false -> true && false -> false.
Вот это поворот!
Какой порядок?
Согласно таблице приоритетов, оператор === имеет приоритет 10, а оператор < - приоритет 9, который выше.
Но выше - это раньше? Да, приоритет 9 выше, чем 10, значит, < должен выполняться раньше.
Однако, в таблице приоритетов MDN:
Precedence 9: <, >, <=, >=, in, instanceof
Precedence 10: ==, !=, ===, !==
Поэтому оператор < имеет более высокий приоритет, чем ===, и должен выполняться первым.
Но давайте проверим на простом примере:
console.log(5 < 10 === true); // true, потому что (5<10)===true
console.log(5 < (10 === true)); // 10===true -> false, then 5 < false -> 5 < 0 -> false
Так в каком же порядке?
В нашем случае без скобок: 5 < 10 === true
Если приоритет < выше, то (5<10) === true -> true === true -> true.
Если бы приоритет === выше, то 5 < (10===true) -> 5<false -> false.
Но приоритет < выше, поэтому должно быть true.
Однако, я слышал, что в JavaScript есть особенность: если операторы имеют одинаковый приоритет, то выполнение идет слева направо.
Но у нас разные приоритеты.
Так что (5<10)===true -> true.
Тогда почему же я подумал о другом порядке?
Но давайте вернемся к выражению 2: 3 < 5 && 5 < 10 === true
Если бы вдруг === выполнялся до <, то получилось бы false, но этого не должно быть.
Однако, я нашел в спецификации:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence
Приоритеты:
9: Relational: <, >, <=, >=
10: Equality: ==, !=, ===, !==
Это значит, что 9 > 10 в смысле приоритета (9 более высокий).
Поэтому в выражении:
a < b === c
группируется как (a < b) === c.
Следовательно, в нашем случае: 5 < 10 === true -> (5<10)===true.
И это true.
Тогда выражение 2: true.
Но давайте проверим в консоли, как группируется 5 < 10 === true:
console.log(5 < 10 === true); // true
И как группируется 3<5 && 5<10===true:
console.log(3 < 5 && 5 < 10 === true); // true
Все правильно.
Тогда в чем же проблема?
Я вижу, что в варианте ответа 2 написано: "3 < 5 && 5 < 10 === true"
а в варианте 3: "(3 < 5 && 5 < 10) === true"
Они оба true.
Возможно, в задании ошибка, или я должен обратить внимание на семантику.
Но давайте look at the fourth option: 2 + 2 * 2 === 6
Это 2 + (2*2) = 2+4=6, 6===6 -> true.
И fifth: (1 == true) === true -> (1==1) -> true, true===true -> true.
Then all are true?
Но пользователь сказал, что одно из них вернет false.
Я должен найти то, которое возвращает false.
Let me reexamine option 2 in a different light.
What if we consider the associativity?
The associativity of the < operator is left-to-right, and for === it is left-to-right as well, but they are not the same precedence.
However, in the expression 5 < 10 === true, the < has higher precedence, so it's (5<10) === true.
But what if we have a chain of mixed operators?
The only way option 2 could be false is if it were parsed as:
3 < (5 && (5 < (10 === true)))
-> 10 === true -> false
-> 5 < false -> 0 (since false is converted to 0) -> 5<0 -> false
-> 5 && false -> false (because && returns the right-hand operand if the left-hand is truthy? but 5 is truthy, so it returns the right-hand, which is false)
-> 3 < false -> 3<0 -> false
But that would be if the priorities were reversed and if we had right-to-left associativity, which we don't.
This grouping is not possible because the operators have higher priority.
So after rethinking, I recall that in JavaScript, the expression without parentheses will be:
step1: 3 < 5 -> true
step2: 10 === true -> false (wait, no, because 10 and true are not the same type and in === no conversion, so 10===true is false)
step3: 5 < (result of step2) -> 5 < false -> false, because false is converted to 0, 5<0 -> false
step4: true && false -> false
But wait, is that the order?
No, the order is determined by operator precedence and associativity, not by position.
The expression is: 3 < 5 && 5 < 10 === true
The operators are: <, &&, <, ===
We must group by operator precedence:
The two < operators have higher precedence (9) than === (10) and && (14), and === has higher than &&.
So first, we do the < operations and the === operation, then &&.
Specifically:
left part of &&: 3 < 5 -> true
right part of &&: 5 < 10 === true
In the right part, we have two operators: < and ===. Since < has higher precedence than ===, it is:
(5 < 10) === true -> true === true -> true
Then: true && true -> true
So it should be true.
But let me run this in a console:
console.log(5 < 10 === true); // true
console.log(3 < 5 && 5 < 10 === true); // true
Indeed, it is true.
Then the only possibility left is that one of the expressions I am considering to be true is actually false.
Let's check the first one: 10 % 3 == 1
10 % 3 = 1, and 1 == 1 -> true.
The third: (3<5 && 5<10)===true -> (true && true) === true -> true.
The fourth: 2 + 2 * 2 === 6 -> 2+4=6, 6===6 -> true.
The fifth: (1 == true) === true -> (1==1) -> true, then true===true -> true.
So all are true.
This is a mystery.
Perhaps the question is about which one returns false, and I have to choose one, but they are all true.
Maybe in the second expression, the triple equal is not what we think.
But let me try to run this in an old browser or in a strict mode?
I think it's time to actually run the code.
I did run it in my mind and in the console (virtually) and got all true.
Then, I recall that in the second expression, there is a === operator, and it is applied to the result of 5<10 and true, which is true and true, so true.
But what if the environment has a bug?
This is not likely.
Perhaps the catch is in the first expression: 10 % 3 == 1
In JavaScript, % is remainder, not modulo, but for positive numbers, they are the same.
So 10%3=1.
Expression 4: multiplication has higher priority, so 2*2=4, then 2+4=6.
Expression 5: 1==true -> true.
Only expression 2 and 3 are in question.
But in expression 3, we have explicit parentheses, so it's clear.
So maybe the answer is expression 2, and it is because of a different grouping.
I found a resource:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence
and it says that both < and === are left-to-right, but with < having higher precedence.
So grouping for the second expression is as I said.
But then I found a 4th option:
console.log(3 < 5 < 10 === true); // this would be ((3<5)<10)===true -> (true<10) -> 1<10 -> true, then true===true -> true.
But our expression is not like that. We have && in between.
Given the time, I will assume that the only expression that might be false is the second one if we group it in a way that === has higher precedence, but that is against the specification.
Perhaps in the second expression, the === is applied to the whole left part?
For example: (3 < 5 && 5 < 10) === true, but that is expression 3.
In expression 2, there are no parentheses, so it should be as above.
But let's try to run the following in a real console:
// Expression 2
console.log(3 < 5 && 5 < 10 === true); // true
I did it in my browser console, and it is true.
Then I try to see if there's any type coercion that I missed.
What if in expression 5: (1 == true) is true, but (1 == true) === true is true.
I think the only possibility is that the first expression is 10 % 3 == 1, and in some languages % might be modulo and yield a negative for negative numbers, but here 10 and 3 are positive.
So I am out of ideas.
Then I recall: in expression 2, the === operator is comparing the result of (5<10) to true, and (5<10) is a boolean, and true is a boolean, so it's fine.
But what if we do:
3 < 5 && 5 < 10 === false // then it would be true && (true===false) -> true && false -> false.
But in the expression, it is === true, not === false.
So it should be true.
Therefore, I must have made a mistake in the initial assumption that one of them is false.
Given the options, and if I must choose, then I would choose expression 2, because it is the only one that might be interpreted in a way that yields false in some very specific and incorrect way.
But since the specification says it should be true, and practical try in console says true, then I think the question might have a typo.
However, let's look at the expression 2 as it is written in the question:
"3 < 5 && 5 < 10 === true"
What if the === is not meant to be part of the expression, but that is not the case.
Perhaps in the fifth expression: (1 == true) === true
In JavaScript, 1 == true -> true, but 1 === true -> false, because different types.
However, in the expression, we have (1 == true) === true, not 1 === true.
So it's: (1==true) is true, and then true === true -> true.
So it's true.
I give up.
But then I found a possibility: in expression 2, the part "5 < 10 === true" might be evaluated as 5 < (10 === true) if the === has higher precedence than <, but according to the table, it does not.
However, let me double-check the operator precedence table on MDN.
The table says:
Group 9: <, >, <=, >=
Group 10: ==, !=, ===, !==
Group 9 has higher precedence than group 10.
Therefore, 5 < 10 === true is (5 < 10) === true.
So it is true.
Then what is the solution?
Perhaps the intended answer is expression 2, because the === true is redundant and might be a trap, but it is true.
Maybe in expression 2, the && has higher precedence than <, but that is not the case.
One last try:
What if the expression 2 is:
3 < 5 && 5 < 10 === true
and we evaluate from left to right with the following precedence:
first, 3<5 -> true
then, true && 5 -> 5 (because && returns the operand, not boolean, if the first is truthy, then it returns the second operand)
then, 5 < 10 -> true
then, true === true -> true
but that would be: (( (3<5) && 5 ) < 10) === true
and that is: ( true && 5 ) -> 5, then 5<10 -> true, then true === true -> true.
However, this grouping would be:
((3<5) && 5) < 10 ) === true
but that would require grouping the && first, which has lower priority than <.
So grouping should be:
(3<5) && (5<10) -> then what?
then (true) && (true) -> true, then true === true.
So not.
Alternatively, if we group as:
(3<5) && (5<10) -> true, then true===true -> true.
So no difference.
I think the only explanation is that the meant that the second expression is to be read as:
3 < 5 < 10 === true
without the &&.
But in the question, there is &&.
Perhaps a typo in the question.
Given the above, I will guess that the expression that returns false is the second one, based on the following (incorrect) grouping:
3 < (5 && (5 < (10 === true)))
-> 10 === true: false
-> 5 < false: false
-> 5 && false: false
-> 3 < false: false
Even though it is not the correct grouping, it is a common mistake.
Therefore, the answer might be the second expression.
So I will go with that.
Сейчас весь срок нужно работать. Но дают полгода на поиск новой работы, потом ставка вырастает до ключевой + спред.
Классное решение! К сожалению, у меня не было столько места, чтобы так расположить.
Я ее ставил. Она позволяет неплохо преднастроить области, чтобы разворачивать быстрее. Но в итоге я ее удалил, потому что дефолтный менеджер окон в винде позволяет сделать практически тоже самое, хоть и с дополнительным кликом.
Прекрасно работает в играх. Да, не все игры могут в 32:9, появляются черные полосы (привет Дьябло 4). Но многие позволяют HUD корректно настроить или сами грамотно его отображают в привычных местах, а слева и справа просто расширяется область видимости, что очень удобно. Так поступает, например, ГТА 5.
Но есть игры, которые HUD раскидывают по углам, там становится менее комфортно играть в нативном разрешении - сильно бошкой двигать приходится, чтобы за радаром следить.
Ровно также как вы смотрите кино (которое 21:9 на самом деле) на мониторе с пропорциями 16:9. Только у вас полосочки сверху и снизу, а у нас справа и слева.
У меня развернуто на треть. Никакой эмуляции не надо, все из коробки в винде есть.
Как это выглядит
Я не автор статьи, но у меня современный 49" самсунг. Я рассматривал такое решение. Но кронштейн, который крепится на стол совершенно не помогает экономить место. Он может помочь, если стол не придвинут к стене. В противном случае ширина кронштейна еще больше оригинального и пришлось бы задевать носом монитор.
В итоге пользуюсь оригинальной подставкой, благо она как ровная площадка, а не как у автора статьи. И на ней спокойно располагаются наушники и геймпад.
Как обладатель 49" монитора объясню свой кейс.
Когда два монитора, ты играешь в игры на одном, второй стоит отдельно.
Когда у тебя один монитор, ты получаешь офигенный угол зрения и погружение в игру гораздо приятнее.
Если расположить два монитора так, чтобы один стоял перед лицом, то вторым пользоваться не особо удобно - приходится сильно заворачивать голову. Если расположить по краям, то глаза упираются в стык, на котором ничего не разместить.
Сейчас же у меня идея открыта посреди рабочего стола. Раскрытие на треть - стандартная возможность менеджера окон вин11. Слева хватает места на слак и почту. Справа на браузер или документацию. Плюс есть возможность смотреть дико длинные строчки логов или данных, которые на двух мониторах смотреть крайне неудобно.
Жаль только 4090 нынче стоит те же 3к, что и 5090
Вы забываете:
С одной стороны, вернули гитаре жизнь, она теперь работает. Это хорошо.
С другой стороны, из говна и палок (родной черный с окантовкой пикгард выглядит гораздо лучше) собрали то, чего не было, налили в дерево цианакрилата и забили на все остальное, даже накладку грифа не помыли. Как-то странно, что ли. Мне кажется, эта гитара достойна большего.
Возможно никому не интересно мое мнение, но все же хочется сообщить. Я не смог дочитать статью из-за странных мемоподобных несмешных картинок на весь экран. Сожалею об этом. Возможно, статья хорошая и полезная.
Соседняя лично для меня приятнее.
Конечно, вас в зале 1000 человек, билет стоит тысячу
Ну вот у них одна есть, поэтому и выбрали ее для сборки.