В конце 90-х HP, Canon и Epson давно уже были зубрами печати. И уже были готовы печатать с фотокачеством (но на тот момент еще дороже минилабов). Например, вот Epson
Считать суперкомпьютер за один компьютер на уровне ОС не вполне честно. Там и RHEL заметно допилен и память неоднородна от слова "совсем", и FS совсем свои. А 32-сокетный монстр — это еще "почти честный" моносервер (Intel: Configure native 4- and 8-socket CPU configurations and extend to up to 32-socket systems via third-party OEM node controllers).
И что характерно, на самом деле многие скриптовые/высокоуровневые языки такими "битовыми" хаками особо не пооптимизируешь. Вот из того, что помню
SQL — за современный Postgres с Jit не скажу, но в MS SQL Server/MySQL/Oracle/PostgreSQL разница на уровне погрешности.
VB/VBS/VBA. Некоторые приемы работают, но только при строгой типизации. Variant или работа с COM мгновенно съедают разницу.
1С — там арифметика на своём "особенном" числовом типе. Этот тип раз в 100 медленнее Int32. Сдвигов и битовой логики нет.
Powershell — с ним смешно. Я лет 6 назад с удивлением обнаружил, что типизированные переменные медленнее нетипизированных. Там просто при каждом присваивании для типизированных переменных происходит принудительное приведение к типу.
Bash, cmd — не найти разницу
Да и JS стал таким чувствительным к битовым хакам примерно с появлением "дерзкого" V8, потом остальные стараются догнать (кто не верит — ставьте виртуалку с IE6 и проверьте).
Все являются, конечно. Главная идея статьи (поста в блоге в оригинале) в последней фразе. Перефразируя "JS такой высокоуровневый, а битовые хаки для оптимизации все равно работают".
Wormholes же в оригинале. И картинка намекает, а перевод не очень удачный. Wormholes в данном случае типа залез в чёрную дыру тут, а вылез в 100 млн парсеков (за 1000 лет до рождения). Червоточины, возможно, было бы точнее и понятнее
Ну для RSA нужны же простые примерно с половину ключа. Сейчас популярны RSA-2048/RSA-4096. Из-за того, что «плотность» простых убывает достаточно медленно, даже в диапазоне 2^1024...2^2048 можно просто взять случайное число и проверять каждое следующее на простоту. Проверку на простоту на практике делают вероятностным, но быстрым методом Миллера-Рабина.
В 94-99 гг прошлого века в Новосибирске (в отделении связи на ул. Ильича) были междугородние телефоны-автоматы, их жетоны были в виде пластиковых линз (примерно такие). Берется пластиковая бутылка от газировки, вырезается полоска длиной 15-20 см, шириной 5-8 мм. К одной стороне суперклеем или, например, 1,2-дихлорэтаном приклеивается жетон. В конце времени, положенного на жетон (зависело от региона) надо было вытащить линзу за полоску и снова вставить. Конструкция была не самой надёжной: была вероятность, что жетон оторвется, или что телефон переклинет, или звонок сорвётся, или снаружи манипуляции заметят. Но при тогдашней стоимости межгорода у студентов и школьников было весьма популярно.
Современные системы управления легко парируют типичные природные явления.
Смотрите, в вашей трактовке неявно получается, что система посадки удовлетворяет таким условиям:
ЛА пустой массой 100-1000 кг или немного больше
Грузоподъёмностью 100+ кг
С посадкой и взлетом без пробега
Посадка на площадку не более 20*20 м (иначе это совсем не любая крыша) с точностью +-2 метра в автономном режиме
Все это хотя бы в условиях порывистого ветра 7-9 м/с (задачи "со звездочкой": сумерки/ночь, осадки, туман, температуры вне диапазона -35..+35, высота 3000 и более над уровнем моря, ветер 12-15+ м/с)
С гарантией сделать это без травм хотя бы 99,99% (иначе это голый экстрим и русская рулетка)
Без автопилота это примерно Robinson. Без надёжности четыре девятки, наверное, есть у вояк (БПЛА). С пробегом и с большей массой, наверное тоже реализуемо (самолёт, БПЛА). Но вот чтобы всё сразу — я очень сомневаюсь. Если есть примеры, было бы интересно почитать. Если вы сами можете сделать такую систему, то станете очень богатым и уважаемым — спасете тысячи жизней.
Сделать автопилот коптера как раз проще, чем автопилот автомобиля
Сделать автопилот для пятиминутных полётов с ценой ошибки в пару тысяч баксов (цена дрона) — да, дешевле. Собственно, поэтому они рассматриваются, как замена курьерам. Сделать автопилот, которому можно доверить тушку пакса, который не умеет садить ЛА — сложнее. И, да, сам полёт — относительно простая задача. Полноценная обработка посадки и взлёта (со всеми хитрыми случаями) — вот реальный челлендж.
Стойте-стойте. Вы тоже перешагнули более простые проблемы.
Что делать с погодой? Я не представляю себе 1-4-местный коптер (или коптероподобный ЛА), который можно относительно безопасно посадить хотя бы ветре при 7-9 м/с (автоматом или с существенной помощью автомата). Ветер — сиди, дождь — сиди, снег — сиди, мороз — сиди. Ах, да, и пока ЛА сидит, его нужно закрыть от влияния погоды.
Пропускная способность площадок приземления. В городе (провода/деревья/здания) нужны посадочные площадки. Мысленный эксперимент для жителей мегаполисов: представьте себе у дома и у работы площадку 50 * 50 или 100 * 100 метров (на меньшую коптер безопасно садить уже прямо сложно), а теперь прикиньте пропускную способность такой площадки у бизнес-центра (подсказка — один ЛА в минуту это примерно как у крупнейших аэропортов), теперь представьте час пик и АДОВУЮ работу диспетчерской системы. А теперь представьте, что в воздухе больше одного коптера с критически малым запасом топлива. Кто-то должен сесть, а другой может рухнуть.
У автопроизводителей начинает немного получаться автопилот на машине, там где вероятная цена ошибки сильно меньше. Чтобы сделать автопилот коптера, который хотя бы не убъёт пассажира нужно еще лет 10-20 после создания еще не созданного автопилота автомобиля. А если автопилот частичный, то пилоты сами себя поубивают.
за спиной не стоял менеджер и не спрашивал каждые 15 минут
По-разному было. И стоял, и кричал, и не один менеджер. Но я с такими "менеджерами" долго не работаю обычно. Оно того не стоит.
никто не дал бы времени
Дал бы. Если другого решения нет. С вашими гиговыми XML — если поток XML станет больше, чем может съесть система. Если нерешение проблемы = отзыв лицензии. Обычно получается объяснить, что время нужно. В общем, надо уметь его взять.
решалку СЛУ еще в колледже вполне успешно писал
Вопрос не в "решалке" (это и я в школе писал), она уже написана была, а в том, что матрица большая и в нескольких местах "неудобная" для Гауссо-подобных алгоритмов, плюс надо было не терять точность. В любом случае — это просто примеры.
Есть вероятность, что эти люди просто не увидели, что "графы, деревья и уникальные сортировки" и прочие "теоретические" вещи нужны.
Мне в своё время (лет 10-20 назад) понадобились:
Диофантовы уравнения и метод ветвей и границ в оптовой торговле фармацевтическими товарами
Реализовать хеш-таблицу и B+ tree в 1С: Бухгалтерии 7.7
Изучить как работает TCP в части three way handshake, модель состояний и работы с SN/ACK SN, чтобы сделать похожий сеансовый обмен между складами
Решить проблемы отсутствия string builder в 1С 8 (при огромном количестве конкатенаций)
Оптимизировать решение систем линейных уровнений в расчете себестоимости.
Это просто примеры того, что якобы "теоретические" штуки могут пригодиться в неожиданных моментах "скучных" и "простых" областей.
Ну если с первым примером всё более-менее понятно, но пример `both` меня совсем удивляет.
Я не считаю это ошибкой, скорее демонстрацией мест, где достаточно сложно сориентироваться в «обычном тексте».
Меня смущает, что я не понимаю почему =1 в разных случаях в разные стороны. И если немного усложнить пример, то я вообще не понимаю что и как.
Вот, например, объясните мне вывод в классе both
data class aleph1 (val אאאאאא:String = "йцу")
data class aleph2 (val אאאאאא:Int = 123)
data class alpha (val αααααα:Int = 123)
data class both (val αααααα:Int = 123, val אאאאא:Int = 123, val אאאאאא:String = "йцу")
fun main(args: Array<String>) {
println(aleph1())
println(aleph2())
println(alpha())
println(both())
}
В SQL:1999 в стандарт введены рекурсивные CTE и вообще-то даже стандартный стал полным по Тьюрингу. При этом аналогичные расширения уже были у некоторых вендоров (Oracle точно, и, кажется, IBM DB/2). При этом T-SQL, PL/SQL и многие другие "расширения" содержали циклы и процедуры (т.е. тоже Тьюринг-полные).
Так что этот аргумент не состоятелен.
fun main(kotlin.Array<kotlin.String>): kotlin.Unit
Байткод показывается нормально.
Если его прогнать Show bytecode и Decompile, то там некомпилируемая шляпа:
public static final void main(@NotNull String[] args) {
Intrinsics.checkParameterIsNotNull(args, "args");
<undefinedtype> var1 = null.INSTANCE;
System.out.println(var1);
}
Но это, пожалуй, простительно. Function references завязаны на reflection, а с ним в Котлине с всё непросто: приходится поддерживать и интероп с java, и js/native/ir, и котлиновые фичи (локальные функции, например). Это прослеживается и в трекере и в документации, особенно если посмотреть на JS.
Например, вот Epson
Считать суперкомпьютер за один компьютер на уровне ОС не вполне честно. Там и RHEL заметно допилен и память неоднородна от слова "совсем", и FS совсем свои. А 32-сокетный монстр — это еще "почти честный" моносервер (Intel: Configure native 4- and 8-socket CPU configurations and extend to up to 32-socket systems via third-party OEM node controllers).
И что характерно, на самом деле многие скриптовые/высокоуровневые языки такими "битовыми" хаками особо не пооптимизируешь. Вот из того, что помню
Да и JS стал таким чувствительным к битовым хакам примерно с появлением "дерзкого" V8, потом остальные стараются догнать (кто не верит — ставьте виртуалку с IE6 и проверьте).
Все являются, конечно. Главная идея статьи (поста в блоге в оригинале) в последней фразе. Перефразируя "JS такой высокоуровневый, а битовые хаки для оптимизации все равно работают".
Пока не заглянул в MDN, не смог понять, что Math.clz32 возвращает количество лидирующих нулевых битов в 32-битном двоичном представлении числа.
Wormholes же в оригинале. И картинка намекает, а перевод не очень удачный. Wormholes в данном случае типа залез в чёрную дыру тут, а вылез в 100 млн парсеков (за 1000 лет до рождения). Червоточины, возможно, было бы точнее и понятнее
В 94-99 гг прошлого века в Новосибирске (в отделении связи на ул. Ильича) были междугородние телефоны-автоматы, их жетоны были в виде пластиковых линз (примерно такие). Берется пластиковая бутылка от газировки, вырезается полоска длиной 15-20 см, шириной 5-8 мм. К одной стороне суперклеем или, например, 1,2-дихлорэтаном приклеивается жетон. В конце времени, положенного на жетон (зависело от региона) надо было вытащить линзу за полоску и снова вставить. Конструкция была не самой надёжной: была вероятность, что жетон оторвется, или что телефон переклинет, или звонок сорвётся, или снаружи манипуляции заметят. Но при тогдашней стоимости межгорода у студентов и школьников было весьма популярно.
Так есть коммерческие решения или пока не очень? Есть где почитать открытое?
Конечно. Но в итоге это вопрос бабла и окупаемости. У вояк нет явного вопроса окупаемости и им не нужны 99,99.
Смотрите, в вашей трактовке неявно получается, что система посадки удовлетворяет таким условиям:
Без автопилота это примерно Robinson. Без надёжности четыре девятки, наверное, есть у вояк (БПЛА). С пробегом и с большей массой, наверное тоже реализуемо (самолёт, БПЛА). Но вот чтобы всё сразу — я очень сомневаюсь. Если есть примеры, было бы интересно почитать. Если вы сами можете сделать такую систему, то станете очень богатым и уважаемым — спасете тысячи жизней.
Сделать автопилот для пятиминутных полётов с ценой ошибки в пару тысяч баксов (цена дрона) — да, дешевле. Собственно, поэтому они рассматриваются, как замена курьерам. Сделать автопилот, которому можно доверить тушку пакса, который не умеет садить ЛА — сложнее. И, да, сам полёт — относительно простая задача. Полноценная обработка посадки и взлёта (со всеми хитрыми случаями) — вот реальный челлендж.
Стойте-стойте. Вы тоже перешагнули более простые проблемы.
По-разному было. И стоял, и кричал, и не один менеджер. Но я с такими "менеджерами" долго не работаю обычно. Оно того не стоит.
Дал бы. Если другого решения нет. С вашими гиговыми XML — если поток XML станет больше, чем может съесть система. Если нерешение проблемы = отзыв лицензии. Обычно получается объяснить, что время нужно. В общем, надо уметь его взять.
Вопрос не в "решалке" (это и я в школе писал), она уже написана была, а в том, что матрица большая и в нескольких местах "неудобная" для Гауссо-подобных алгоритмов, плюс надо было не терять точность. В любом случае — это просто примеры.
Есть вероятность, что эти люди просто не увидели, что "графы, деревья и уникальные сортировки" и прочие "теоретические" вещи нужны.
Мне в своё время (лет 10-20 назад) понадобились:
Это просто примеры того, что якобы "теоретические" штуки могут пригодиться в неожиданных моментах "скучных" и "простых" областей.
Я не считаю это ошибкой, скорее демонстрацией мест, где достаточно сложно сориентироваться в «обычном тексте».
Меня смущает, что я не понимаю почему
=1в разных случаях в разные стороны. И если немного усложнить пример, то я вообще не понимаю что и как.Вывод:
В SQL:1999 в стандарт введены рекурсивные CTE и вообще-то даже стандартный стал полным по Тьюрингу. При этом аналогичные расширения уже были у некоторых вендоров (Oracle точно, и, кажется, IBM DB/2). При этом T-SQL, PL/SQL и многие другие "расширения" содержали циклы и процедуры (т.е. тоже Тьюринг-полные).
Так что этот аргумент не состоятелен.
"Вспомогательность" SQL тоже спорная.
Почему "уже"? Почему "не должен"?
Полный код:
Код компилируется, работает. Вывод:
Байткод показывается нормально.
Если его прогнать Show bytecode и Decompile, то там некомпилируемая шляпа:
Но это, пожалуй, простительно. Function references завязаны на reflection, а с ним в Котлине с всё непросто: приходится поддерживать и интероп с java, и js/native/ir, и котлиновые фичи (локальные функции, например). Это прослеживается и в трекере и в документации, особенно если посмотреть на JS.