| открыта вакансия поисковика |
[Jul. 15th, 2017|05:15 am] |
опять попробуем народную помощь. нет ли у вас в кармане способа делать из набора плоскостей мэш? ну, как в первокваке: все мэши заданы наборами плоскостей, это надо превратить в нормальный набор полигонов.
самый простой способ, понятно — это взять Очень Большой Кубик, и обрезать плоскостями всё лишнее. несложно, конечно, но, может, поумнее что придумано? «поумнее» — это, натурально, не «понавороченей», а «быстрее и проще».
найти все точки пересечения плоскостей и натравить на это QuickHull нифига не выглядит ни проще, ни быстрее, если чо. |
|
|
| раз уж мы тут о еде заговорили... |
[Jul. 15th, 2017|10:56 am] |
…развлечёмся ещё немножко риалполитиком 101.
знаете, что нужно, чтобы ЙОБНУЛО (ну, или говоря наукообразно — «произошёл социальный взрыв»)? одномоментное изменение норм питания примерно на треть. в любую сторону. дай сразу слишком много хлеба — получишь «сытые бунты», отбери — получишь «голодные бунты». а вот если делать это постепенно — то бунтов не будет.
второе. какое население для государства удобней: сытое и имеющее время на лишние мысли, или голодное и думающее в основном о том, чтобы хватило пожрать? учтите, что уровень жизни действующих правителей совершенно не зависит от производственного и экономического уровня страны, которой они «управляют».
третье. что бы ни происходило, как бы ни происходило — государство формально не должно быть в этом виновато. «мы старались… но перегибы на местах, но внешний враг, но инопланетяне…» кто угодно, но не действующие правители.
а чтобы это всё заполировать — посмотрите, кого назначили виноватым в «санкциях», и как понижается продовольственная норма (количественно и качественно).
всё, дальше разжёвывать не буду: станет невкусно, да и граничит с оскорблением уже.
дополнение специально для вышиваты: конечно, в войне на донбассе виноват исключительно внешний враг. |
|
|
| cpu bugs |
[Jul. 15th, 2017|05:27 pm] |
я, конечно, ругался на то, что у меня ядро раком встаёт, но это процесс сопутствующий. главный — это ходить в сортир, потому что там думать удобно. гипотеза на данный момент вот какая: некий специфический код в драйвере ext4, в неких специфических условиях — триггерит баг в микрокоде. ситуация не новая (смотри, например, «skylake bug»), и с моей стороны в принципе нерешаемая. даже недиагностируемая, потому что чёткого повторения бага я добиться так и не смог. в 32-битном режиме у говнохасвела есть known bug — периодически вылезающие parity errors. сами по себе они значат только то, что процессор ошибку поймал и исправил. говноинтель, конечно, говорит, что «это ерунда, нестрашно, всё работает, вы не беспокойтесь только. мы чинить не будем, нам и так всё заебись.» а если не поймал? или не исправил? больше всего parity errors валит, когда начинаешь мучать FS. при этом опять непрогнозируемо: то густо, то пусто, от объёмов i/o не зависит. так что это связано с какими-то операциями на внутренних структурах FS. fsck, например, этих багов не триггерит вообще.
увы, вывод такой, что придётся и дальше жить на вулкане: в силу невозможности стабильно баг повторить — а, следовательно, и изолировать. надеюсь, что оно не развалит мне FS к ебеням однажды. в принципе, ext4 — штука очень дубовая, потому более-менее устойчивая. надеюсь. |
|
|
| очевидное про «о большое» |
[Jul. 15th, 2017|06:31 pm] |
отойдём от политики и социопсихологии. я тут вспомнил, что — удивительным образом — есть люди, которые считают «о-нотацию» (это которая O(1), например) «интуитивно понятной», и интуитивно понимают её неправильно. ща я напишу то, что должен знать каждый, но знают далеко не все. внемлите!
«о большое» показывает зависимость времени выполнения алгоритма от количества элементов, а не быстродействие алгоритма.
да, это совершенно разные вещи. алгоритм, у которого с каждым новым элементом время выполнения увеличивается на наносекунду, имеет сложность O(n). алгоритм, у которого с каждым новым элементом время выполнения увеличивается на миллиард лет, имеет сложность O(n). потому что константы из обычно используемой «о-нотации» убираются, как неинтересные.
ещё раз повторю: O(n) обозначает, что время исполнения алгоритма линейно зависит от количества элементов. но оно не говорит нам, какое это время. поэтому алгоритм поиска элемента в массиве, который вне зависимости от реального количества элементов всегда резервирует массив одного и того же размера (с запасом), и всегда перебирает все элементы массива (даже если нашёл элемент сразу), будет O(1). опа-опа, мы только что сделали «самый быстрый алгоритм поиска элемента в массиве, не зависящий от количества элементов» — если пишуший или читающий не понимает, как читать «о-нотацию».
если для вас вышенаписаное очевидно — здорово. но очевидно это далеко не для всех, увы. поэтому при обсуждении (или при чтении статей из интернетов) убедитесь, что собеседник (или автор статьи) правильно понимает «о большое». на всякий случай. если не лень.
на самом деле «о большое» ещё сложнее, я знаю, спасибо. но обычно его используют именно так. |
|
|