Pull to refresh
18
0
Dmitry @pleax

User

Send message
1. Асимптотически никакой разницы нет.
2. Даже если оптимизировать количество операций, то тоже не поможет. Мы же не знаем сколько единиц в массиве. А что, если там нулей сильно больше, чем единиц?
> О шейдерах можно писать долго и много, можно расписать в деталях, с алгоритмами и кодом.

А было бы интересно почитать такие посты :)
Т.е. я, например, достаточно плохо (от слова совсем) понимаю из чего состоит «современная» картинка.
> Правда думаете, что цикл на итераторах работает быстрее, чем на индексах

А если стурктура данных — linked list? ;)
Да, можно. Важен deployment target, конечно. Но это вопрос не компилятора.
Например, приложение WWDC написано на Swift. На iOS7 работает. За более ранние на скажу.
Конечно, никто не может помешать заново полностью реализовать грамматику, но я немного о другом.
Объем работы для того, чтобы сделать поддержку кросс-платформенности в уже существующей реализации достаточно мал. Есть даже ненулевая вероятность, что это zero cost, или даже уже работает и отключено специально. Так уж устроен llvm.
PS: На счет ненужности mono и C# тоже можно поспорить.
На счет «не кросс-платформенный» на самом деле все не так однозначно.
Да, в настоящий момент приоритет, конечно же, Cocoa. Но нет никаких технических проблем сделать его как минимум кросс-компилируемым на другие платформы, так как это, по сути, просто llvm frontend.
Вопрос больше политический: допустит ли это Apple.
Следующий шаг: софт, распознающий троллинг.
До конца (пока) не дочитал, но в первом же примере вижу нарушение рекомендуемых практик по реализации MVC в iOS SDK.

View, в том числе и UITableViewCell, в идеале, не должны знать о модели приложения. И view controller должен выступать медиатором между слоями модели и представления.

Применительно к вашему примеру, ETRDocumentCell вообще не должна иметь ссылок на model layer и ETRDocument в частности. Подписываться на события об изменениях документа, соответственно, должен view controller, и вызывать -reloadRowsAtIndexPaths: из обработчика.
Насколько я заметил, то, что автор топика привел как «готовую реализацию» на самом деле просто выпилено из кода примеров WWDC. Статья тоже по сути просто вольный пересказ небольшого кусочка одной из сессий WWDC.
Приведите пару примеров того, что вы понимаете под практическими вопросами?
Я это к тому, что
константа, иррациональное число, равное длине окружности поделенной на удвоенный радиус этой окружности.
фактически колмогоровская сложность числа pi.
Вы предлагаете по произвольной последовательности находить колмогоровскую сложность. Но, если я ничего не путаю, колмогоровская сложность невычислима.
Тут, видимо, нужно вспомнить еще про колмогоровскую сложность.
Мне больше интересно, как можно НЕ проводить рефакторинг кода.
Это даже звучит глупо: нельзя делать extract class потому что у тебя не достаточный уровень квалификации.
Пробовал. Не понравилось.
Построить рекуррентную формулу для чисел Каталана можно легко просто поняв каким способом из 2*n скобочных структур строятся 2*(n+1) скобочные структуры без повторений.

При должной сноровке можно даже решить рекуррентность (некоторые методы рассматриваются в «Конкретной математике» Грехем, Кнут, Поташник).

Впрочем, я не думаю, что в летнюю школу вам бы потребовалось решать рекуррентность.
так как подчеркнутые переменные удел внутренних классов apple

Это, кстати, давно уже не так. Эппл смирились с тем, что комьюнити выбрало такую конвенцию для инстанс мемберов. В последних версиях clang для @property даже не нужен @syntesize, и @syntesize name = _name; будет сгенерировано компилятором автоматически.
Ну на счет «очень эффективных» методов можно говорить только в отношении к предыдущему поколению играющих программ. Речь до сих пор идет о нескольких камнях форы перед профессионалами.

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

PS: Я это все не к тому, чтобы выяснять кто же сложнее там и круче. Просто такое вот дежа-вю. Даже цитата с википедии какбэ намекает.
Среди множества настольных игр, го выделяется ещё и тем, что она оказалась наиболее сложной для компьютера.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Works in
Registered
Activity