А если масса материи перед горизонтом станет настолько большой, что ее силы гравитации хватит на образование еще одного горизонта событий. Это выходит что сверхмассивные ЧД, это слоеный пирог из тысяч горизонтов?
Наверное было бы хорошо, если бы все эти красивости можно было отключить через настройки. Тогда каждый может сам решить нужно ему это или нет. Я например для целей навигации использую всегда вид сверху, без наклона карты и все эти красивости не особо нужны.
Если взять например python, то в нем много чего в библиотеках написано на C, который на порядок быстрее paython. И любой ваш супер оптимальный алгоритм будет проигрывать в скорости коду на C. Да и по затратам памяти массив в numpy намного меньше чем аналогичный paython - ский список. Поэтому для прикладной разработки использовать библиотеки это наверное более оптимально, чем самому изобретать. А вот для системной разработки наверное уже может иметь смысл что-то придумывать.
Тут наверное можно поиметь проблемы со spring, если попробовать заижектить объект в поле или параметр у которого тип это sealed интерфейс. Оно может при исполнении рвануть и не сразу будет понятно от чего.
Спасибо. И ещё тогда вопрос: Как учитывается комиссия брокера в расчёте доходности в этой стратегии. Ведь по факту за эти три сделки можно заплатить 25 р комисси при 24 р дохода.
А есть возможность прогнать эту стратегию на реальных данных, а не исторических. Но при этом в демо режиме, без реальной торговли? Так можно было бы реально её оценить, погоняв пару дней например.
А если представить как разность двух арифметических прогрессии, то выходит для чётной части сумма n первых членов =(n+1)*n, а для нечетной части = n^2, при длинне ряда 2*n.
Если теперь из нечетной вычесть учётную, то выходит = n^2 - (n^2 + n) = - n.
Т.е. с ростом числа членов в ряду сумма ряда стремиться к -infinity.
А индексы тоже сжимается или только данные в таблицах?
Ну и наверное есть повышенное требование на оперативную память, ведь поднять в память кусок таблицы и распаковать займёт теперь в 5 раз больше места, или это не так?
Как распаковка данных влияет на требования к cpu, теперь же кроме джойнов нужно ещё и распаковку выполнять, особенно сильно должно в много пользовательского системе влиять, делали ли такие замеры?
А отсюда как-то можно понять что это за коэффициенты k и g00 и какая у них размерность? Можно ли отсюда установить связь с гравитационной постоянной G?
А если со временем из-за излучения Хокинга масса дыры упадёт до того состояния, что дыра не может оставаться чёрной дырой, то дыра рванет и снова все вернётся и материя и информация?
А если масса материи перед горизонтом станет настолько большой, что ее силы гравитации хватит на образование еще одного горизонта событий. Это выходит что сверхмассивные ЧД, это слоеный пирог из тысяч горизонтов?
А если жесты показывать левой и правой рукой они одинаково правильно распознаются?
Наверное было бы хорошо, если бы все эти красивости можно было отключить через настройки. Тогда каждый может сам решить нужно ему это или нет. Я например для целей навигации использую всегда вид сверху, без наклона карты и все эти красивости не особо нужны.
А вы заводите MR на исправление этих ошибок? Так было бы больше пользы от проведенной проверки.
Хорошо что пока не пришли к тому, что просто люди не нужны :)
Если взять например python, то в нем много чего в библиотеках написано на C, который на порядок быстрее paython. И любой ваш супер оптимальный алгоритм будет проигрывать в скорости коду на C. Да и по затратам памяти массив в numpy намного меньше чем аналогичный paython - ский список. Поэтому для прикладной разработки использовать библиотеки это наверное более оптимально, чем самому изобретать. А вот для системной разработки наверное уже может иметь смысл что-то придумывать.
Тут наверное можно поиметь проблемы со spring, если попробовать заижектить объект в поле или параметр у которого тип это sealed интерфейс. Оно может при исполнении рвануть и не сразу будет понятно от чего.
И рыбы все помрут под таким слоем льда.
А почему обязательно e-ink, вроде ЖК дисплеи еще меньше потребляли?
Спасибо. И ещё тогда вопрос: Как учитывается комиссия брокера в расчёте доходности в этой стратегии. Ведь по факту за эти три сделки можно заплатить 25 р комисси при 24 р дохода.
А есть возможность прогнать эту стратегию на реальных данных, а не исторических. Но при этом в демо режиме, без реальной торговли? Так можно было бы реально её оценить, погоняв пару дней например.
У нас модульный монолит. Без orm, для работы с PG написали конвертер запросов, который на лету конвертирует запрос с mssql в pgsql.
Насколько сложно подключить к анализатору новый язык. Например Rust вместо C. Или это равносильно тому что все переписывать?
Скорее это код, который Не написали. Он чистый и прозрачный :)
А если представить как разность двух арифметических прогрессии, то выходит для чётной части сумма n первых членов =(n+1)*n, а для нечетной части = n^2, при длинне ряда 2*n.
Если теперь из нечетной вычесть учётную, то выходит = n^2 - (n^2 + n) = - n.
Т.е. с ростом числа членов в ряду сумма ряда стремиться к -infinity.
А индексы тоже сжимается или только данные в таблицах?
Ну и наверное есть повышенное требование на оперативную память, ведь поднять в память кусок таблицы и распаковать займёт теперь в 5 раз больше места, или это не так?
Как распаковка данных влияет на требования к cpu, теперь же кроме джойнов нужно ещё и распаковку выполнять, особенно сильно должно в много пользовательского системе влиять, делали ли такие замеры?
А отсюда как-то можно понять что это за коэффициенты k и g00 и какая у них размерность? Можно ли отсюда установить связь с гравитационной постоянной G?
А если со временем из-за излучения Хокинга масса дыры упадёт до того состояния, что дыра не может оставаться чёрной дырой, то дыра рванет и снова все вернётся и материя и информация?
Не очень понятно из предложенного кода, как учитывается вероятность перехода при генерации текста. По коду выходит, что все переходы равновероятны.
Вроде это из манифеста python третий пункт, он Guido van Rossum :)