Если орм то это же не просто пишет в ту-же табличку это и определения классов, и транзакции (а управление ими это совсем другая бибилиотека у которой тоже свои требования к версии) и много еще чего.
Все-таки самый простой вариант - оставить одну бибилиотеку. А если апи не слишком изменилось, то оно может заработать и так. Или какую-то простенькую прокладку написать.
Иметь две разные библиотеки еще большая глупость. Представьте что это библиотеки логирования, тогда для каждой нужна своя конфигурация. И у каждой будет свой файл с логами. А если это ОРМ, то у нас будет несколько транзакций, несколько копий entity, это точно не взлетит.
Чесно говоря не понял, в чпм проблема загрузить .bss и .data если с .text проблем нет.
После вашей загрузки вы спрашиваете размер памяти выделяете и отдаете программе. Но это тоже самое что загрузить остальные сегменты и дать программе адреса где они есть. Может вместо GetGlobalStateSize лучше было GetDataAddress, GetBssAddress или что-то подобное.
Дико читать на жалобы размера современных игр, с учетом того что там исполняемого кода (пусть даже не оптимизированого) от общего размера доли процента.
Я думаю стоит различать алгоритм и его реализацию. В алгоритме указываются ограничения на входные параметры и все. Писать там что делать, если не открылся файл или в файле не те данные глупо (да и невозможно, так как ввод вывод специфичен для языка, операционки,...). А вот эти всякие исключения и остальные ошибки - это неидеальная реальность, не имеющая никакого отношения к алгоритму.
Я вел речь про свою программу, исходный код которой выше. И все мои высказывания касаются указанной программы. Судя по всему мы говорим про разные вещи.
Я вас разочарую, да НИКОГДА. Потому что программа показывет частоту события а формула дает вероятность события. В чем разница - гугл или книжка по теории вероятности.
Вы о чем?! Какая вероятность что взятые от балды N, M, К, ETALON совпадут с фомулой?
Давайте по другому - у вас есть программа, у вас есть формула - контрпример в студию!
ЗЫ Только имейтке ввиду что количество интераций CCC дожно быть гораздо больше чем K^N - тогда у вас будет нормальный результат. В примере - 10000 / 1000000000 = 0,00001 - вполне достаточная цифра по сравнению с 0.003.
ЗЫЗЫ И вы НИКОГДА не пролучите точное значение из программы. Для точного значения требуется сделать БЕСКОНЕЧНОЕ число попыток.
Но подождите, это классический парадокс Рассела!
После строки
'ACCESS_TOKEN_LIFETIME': timedelta(days=30)
читать перестал.
Можно ж в SQL написать .... ((:val IS NULL) OR (column = :val)).... В функцию передаем или null или значение.
Если орм то это же не просто пишет в ту-же табличку это и определения классов, и транзакции (а управление ими это совсем другая бибилиотека у которой тоже свои требования к версии) и много еще чего.
Все-таки самый простой вариант - оставить одну бибилиотеку. А если апи не слишком изменилось, то оно может заработать и так. Или какую-то простенькую прокладку написать.
Иметь две разные библиотеки еще большая глупость. Представьте что это библиотеки логирования, тогда для каждой нужна своя конфигурация. И у каждой будет свой файл с логами. А если это ОРМ, то у нас будет несколько транзакций, несколько копий entity, это точно не взлетит.
Чесно говоря не понял, в чпм проблема загрузить .bss и .data если с .text проблем нет.
После вашей загрузки вы спрашиваете размер памяти выделяете и отдаете программе. Но это тоже самое что загрузить остальные сегменты и дать программе адреса где они есть. Может вместо GetGlobalStateSize лучше было GetDataAddress, GetBssAddress или что-то подобное.
Дико читать на жалобы размера современных игр, с учетом того что там исполняемого кода (пусть даже не оптимизированого) от общего размера доли процента.
Я думаю стоит различать алгоритм и его реализацию. В алгоритме указываются ограничения на входные параметры и все. Писать там что делать, если не открылся файл или в файле не те данные глупо (да и невозможно, так как ввод вывод специфичен для языка, операционки,...). А вот эти всякие исключения и остальные ошибки - это неидеальная реальность, не имеющая никакого отношения к алгоритму.
Еще самый красивый вариант:
@Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE, proxyMode = ScopedProxyMode.TARGET_CLASS)
Я вел речь про свою программу, исходный код которой выше. И все мои высказывания касаются указанной программы. Судя по всему мы говорим про разные вещи.
Я вас разочарую, да НИКОГДА. Потому что программа показывет частоту события а формула дает вероятность события. В чем разница - гугл или книжка по теории вероятности.
Очередной тест:
K = 5
N = 10
ETALON = {2, 1, 4, 3}
M = 4
cnt = 11187608, % = 0.011187608
((N - M + 1) * K ^ (N - M)) / K ^ N
((10 - 4 + 1) * 5 ^ (10 - 4)) / 5 ^ 10
7 * 5 ^ 6 / 5 ^ 10
7 * 15625 / 9 765 625 = 0.0112
Опять сходится!
Вы о чем?! Какая вероятность что взятые от балды N, M, К, ETALON совпадут с фомулой?
Давайте по другому - у вас есть программа, у вас есть формула - контрпример в студию!
ЗЫ Только имейтке ввиду что количество интераций CCC дожно быть гораздо больше чем K^N - тогда у вас будет нормальный результат. В примере - 10000 / 1000000000 = 0,00001 - вполне достаточная цифра по сравнению с 0.003.
ЗЫЗЫ И вы НИКОГДА не пролучите точное значение из программы. Для точного значения требуется сделать БЕСКОНЕЧНОЕ число попыток.
import java.security.SecureRandom;
public class Main {
private static int CCC = 1000_000_000;
private static int K = 10;
private static int N = 5;
}
Прогон програмы - результат cnt = 2990046, % = 0.002990046
По формуле - ((5-3+1)*10^2)/10^5 = 300/10000 = 0.003
Формула правильная.
Моя ошибка - учел вероятность нахождения последовательности в определленой позиции. Позиций всего (n-m+1)
Итог - ((n-m+1)*k^(n-m))/k^n
Давайте подставим - предположим у нас один символ и мы его и ожидаем. Понятно, что его вероятность 1/k. По формуле - к^0/k^1 = 1/k
Домашнее задание, рассмотреть строку из двух симвлов где один ожидаемый, и убедиться, что верояность соответствует формуле.
Решаем задачу классически:
Дано строка размера n с подстрокой размера m, вариантов каждого элемента k.
Вычисляем количество успешных вариантов - это сама подстрока плюс все возможные варианты каждого элемента и их n-m - итого k^(n-m)
Всего комбинаций - k^n
Вероятность - успешные варианты / всего вариантов - k^(n-m)/k^n
Самый надежный пароль - это его отсутствие (WebAuthn)! ;)
Так есть такой - micrometer traсing, для 2.х - spring cloud sleuth
Вроде как traceId передается в HTTP заголовке, и если его нет то вы и получите два трейса. Отсюда решение - проверить что этот заголовок передается.