Нет, не приводятся - double он и в Африке double, и что там, что тут - 64 бит (размеры floating-point data types не зависит от разрядности и одинаковы и для x86 и для x64). При этом даже для x86, внутренние FPU регистры - 80 бит. Различие может быть лишь в оптимизации, да в используемых инструкциях (mulsd vs fmul).
Да. Гипотеза не работает для большинства значений n в районе 906 150 257 ≤ n ≤ 906 488 079. В этой области суммирующая функция Лиувилля достигает максимального значения 829 при n = 906 316 571.
Совершенно верно... Вообще очень странные тесты... В конкретном случае - var vs let vs const vs sloppy там по большей части вообще измеряется spreading array mutations & push (+ память/кэш всех уровней, + GC, + тому подобное), но никак не заявленное в названии теста.
Если переписать тест хотя бы без вызова push и spread-op (что справедливо ибо объявленная g всё равно immutable), всё очень сильно изменится (и соответственно возможноvar будет быстрее только лишь sloppy, проигрывая и let и const):
"Возможно" - потому что оверхед собственно измерения и соответственно шумы и погрешности будут много выше той незначительной разницы (если она вообще есть в SpiderMonkey или V8 при компиляции в браузере).
<img src="боромир-мим.jpg"/> Нельзя просто взять и померить разницу в скорости var vs let vs const в JS в браузере, просто потому что там нет подходящего быстрого инструмента (цикла) для измерений, так чтобы при компиляции var, let или const результат не вырождался тупо в константное выражение, посчитанное на стадии компиляции цикла.
Т.е. даже что-то подобное нижеследующему вряд ли покажет ту разницу реально (и те +13ms или +173ms ниже тупо не являются какими-либо флуктуациями опять же из-за огромного overhead сверху):
// 1e9 итераций, const vs var:
(() => { const x = 1, X = {f: function() {return x}}; var v = 0; performance.mark('m1'); for (let i = 1e9; i > 0; i--) { v += X.f()+X.f()+X.f()+X.f()+X.f(); } performance.mark('m2'); })(); performance.measure('test', 'm1', 'm2')
► PerformanceMeasure {..., duration: 1057}
(() => { var x = 1, X = {f: function() {return x}}; var v = 0; performance.mark('m1'); for (let i = 1e9; i > 0; i--) { v += X.f()+X.f()+X.f()+X.f()+X.f(); } performance.mark('m2'); })(); performance.measure('test', 'm1', 'm2')
► PerformanceMeasure {..., duration: 1070}
// 1e10 итераций, const vs var:
(() => { const x = 1, X = {f: function() {return x}}; var v = 0; performance.mark('m1'); for (let i = 1e10; i > 0; i--) { v += X.f()+X.f()+X.f()+X.f()+X.f(); } performance.mark('m2'); })(); performance.measure('test', 'm1', 'm2')
► PerformanceMeasure {..., duration: 13077.5}
(() => { var x = 1, X = {f: function() {return x}}; var v = 0; performance.mark('m1'); for (let i = 1e10; i > 0; i--) { v += X.f()+X.f()+X.f()+X.f()+X.f(); } performance.mark('m2'); })(); performance.measure('test', 'm1', 'm2')
► PerformanceMeasure {..., duration: 13250.1}
В 98-99 гг? Я где-то в году так 2015-м эту утку снова встречал, причем с кучей комментов поверивших в это людей. Особенно доставляет, что икра той жабы чёрная и мелкая (т.е. с красной икрой ну никак не возможно спутать) и в 2015-м это всё прекрасно гуглится.
Выглядит как-то так...
Икра откладывается в виде шнуров длиной до 1,5-1,8 м. Икринки в шнуре расположены в 2 ряда. Диаметр яйца 1,1-1,5 мм.
Два контакта по 65*65 нм нельзя изготовить на литографе для работы с нормами 90 нм.
Ну во первых строго говоря это не совсем так, вернее совсем не так (и я даже не про множественное экспонирование)... А во вторых изменением архитектуры (например другая компоновка типа тех же интелёвых Foveros, ODI, Co-EMIB и т.п. 2.5D или 3D stacking) можно на 90 нм литографе в теории сделать хоть 10 нм (ну типа в девять "слоёв" если). Я не говорю сейчас что просто и без проблем, я лишь собственно про "нельзя изготовить".
Зачем дергать при каждом запуске и держать список из 12 тысяч с гаком команд (ака wordlist) для каждой сессии bash, тем более если оно нужно то бывает редко-редко.
К звуку это отношения не имеет. И замена довольно распространенная в IT (да и не только там)... Например µs -> us (потому что ms уже занято за миллисекундами).
Проблема с теми AI здесь всегда собственно обучающая выборка - на чем его натаскивают и насколько это "правильно" им разбирается, от "синтаксиса" и "морфологии" до абстракций каких-нибудь... А сарказм если, а пограничные условия какие-либо, и т.п.
Притом что врёт местами безбожно. Например в случае sqlite про скорость оно всё с точностью наоборот. Т.к. sqlite не умеет в оптимизацию NOT IN () чтобы юзать кортёжный индекс (type,id), т. е. получим fullscan со всеми вытекающими. Более того не просто соврамши - а конкретно так, ибо big-O в случае NOT IN () сильно так нелинейно будет.
Прув на Tcl (просто мерить сподручнее и быстрее)
% sqlite3 db :memory:
% db eval "CREATE TABLE pages ( type TEXT, id TEXT, content TEXT, PRIMARY KEY (type, id) ); CREATE TABLE pages_done ( type TEXT, id TEXT, PRIMARY KEY (type, id) );"
% set i 0; while {$i < 10000} {incr i; set t "type$i"; set c "content $i"; db eval {insert into pages values(:t, :i, :c)}; if {$i & 1} {db eval {insert into pages_done values(:t, :i)}}}
% db eval {select (select count(*) from pages), (select count(*) from pages_done)}
10000 5000
% timerate {db eval {SELECT p.type, p.id, p.content FROM pages p LEFT JOIN pages_done pd ON p.type = pd.type AND p.id = pd.id WHERE pd.type IS NULL LIMIT 4999,1}}
4185.05 µs/# 239 # 238.95 #/sec 1000.226 net-ms
% timerate {db eval {SELECT type, id, content FROM pages WHERE (type, id) NOT IN (SELECT type, id FROM pages_done) LIMIT 4999,1}}
1520435 µs/# 1 # 0.658 #/sec 1520.435 net-ms
Для случая IN () AI был бы прав:
% timerate {db eval {SELECT p.type, p.id, p.content FROM pages p LEFT JOIN pages_done pd ON p.type = pd.type AND p.id = pd.id WHERE pd.type IS NOT NULL LIMIT 4999,1}}
3879.22 µs/# 258 # 257.78 #/sec 1000.839 net-ms
% timerate {db eval {SELECT type, id, content FROM pages WHERE (type, id) IN (SELECT type, id FROM pages_done) LIMIT 4999,1}}
2326.35 µs/# 431 # 429.86 #/sec 1002.658 net-ms
Тоже резануло по глазам... Это при том что он прямо об обратном говорил (и неоднократно на моей памяти). Да и как оно возможно вообще, когда такое изменение вызовет целую лавину (с потенциальными конфликтами везде и вся, и т.д.), ибо как писал упомянутый RMS:
"When we say that GPLv2 and GPLv3 are incompatible, it means there is no legal way to combine code under GPLv2 with code under GPLv3 in a single program. This is because both GPLv2 and GPLv3 are copyleft licenses: each of them says, “If you include code under this license in a larger program, the larger program must be under this license too.” There is no way to make them compatible."
Нужно наверно уточнить что здесь значит "in a single program" - link, merge or combine code of two different programs with GPLv2 and GPLv3.
Центр Гамбурга (Германия - согласно той статистики 33-е место), 4G/LTE с трудом выдает 3Mbps (и пинг за сотню), при том что в различных крыльях здания, расположенного буквой П, местами тот 4G падает до E а то и вообще до 0 (причем в разных местах у разных провайдеров по разному - в одном месте у одного 0 или E, в другом - у другого).
Отъехав от Гамбурга на какие то 5 км (да и в самом городе местами) вы можете вообще потерять связь. Совсем. Езжу 15км от дома до работы и местами (всегда одни и те же три/четыре точки) - тупо дыра, ни интернет-радио, ни ватсап, ни ТГ - ничего, пока тупо их не проедешь.
покрытие около г. Гамбург для разных сетей
O2 / TelefonicaD2 / VodafoneD1 / Telekom
И это не в одной Германии так. Поездив по миру, я много где наблюдал подобную картину (за несколькими исключениями, например в той же Голландии и Норвегии). При том что в РФ как раз очень редко случалось, что связи нет вовсе. И я не про "внутри МКАДа" сейчас... Даже, как-то лет 10 назад, проехав 2 тысячи км, Санкт-Петербург - Вологда - Киров - Пермь - Екатеринбург, связь по ощущениям была почти везде. В той же Германии 10 лет назад было совсем печально всё.
гигабит по воздуху доступен
Да-да... и травка зеленее, и солнышко желтее.
В массе своей 50-100 а то и 10Мбит/с для стационарного-то интернета (DSL) - уже считается хорошо. Стекловолокно тянут конечно тут и там, но как-то всё не разгонятся. По воздуху же гигабит - вообще что-то из области фантастики. И даже если он номинально имеется (по договору 5G присутствует), то по факту выше 4G+ (а реально где-то в районе 250Мбит/с) я скоростей не видел, и не слышал ни от кого пока.
Как мне кажется проблема в той статистике, что если "сложить" человека (сидящего рядом с 5G антенной) с условными 450Мбит/с и 9 человек с 10Мбит/с, то в среднем получим тот полтинник (согласно статистике 53.65Mbps). Только его по факту как не было так и нет. Ну и парадокс выжившего сверху (из мест с 0Мбит статистика тупо не идет).
Нужно просто добавить итераций (параметер number)... Все эти варианты очень быстры и при 1000 итераций (время исполнения микросекунды) погрешность измерения очень высока - оверхед близок к собственно исполнению, плюс некоторая гранулярность из-за разрешения таймера (для винды как правило 15.6 ms) и т.д.
Для замеров скорости мелкого и быстрого кода, нужно использовать number=1000000 и выше.
Про Kann-Darf-Soll? Не зависит это от "местных разговорных обычаев" никак. Что в Гамбурге, что в Мюнхене, что в городе, что в деревне всё одно будет (разве только местами с жутким выговором).
Мешаем 10K раз текущие год-неделя и/или год-месяц, ну и только год с каким-нибудь секретом и "семечками", всё это в строчку по основанию 36 и получаем кучу доменов видаrmncxhceao.tld. Аппараты будут пробовать стучаться по всем 10K доменам, а ботоводу нужно создать из тех вариантов только 1 для года, 1 для года-месяца, чтобы отдать "команду". Ну или ещё один для года-неделя, если сильно срочно надо или там увезти или "поднагрузить" чуть-чуть уже проданную бот-сеть нужно.
Есть и много хитрее алгоритмы, но мы тут не будем скрипт-киддис обучать.
Вопрос только в том, известна ли конкретная реализация DGA (расковыряли ли то всё уже или ещё нет), чтобы проверить какой-либо трафик. Заблокировать же это всё, да ещё и на месяц/другой вперед - много сложнее (и дороже). Можно конечно просто прикинуться "аппаратом" и искать те домены каждый день и абузить сразу по созданию, однако пока найдем, пока залочим...
Нет! От слова совсем. Не вводите людей в заблуждение, пожалуйста.
Начнем с того что вы путаете Euch (личн., 2-е л., мн.ч., дат.п., типа "Вам, друзья") и Ihnen (личн., вежл., дат.п., типа "Вам, молодой человек"). Т. е. Euch вы можете использовать когда вы спрашиваете несколько человек, или если мы в десятом веке.
Конкретно фразы "Kann ich Ihnen helfen?", "Darf ich Ihnen helfen?" и даже "Soll ich Ihnen helfen?" являются практически синонимами (хоть и с оттенками "могу ли я", "смею ли я", "нужно ли" соответственно), но и в случае с инвалидом Soll тут не несёт никакого оскорбительного оттенка, пока это либо специально интонацией не выделить. Либо "магическим" словом каким, типа etwaили noch :
Soll ich Ihnen etwa helfen?! -> Мне что-ли вам еще и помогать нужно?!
Ну и коренной немец в случае вежливой просьбы помочь использует скорее что-нибудь типа:
Kann ich Ihnen behilflich sein? -> Могу ли я вам помочь (быть полезным)?
И да, вот тут уже можно использовать только Darf вместо Kann, а Soll просто по смыслу не подойдет (опять же без всякого оскорбительного оттенка), просто это будет означать:
Soll ich Ihnen behilflich sein? -> Должен ли я вам быть полезным. (что, согласитесь, звучит никак)
С остальным же тоже передергивание...
Т. к. ни "Brauchen Sie Hilfe?" ни остальные тоже не несут никакого оскорбления или издевки в случае вопроса к инвалиду или вообще к человеку нуждающемуся в помощи. Кроме разве что "Wie kann ich Ihnen helfen?", который просто не очень подходит, ибо как правило используется как вопрос, по телефону или в прихожей например, к незнакомому человеку ("Вам чем-нибудь помочь?" или "Чем я вам могу помочь?"), короче не совсем отсюда.
И да. Немецкий Sollen и английский Shall похожи по смыслу, но в очень определенных формах (например в том же повелительном наклонении, в Präteritum или как раз в архаичных конструкциях).
А тут на самом деле не просто всё. Как в общем случае отличить количественные, порядковые, собирательные, те же рода и единственное/множественное и т.п. Не говоря уж про всякие зависимости окончания от одушевлённости/неодушевлённости...
Ну и без контекстного фильтра, и/или семантических и морфологических моделей сложностей хватает, к примеру - "17 года" - это "семнадцатые года́" или "семнадцатого гóда"?
Я как-то игрался с такими преобразованиями (и чисто алгоритмически и на ML) в контексте предложения, где-то лежит для русского в том числе, если найду выложу и кину ссылку.
Нет, не приводятся - double он и в Африке double, и что там, что тут - 64 бит (размеры floating-point data types не зависит от разрядности и одинаковы и для x86 и для x64). При этом даже для x86, внутренние FPU регистры - 80 бит. Различие может быть лишь в оптимизации, да в используемых инструкциях (mulsd vs fmul).
Да.
Гипотеза не работает для большинства значений
nв районе906 150 257 ≤ n ≤ 906 488 079. В этой области суммирующая функция Лиувилля достигает максимального значения829приn = 906 316 571.(кстати 829 а не 849 как написано в статье).
Совершенно верно... Вообще очень странные тесты...
В конкретном случае -
var vs let vs const vs sloppyтам по большей части вообще измеряется spreading array mutations & push (+ память/кэш всех уровней, + GC, + тому подобное), но никак не заявленное в названии теста.Если переписать тест хотя бы без вызова push и spread-op (что справедливо ибо объявленная
gвсё равно immutable), всё очень сильно изменится (и соответственно возможноvarбудет быстрее только лишьsloppy, проигрывая иletиconst):"Возможно" - потому что оверхед собственно измерения и соответственно шумы и погрешности будут много выше той незначительной разницы (если она вообще есть в SpiderMonkey или V8 при компиляции в браузере).
<img src="боромир-мим.jpg"/>Нельзя просто взять и померить разницу в скоростиvar vs let vs constв JS в браузере, просто потому что там нет подходящего быстрого инструмента (цикла) для измерений, так чтобы при компиляцииvar, let или constрезультат не вырождался тупо в константное выражение, посчитанное на стадии компиляции цикла.Т.е. даже что-то подобное нижеследующему вряд ли покажет ту разницу реально (и те +13ms или +173ms ниже тупо не являются какими-либо флуктуациями опять же из-за огромного overhead сверху):
В 98-99 гг?
Я где-то в году так 2015-м эту утку снова встречал, причем с кучей комментов поверивших в это людей.
Особенно доставляет, что икра той жабы чёрная и мелкая (т.е. с красной икрой ну никак не возможно спутать) и в 2015-м это всё прекрасно гуглится.
Выглядит как-то так...
Ну во первых строго говоря это не совсем так, вернее совсем не так (и я даже не про множественное экспонирование)...
А во вторых изменением архитектуры (например другая компоновка типа тех же интелёвых Foveros, ODI, Co-EMIB и т.п. 2.5D или 3D stacking) можно на 90 нм литографе в теории сделать хоть 10 нм (ну типа в девять "слоёв" если).
Я не говорю сейчас что просто и без проблем, я лишь собственно про "нельзя изготовить".
Конечно же Sissi, кто-же еще...
В традиционном, восточном (китайском?) свадебном платье :)
Зачем дергать при каждом запуске и держать список из 12 тысяч с гаком команд (ака wordlist) для каждой сессии bash, тем более если оно нужно то бывает редко-редко.
Тогда уж лучше как-то так:
К звуку это отношения не имеет. И замена довольно распространенная в IT (да и не только там)...
Например
µs -> us(потому чтоmsуже занято за миллисекундами).Ну как близко... https://stackoverflow.com/a/2246793
Проблема с теми AI здесь всегда собственно обучающая выборка - на чем его натаскивают и насколько это "правильно" им разбирается, от "синтаксиса" и "морфологии" до абстракций каких-нибудь... А сарказм если, а пограничные условия какие-либо, и т.п.
Притом что врёт местами безбожно. Например в случае
sqliteпро скорость оно всё с точностью наоборот. Т.к.sqliteне умеет в оптимизациюNOT IN ()чтобы юзать кортёжный индекс(type,id), т. е. получим fullscan со всеми вытекающими.Более того не просто соврамши - а конкретно так, ибо big-O в случае
NOT IN ()сильно так нелинейно будет.Прув на Tcl (просто мерить сподручнее и быстрее)
Для случая
IN ()AI был бы прав:Тоже резануло по глазам...
Это при том что он прямо об обратном говорил (и неоднократно на моей памяти).
Да и как оно возможно вообще, когда такое изменение вызовет целую лавину (с потенциальными конфликтами везде и вся, и т.д.), ибо как писал упомянутый RMS:
"When we say that GPLv2 and GPLv3 are incompatible, it means there is no legal way to combine code under GPLv2 with code under GPLv3 in a single program. This is because both GPLv2 and GPLv3 are copyleft licenses: each of them says, “If you include code under this license in a larger program, the larger program must be under this license too.” There is no way to make them compatible."
Нужно наверно уточнить что здесь значит "in a single program" - link, merge or combine code of two different programs with GPLv2 and GPLv3.
Центр Гамбурга (Германия - согласно той статистики 33-е место), 4G/LTE с трудом выдает 3Mbps (и пинг за сотню), при том что в различных крыльях здания, расположенного буквой П, местами тот 4G падает до E а то и вообще до 0 (причем в разных местах у разных провайдеров по разному - в одном месте у одного 0 или E, в другом - у другого).
Отъехав от Гамбурга на какие то 5 км (да и в самом городе местами) вы можете вообще потерять связь. Совсем. Езжу 15км от дома до работы и местами (всегда одни и те же три/четыре точки) - тупо дыра, ни интернет-радио, ни ватсап, ни ТГ - ничего, пока тупо их не проедешь.
покрытие около г. Гамбург для разных сетей
И это не в одной Германии так. Поездив по миру, я много где наблюдал подобную картину (за несколькими исключениями, например в той же Голландии и Норвегии). При том что в РФ как раз очень редко случалось, что связи нет вовсе. И я не про "внутри МКАДа" сейчас... Даже, как-то лет 10 назад, проехав 2 тысячи км, Санкт-Петербург - Вологда - Киров - Пермь - Екатеринбург, связь по ощущениям была почти везде.
В той же Германии 10 лет назад было совсем печально всё.
Да-да... и травка зеленее, и солнышко желтее.
В массе своей 50-100 а то и 10Мбит/с для стационарного-то интернета (DSL) - уже считается хорошо. Стекловолокно тянут конечно тут и там, но как-то всё не разгонятся.
По воздуху же гигабит - вообще что-то из области фантастики. И даже если он номинально имеется (по договору 5G присутствует), то по факту выше 4G+ (а реально где-то в районе 250Мбит/с) я скоростей не видел, и не слышал ни от кого пока.
Как мне кажется проблема в той статистике, что если "сложить" человека (сидящего рядом с 5G антенной) с условными 450Мбит/с и 9 человек с 10Мбит/с, то в среднем получим тот полтинник (согласно статистике 53.65Mbps). Только его по факту как не было так и нет.
Ну и парадокс выжившего сверху (из мест с 0Мбит статистика тупо не идет).
Нужно просто добавить итераций (параметер
number)... Все эти варианты очень быстры и при 1000 итераций (время исполнения микросекунды) погрешность измерения очень высока - оверхед близок к собственно исполнению, плюс некоторая гранулярность из-за разрешения таймера (для винды как правило 15.6 ms) и т.д.Для замеров скорости мелкого и быстрого кода, нужно использовать
number=1000000и выше.Не нужно измерять
print, читайте внимательнее, в статье написано как оно измерялось...Liebe Kolleginnen und Kollegen, ich begrüße Euch recht herzlich zu...
ЧЯДНТБывают исключения, когда нужно и можно, что бы, значит, уважение показать.Про Kann-Darf-Soll? Не зависит это от "местных разговорных обычаев" никак. Что в Гамбурге, что в Мюнхене, что в городе, что в деревне всё одно будет (разве только местами с жутким выговором).
А чего там уметь то?
Мешаем 10K раз текущие год-неделя и/или год-месяц, ну и только год с каким-нибудь секретом и "семечками", всё это в строчку по основанию 36 и получаем кучу доменов вида
rmncxhceao.tld. Аппараты будут пробовать стучаться по всем 10K доменам, а ботоводу нужно создать из тех вариантов только 1 для года, 1 для года-месяца, чтобы отдать "команду".Ну или ещё один для года-неделя, если сильно срочно надо или там увезти или "поднагрузить" чуть-чуть уже проданную бот-сеть нужно.
Есть и много хитрее алгоритмы, но мы тут не будем
скрипт-киддис обучать.Вопрос только в том, известна ли конкретная реализация DGA (расковыряли ли то всё уже или ещё нет), чтобы проверить какой-либо трафик. Заблокировать же это всё, да ещё и на месяц/другой вперед - много сложнее (и дороже). Можно конечно просто прикинуться "аппаратом" и искать те домены каждый день и абузить сразу по созданию, однако пока найдем, пока залочим...
Нет! От слова совсем. Не вводите людей в заблуждение, пожалуйста.
Начнем с того что вы путаете
Euch(личн., 2-е л., мн.ч., дат.п., типа "Вам, друзья") иIhnen(личн., вежл., дат.п., типа "Вам, молодой человек").Т. е.
Euchвы можете использовать когда вы спрашиваете несколько человек, или если мы в десятом веке.Конкретно фразы "Kann ich Ihnen helfen?", "Darf ich Ihnen helfen?" и даже "Soll ich Ihnen helfen?" являются практически синонимами (хоть и с оттенками "могу ли я", "смею ли я", "нужно ли" соответственно), но и в случае с инвалидом
Sollтут не несёт никакого оскорбительного оттенка, пока это либо специально интонацией не выделить. Либо "магическим" словом каким, типаetwaилиnoch:Soll ich Ihnen etwa helfen?! -> Мне что-ли вам еще и помогать нужно?!
Ну и коренной немец в случае вежливой просьбы помочь использует скорее что-нибудь типа:
Kann ich Ihnen behilflich sein? -> Могу ли я вам помочь (быть полезным)?
И да, вот тут уже можно использовать только
DarfвместоKann, аSollпросто по смыслу не подойдет (опять же без всякого оскорбительного оттенка), просто это будет означать:Soll ich Ihnen behilflich sein? -> Должен ли я вам быть полезным.
(что, согласитесь, звучит никак)
С остальным же тоже передергивание...
Т. к. ни "Brauchen Sie Hilfe?" ни остальные тоже не несут никакого оскорбления или издевки в случае вопроса к инвалиду или вообще к человеку нуждающемуся в помощи.
Кроме разве что "Wie kann ich Ihnen helfen?", который просто не очень подходит, ибо как правило используется как вопрос, по телефону или в прихожей например, к незнакомому человеку ("Вам чем-нибудь помочь?" или "Чем я вам могу помочь?"), короче не совсем отсюда.
И да. Немецкий
Sollenи английскийShallпохожи по смыслу, но в очень определенных формах (например в том же повелительном наклонении, в Präteritum или как раз в архаичных конструкциях).Попробовал на 3.11 (в сравненини с 3.10) код из "Sexy primes, «медленный питон» ...". Как чистая "числодробилка" оно всё ещё не очень комильфо...
где-то даже чуть медленнее ...
где-то действительно чуть быстрее ...
Тесты делал на i7-4790 @ 3.60GHz, обе версии собирались локально с оптимизацией (
configure --enable-optimizations,-mtune=native,-O3и т.д.).Хотя судя по всему что-то в этом PEP 659 "кэшировании" (ака specializing adaptive interpreter) всё-таки есть, надо будет потискать в бою.
А тут на самом деле не просто всё. Как в общем случае отличить количественные, порядковые, собирательные, те же рода и единственное/множественное и т.п.
Не говоря уж про всякие зависимости окончания от одушевлённости/неодушевлённости...
Ну и без контекстного фильтра, и/или семантических и морфологических моделей сложностей хватает, к примеру - "
17 года" - это "семнадцатые года́" или "семнадцатого гóда"?Я как-то игрался с такими преобразованиями (и чисто алгоритмически и на ML) в контексте предложения, где-то лежит для русского в том числе, если найду выложу и кину ссылку.