Comments 123
Можно без умножения, деления, дополнительной памяти и экономно по процу. Это калька с Асма на Си.
a=a^b;
b=b^a;
a=a^b;
Насчёт "экономно по процу" уже можно сильно спорить.
Если нужно обменять два значения в памяти, то решения без использования дополнительной памяти просто не существует. Придётся задействовать хотя бы один регистр процессора. В этом случае код с тремя XOR превратится в что-то вроде:
mov r0, [a]
xor r0, [b]
mov [a], r0
xor r0, [b]
mov [b], r0
xor r0, [a]
mov [a], r0
Куча дорогих обращений к памяти/кэшу. Зачем?
Если же у нас RISC-архитектура, то одноременный xor и чтение из памяти будут невозможны, придётся использовать два регистра:
mov r0, [a]
mov r1, [b]
xor r0, r1
; mov [a], r0 - тут, конечно, можно было бы записывать в память временные результаты
; mov [b], r1 - но зачем?
xor r1, r0
xor r0, r1
mov [a], r0
mov [b], r1
А теперь вопрос: зачем нужны эти xor, когда можно просто написать так:
mov r0, [a]
mov r1, [b]
mov [a], r1
mov [b], r0
Если же нужно поменять значения в регистрах общего назначения, тогда:
xchg r0, r1
И только если нужно поменять значения в регистрах, а xchg нет, тогда можно выкатить вариант с тремя xor:
xor r0, r1
xor r1, r0
xor r0, r1
Ну и не стоит забывать, что современные процессоры суперскалярные, регистры в них логические, и простая пересылка все равно будет эффективнее, потому что три вышеуказанных xor зависят друг от друга, следовательно, суперскалярность не будет задействована.
Спасибо за подробности, я уже давно не в теме. Просто задачка напомнила институтские времена, когда препод спрашивал как поменять два регистра местами, по-моему ещё на Motorola m68k мы работали. Ностальгия.
Не забыли, просто в тесте переполнение не портит конечного результата, при решении со сложением-вычитанием. Но лучше либо не допускать, либо чётко понимать что происходит.
var a = 26;
var b = 7000;
a = [(-((a — b) — a)), ((a — b) + b)];
b = a[1];
a = a[0];
После удобного MysqlFront этим нагромождённым недоумением нет желания пользоваться. Максимум загрузить дамп, это он умеет делать быстрее.
Никогда не понимал, как можно работать головой при жаре.
Привыкай комментировать практически каждую часть кода, ведь это значительно упростит анализ кода коллегами
Правильная и отличная мысль, можно мне добавить, что комментировать не в стиле зачем (что делает код ясно из самого кода), а в стиле почему. Почему я делаю unshift в array, а не push?
Я сначала комментирую ненужные куски кода, потом через два-три коммита начинаю их потихоньку стирать. Некоторые куски кода оставляю в комментах жить вообще бесконечно, чтобы в будущем не пытаться переписать код к варианту, когда он был оттестирован как неправильный ранее. Даже изменения в коде часто делаю по алгоритму — сначала добавил нужные символы, потому удалил ненужные. (Особенно это касается изменения статических исходных данных, имён таблиц, полей).
Если какой-то код отлажен, приносит пользу и оброс комментариями, то и комментарии тоже копируются вместе с кодом в новый проект.
Если я взял код у кого-то, то даю ссылку на страницу, откуда взято и т.д.
Идея с комментариями ещё может получить дополнительное развитие. Действительно не стоит ими пренебрегать.
Комментировать стоит только самые сложные или хитрые места кода или тогда, когда «как-то получилось, но второй раз не воспроизведу» вот для этого случая и пишу комментарий, по крайней мере я =)
То, что дальше на север идти будет уже нельзя.
Я тоже вначале поплыл на этом моменте. Но похоже, что компас задаёт не только изначальное направление движения, а вообще всё время пока человек идёт. Т.е это не движение по прямой.
Задачи оказались известны — попробую рискнуть на свежую
В некой тюрьме решили устоить экзекуцию в виде расстрела заключенным, но соблюдая видимость демократии дали возможность спасти свою жизнь
Заключенным написали сзади произвольные целые числа так, что при построении в колонну каждый заключенный видит числа впереди стоящих. Если заключенный называет свое число, он остается жив, иначе расстреливается на месте.
Какая самая оптимальная стратегия для сохранения большего количества жизней?
И вопрос — а почему анонимность
Насчет комментирования — это увеличение времени набора в 1.5-2 раза. лучше давать вместо комментариев вразумительные имена переменным, функциям и прочим сущностям. Числовым константам тоже давать названия.
От языка сильно зависит. Попробуйте пописать на ассемблере без комментирования.
Но для языков высокого уровня верно: код, нуждающийся в комментировании, должен быть переписан.
Самые лучше комментарии — это грамотная структура кода, а самая лучшая документация — это тесты.
Ну и отдельная (не интегрированная в код) документация по API библиотек.
Заключенным написали сзади произвольные целые числа так, что при построении в колонну каждый заключенный видит числа впереди стоящих. Если заключенный называет свое число, он остается жив, иначе расстреливается на месте.
Какая самая оптимальная стратегия для сохранения большего количества жизней?
Если число заключённых конечно, то последний стоящий заключённый преобразует номера впереди стоящих в одно число (типа new LongInteger(GetBytesFromString("1,2,3,435"))), а дальше каждый следующий декодирует число обратно в список и называет свой номер по порядку.
ассемблер — это же не язык, а код — хотя можно спорить чем код отличается от языка.
В бытность молодым я довольно быстро научился читать тест программы с перфокарт.
Но согласен с вами — пишите программы правильно.
с решением отлично как говорится ответ написан явно — но сколько останется в живых?
Останутся живы все, кроме одного.
Язык ассемблера
Ассемблер привязан к архитектуре — то есть он машинно-зависим — то есть по сути это мнемоническая кодировка машинных кодов.
Язык программирования — он прежде всего машинно-независим — это средство записи алгоритмов, которая базируется на определенной структуре данных, базовых алгоритмов и интерфейсов.
Для меня это принципиальная разница
например:
12 23 1 14 16 123 4
сначала спросили последнего, а потом 3-го — какое у него число 1, 11, 114, 1141?
И спасибо за задачу!)
чистый процедурный стиль → функциональный стиль → объектный стиль
Т.е. ООП для вас — вершина эволюции, а функциональщина — лишь шаг к этой вершине?
HeidiSQL — MySQL, MSSQL and PostgreSQL made easy
Кто из них пойдет умываться?
Надеюсь, оба :)
Я помню это как
– Ну как, Василий Иванович, чему ты там научился?
– Да много чему, Петька… Вот, например, науки такие: логика, психология, философия…
– Ой, расскажи про науки!
– Ну, как бы тебе объяснить-то… Представь себе, что в сторону бани идут два мужика: один чистый, а другой грязный. Кто из них идет в баню, а кто мимо?
– А черт их знает!
– Эх ты, Петька! В баню пойдет грязный мужик – чистому-то зачем мыться? Вот тебе пример из логики.
– Здорово, Василий Иванович!
– А вот тебе еще задачка: опять идут два мужика: чистый и грязный. Какой из них в баню идет?
– Ну как же, вы же сами сказали – грязный!
– Эээ, нет – подумай, почему он грязный? Потому, что в баню не ходит! Значит, чистый пойдет! Вот это тебе пример из психологии…
– Ну, Василий Иванович, ты даешь!
– А вот еще послушай: идут два мужика…
– Да задрал ты меня своими мужиками!
– А это уже пример из философии…
что? серьезно? никто еще не сказал, что жквери не нужен? :)
А если серьезно — прикладные вещи конкретной технологии, типа жквери, не нужны, если ты работаешь с микроконтроллерами, например, так что это тупо выбивается из общего списка.
Скажи мне, как может быть такое, чтобы два человека спускались по одной и той же трубе, и один из них испачкал лицо, а другой — нет?! Неужели ты не понимаешь? Весь этот вопрос — бессмыслица, и если ты потратишь жизнь, отвечая на бессмысленные вопросы, то все твои ответы тоже будут лишены смысла!
Источник
Согласен, ваши задачи бессмысленные.
К мышлению это очень слабо относиться.
Например я уже знал решения для половины ваших задач.
А то что не знал легко нагуглил.
Сейчас, когда информация находится на кончике пальцев, только на испытательном сроке можно понять — может человек работать или нет.
P.S. Код с комментариями очень трудно читать. Т.к. «все лгут», а уж комментарии особенно.
Вместо кучи комментариев, я бы предпочел хотя бы 50% покрытие unit-тестами. :-)
— 9-11 пил кофе и читал новости/хабр/статьи
— 11-12 очень продуктивно работал
— 12-13 работал так себе и ждал обед
— 13-14 обед
— 14 и до конца работал в ожидании «когда же домой»
Основной объем работы делался дома с 22 до 02.00. Потом устроился в компанию, где в офисе надо было появляться на 2 часа, где обсуждались насущные вопросы, шаги, корректировались сроки. Работал часов 5-6 в день с максимальным КПД и объем работ выполнял в разы выше, чем на графике 5/2.
Думаю большое количество разработчиков (не обязательно программисты) поймут меня. Бывает настроения нет, а бывает, что прям распирает.
B = B+(A-B)
Задачи не дают никакого челенджа, да и на самом деле на такие задачи не очень трудно натренироваться.
1. a+b-a
2. a+b-b
Первая итерация: А = A + B (7 + 8 = 15), теперь у вас A = 15, B = 8. Вторая итерация: B = A — B (15 — 8 = 7), теперь у нас B = 15, A = 7.
верно так «теперь у нас B = 7, A = 15». а то я подумал, что тут какая-то магия :)
Про оду JQuery. Я давно уже не использую в новых проектах, и ничуть жалею. Обнако, недавно имел удовольствие лицезреть при отладке старого кода, ЧТО под капотом делает метод JQuery.remove для элемента. Я думал это примерно как Node.removeChild, оказалось- там множество циклов и кода при вызовах различных достаточно непростых функций. Весьма любопытно, как такое скажется на прризводительности...
В разработанной вами системе я бы постоянно затаривался товарами со стоимостью <= 24 руб)
Есть постоянное изучение фреймворков, языков, библиотек и апи, есть дибилы-заказчики и упыри-аутсорсеры, есть сайты на ___ПЯТЬСОТ МЕГАБАЙТ КОДА И СОТНИ ЧЁРТОВЫХ БИБЛИОТЕК ___, есть надо сделать вчера, есть случайные падения сервера, есть падения гита которых не ожидаешь, есть твои приложения, которые менеджер передумал выпускать.
При условии того, что ты проплаваешь во всём этом дерьме года три а лучше пять ты сможешь уехать в #ТАЙ и писать на аутсорс говнокод не парясь по поводу его качества.
Только это довольно хреновый путь. Потому, что толком программировать ты так и не научишься, зато научишься пихать в любой проект Angular и jQuery, потому что это «ускоряет» разработку.
Программистами не рождаются а становятся. Изучая теорию, читая чужой код, разбираясь в принципах работы сетей, учась администрировать сервера. Тратя на это почти всё своё свободное время. А эта статья о том, что ты избранный и тебя ждёт #ТАЙ, просто маркетинговый буллшит.
На другой стороне, пока вы с волком грести бкудете, коза начнет поедать капусту.
Что такое идти на северо-восток? У этого понятия есть 2 трактовки: выбрать направление и идти, не сворачивая; и ваш вариант с непрерывной корректировкой. Про магнитный полюс тоже уже написали выше.
Например, фраза
Какая конечная точка будет у вашего путешествия, которое в действительности может продолжаться бесконечно долго, но все же закончится в конкретной точке?однозначно определяет, что имелось в виду под «идти на северо-восток».
Но я соглашусь, что программист, по-ковбойски интерпретирующий задачу первым пришедшим в голову способом, опасен)
Задачи «на логику» сами должны быть чёткими и логичными. Потому что без внесения достаточного уровня абстракции они просто не работают. Невозможно идти постоянно на северо-восток: кроме гор и морей мы упрёмся ещё и в дискретность шага. Если корректировки очень редки, то можно вообще никогда не остановиться. Математика это не влезание в голову к спрашивающему, а работа только своей.
Общение с заказчиком это не головоломка, не математическая задача, это совершенно ортогональный навык. Там как раз наоборот требования нелогичны и противоречивы и часто вообще не соотносятся с тем, что действительно удовлетворит потребности. И безполезно лезть в голову к кому-либо, там всё равно ответа нет. Его надо создать.
А «кодер» как раз ищет наиболее простое логичное решение в задаче. Например, (A, B) = (B, A), потому что «в моём языке так можно».
решения a=a^b;
и a = a + b
— это не классическая математика, потому что в математике запрещено повторное присваивание.
Бред не несите. Переменные и в математике переменные.
По вашим суждениям тогда уж и задача бессмысленна.
Повежливей, пожалуйста.
В математике используется одноразовое связывание. Не бывает так, что в начале решения уравнения у вас x = 42, а в середине x = 43.
Задача бессмысленна по своей сути, потому что на высокоуровневых языках пишут a,b = b,a
. A на низкоуровневых языках у вас возникает проблема переполнения, чтобы решить которую понадобиться написать еще несколько проверок.
Заказал кучу техники в тот день в том магазине, но магазин нисколечко не сомневаясь отменил все мои заказы)
Почему-то ожидал, что будет статья о работе программистом в Таиланде. Тут уже писал человек, который жил и работал там не удаленно.
Лучшее мнение о Тайланде, что мне приходилось слышать — http://artgorbunov.ru/bb/soviet/20130304/
Последние пять лет каждый год провожу по месяцу в тае, с планами «заодно и поработаю». И каждый раз думаю заранее — «ну теперь точно поработаю». И каждый раз оказывается что работать совершенно невозможно… Что-то я, конечно, делаю — но производительность оставляет желать.
1) умываться идут оба (один за компанию)
2) умываться пойдет только грязный
3) умываться пойдет только чистый (почему бы и нет)
4) никто не пойдет умываться (им, может, еще раз в трубу надо будет лезть)
Есть два варианта решения второй задачи. В обоих предполагается, что мы рассматриваем движение одной материальной точки в другую и пренебрегаем скоростью вращения земли. Мы также предполагаем, что исходная точка не находится ни на одном из посюсов.
В первом варианте мы выбираем направление и движемся прямо. В этом случае траектория пути будет эллипсом, а двигаться мы будем бесконечно.
Во втором варианте в каждый момент времени вектор скорости движущейся точки указывает на северо-восток. Так как в отличие от севера и юга восток является относительным понятием (задаётся отношением магнитных сил, которые действуют с разных полюсов), с приближением к северному полюсу вектор будет всё сильнее указывать на север, но никогда не покажет строго на него. В результате траекторией движения будет локсодрома. Конечной точкой пути будет северный полюс, но достигаться он будет бесконечно долго. Всё это верно для математической модели. В реальном мире компас при приближении к полюсу перестанет работать.
Конечной точкой пути будет северный полюс, но достигаться он будет бесконечно долго.
(1) Это если идти всё медленнее и медленнее, иначе дойдём за конечное время (сделав каким-то образом бесконечное число витков воруг полюса).
(2) Для большинства практических приложений достаточно приблизиться к полюсу на расстояние равное размеру атома.
2. Про то, что надо будет плыть, уже написали. Но скорее всего надо определить, насколько мне можно отклоняться от строгого «северо-восток». Если нельзя, то до ближайшей стены.
3. Недостаточно условий для решения. Например, пойдёт умываться тот, кто всегда умывается после дымохода.
Странные у вас задачи.
Я не утверждаю, что любой проект обречён в Тае на провал, а любой программист — на забвение. Нет. Я просто хочу сказать: из «сработало у меня» не следует «сработает у всех». Автор путает квантор всеобщности с квантором существования.
я смогу сделать через HeidiSQL за 1 минуту.
Если Хейди неожиданно не крашнется, что иногда выбешивает.
Все программисты попадают в #ТАЙ