tangriel: (иногда я)
[personal profile] tangriel
1. Я написала заполнение квадратной матрицы нулями, а побочной диагонали (из правого верхнего в левый нижний угол) единицами за два цикла (вернее, три: один обычный и еще с вложенным). Можно написать за один. А вы как думаете? (с) Что лучше - интуитивно понятный код (имхо, конечно) со сложностью выше на константу или менее понятный, но работающий немножечко быстрее на больших объемах данных?
2. Написать бы не на ассемблере (в универе еще и не то было, LISP до сих пор жив в моей памяти): на (во) сколько раз больше билетиков-встреч, чем счастливых билетиков? Какова вероятность (распределение? хотя тут более-менее понятно) появления таких билетиков? Счастливый - тот, в котором сумма первых трех цифирек в номере равна сумме вторых трех цифирек. Встреча - там, где две вышеназванные суммы отличаются на 1 (сумма слева на 1 меньше или больше, чем сумма справа).
3. Размышляю: питон или powershell. Пока склоняюсь ко второму, как к более странному для меня. ) Правда, на работе по-прежнему стоит версия 1.0, так и не справилась с веселым квестом установки 2.0 на XP SP3. (
4. Надеюсь таки догнать за три дня курс по БД. Сейчас - триггеры. С constraints успешно справилась. Любопытно это все.
Извинити. )

Date: 2013-03-07 11:49 pm (UTC)
From: [identity profile] x-good-boy.livejournal.com
Лучше интуитивно понятный код - его проще читать и отлаживать. Оптимизирущий компилятор в обоих случаях сгенерит одно и то же.

Date: 2013-03-08 09:55 am (UTC)
From: [identity profile] tangriel.livejournal.com
О, действительно, логично. Спасибо!
(Надо бы узнать о компиляторах больше, чем смутные воспоминания о семестровом курсе, синтаксических и семантических анализаторах, т.д.)

Date: 2013-03-08 12:15 pm (UTC)
From: [identity profile] x-good-boy.livejournal.com
Тогда вот еще немного знаний. Мой бывший коллега ушел работать в игровую индустрию. Он говорил, что код для рендеринга кадров в игрушках уже давно перестали писать на ассемблере. Время разработчиков стоит дорого, а написать на ассемблере код, который будет работать быстрее, чем то что сгенерит gcc -O3 из сишного кода, по силам далеко не каждому. Правда, этот разговор происходил до изобретения nVidia cuda.

Вторая история от одного директора софтверной компании, бывшего ученого из института кибирнетики Глушкова. Он говорил буквально следующее - если один алгоритм имеет сложность, скажем, n^2, но пишется и отлаживается за день, а второй имеет сложность n*log n , но пишется и отлаживается неделю - в современной IT индустрии, скорее всего, реализуют первый алогритм.

С праздником! :)

Date: 2013-03-08 05:18 pm (UTC)
From: [identity profile] tangriel.livejournal.com
Спасибо за истории. )

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

Разумно. ) А если n^3 и n*log n, уже имеет смысл? Любопытно, начиная с какого n вообще нужно заботиться о сложности алгоритма сейчас?

Спасибо. )

Date: 2013-03-08 11:08 pm (UTC)
From: [identity profile] x-good-boy.livejournal.com
Вы неправильно ставите вопрос. В индустрии разработки софта на заказ или на продажу, главное - customer should be happy. Кастомер не знает чем отличается сложность n^2 от n^3, а слова "логарифм" он вообще не понимает, потому что в школе у него была двойка по математике. Кастомер знает только что час работы программиста стоит x долларов, час работы тестировщика y долларов, и программа должна выполнять рассчет и выдавать результат за заданное время. Так что ответ на вопрос в том виде, в каком вы его задали - n^3 или n*log n - зависит от того, сколько времени будет считать первый и второй алгоритм на стандартных наборах входных данных. Если n^3 будет считать семь часов, а n*log n - один час, а кастомер запускает программу на ночь и ложится спать, чтобы получить результат к утру, думаю, ответ очевиден.

Date: 2013-03-09 09:16 am (UTC)
From: [identity profile] tangriel.livejournal.com
Вполне очевиден. )
Про распараллеливание в целом понятно. Т.е. понятно, как делать, если можно распараллелить. Интересно, а если нельзя (на первый взгляд), то вот совсем-совсем нельзя? Или все же можно, используя какие-то приемы (алгоритм распараллеливания, что ли )), привести алгоритм к виду общей сложностью выше исходной, но при этом для каждого потока сильно меньшей (линейной, скажем)? Значит, и суммарно быстрее будет.

Date: 2013-03-09 11:37 am (UTC)
From: [identity profile] x-good-boy.livejournal.com
Не знаю, с такими вопросами лучше к программистам. Я всего лишь скромный админ и в жизни своей не распараллелил ни одного алгоритма.

Date: 2013-03-08 11:19 pm (UTC)
From: [identity profile] x-good-boy.livejournal.com
Да, кстати, еще один совет - лучше заботиться не о сложности алгоритма, а о том, насколько хорошо он параллелится. Если алгортим n^3 или даже n^5, но хорошо параллелится, это лучше чем n*log n, который не параллелится. Ядер в процессорах сейчас много, в видяшках тем более, а скорость одного ядра почти не растет.

Date: 2013-03-08 08:16 am (UTC)
From: [identity profile] sunny-lioness.livejournal.com
Если заказчик не выставил критических ограничений по времени, и скорость падает не в разы (экспоненциальный алгоритм vs полиномиальный), то лучше интуитивно понятный код.

Date: 2013-03-08 09:50 am (UTC)
From: [identity profile] tangriel.livejournal.com
Нет, изменяется на константу, даже не линейно.
Спасибо! )

Date: 2013-03-09 01:12 pm (UTC)
From: [identity profile] alexbnd.livejournal.com
Во втором случае увеличивается сложность поддержки кода. И если решение сильно нестандартное, то оно часто менее универсальное и когда нужно будет внести изменения - это будет гораздо сложнее.
Edited Date: 2013-03-09 01:12 pm (UTC)

Date: 2013-03-09 01:28 pm (UTC)
From: [identity profile] tangriel.livejournal.com
Да, поддерживать сложнее. Но как быть, если такое решение более, а не менее универсальное?

Date: 2013-03-09 01:48 pm (UTC)
From: [identity profile] alexbnd.livejournal.com
писать ОЧЕНЬ хорошие и детальные комментарии.

Profile

tangriel: (Default)
tangriel

January 2014

S M T W T F S
   1234
5 67891011
12131415161718
19202122232425
262728293031 

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 26th, 2017 04:36 am
Powered by Dreamwidth Studios