Это не сработает. Если вы предлагаете мысленный эксперимент — то у человека уже явно проблемы с такими вещами, это его не убедит. В его мыслях лазер никуда не поднимется.
Если реальный — то для «подъёма» лазера на один метр лодку нужно будет удалить на ~3.5 км, чего не каждый лазер сможет достигнуть. Чего уж тут говорить о том, что любые заметные изменения лазера будут нивелированы банальными волнами, да и чётко прицелить лазер не получится — его, по идее, нельзя двигать. А если двигать можно — то любые изменения будут списаны на счёт движения лазера.
Вы как-то странно переиначили мою фразу. Речь не шла о том, что вы треть дня играли в танки, а теперь «можете помочь компании», перестав играть. Речь шла именно о том, что вы выросли, и теперь можете больше, чем раньше.
Про зарплаты в отрасли вопрос более эфемерный, нет чёткого показателя как «зарплата в отрасли», который можно было бы посмотреть в справочнике, поэтому этот аргумент найдёт кучу вариантов типа «вот давай откроем хэдхантер, я тебе там кучу вакансий покажу на меньшие деньги»,
То есть, либо разговор с угрозами, коими безусловно являются рассказы про оффер от другой компании, либо работа на голом энтузиазме? Это чёрно-белый взгляд на вещи.
Если вы не можете вести деловые разговоры никак иначе, как с позиции силы — это вполне ваше право, можете так и поступать, это — вполне вариант достижения цели. Однако, альтернативы есть.
> Кто-то сведущий в теории переговоров пусть меня поправит, но торговаться можно только с позиции силы
Ну, давайте попробую поправить.
Только с позиции силы следует разговаривать лишь в случае ответной реакции, как контраргумент. Так можно разговаривать и в других ситуациях, но как вы представляете себе работу с людьми, с которыми вам нужны козыри для простого разговора о зарплате? С другой стороны, конечно, и такое работает — когда деньги важнее отношений с коллегами, почему бы и нет? То есть, разговор с позиции силы — это инструмент конкуренции, а не сотрудничества.
Простое общение с руководителем на тему «а почему бы тебе, родной, не повысить мне зарплату?» — это инструмент сотрудничества, но он сработает только если руководитель весь такой из себя душка. Но душки обычно руководителями не становятся. Либо становятся, но не надолго, повышая всем зарплаты и разоряя компанию.
Третий вариант — тоже сотрудничества (симбиоз, если хотите), но основанный на понимании того, что оба выиграют в результате переговоров. Это диалог в стиле «я могу дополнительно помочь компании ещё вот так, так и вот так, но компания должна помочь мне». Под «помочь» может быть всё, на что хватит фантазии.
В конечном итоге, преимущества от повышения зарплаты должны перевешивать риски от отказа.
И вы дальше описываете, очевидно, действия телепата, верно? Про кучу тестовых кейсов, хоть и не полную?
Тесты написаны, реализация готова, запускаем в продакшен
Без интеграционных тестов? Без тестирования вручную? Да, похоже на работу телепата.
В итоге, вы ограничили себя только одним методом поиска ошибок, за что и поплатились. Я даже не хочу рассыпаться рассуждениями о том, что после изменения алгоритма, вам, судя по всему, придётся переписывать тесты.
Я вам привёл пример, как знание внутренней кухни позволяет учесть больше вариантов.
А может и меньше. В вашем примере вы могли учесть только два своих «класса» данных — чётный и нечётный, и забить на, например, совпадения.
Вот и получается, что в случае, когда ты ещё не знаешь точно какой у тебя будет интерфейс (а это большинство случаев)
В смысле — интерфейс? У вас функция сортировки какой-то необычный интерфейс имеет, который изменился во время реализации?
А тестирование белого ящика эффективней, так как программист знает все внутренние критические точки. TDD же провоцирует тестировать чёрный ящик, когда реализации ещё нет и соответственно ты не знаешь при каких значениях у тебя может всё сломаться.
Первое, чёрный ящик позволяет отвлечься от того, как у вас там всё работает и представить себя «внешним наблюдателем», не замыленным взглядом взирающим на код.
Второе, знание того, как всё работает может соблазнить писать тесты только под те случаи, которые реально были учтены в коде, оставляя за скобками неучтённые варианты.
Третье, я не вижу вообще никакой причины использовать только чёрный или белый ящик, только TDD или TLD. Почему бы не написать тесты в начале, до того как вы знаете что внутри, а потом — после написания кода, обеспечивая покрытие?
Вашей функции дали плохие данные. Вы сообщаете об этом факте — это хорошо.
Но после сообщения вы возвращаете, опять-таки, плохие данные. Ваша функция — её контракт, если хотите — вернуть имя пользователя. null — это не имя пользователя ни в коей мере, вы проталкиваете плохие данные дальше, рискуя:
1. Упасть где-то ещё — проблемы с нахождением первопричины ошибки
2. Испортить пользовательские данные
3. Где-то ещё плодить кучу костылей, героически справляясь со своим кривым дизайном
> Это не аргумент основанный на личности оппонента, а аргумент основанный на том, что оппонент не имеет соответствующих знаний и образования
Вы противоречите сами себе.
> Что до моего образования — то это второй мед, отделение биохимии, хоть и ни дня не работал по специальности, но некоторое понимание темы имею
Тогда тот факт, что единственное, что вы можете сказать по статье — это то, что у автора не то образование, заставляет, во-первых, считать статью правдивой, а автора — эрудированным настолько, что может рассуждать грамотно о том, чему не обучался долгие годы.
Ну не относитесь, пройдите мимо. Вы же — тоже не химик-биолог, как я могу предположить.
Ваш посыл является логической ошибкой ad hominem ( https://ru.wikipedia.org/wiki/Ad_hominem ).
Кстати, посыл «Впрочем, остальные комментарии — неплохо характеризуют статью» — это ещё один способ использовать эту ошибку. В статье по ссылке она описывается в «Нахождение легко критикуемого единомышленника».
Во-первых, как я уже предложил ниже, давайте придём к общему пониманию понятия «вычислительной эффективности». Что вы понимали под ним в статье?
Во-вторых, на мой взгляд, асимптотическая сложность — это главный (и если мы говорим об аналитике, то единственный) критерий вычислительной эффективности алгоритма. Следовательно, алгоритм с лучшей асимптотикой будет эффективнее.
как Вам указали выше, вы не сможете сделать различие между алгоритмами с одинаковой O-асимптотикой.
На уровне анализа — не сможете, конечно. Эта разница проявится только во время измерений. И результаты могут вас удивить.
Да, общий случай — это такой случай, который включает все частные. То есть, и те матрицы, с которыми реально работают инженеры, и малюсенькие, и огромные, которые, возможно, никогда и не понадобятся. Или понадобятся через тысячи лет.
И вот в общем случае алгоритм с лучшей асимптотикой эффективнее.
Из O(1) следует только ограниченность, но не следует, что невозможно подобрать мажорирующую функцию, которая будет точнее описывать поведение исследуемой функции.
А зачем вообще, по-вашему, подбирать мажорирующую функцию, если у нас уже есть исследуемая? Какой в этом смысл?
Повторюсь, Вы просто подменяете понятия, называя «эффективностью алгоритма» его «асимптотическую сложность», в то время как это понятие включает в себя в том числе и поведение вычислимой функции на наборах данных конечной и даже конкретно фиксированной размерности.
Пожалуйста, приведите определение понятия «эффективность алгоритма», чтобы впредь избежать подмены, в которой вы меня обвиняете. Учитывая, что в статье определения нет, то со ссылкой на литературу. Вполне возможно, что мы под эффективностью алгоритма понимаем разные вещи.
Конечно, реальный. И пример правильный. Неправильный только вывод.
Ваш вывод
Нельзя утверждать, что один алгоритм эффективнее другого на основании простого сопоставления их O-оценок.
на мой взгляд, неверен.
Один алгоритм может быть эффективнее на ограниченном наборе значений n. Но это как сравнивать O(n) и O(log n). Можно найти пару конкретных вариантов, когда O(n) будет быстрее, но это не делает сам алгоритм эффективнее.
Человек, который, как у вас в примере, имеет именно такой случай и конкретные задачи должен это понимать.
PS. Кстати, на ограниченном наборе значений, как вы сами ловко подметили, у неё O(1), так что асимптотика теряет свой смысл.
Нельзя утверждать, что один алгоритм эффективнее другого на основании простого сопоставления их O-оценок.
А не о применимости в реальной жизни. И я уточнил, что это «в общем случае». Вы второй человек который пишет в ответ про реальную жизнь.
В реальной жизни очень много переменных, которые придётся учитывать и сделать это точно слишком сложно (если вообще возможно), проще измерять. По измерениям, на реальных матрицах эффективнее алгоритм Штрассена? Используйте его. Но это не значит что он сразу стал эффективнее, напротив.
Если мы да же не может утверждать, что быстрая сортировка эффективней сортировки слиянием.
Эти сортировки одного класса и в рамках Big-O они равны.
Я могу утверждать, что в общем случае быстрая сортировка быстрее пузырьковой, так как они разного класса.
Или же сортировка 5 элементов пузырьком не эффективней быстрой сортировки?
Вы же даже процитировали меня, где я пишу «в общем случае». Разве сортировка 5 элементов — это общий случай?
В частных случаях Big-O может не давать ответа на вопрос, какой алгоритм лучше, тут нужны измерения. Но Big-O говорит о том, что мало смысла проводить сравнения с, например, пузырьковой сортировкой по умолчанию.
На голосовании однозначно победит. Тогда можно будет покупать пиво за три эбля.
Если реальный — то для «подъёма» лазера на один метр лодку нужно будет удалить на ~3.5 км, чего не каждый лазер сможет достигнуть. Чего уж тут говорить о том, что любые заметные изменения лазера будут нивелированы банальными волнами, да и чётко прицелить лазер не получится — его, по идее, нельзя двигать. А если двигать можно — то любые изменения будут списаны на счёт движения лазера.
Про зарплаты в отрасли вопрос более эфемерный, нет чёткого показателя как «зарплата в отрасли», который можно было бы посмотреть в справочнике, поэтому этот аргумент найдёт кучу вариантов типа «вот давай откроем хэдхантер, я тебе там кучу вакансий покажу на меньшие деньги»,
Если вы не можете вести деловые разговоры никак иначе, как с позиции силы — это вполне ваше право, можете так и поступать, это — вполне вариант достижения цели. Однако, альтернативы есть.
Ну, давайте попробую поправить.
Только с позиции силы следует разговаривать лишь в случае ответной реакции, как контраргумент. Так можно разговаривать и в других ситуациях, но как вы представляете себе работу с людьми, с которыми вам нужны козыри для простого разговора о зарплате? С другой стороны, конечно, и такое работает — когда деньги важнее отношений с коллегами, почему бы и нет? То есть, разговор с позиции силы — это инструмент конкуренции, а не сотрудничества.
Простое общение с руководителем на тему «а почему бы тебе, родной, не повысить мне зарплату?» — это инструмент сотрудничества, но он сработает только если руководитель весь такой из себя душка. Но душки обычно руководителями не становятся. Либо становятся, но не надолго, повышая всем зарплаты и разоряя компанию.
Третий вариант — тоже сотрудничества (симбиоз, если хотите), но основанный на понимании того, что оба выиграют в результате переговоров. Это диалог в стиле «я могу дополнительно помочь компании ещё вот так, так и вот так, но компания должна помочь мне». Под «помочь» может быть всё, на что хватит фантазии.
В конечном итоге, преимущества от повышения зарплаты должны перевешивать риски от отказа.
И вы дальше описываете, очевидно, действия телепата, верно? Про кучу тестовых кейсов, хоть и не полную?
Без интеграционных тестов? Без тестирования вручную? Да, похоже на работу телепата.
В итоге, вы ограничили себя только одним методом поиска ошибок, за что и поплатились. Я даже не хочу рассыпаться рассуждениями о том, что после изменения алгоритма, вам, судя по всему, придётся переписывать тесты.
А может и меньше. В вашем примере вы могли учесть только два своих «класса» данных — чётный и нечётный, и забить на, например, совпадения.
В смысле — интерфейс? У вас функция сортировки какой-то необычный интерфейс имеет, который изменился во время реализации?
Первое, чёрный ящик позволяет отвлечься от того, как у вас там всё работает и представить себя «внешним наблюдателем», не замыленным взглядом взирающим на код.
Второе, знание того, как всё работает может соблазнить писать тесты только под те случаи, которые реально были учтены в коде, оставляя за скобками неучтённые варианты.
Третье, я не вижу вообще никакой причины использовать только чёрный или белый ящик, только TDD или TLD. Почему бы не написать тесты в начале, до того как вы знаете что внутри, а потом — после написания кода, обеспечивая покрытие?
Но после сообщения вы возвращаете, опять-таки, плохие данные. Ваша функция — её контракт, если хотите — вернуть имя пользователя. null — это не имя пользователя ни в коей мере, вы проталкиваете плохие данные дальше, рискуя:
1. Упасть где-то ещё — проблемы с нахождением первопричины ошибки
2. Испортить пользовательские данные
3. Где-то ещё плодить кучу костылей, героически справляясь со своим кривым дизайном
Вы противоречите сами себе.
> Что до моего образования — то это второй мед, отделение биохимии, хоть и ни дня не работал по специальности, но некоторое понимание темы имею
Тогда тот факт, что единственное, что вы можете сказать по статье — это то, что у автора не то образование, заставляет, во-первых, считать статью правдивой, а автора — эрудированным настолько, что может рассуждать грамотно о том, чему не обучался долгие годы.
Ваш посыл является логической ошибкой ad hominem ( https://ru.wikipedia.org/wiki/Ad_hominem ).
Кстати, посыл «Впрочем, остальные комментарии — неплохо характеризуют статью» — это ещё один способ использовать эту ошибку. В статье по ссылке она описывается в «Нахождение легко критикуемого единомышленника».
Иначе, один алгоритм не может быть эффективнее другого, так как всегда найдётся какой-нибудь частный случай, когда один алгоритм не хуже другого.
Во-вторых, на мой взгляд, асимптотическая сложность — это главный (и если мы говорим об аналитике, то единственный) критерий вычислительной эффективности алгоритма. Следовательно, алгоритм с лучшей асимптотикой будет эффективнее.
На уровне анализа — не сможете, конечно. Эта разница проявится только во время измерений. И результаты могут вас удивить.
И вот в общем случае алгоритм с лучшей асимптотикой эффективнее.
Пожалуйста, приведите определение понятия «эффективность алгоритма», чтобы впредь избежать подмены, в которой вы меня обвиняете. Учитывая, что в статье определения нет, то со ссылкой на литературу. Вполне возможно, что мы под эффективностью алгоритма понимаем разные вещи.
Ваш вывод
на мой взгляд, неверен.
Один алгоритм может быть эффективнее на ограниченном наборе значений n. Но это как сравнивать O(n) и O(log n). Можно найти пару конкретных вариантов, когда O(n) будет быстрее, но это не делает сам алгоритм эффективнее.
Человек, который, как у вас в примере, имеет именно такой случай и конкретные задачи должен это понимать.
PS. Кстати, на ограниченном наборе значений, как вы сами ловко подметили, у неё O(1), так что асимптотика теряет свой смысл.
В реальной жизни очень много переменных, которые придётся учитывать и сделать это точно слишком сложно (если вообще возможно), проще измерять. По измерениям, на реальных матрицах эффективнее алгоритм Штрассена? Используйте его. Но это не значит что он сразу стал эффективнее, напротив.
Эти сортировки одного класса и в рамках Big-O они равны.
Я могу утверждать, что в общем случае быстрая сортировка быстрее пузырьковой, так как они разного класса.
Вы же даже процитировали меня, где я пишу «в общем случае». Разве сортировка 5 элементов — это общий случай?
В частных случаях Big-O может не давать ответа на вопрос, какой алгоритм лучше, тут нужны измерения. Но Big-O говорит о том, что мало смысла проводить сравнения с, например, пузырьковой сортировкой по умолчанию.