А почему не просто на python бот? Даже вайбкодингом это уже можно сделать, но зато весь код ваш и крутится на вашем сервере, если что можно переехать на другой.
Может хотели купон получить и продать все потом :) Интересно, почему рыночная цена такая высокая на них была, неужи никто вообще не пытался продавать до погашения, чтобы хоть что-то близкое к номиналу вернуть.
Если числа целые и ограничены например 00-FF, то ту наверное обычный массив который в ячейке с индексом равным этому числу храниться количество раз, когда это число встретилось в потоке может быть проще и быстрее для вычисления медианы и по памяти не очень затратно.
А сколько нужно опервций на вычисление одного хеша? Какой нибудь sha 256 с его несколькими раундами модеж для одного значения взять столько же времени сколько вся сортировка.
Часто встречается использование этой конструкции для блокировки select в получении некоторого somefield, когда это поле меняется в параллельной транзакции, чтобы получить актуальное значение, когда поле используется как сквозной счетчик например (всякие кейсы со счетчиком лайков в соц сети или тому подобное) . Т.е. для конкурентного доступа к счетчику.
Я вообще то про работу копирайтара писал :). А вайб кодинд пока, как выи сказали, быстро мвп сделать. Просто если для мвп норм, то отчего в написании обычных текстов сразу фу?
Зачем это нужно? Вот если код написн с помошью vibeciding это круто время экономит и никого не смушает особо, если работает. А если текст писал не человек (что тоже не совсем так, тк учили сетку изначально на человеческих текстах) , то все пропало даже если текст нормальный(а раз нужен спец детектор, то текст точно нормальный)? Где логика? Конкуренты посмышленнее могут использовать это у себя и быстрее выводить предложения на рынок.
Те выходит что оператор not in (null, 1, 2) по идее всегда будет пустой датасет отдавать, потому что первое сранение всегда дает null, а дальше включается лен вая логика расчета логических выражений и проверок с 1 и 2 уже не будет?
Бездоказательно. Быстрая сортировка требует n log n операций на n элементов, а merge еще n операций на мерж, те условно n*(1+ log n) операций, а сколько потребует операций вычисление хеша для каждого из n элементов? Тут может быть совсем не проще и не быстрее.
А для каких объемов данных это актуально? Для того с чем нормально справляется python наверное отсортировать два множества и пройтись по ним аналогично merge sort оставляя только отсутствующие элементы в одном из списков, будет скорее всего не медленее вычисления хэшей для каждого элемента.
Тут уже не про parsint. Я пытаюсь понять чем цикл по символам строки с проверкой на вхождение в диапазон '0'-'9' медленее регэкспа. В любом же случае нужно пройти все символы строки минимум родин раз. При этом регжксп имеет оверхед на построение конечного автомата.
Если так просто, то можно было бы вытаскивать co2 из воздуха на платформах в океане (там вроде ветра и солнца в избытке чтобы энергию генерить) и полученный сухой лед складывать на дне в глубоких впадинах, где высокое давление 1000 бар и низкая температура (около 4 С) по идее оно там должно почти не сублимироваться и храниться очень долго не попадая обратно в атмосферу. Чем не способ бороться с парниковыми газами.
Ну я это к тому, что сам факт состоит строка только из цифр или нет сам по себе не очень ценен, следом же скорее всего будет вызван конверт в число, а тут сразу имеем это число или эсцепшен, когда не число.
А почему не просто на python бот? Даже вайбкодингом это уже можно сделать, но зато весь код ваш и крутится на вашем сервере, если что можно переехать на другой.
Может хотели купон получить и продать все потом :) Интересно, почему рыночная цена такая высокая на них была, неужи никто вообще не пытался продавать до погашения, чтобы хоть что-то близкое к номиналу вернуть.
Хм, а почему мы верим что в компиляторе нет ошибки? Он тоже скомпилен из кода на этом языке?
Если числа целые и ограничены например 00-FF, то ту наверное обычный массив который в ячейке с индексом равным этому числу храниться количество раз, когда это число встретилось в потоке может быть проще и быстрее для вычисления медианы и по памяти не очень затратно.
А сколько нужно опервций на вычисление одного хеша? Какой нибудь sha 256 с его несколькими раундами модеж для одного значения взять столько же времени сколько вся сортировка.
Часто встречается использование этой конструкции для блокировки select в получении некоторого somefield, когда это поле меняется в параллельной транзакции, чтобы получить актуальное значение, когда поле используется как сквозной счетчик например (всякие кейсы со счетчиком лайков в соц сети или тому подобное) . Т.е. для конкурентного доступа к счетчику.
Я вообще то про работу копирайтара писал :). А вайб кодинд пока, как выи сказали, быстро мвп сделать. Просто если для мвп норм, то отчего в написании обычных текстов сразу фу?
Зачем это нужно? Вот если код написн с помошью vibeciding это круто время экономит и никого не смушает особо, если работает. А если текст писал не человек (что тоже не совсем так, тк учили сетку изначально на человеческих текстах) , то все пропало даже если текст нормальный(а раз нужен спец детектор, то текст точно нормальный)? Где логика? Конкуренты посмышленнее могут использовать это у себя и быстрее выводить предложения на рынок.
Не совсем так. GCC без входных данных (исходников) ничено не сгенерит, а чтобы написать исходники мозги нужны.
Те выходит что оператор not in (null, 1, 2) по идее всегда будет пустой датасет отдавать, потому что первое сранение всегда дает null, а дальше включается лен вая логика расчета логических выражений и проверок с 1 и 2 уже не будет?
Это лечится включением параметра ANSI_NULLS на MS SQL. Добавлено было очень давно, где в 2008 версии.
Бездоказательно. Быстрая сортировка требует n log n операций на n элементов, а merge еще n операций на мерж, те условно n*(1+ log n) операций, а сколько потребует операций вычисление хеша для каждого из n элементов? Тут может быть совсем не проще и не быстрее.
А для каких объемов данных это актуально? Для того с чем нормально справляется python наверное отсортировать два множества и пройтись по ним аналогично merge sort оставляя только отсутствующие элементы в одном из списков, будет скорее всего не медленее вычисления хэшей для каждого элемента.
Даже если таблица создана как unloggable?
Филантропы и государство, врядли кто-то еще захочет.
Тут уже не про parsint. Я пытаюсь понять чем цикл по символам строки с проверкой на вхождение в диапазон '0'-'9' медленее регэкспа. В любом же случае нужно пройти все символы строки минимум родин раз. При этом регжксп имеет оверхед на построение конечного автомата.
Если так просто, то можно было бы вытаскивать co2 из воздуха на платформах в океане (там вроде ветра и солнца в избытке чтобы энергию генерить) и полученный сухой лед складывать на дне в глубоких впадинах, где высокое давление 1000 бар и низкая температура (около 4 С) по идее оно там должно почти не сублимироваться и храниться очень долго не попадая обратно в атмосферу. Чем не способ бороться с парниковыми газами.
А за счет чего быстрее выходит?
Глобально, в любом случае, нужно пройти всю строку и каждый символ чекнуть на принадлежность диапазону >= '0' and <= '9'.
Тут сравнивается скорость скомпиленного в натив кода с кодом выполненным виртуальной машиной?
Ну я это к тому, что сам факт состоит строка только из цифр или нет сам по себе не очень ценен, следом же скорее всего будет вызван конверт в число, а тут сразу имеем это число или эсцепшен, когда не число.
А всякие Int32.Parse насколько хуже чем регулярки?