сдается мне, что нет, но задам уточняющие вопросы: «за меньшее число сравнений» означает ли «за меньшее число операций», или сравнение можно заменить на сложение/вычитания/побитовые операции, главное, чтобы знаков <> не было?
Ну автор топика прав в том смысле, что чтобы писать самому что-то уже реализованное, нужна причина. Ей могут быть: стандартные решение не готово к промышленному использованию, оно платное а мы жадные или оно нас не удовлетворяет в части некоторых своих функций/показателей.
Если такой причины нет, лучше и дешевле взять готовое. Работа программиста ведь не в том, чтобы все написать, а чтобы в заданный бюджет реализовать максимально качественное/быстрое решение.
Я для себя эту проблему решаю так: стараюсь разбираться, как работают библиотеки, которые я использую. Конечно, хитрым математическим алгоритмам это не научит, но и думать не разучусь, и свое при условии специфичных требований смогу написать.
1. Если 0 больше одного, выкидываем любой элемент.
2. Если 0 один, считаем произведение без него. Если получилось <0, то выкидываем любой элемент кроме нуля, если >0, то выкидываем 0.
3. Считаем произведение всех n чисел, допустим, оно = M
4. Проходим по массиву, вычисляем M/ar[i], это будет произведение всех чисел без i-го элемента, его и нужно оптимизировать, дальше понятно.
Повторю то, что я написал в upd2. То, что некоторые данные нужны для выполнения некоторой бизнес-функции/операции, это естественно, это я даже не обсуждаю. Я обсуждаю способ ввода, при котором обычно требуется ввести эти данные сразу и полностью, вместо этого предлагая вводить по частям по мере доступности и промежуточные (неполные) результаты тоже хранить в БД.
Да, все правильно. За одним исключением — речь о большинстве полей из тех, что маппятся 1:1 в пользовательский интерфейс. В схеме БД еще много всяких чисто технических полей, которых не видно в интерфейсе, и их целостность обычно на уровне БД обеспечивается.
Средства по контролю целостности БД используем. Там, где поле на форме соответствует 1:1 полю в БД, иногда это ограничение заносится в схему, иногда нет, зависит от. Проверка обязательности на уровне приложения есть в обоих случаях.
Ну да, не определяется. Ведь поле, обязательное для одного бизнес-процесса, может быть (и часто является) необязательным для другого. И на всякий случай повторю, что мы не доводим ничего до абсурда. Обязательные поля в схеме БД есть, и их обязательность определяется многими факторами, в т.ч. и бизнес-процессами. Но мы стараемся такие места минимизировать. Объемы — 105—106 учетных единиц.
Да, я там в UPD #2 уточнял потом, что именно я пытался сказать. Там речь не о вообще любых формах, а о формах ввода/редактирования/сбора информации в системе. Не могу подобрать термина адекватного, но суть в том, что логин — это немного другое, это форма запуска действия, а не сбора (что бы это ни значило) информации.
К каптче отношусь плохо, это как раз тот случай, когда часть работы (отсеивать ботов) программист переложил на пользователя. С другой стороны, при логине еще терпимо, логинимся мы редко; слава богу, что она не выскакивает при каждом комментарии.
В модели данных документируются обязательные для схемы данных поля. Обязательность поля для бизнес-процесса документируется в описании бизнес-процесса, потому как только там и используется.
Вы не поняли, пусть будет по типу «здесь и сейчас», но только чтобы все три поля не требовалось заполнить обязательно. Например, не хочу я указывать возраст. Если без возраста анкета гарантировано полетит в корзину, его нужно делать обязательным. С другой стороны, такая анкета вполне сгодится для графика «стаж курения в зависимости от пола». Т.е. зависит от того, какие закономерности вы ищете. Если вы этого заранее не знаете, нужно принимать любые анкеты, в которых ну хотя бы на два вопроса отвечено.
То есть таки только те избранные, кому выпала честь пользоваться вашей чистейшей программой, достойны… Подумайте на секунду не о себе. Представьте себе врача, который посылает больных лесом, потому что они «неправильно заболели». Представьте себе архитектора, который сделал дверные проемы высотой в 1,5 метра, потому что «так композиция обретает красоту», и проход в из комнаты в кухню через ванную комнату, потому что сам он любит поесть, когда моется. Что было бы, а?
Вот вы сами пришли к тому, что без каких-то данных какие-то функции не будут работать. Но ведь какие-то будут! Напишите прям на форме об этом, пользователь поймет, он же не тупой, пусть сам принимает решение, в конце концов он в этом лично заинтересован (иначе бы и знать не знал о вашей программе).
Вход на сайт — это действие, совершенно нормально, что для действия нужны какие-то данные. Речь о формах ввода/редактирования предметной информации. В рамках этого сайта такая форма, например — это профиль, и с ним все ок, можно заполнять в любой последовательности и в любом составе.
Вы тут смешали немного. Зависит от того, кому заполнение этой анкеты нужно.
1. Если пользователю, то он и придет, и дозаполнит, и зарегистрируется ради такого дела. Единственное, что надо делать, это моргнуть, мол, помни, ты не все заполнил!
2. Если организации, проводящей опрос, то она должна сделать заполнение максимально простым. Меня лично в формах соцопроса больше всего раздражает (ну, может, после случая, когда спрашивают адрес и телефон), когда вопросов много и надо обязательно ответить на все. Сколько людей бросает заполнять такую, заполнив половину, хотя могли бы хотя бы эту половину отослать? То есть, опять же, все вопросы сделать необязательными.
Вы какой-то странный. Вы с чем спорите? С тем, что при вводе данных часть из них может быть неизвестна? Какой отчет должен себе отдавать оператор, вбивающий список проживающих в доме, где дата рождения указана хорошо если у каждого десятого, а умный программист, следуя принципу KISS, отметил это поле на форме как обязательное?
Если такой причины нет, лучше и дешевле взять готовое. Работа программиста ведь не в том, чтобы все написать, а чтобы в заданный бюджет реализовать максимально качественное/быстрое решение.
1. Если 0 больше одного, выкидываем любой элемент.
2. Если 0 один, считаем произведение без него. Если получилось <0, то выкидываем любой элемент кроме нуля, если >0, то выкидываем 0.
3. Считаем произведение всех n чисел, допустим, оно = M
4. Проходим по массиву, вычисляем M/ar[i], это будет произведение всех чисел без i-го элемента, его и нужно оптимизировать, дальше понятно.
К каптче отношусь плохо, это как раз тот случай, когда часть работы (отсеивать ботов) программист переложил на пользователя. С другой стороны, при логине еще терпимо, логинимся мы редко; слава богу, что она не выскакивает при каждом комментарии.
1. Если пользователю, то он и придет, и дозаполнит, и зарегистрируется ради такого дела. Единственное, что надо делать, это моргнуть, мол, помни, ты не все заполнил!
2. Если организации, проводящей опрос, то она должна сделать заполнение максимально простым. Меня лично в формах соцопроса больше всего раздражает (ну, может, после случая, когда спрашивают адрес и телефон), когда вопросов много и надо обязательно ответить на все. Сколько людей бросает заполнять такую, заполнив половину, хотя могли бы хотя бы эту половину отослать? То есть, опять же, все вопросы сделать необязательными.