Кстати, мне кажется, что вы не совсем понимаете как работает хеш-таблица. Там нет поиска в массиве и нет циклов, кроме однократного вычисления хеша.
А что происходит в случае коллизий?
Но дело в том, что каждой небольшой массив всегда вырастает после две версии программы. ;)
Заменить линейный поиск на поиск в хэш-таблице — дело 5 минут (если код хорошо спроектирован).
Но часто выясняется более веселое. Нужно сравнивать строки не как попало, а по умному.
Во-первых, строки бывают в юникоде. Простое сравнение уже не всегда работает. Хеш-функция должна это учесть.
Во-вторых, сравнивать нужно без учета регистра. Иногда. Опять же простым сравнением не получается. Хеш-функция должна это учесть и это.
Для дополнительного веселья выясняется, что один из поддерживаемых языков имеет странные правила. И сравнивать строки нужно с учетом этих правил. Хеш-функция разрастается в монстра.
И тут уже все сильно зависит от доступного инструментария. Многие ЯВУ содержат встроенные средства для работы со всем этим. Хотя тот же C++ нет, но можно что-то найти.
если мы запускаем виндовый запускаемый файл под линуксом через wine — он не становится нативным приложением, ведь так?
Не так. Приложение исполняется полностью нативно, на том же процессоре, на котором запущена система. Эмуляция ограничена подменой вызовов.
Кстати, сама ОС может быть виртуализирована. Вы же не говорите, что от этого все приложения в ней стали не нативными? А они могут все исполняться в режиме эмуляции, на виртуальной машине эмулирующей требуемый процессор.
Более того, тот же .Net в нормальных случаях не предполагает исполнения в режиме эмуляции, весь код исполняется нативно.
Мы можем, конечно, привязаться именно к содержимому исполняемого файла. Но можно взять тот же C, откомпилировать и сразу запустить, не создавая никаких файлов вообще. Что в таком случае?
Нельзя что-то ускорить на 200%. Максимум можно ускорить на 100% и это уже будет в бесконечность раз быстрее. А на 200% можно только замедлить.
"автомобиль ускорился на 200%" = "автомобиль увеличил скорость в 3 раза".
"автомобиль замедлился на 200%" = ???
P.S. Изначально производительность была N исполнений в секунду. После оптимизации стала 3N исполнений в секунду. Была 100%. Стала 300%. Изменилась на 200%.
Как нам говорит википедия (https://en.wikipedia.org/wiki/Fibonacci_number), правильная матрица ((1,1),(1,0)). Соответственно, для вычисления F[N] нам достаточно быстрого возведения матриц в степень. Очевидно, что существует алгоритм с логарифмической сложностью. Таким образом алгоритмы с меньшей эффективностью для достаточно большого N покажут результат хуже.
При желании можно заняться оптимизацией возведения в степень, ибо логарифмический алгоритм не является лучшим, хоть и тривиально реализуется.
Всё-таки, большая часть рогаликов не песочницы с открытый миром. Типичная схема — рельсы с парой ответвлений. Так что встроить что-то похожее на сюжет не то, чтобы чрезвычайно сложно, просто многие разделяют мнение Кармака. Есть общее направление (например, мы идем за древним артефактом) и ладно. Упор делается не на сюжете, а на создании интересного геймплея и уникальных ситуаций, требующих от игрока совершенствовать и применять навыки игры
Решается созданием случайных колебаний уровня WiFi сигнала, по величине сопоставимых с помехами. После этого такой анализ уже не сработает, слишком много шума. Вероятно, вопрос можно будет решить на уровне прошивки
У правильных параноиков средства вложены не в золотые монеты, которые сложно съесть, но легко изъять, а в долгосрочный запас патронов, соли и спичек ресурсов, представляющих непосредственную ценность
Да, они самые. В DF они часто включают необязательные шаги, которые добавляют ценности предметам. Сделал, скажем, стул, а потом украсил его. Но, с другой стороны, разный сеттинг, разная конечная цель. Если в DF нужно создать форт, который будет жить своей жизнью, то в RimWirld собрать корабль и улететь в более продвинутые миры.
Скорее это казуальный клон с улучшенной графикой. Не скажу, что это сильно плохо.
DF имеет несколько крутую кривую обучения. "Отличный" интерфейс. Непредсказуемость места высадки (хотите огромную тучу гигантских москитов? нет? а вот и зря, веселье же). Гиперважность одних дварфов при почти полной бесполезности других. Огромное количество экономических цепочек. Хотя после некоторого уровня появляется умение в любой более-менее средней стартовой позиции построить форт, который если и не может отбить любую атаку, так хотя бы пересидеть.
В RimWorld это все сильно приглушено. Экономика проста и прямолинейна. Меньшее число колонистов. Двумерная карта облегчает ситуацию. Хотя, скажем, механика температуры вполне хорошо получилась, хотя на более поздних стадиях это сильно нивелируется. Генератор случайных событий не дает совсем расслабиться. Но некоторые события потом вместо интереса вызывают усталое "что, опять короткое замыкание?".
К нашей великой радости, на Go написана только каноничная версия Go. Модуль math напичкан оптимизациями под разные процессоры https://go.googlesource.com/go/+/master/src/math/, которые должны быть эквивалентны каноничной версии
Скажем, на x86 реализация округления до целого оказалась даже быстрее. Вариант с указанием количества значимых цифр медленнее. Похоже, что из-за умножения и деления на степень десятки.
Во-первых, кресло в офисе удобное ровно по одной причине — это может потенциально улучшить эффективность и лояльность сотрудников, что потенциально может повысить прибыль. Вот вам коммерческий интерес удобных кресел.
Во-вторых, ситуация такова, что golang контролируется Google, а его разработка ведется со вполне определенной целью — повысить эффективность сотрудников Google, использующих его в работе.
Так что аналогия с креслом тут никак не применима.
Это зависит от ваших намерений относительно молотка.
Если вы планировали с его помощью увеличить доход или снизить затраты, то это самая настоящая коммерческая разработка.
Если цель была в получении новых знаний, то тогда разработка была бы исследовательская.
Еще бывает благотворительность, там цель — передача некоторых ценностей третьим лицам (в случае, если лица оказались не третьи, этим всем могут заинтересоваться органы).
Бывают смешанные случаи, скажем, более того, большая часть компаний большую часть своих продуктов (даже внутренних) разрабатывает хотя бы отчасти с коммерческими целями.
Тут, конечно, можно начать рассуждать о разработке некой группой, где не все участники планируют применять продукт разработки в коммерческих целях. Но тут нужно смотреть уже по отдельным участникам.
Так что, молоток для чего нужен?
Возвращаясь к golang, Google, очевидно, контролирует разработку языка, а цель разработки явно далека от чистого исследования или от благотворительности.
fun retrieveIssues() = async {
println("Retrieving user")
val user = await(githubApi.retrieveUser())
println("$user retrieved")
val repositories = await(githubApi.repositoriesFor(user))
println("${repositories.size} repositories")
}
async void RetrieveIssues()
{
Console.WriteLine("Retrieving user");
var user = await githubApi.retrieveUser();
Console.WriteLine($"{user} retrieved");
var repositories = await githubApi.repositoriesFor(user);
Console.WriteLine($"{repositories.size} repositories");
}
А что происходит в случае коллизий?
Заменить линейный поиск на поиск в хэш-таблице — дело 5 минут (если код хорошо спроектирован).
Но часто выясняется более веселое. Нужно сравнивать строки не как попало, а по умному.
Во-первых, строки бывают в юникоде. Простое сравнение уже не всегда работает. Хеш-функция должна это учесть.
Во-вторых, сравнивать нужно без учета регистра. Иногда. Опять же простым сравнением не получается. Хеш-функция должна это учесть и это.
Для дополнительного веселья выясняется, что один из поддерживаемых языков имеет странные правила. И сравнивать строки нужно с учетом этих правил. Хеш-функция разрастается в монстра.
И тут уже все сильно зависит от доступного инструментария. Многие ЯВУ содержат встроенные средства для работы со всем этим. Хотя тот же C++ нет, но можно что-то найти.
Не так. Приложение исполняется полностью нативно, на том же процессоре, на котором запущена система. Эмуляция ограничена подменой вызовов.
Кстати, сама ОС может быть виртуализирована. Вы же не говорите, что от этого все приложения в ней стали не нативными? А они могут все исполняться в режиме эмуляции, на виртуальной машине эмулирующей требуемый процессор.
Более того, тот же .Net в нормальных случаях не предполагает исполнения в режиме эмуляции, весь код исполняется нативно.
Мы можем, конечно, привязаться именно к содержимому исполняемого файла. Но можно взять тот же C, откомпилировать и сразу запустить, не создавая никаких файлов вообще. Что в таком случае?
"автомобиль ускорился на 200%" = "автомобиль увеличил скорость в 3 раза".
"автомобиль замедлился на 200%" = ???
P.S. Изначально производительность была N исполнений в секунду. После оптимизации стала 3N исполнений в секунду. Была 100%. Стала 300%. Изменилась на 200%.
Ускорить на 200% = ускорить в 3 раза = увеличить скорость в 3 раза. Есть такая величина. Скорость.
Как нам говорит википедия (https://en.wikipedia.org/wiki/Fibonacci_number), правильная матрица ((1,1),(1,0)). Соответственно, для вычисления F[N] нам достаточно быстрого возведения матриц в степень. Очевидно, что существует алгоритм с логарифмической сложностью. Таким образом алгоритмы с меньшей эффективностью для достаточно большого N покажут результат хуже.
При желании можно заняться оптимизацией возведения в степень, ибо логарифмический алгоритм не является лучшим, хоть и тривиально реализуется.
Всё-таки, большая часть рогаликов не песочницы с открытый миром. Типичная схема — рельсы с парой ответвлений. Так что встроить что-то похожее на сюжет не то, чтобы чрезвычайно сложно, просто многие разделяют мнение Кармака. Есть общее направление (например, мы идем за древним артефактом) и ладно. Упор делается не на сюжете, а на создании интересного геймплея и уникальных ситуаций, требующих от игрока совершенствовать и применять навыки игры
Решается созданием случайных колебаний уровня WiFi сигнала, по величине сопоставимых с помехами. После этого такой анализ уже не сработает, слишком много шума. Вероятно, вопрос можно будет решить на уровне прошивки
У правильных параноиков средства вложены не в золотые монеты, которые сложно съесть, но легко изъять, а в долгосрочный запас
патронов, соли и спичекресурсов, представляющих непосредственную ценностьДа, они самые. В DF они часто включают необязательные шаги, которые добавляют ценности предметам. Сделал, скажем, стул, а потом украсил его. Но, с другой стороны, разный сеттинг, разная конечная цель. Если в DF нужно создать форт, который будет жить своей жизнью, то в RimWirld собрать корабль и улететь в более продвинутые миры.
Главное по краю не забыть разделение на секторы добавить, чтобы можно было впускать переселенцев, не подвергаясь опасности
Главное — не забыть добавить задание на разделку. Т.е. строишь разделочный стол — сразу добавляешь приказ разделывать до бесконечности
Скорее это казуальный клон с улучшенной графикой. Не скажу, что это сильно плохо.
DF имеет несколько крутую кривую обучения. "Отличный" интерфейс. Непредсказуемость места высадки (хотите огромную тучу гигантских москитов? нет? а вот и зря, веселье же). Гиперважность одних дварфов при почти полной бесполезности других. Огромное количество экономических цепочек. Хотя после некоторого уровня появляется умение в любой более-менее средней стартовой позиции построить форт, который если и не может отбить любую атаку, так хотя бы пересидеть.
В RimWorld это все сильно приглушено. Экономика проста и прямолинейна. Меньшее число колонистов. Двумерная карта облегчает ситуацию. Хотя, скажем, механика температуры вполне хорошо получилась, хотя на более поздних стадиях это сильно нивелируется. Генератор случайных событий не дает совсем расслабиться. Но некоторые события потом вместо интереса вызывают усталое "что, опять короткое замыкание?".
К нашей великой радости, на Go написана только каноничная версия Go. Модуль math напичкан оптимизациями под разные процессоры https://go.googlesource.com/go/+/master/src/math/, которые должны быть эквивалентны каноничной версии
Скажем, на x86 реализация округления до целого оказалась даже быстрее. Вариант с указанием количества значимых цифр медленнее. Похоже, что из-за умножения и деления на степень десятки.
Пример на C# http://ideone.com/KTbHGi
Может быть из-за этого и добавляют встроенные функции для таких операций?
В огороде бузина, а в Киеве дядька.
Во-первых, кресло в офисе удобное ровно по одной причине — это может потенциально улучшить эффективность и лояльность сотрудников, что потенциально может повысить прибыль. Вот вам коммерческий интерес удобных кресел.
Во-вторых, ситуация такова, что golang контролируется Google, а его разработка ведется со вполне определенной целью — повысить эффективность сотрудников Google, использующих его в работе.
Так что аналогия с креслом тут никак не применима.
Это зависит от ваших намерений относительно молотка.
Если вы планировали с его помощью увеличить доход или снизить затраты, то это самая настоящая коммерческая разработка.
Если цель была в получении новых знаний, то тогда разработка была бы исследовательская.
Еще бывает благотворительность, там цель — передача некоторых ценностей третьим лицам (в случае, если лица оказались не третьи, этим всем могут заинтересоваться органы).
Бывают смешанные случаи, скажем, более того, большая часть компаний большую часть своих продуктов (даже внутренних) разрабатывает хотя бы отчасти с коммерческими целями.
Тут, конечно, можно начать рассуждать о разработке некой группой, где не все участники планируют применять продукт разработки в коммерческих целях. Но тут нужно смотреть уже по отдельным участникам.
Так что, молоток для чего нужен?
Возвращаясь к golang, Google, очевидно, контролирует разработку языка, а цель разработки явно далека от чистого исследования или от благотворительности.
Вы правда не замечаете некоторой противоречивости утверждений "golang совершенно некоммерческий" и "Он вкладывается в СВОЙ СОБСТВЕННЫЙ ИНСТРУМЕНТ"?
Google вкладывает средства в разработку языка по доброте душевной?
Может дело в том, что переписав с tomcat+java на tomcat+java с 10-кратным приростом, получится покаянное письмо "какими же говнокодерами мы были"?
В чем принципиальное отличие?