Я никак не могу понять ситуацию с библиотечными функциями, скорость работы которых драматически зависит от величины аргумента. Это получается, что авторы библиотеки не тестировали производительность и не воспользовались очевидными свойствами симметричности и периодичности? Это ведь не экзотические функции, и это происходит в языке, которому 50 лет.
Я далёк от мира микроконтроллеров, но мне это кажется ненормальным. Может быть, этому есть логичное объяснение?
Проясните один вопрос, пожалуйста. Не могу найти на него ответ. Наблюдения свидетельствуют о том, что вселенная расширяется, и дают примерную оценку времени ее существования и расширения. С другой стороны, есть радиус Шварцшильда, который для наблюдаемой вселенной равен примерно 10 миллиардам световых лет. Это меньше, чем оценки текущего размера вселенной, соответственно, скорее всего, в данный момент мы не находимся в черной дыре. С другой стороны, когда-то радиус наблюдаемой вселенной был меньше радиуса Шварцшильда. Была ли вселенная на том этапе черной дырой? И если была, то применим ли такой же механизм эволюции черной дыры во что-то другое к другим черным дырам? А если нет (вселенная никогда не была черной дырой), то почему?
Да на самом деле я намекаю на то, что это не работает вот так. Судьба пингвинов в Антарктиде - безусловно, важно, но коммерческие компании создаются для получения прибыли. И действенными являются экономические методы. Вот, например, дешевая электроэнергия во время избытка и дорогая во время дефицита. А в этом случае уже становится все равно, как именно её потреблять. Если датацентру будет выгоден простой мощностей во время дефицита энергии, он сам появится без всякого булшита типа "Информационные батареи". И если стирку будет выгодно запускать ночью, на рынке появятся стиральные машины с таймером.
При таком раскладе, через пять лет количество вычислительных мощностей, например, ежегодно простаивающих в Калифорнии, будет эквивалентно количеству вычислительных мощностей, используемых Лос-Анджелесом каждый год.
И окажется, что существуют (как концепция, по крайней мере) электростанции на газу, которые можно включать во время недостатка мощности.
Хотел задать тот же вопрос. Про геостационарную орбиту так с натяжкой можно было бы сказать, но тут и близко не она.
Но по сути вся статья состоит из игнорирования законов экономики, математики и небесной механики, а также перевирания фактов. Я даже уверен, что это не "добросовестное заблуждение" а вполне сознательная ложь.
С другой стороны, ложь в данной статье не означает, что Старлинк взлетит. Но если его и ждёт провал, то по другим причинам.
Получется не очень красиво, но мое полное решение пока выглядит так:
Первая задача сводится к системе уравнений
a+b=x^2
a+c=(x+1)^2
b+c=(x+2)^2
с условиями целых корней a, b, c в интервале [n, 2n]
эта система имеет корни a = (x^2-2*x-3)/2, b = (x^2+2*x+3)/2 и c = (x^2+6*x+5)/2. Целые корни будут при нечетных x. Теперь нас интересует, при каких n в интервале [n, 2*n] всегда найдется тройка целых чисел такого вида. По сути, поскольку a < b < c, то нас интересуют числа a и c. Это автоматически выполняется, когда a(x)*2 >= c(x+2) (это не умножение, а аргумент). То есть, когда (x+2)^2+6*(x+2)+5 <= 2*(x^2-2*x-3). Это неравенство имеет решение x >= 7+2*sqrt(19). Ближайшее нечетное целое - 17. Соответственно, утверждение доказано для с >= 198 и соответственно a >= 99 (n = a >= 99).
Мои соображения по первой: она сводится к системе уравнений
a+b=x^2
a+c=(x+1)^2
b+c=(x+2)^2
с условиями целых корней a, b, c в интервале [n, 2n]
эта система имеет корни (x^2-2x-3)/2, (x^2+2x+3)/2 и (x^2+6x+5)/2. Целые корни будут при нечетных x. Нас по сути интересует первое и последнее, (x^2-2x-3)/2 >= n, (x^2+6x+5)/2 <= 2n. Преобразуя эти неравенства, получим x^2-10x-11 >= 0, и соответственно x >= 11. Соответственно условие из исходной задачи выполняется при n >= 48
Но ведь в механике игры нет блоков, есть только ячейки, которые синхронно меняют поколения. Устойчивые блоки и разные примечательные фигуры - это уже результат нашего восприятия процесса.
Возможно, я вас неправильно понял, но я не могу представить простых правил, которые будут делить фигуры на поколения.
Мой вариант: поскольку жизнь зарождается только при наличии трёх соседей, то можно определить правила для цвета новой ячейки. Например (первые два циклические, как сделать равноправное третье пока не придумал):
Да я не об этом, просто после беглого прочтения возникло ощущение, что что-то в этом комментарии не то. А вот на понимание того, что именно, ушло прилично времени.
Все-таки пока 50, и 20-30 минут - это для 50. Но ради заголовка я попробовал и 100, просто продублировав товары с разными Id - работает.
Что касается LuceneNet, то определенно стоит изучить возможности. Но я люблю работать с алгоритмами больше, чем с конфигурациями, а тут такая возможность появилась.
Поиск для конечных пользователей, когда до него дойдет очередь, будем строить на сторонних библиотеках, скорее всего. А требования (или пожелания) к поиску для администраторов как раз лучше закрываются самописным алгоритмом.
Первоначальное заполнение занимает около 20-30 минут.
Что касается готовых движков, то те, с которыми я работал раньше, не умели искать по подстроке, то есть, были не способны найти "65U790KB" по запросу "65U790K", а это в нашем случае важно. По сути, такое поведение понятно, они создавались для поиска по тексту на естественном языке. Возможно, сейчас кто-то уже так может, но я положился на свой прошлый опыт.
Второй вариант - использовать готовый движок, но с индексом не по словам, а по триграммам. И сначала у нас был именно такой подход, но в какой-то момент перестала устраивать скорость работы.
Есть еще два аргумента против готового:
Свой поиск получился довольно простым по устройству, и его мы полностью контролируем, а не ограничены настройками готового движка. С другой стороны, мы ограничены своими возможностями, и, например, морфологии у нас никогда не будет.
Мы стараемся минимизировать количество инфраструктурных зависимостей. Сейчас такая зависимость только одна - SQL Server. В общем, такой вот keep it simple.
Я даже не знаю, сколько пустых, но давайте попробуем посчитать потенциальную экономию.
public class List<T> : IList<T>, IList, IReadOnlyList<T>
{
private const int DefaultCapacity = 4;
internal T[] _items; // Do not rename (binary serialization)
internal int _size; // Do not rename (binary serialization)
private int _version; // Do not rename (binary serialization)
private static readonly T[] s_emptyArray = new T[0];
........
}
Это фрагмент исходного кода .NET 5
Для хранения пустого списка на 64-битной системе потребуется 8 + 4 + 4 = 16 байт. Плюс хранение ссылки на этот список потребует 8 байт, итого 24 байта без учета выравнивания. Потребление памяти с выравниванием я сходу не посчитаю, к сожалению, поэтому оставим так.
Всего у нас 343 000 списков, это дает 8 232 000 байт потенциальной экономии для случаев, когда индекс создали, а использовать не стали.
Думаю, в нашем случае, когда индекс создается в одном экземпляре, экономией 8 мегабайт памяти можно пренебречь ради упрощения кода. С другой стороны, если бы речь шла про переиспользуемую библиотеку, учесть это обязательно нужно.
Возможно, я найду время и оформлю эту идею в виде nuget - пакета, и тогда сделаю ленивую инициализацию.
Я никак не могу понять ситуацию с библиотечными функциями, скорость работы которых драматически зависит от величины аргумента. Это получается, что авторы библиотеки не тестировали производительность и не воспользовались очевидными свойствами симметричности и периодичности? Это ведь не экзотические функции, и это происходит в языке, которому 50 лет.
Я далёк от мира микроконтроллеров, но мне это кажется ненормальным. Может быть, этому есть логичное объяснение?
Проясните один вопрос, пожалуйста. Не могу найти на него ответ. Наблюдения свидетельствуют о том, что вселенная расширяется, и дают примерную оценку времени ее существования и расширения. С другой стороны, есть радиус Шварцшильда, который для наблюдаемой вселенной равен примерно 10 миллиардам световых лет. Это меньше, чем оценки текущего размера вселенной, соответственно, скорее всего, в данный момент мы не находимся в черной дыре. С другой стороны, когда-то радиус наблюдаемой вселенной был меньше радиуса Шварцшильда. Была ли вселенная на том этапе черной дырой? И если была, то применим ли такой же механизм эволюции черной дыры во что-то другое к другим черным дырам? А если нет (вселенная никогда не была черной дырой), то почему?
Да на самом деле я намекаю на то, что это не работает вот так. Судьба пингвинов в Антарктиде - безусловно, важно, но коммерческие компании создаются для получения прибыли. И действенными являются экономические методы. Вот, например, дешевая электроэнергия во время избытка и дорогая во время дефицита. А в этом случае уже становится все равно, как именно её потреблять. Если датацентру будет выгоден простой мощностей во время дефицита энергии, он сам появится без всякого булшита типа "Информационные батареи". И если стирку будет выгодно запускать ночью, на рынке появятся стиральные машины с таймером.
Хотя, погодите...
А потом второй заход.
И окажется, что существуют (как концепция, по крайней мере) электростанции на газу, которые можно включать во время недостатка мощности.
Похоже на результаты выборов.
В сумме больше ста процентов, размеры секторов не соответствуют числам.
Скорее всего, на горящие полигоны и ТБО приходится 35.3%
Хотел задать тот же вопрос. Про геостационарную орбиту так с натяжкой можно было бы сказать, но тут и близко не она.
Но по сути вся статья состоит из игнорирования законов экономики, математики и небесной механики, а также перевирания фактов. Я даже уверен, что это не "добросовестное заблуждение" а вполне сознательная ложь.
С другой стороны, ложь в данной статье не означает, что Старлинк взлетит. Но если его и ждёт провал, то по другим причинам.
CSS is awesome!
Получется не очень красиво, но мое полное решение пока выглядит так:
Первая задача сводится к системе уравнений
a+b=x^2
a+c=(x+1)^2
b+c=(x+2)^2
с условиями целых корней a, b, c в интервале [n, 2n]
эта система имеет корни a = (x^2-2*x-3)/2, b = (x^2+2*x+3)/2 и c = (x^2+6*x+5)/2. Целые корни будут при нечетных x. Теперь нас интересует, при каких n в интервале [n, 2*n] всегда найдется тройка целых чисел такого вида. По сути, поскольку a < b < c, то нас интересуют числа a и c. Это автоматически выполняется, когда a(x)*2 >= c(x+2) (это не умножение, а аргумент). То есть, когда (x+2)^2+6*(x+2)+5 <= 2*(x^2-2*x-3). Это неравенство имеет решение x >= 7+2*sqrt(19). Ближайшее нечетное целое - 17. Соответственно, утверждение доказано для с >= 198 и соответственно a >= 99 (n = a >= 99).
У меня получилось 4 = 4 для этого случая, т.е. нестрогое неравенство выполняется.
Вы правы. Похоже, n >= 48 это необходимое условие, над достаточным надо ещё подумать, пока ничего в голову не приходит.
Мои соображения по первой: она сводится к системе уравнений
a+b=x^2
a+c=(x+1)^2
b+c=(x+2)^2
с условиями целых корней a, b, c в интервале [n, 2n]
эта система имеет корни (x^2-2x-3)/2, (x^2+2x+3)/2 и (x^2+6x+5)/2. Целые корни будут при нечетных x. Нас по сути интересует первое и последнее, (x^2-2x-3)/2 >= n, (x^2+6x+5)/2 <= 2n. Преобразуя эти неравенства, получим x^2-10x-11 >= 0, и соответственно x >= 11. Соответственно условие из исходной задачи выполняется при n >= 48
Но ведь в механике игры нет блоков, есть только ячейки, которые синхронно меняют поколения. Устойчивые блоки и разные примечательные фигуры - это уже результат нашего восприятия процесса.
Возможно, я вас неправильно понял, но я не могу представить простых правил, которые будут делить фигуры на поколения.
Мой вариант: поскольку жизнь зарождается только при наличии трёх соседей, то можно определить правила для цвета новой ячейки. Например (первые два циклические, как сделать равноправное третье пока не придумал):
rrr -> g, rrg -> b, rgb -> r
Да я не об этом, просто после беглого прочтения возникло ощущение, что что-то в этом комментарии не то. А вот на понимание того, что именно, ушло прилично времени.
как-то так
Я чуть мозг не сломал, пытаясь понять, что не так с вашим комментарием.
В таком случае деплатформить должны юрлицо, а не хостинг. И госорганы, а не частная компания.
Очень хочется иметь такое меню на десктопе во-первых, и возможность настраивать доступные пункты на мобильном во-вторых.
Лично мне нужны только copy и web search, но web search спрятан за тремя точками.
А на десктопе пока расширением Selection Search пользуюсь, но оно неидеально работает.
Все-таки пока 50, и 20-30 минут - это для 50. Но ради заголовка я попробовал и 100, просто продублировав товары с разными Id - работает.
Что касается LuceneNet, то определенно стоит изучить возможности. Но я люблю работать с алгоритмами больше, чем с конфигурациями, а тут такая возможность появилась.
Поиск для конечных пользователей, когда до него дойдет очередь, будем строить на сторонних библиотеках, скорее всего. А требования (или пожелания) к поиску для администраторов как раз лучше закрываются самописным алгоритмом.
Первоначальное заполнение занимает около 20-30 минут.
Что касается готовых движков, то те, с которыми я работал раньше, не умели искать по подстроке, то есть, были не способны найти "65U790KB" по запросу "65U790K", а это в нашем случае важно. По сути, такое поведение понятно, они создавались для поиска по тексту на естественном языке. Возможно, сейчас кто-то уже так может, но я положился на свой прошлый опыт.
Второй вариант - использовать готовый движок, но с индексом не по словам, а по триграммам. И сначала у нас был именно такой подход, но в какой-то момент перестала устраивать скорость работы.
Есть еще два аргумента против готового:
Свой поиск получился довольно простым по устройству, и его мы полностью контролируем, а не ограничены настройками готового движка. С другой стороны, мы ограничены своими возможностями, и, например, морфологии у нас никогда не будет.
Мы стараемся минимизировать количество инфраструктурных зависимостей. Сейчас такая зависимость только одна - SQL Server. В общем, такой вот keep it simple.
Хорошее замечание, спасибо.
Я даже не знаю, сколько пустых, но давайте попробуем посчитать потенциальную экономию.
Это фрагмент исходного кода .NET 5
Для хранения пустого списка на 64-битной системе потребуется 8 + 4 + 4 = 16 байт. Плюс хранение ссылки на этот список потребует 8 байт, итого 24 байта без учета выравнивания. Потребление памяти с выравниванием я сходу не посчитаю, к сожалению, поэтому оставим так.
Всего у нас 343 000 списков, это дает 8 232 000 байт потенциальной экономии для случаев, когда индекс создали, а использовать не стали.
Думаю, в нашем случае, когда индекс создается в одном экземпляре, экономией 8 мегабайт памяти можно пренебречь ради упрощения кода. С другой стороны, если бы речь шла про переиспользуемую библиотеку, учесть это обязательно нужно.
Возможно, я найду время и оформлю эту идею в виде nuget - пакета, и тогда сделаю ленивую инициализацию.
По сути, мы именно это и сделали, только на уровне триграмм, а не слов.