Программирование для математиков: класс Polynomial

[Munin]

А он что, ещё и преподаёт программирование???

Да вы что. Пусть лучше скорее бросит это делать, и займётся тем, что умеет. И чем принесёт людям пользу, а не вред.

[photon]

Munin в сообщении #1386097 писал(а):

pair в данном случае наиболее очевидный и естественный способ достичь желаемого. На функциональном языке однозначно именно так бы и было сделано.

В данном конкретном случае, пожалуй, я бы тоже выбрал пару - вполне естественным представляется первым элементом написать результат деления, а вторым - остаток, но вообще, лично я в случае однотипных значений, чтобы не перепутать, что первое, а что второе (третье и т.д., если с std::tuple) предпочитаю оборачивать возвращаемый результат структурой - именованные поля не дадут запутаться.

-- Fri Apr 05, 2019 14:33:11 --

VTsalyuk в сообщении #1386067 писал(а):

И может ради быстродействия писать сколь угодно длинные коды.

Иногда да - и код может стать неудобочитаемым и появляются ассемблерные вставки ради быстродействия, но вы начали с конца - поставили телегу впереди кобылы: сначала пишется код, который хорошо структурирован, удобочитаем, легко понимаем, а уже потом, если с этим кодом возникают проблемы, связанные с быстродействием, проводится его анализ, выявляются узкие места, возможно меняются алгоритмы (не везде подряд, а только в узких местах - если, скажем, программа вызывает 2 функции, одна из которых занимает 99% времени, а вторая 1%, то ускорение даже в 100 раз второй, если это снизит ее удобство поддержки и использования/надежность, противопоказано), возможно, меняется архитектура целиком, чтобы избежать этих узких мест, а уже потом, если все еще остается необходимость, возможна микрооптимизация. Интересно, что во многих случаях с современными компиляторами и современными процессорами приемы этой микрооптимизации, которые могли быть актуальны в 90-е, сейчас не имеют смысла - компилятор сам соптимизирует, и уж, конечно, при анализе производительности смотреть можно только на релизный вариант - тот, в котором компилятор эти оптимизации делает. Поэтому важно: а) собирать релизную версию; б) указывать ключи оптимизации (-O2, -O3 и т.п.), в) указывать, на каком железе проводилось тестирование.

[Munin]

photon в сообщении #1386132 писал(а):

В данном конкретном случае, пожалуй, я бы тоже выбрал пару

Ну я бы сказал, что pair tie здесь хороши тем, что стандартные - не требуют их реализовывать - и главное, по этой причине ясно читаемые для любого читателя. Напоровшись на отсебятину вместо стандартных типов, читатель начнёт искать подводные камни и разбираться, не сможет спокойно этим пользоваться.

А! Я понял! Надо затайпдефить какой-нибудь quotient_remainder_pair на стандартный pair.

(Оффтоп)

Я не помню, как это делается для шаблонов...

photon в сообщении #1386132 писал(а):

Иногда да - и код может стать неудобочитаемым и появляются ассемблерные вставки ради быстродействия

И за это программистам отрывают руки.

Потому что support важнее крох быстродействия. Которые закон Мура всё равно съест за считанные годы.

-- 05.04.2019 16:02:29 --

photon в сообщении #1386132 писал(а):

сначала пишется код, который хорошо структурирован, удобочитаем, легко понимаем

... легко тестируем, легко отлаживаем, хорошо документирован, легко (гибко и эффективно) модифицируем и расширяем.

[mihaild]

Munin в сообщении #1386142 писал(а):

Напоровшись на отсебятину вместо стандартных типов, читатель начнёт искать подводные камни и разбираться, не сможет спокойно этим пользоваться.

Я готов к тому, что в библиотеке на плюсах есть свои типы. А вот запоминать порядок аргументов и возвращаемых значений одинакового типа я готов существенно меньше.
Если я что-то напутал в обращении к новым типам - компилятор мне об этом скажет. Если я перепутал, в каком порядке возвращают частное и остаток - нет, но работать всё будет неправильно.

Munin в сообщении #1386142 писал(а):

Потому что support важнее крох быстродействия. Которые закон Мура всё равно съест за считанные годы.

Зависит от деталей. Почти всегда это так. Но в некоторых случаях ускорение кода на пару процентов экономит такие суммы, что с лихвой окупает целые отделы, портящие читаемость в угоду производительности.

[realeugene]

mihaild в сообщении #1386145 писал(а):

Но в некоторых случаях ускорение кода на пару процентов экономит такие суммы, что с лихвой окупает целые отделы, портящие читаемость в угоду производительности.

Думаю, что в HFT это может быть разница между богатством и банкротством.

[photon]

Munin в сообщении #1386142 писал(а):

И за это программистам отрывают руки.

