То-же самое
f(1) || (f(2) + f(3))
Если f(1) == true, правую часть считать бессмысленно.
f(0) || (f(2) + f(3))
Выводит f(0) (f(2) f(3))
А в документации должен быть описан ход работы парсера интерпретатора? Здесь примитивная логика, которую даже разъяснять смысла нет, поэтому никто и не пишет об этом. В документации описан конечный результат логического выражения. Вам шашечки, или ехать? :) Вообще не вижу смысла Ваших упражнений. Если сомневаетесь в приоритетах операций, добавляйте скобки. "Уличить" создателей интерпретатора Вам не удастся, все там работает, как написано.
Что значит "будет"? Откуда-то и в каком-то формате эти данные будут-же поступать? Тут либо через вложенные запросы, либо через единый массив аргументов. Повторюсь, я ни задачи Вашей не знаю, ни фреймворка этого. Но в любом случае формировать массив из > 1000 элементов для единого запроса к БД, это, IMHO, многовато, как-то оптимизировать это дело нужно.
+1. Например "МикроЭВМ своими руками" В.Тищенко 1989г. Собирать полностью, наверное, смысла нет, чисто по электронике немало возни выйдет, а вот подробно изучить будет полезно ( двоичная логика, доступ к памяти, цифровые шины, мультиплексоры и.т.д. ). По большому счету, в цифровой электронике в целом и в работе ЭВМ в частности, изменилось немногое, частоты выросли да объемы носителей для хранения данных увеличились. :) Весь вышеперечисленный фундаментальный материал конечно-же понадобится, но позже, когда перестанет быть "китайской грамотой".
profesor08, требуемая пирамида будет видна даже в консоли отладчика, без лишних движений, к которым Вы призываете. Если у ТС сейчас проблемы с пониманием циклов, то работа с массивами, IMHO, это последнее, о чем ему нужно думать. :)
profesor08, не согласен. IMHO, нужно самому понимать структуру выводимых данных. К тому-же для console.table нужно специально формировать массив. С console.log не нужно подгонять структуру программы под отладочный вывод. Ну и пошаговый отладчик в браузере весьма полезная штука, всем рекомендую, безо всяких IDE программу по шагам прогнать можно.
Практика и только практика. Я когда учился, ни интернета, ни обучающих видеоуроков не было. Первым был Бейсик, в кружке по программированию при институте, в 8-м классе учился. Потом немного Фортран. Из уже серъезного - Си. Потом все остальное.
+1. Для 20-ти итераций надо либо for (let i = 1; i <= 20; i++), либо for (let i = 0; i < 20; i++) И.т.д. Разберитесь сначала хотя-бы с этим. Вместо document.write(n); удобнее использовать консоль отладчика и console.log(n);
Ничего личного, просто предостережение. :) Контроллер наклеиваемой на монитор пленки touch-screen о которой говорил Владимир Проскурин ( по крайней мере те, которые видел я), будучи подключенным к USB, прикидывается манипулятором "мышь" и шлет в систему события нажатие кнопок оной в координатах соответствующих точке нажатия. Подобную операцию можно с обычным монитором провернуть. Да и то, лично я плохо представляю, как получится после наклейки touch-screen, собрать монитор обратно и ещё после обеспечить подключение контроллера, т.к. у этой пленки есть свои поля, толщина, контроллер на плате, интерфейсные и питающие провода. А после установки такого бутерброда в ноутбук, то не представляю вообще, что за ноутбук получится и как он будет открываться-закрываться. Собственно мысль очень проста: вряд-ли Вам доводилось разбирать-собирать ноутбуки, иначе Вы не спрашивали-бы о том, о чем спросили. Поэтому, IMHO, для желающих получить опыт разработки с сенсорными экранами есть четыре пути: 1. Купить ноутбук с изначально сенсорным экраном ( дорого ). 2. Купить монитор с изначально сенсорным экраном ( тоже недешево ). 3. Купить touch-screen нужного размера, разобрать монитор, наклеить и пользоваться не собирая монитор обратно, хотя, с монитором на ЭЛТ имеющем плоский экран, может и получится собрать ( дешевле, чем п.1 и п.2, но для игрушек, тоже дорого. По крайней мере у меня лишних ~10 000 нет). 4. Купить сенсорный монитор от торгового терминала/ларька ( дешево и сердито ). Я такой от киоска Kodak недавно купил на 24au.ru всего за 700. Он выглядит как уже готовый монитор. Повесил на стену рядом с сервером, будет средоточием моего "умного дома". Повторюсь, понятия "дорого"/"дешево" применяю соотнесясь с собственным бюджетом, объем которого, разумеется, у каждого свой. :)
Человек, который написал :
{
новичку лучше начать с простого и удобного
потом при желании перейти на С и С++ не сложно
}
IMHO, и близко не знает ни С, ни С++.
А Вы не видите разницы? C JSON-данными MySQL работает ( ищет, модифицирует ) посредством встроенных функции. Не подскажете, как средствами MySQL найти что-либо в строке подобной следующей : "1|21.02.2012#10#23.02.2012|24.02.2012#10#29.02.2012"? В данной реализации это типовой случай, попадаются и такие: "0|02.03.2012#10#02.03.2012|16.03.2012#5#23.03.2012|16.03.2012#5#02.03.2012|16.03.2012#5#|16.03.2012#5#24.04.2012|17.04.2012#15#17.04.2012|17.04.2012#15#30.04.2012|17.04.2012#15#04.05.2012|17.04.2012#15#02.05.2012|30.04.2012#15#28.05.2012|04.05.2012#15#24.05.2012|21.05.2012#15#11.06.2012|13.06.2012#15#15.06.2012|15.06.2012#15#09.07.2012|05.07.2012#15#27.07.2012|05.07.2012#15#24.07.2012|19.07.2012#15#26.07.2012|31.07.2012#15#07.08.2012|17.08.2012#15#07.09.2012|03.09.2012#15#05.10.2012|09.10.2012#15#30.10.2012|25.10.2012#15#|13.11.2012#15#15.01.2013|13.11.2012#15#20.12.2012|17.12.2012#15#30.01.2013|25.01.2013#15#|28.01.2016#4#05.02.2016|11.02.2016#4#12.02.2016|02.03.2016#4#11.03.2016|20.04.2016#4#20.04.2016". Просто строка и строка в виде "[145, 39]" для MySQL ни хрена не одно и то-же. Может быть и лучше, как советуете Вы, я для этого здесь вопросы и задаю. Просто хочется максимум работы свалить на MySQL-сервер, чем после разгребать выборки вручную.
В предыдущем решении так и было, все в одну кучу. Особенно порадовал подход, когда данные из массива значений склеиваются в одну строчку с вертикальным слешем в качестве разделителя. Причем создатель всей этой хрени считает, что это нормальный подход. Сложность сейчас в том, что таблиц с разными сущностями будет несколько, х.з. сколько вообще. К примеру, сейчас рассматриваю такое решение. Есть таблица links и в ней поля id автоинкремент, первичный индекс, link_type_id ( int ) тип связи ( email, моб. тел, раб. тел, Telegram и.т.д ) data_digital ( int ) для телеф. номеров, data_alpha ( varchar ) для текстовых данных. Данные для связи могут быть и у пользователей, и у контрагентов и у родственников пользователей, т.е. завести user_id в таблице links не получится, неизвестно какой id там будет храниться. Завести поле link_id собственно в целевых таблицах тоже нельзя, так как контактов для связи может быть несколько. Для этого в каждой такой таблице я завел поле links типа JSON, где храню массив id из таблицы links типа [ 101, 115 ] и.т.д. Связь типа LEFT JOIN links on JSON_CONTAINS( users.links, CAST( links.id AS JSON ) ) работает, запросов таких будет немного, но я почти совсем не работал с JSON в MySQL. Как вам такой подход?
Спасибо, примерно так я сейчас и предлагаю. И сотрудники, и их родственники в одной таблице, ссылки на степень родства в другой таблице, контакты для связи с описанием в третьей таблице ( тел. мобильный, рабочий, e-mail, WhatsApp и.т.д ), адрес с разбивкой на страну, город и улицу. Родственников может быть несколько, телефонов и e-mail тоже. Просто хотелось-бы посмотреть и сравнить с готовым решением.
f(1) || (f(2) + f(3))
Если f(1) == true, правую часть считать бессмысленно.
f(0) || (f(2) + f(3))
Выводит f(0) (f(2) f(3))
А в документации должен быть описан ход работы парсера интерпретатора? Здесь примитивная логика, которую даже разъяснять смысла нет, поэтому никто и не пишет об этом. В документации описан конечный результат логического выражения. Вам шашечки, или ехать? :) Вообще не вижу смысла Ваших упражнений. Если сомневаетесь в приоритетах операций, добавляйте скобки. "Уличить" создателей интерпретатора Вам не удастся, все там работает, как написано.