С программистами, которым оторвали руки, пока не встречался, а вот с задачами, что "вот этот конкретный функционал на вот этом конкретном устройстве должен работать не больше стольких-то миллисекунд без потери качества до такого-то числа", к сожалению, встречался - для продуктов, которые что-то делают real-time такие требования возникают постоянно, и да, если не удается впихнуть в имеющийся девайс, отказываются от релиза этого функционала до следующего более производительного устройства.

-- Fri Apr 05, 2019 15:56:20 --

Munin в сообщении #1386142 писал(а):

А! Я понял! Надо затайпдефить какой-нибудь quotient_remainder_pair на стандартный pair.

(Оффтоп)

Я не помню, как это делается для шаблонов...

Используется синтаксис C++

template<typename T, typename U>
using quotient_remainder_pair = std::pair<T, U>;

-- Fri Apr 05, 2019 16:02:57 --

Munin в сообщении #1386142 писал(а):

... легко тестируем

Да, и на него пишутся тесты, а все последующие рефакторинги не должны затрагивать или ронять эти тесты.

[Munin]

И потом через полгода-год приносят новое устройство, на котором памяти вдвое больше, и герцев получше. И говорят "переписывай на него".

[realeugene]

Munin в сообщении #1386159 писал(а):

И потом через полгода-год приносят новое устройство, на котором памяти вдвое больше, и герцев получше. И говорят "переписывай на него".

Разница в прибыли, неполученной со старого медленного устройства за полгода-год, и в объёме потерянного рынка.

-- 05.04.2019, 17:18 --

photon в сообщении #1386152 писал(а):

С программистами, которым оторвали руки, пока не встречался

А с уволенными за плохой код, встречались?

[Munin]

realeugene в сообщении #1386161 писал(а):

Разница в прибыли, неполученной со старого медленного устройства за полгода-год

Угу. И в убытках, непотерянных из-за увеличения объёма работ в 3-10 раз.

[mihaild]

Munin в сообщении #1386164 писал(а):

И в убытках, непотерянных из-за увеличения объёма работ в 3-10 раз

Программисты потратили какое-то время на сами оптимизации, и кроме этого написали какой-то еще код медленнее, потому что вместо понятного кода пришлось править непонятный. За это время им пришлось заплатить зарплату, которую можно было бы не платить, если эти оптимизации не делать.
Но зато этот код работал быстрее, и, в зависимости от деталей, либо просто позволял использовать меньше железа и электричества, либо работал лучше, чем неоптимизированный код конкурентов, за счет чего к нам пришло больше пользователей. В результате мы сэкономили денег на железе и / или получили больше денег от пользователей, которые бы не сэкономили / не получили, если бы оптимизаций не было.

В одних ситуациях одна сумма больше, в других другая.

А у вас почему-то "крохи быстродействия" и "увеличение работ в 3-10 раз". Такое соотношение бывает. Но бывает и не такое.

[photon]

Munin в сообщении #1386159 писал(а):

И потом через полгода-год приносят новое устройство, на котором памяти вдвое больше, и герцев получше.

Но у конкурента это работает уже полгода-год.

Munin в сообщении #1386164 писал(а):

И в убытках, непотерянных из-за увеличения объёма работ в 3-10 раз.

Пара человеко-месяцев работы при миллионных тиражах устройств - мелочь, особенно если учесть, что бОльшая часть кода в любом случае не релизится, а уходит в стол.

-- Fri Apr 05, 2019 17:06:42 --

realeugene в сообщении #1386161 писал(а):

А с уволенными за плохой код, встречались?

Не плохой, а неудобочитаемый при условии постановки задачи "любой ценой выжать производительность" - это вопрос приоритетов. Иногда неважно, код работает секунду или две (или, если хотите, 15 дней, а не 10), а иногда критично, что он 50мс, а не 30мс. Это не значит, что код будет совсем отвратителен - он все равно должен быть задокументирован, протестирован, разумно структурирован, но где-то красота кода будет отдана в жертву производительности.

[Munin]

Бывает много что. Но непонятно, зачем ориентироваться на редкие случаи.

[photon]

Munin в сообщении #1386173 писал(а):

Бывает много что. Но непонятно, зачем ориентироваться на редкие случаи.

А никто и не предлагает на них ориентироваться, вроде. Я за красоту кода, когда это возможно. Но сказал, что бывают случаи, когда приоритеты меняются, и иногда это доводит даже до микрооптимизаций, но никто с них не начинает (как это делает ТС).

Редкость случаев различна в различных программистских сферах деятельности - у кого-то не возникает проблем с быстродействием, а для кого-то это постоянно висящий вопрос.

[Munin]

Согласен. Но и сами сферы можно оценить по, грубо говоря, объёму рынка вакансий.

[realeugene]

photon в сообщении #1386175 писал(а):

и иногда это доводит даже до микрооптимизаций, но никто с них не начинает

Кнут большой любитель микрооптимизированных алгоритмов.

-- 05.04.2019, 18:37 --

photon в сообщении #1386169 писал(а):

а иногда критично, что он 50мс, а не 30мс

На нижнем уровне и лишней микросекунды может не оказаться.