Спасибо.

Killua, nickname никуда не годится

?

Я без этих штуковин прекрасно все парсил, не нужно. Если вместо тяжелого дом парсера юзать регекспы - то плюсик к опыту регекспов и скорость вырастет в разы, и память соответственно

https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags

(coffeescript) desc = res.match ///<p\sclass="place_desc">(.*?)</p>/// if desc desc = desc[0] ... вроде такого

Пришло время вспомнить kotlin. И D. Это типа легкая альтернатива С++, и сишный код с ним полностью совместим. Кстати, смишнявый. https://ru.m.wikipedia.org/wiki/D_(язык_программирования)

>вспомнить kotlin Звучит интересно

Учитывая возраст языка

Пришло время вспомнить kotlin. И D. Это типа легкая альтернатива С++, и сишный код с ним полностью совместим. Кстати, смишнявый. https://ru.m.wikipedia.org/wiki/D_(язык_программирования)

А так же кристал и ним ) В ниме уже готов биндинг к луаджиту

А так же кристал и ним ) В ниме уже готов биндинг к луаджиту

https://github.com/veelenga/lua.cr

https://github.com/veelenga/lua.cr

Отлично, гуд. Правда непонятно как с джитом быть

надо бы заняться макромагией, чтобы автоматически выставлять кристаловые методы в интерпретатор луа. и еще ассемблерной магией, чтобы можно было вызывать из луа методы со splat'ами

Там вроде с макросами проблем небыло, значит можно сделать красиво и не слишком сложно

Хм. Логики тут немного. Особенно когда math.huge/math.huge получается nan а не 1.

а какой кейс этого момента?

Мне - прост побаловаться. Официально - хз.

ну тогда гуд )))

Ну, официально, это "число, которое больше любого выразимого в языке числа. Не применяйте его нигде кроме выражений сравнения".

Там вроде с макросами проблем небыло, значит можно сделать красиво и не слишком сложно

Вот бы ещё это было модулярно, типа общий интерфейс + плагины для поддержки языков

Это можно например использовать для вычисления расстояний и нахождения ближайшего. То бишь стартовать с math.huge и далее уже уменьшать расстояние

Хм. Логики тут немного. Особенно когда math.huge/math.huge получается nan а не 1.

1) math.huge/math.huge таки равно nan.

2) PUC-Rio Lua всех версий даже говорит что -nan, а не просто nan

Ну, если две бесконечности равной мощности поделить одну на другую - результат должен быть равен единице, так же как с равными числами : )

проблема в том, что бесконечность это не число

поэтому на него не совсем распространяются правила вычисления чисел

Помнится, это можно интерпертировать как некоторую "функцию", которая стремится к бесконечности с определённой скоростью.

это логическая абстракция. И официально результат деления бесконечности на бесконечность не определён

Но если делить результаты двух функций равной мощности - результат любого деления будет равен единице.

Если погуглить, то вовсе не единица, природа бесконечности она такая, необычная

по сему в lua название huge, то есть число, которое ведет себя более похоже на число, не бесконечность, все правильно сделали

Хех, ну ладно, будем так считать : )

а что алгебра говорит об этом?

говорит что неопределенность в общем виде

что я и сказал выше

ну да

А если одинаковые - то везде где эти бесконечности не равны нулю - должна быть единичка )))

в общем "не ходите дети в Африку" )))

А если одинаковые - то везде где эти бесконечности не равны нулю - должна быть единичка )))

если тебе это так надо - задефайнь свою функцию-компаратор

Лады, лады )) Это - баловство, никто не собирается использовать бесконечности в вычислениях, только как сравнение.

алсо, ты ещё скажи, что бесконечность минус бесконечность должно быть 0 :)

Ну типа если мощности равны : ) Если не равны - какая-то перевешивает в ту или другую бесконечность )) Поэтому в "общем случае" - неопределённость, а в конкретном (когда известны мощности) - можно сказать точнее.

Ну, типа бесконечность вида условно f(y) x ^ 2 менее мощная чем f(y) x ^ 3 Если из первой вычесть вторую, явно получится минус бесконечность. Мощности (x^2 - x^3). Ну тип арифметика, все дела.

и как тебе lua определит мощности? :)

s/lua/whatever programming language/

даже хаскель всё тоже самое скажет, емнип

> print(math.huge == math.huge) true Они одинаковые тип ))

потому что это одинаковые функции

а не результат у них одинаковый

> return (print == print) [1] true

А вот это вообще забавно. > print(math.huge == math.huge) true > print(math.huge > math.huge) false > print(math.huge > math.huge + 1) false > print(math.huge < math.huge + 1) false > print(math.huge == math.huge + 1) true >

особенно последнее норм

хотя предпоследнее тоже

но сути это не меняет

Да, math.huge - это НЕ функция, это типа специальный тип.

О, вот весёлая задачка. Сделать .txt файл со 100,000,000 строк с числами в диапазоне от 0 до 99,999,999: - формат чисел - 8 разрядов (1 = 00000001, 65535 = 00065535) - диапазон от 0 до 99,999,999 - все числа в рандомном порядке: 00306453 99645283 70000021 06847127 - без повторов (каждая строка - уникальное число) Мы пишем под микроконтроллер с 640кб оперативки. Их должно быть достаточно для каждого.

А что сделать то надо?

А что сделать то надо?

> Сделать .txt файл со 100,000,000 строк с числами в диапазоне от 0 до 99,999,999:

А в чем проблема?

Какие библиотеки?

Какой язык?

С++?

Lua?

А в чем проблема?

А в чём решение? : ) Язык - произвольный. Тут важно абстрактное "описание алгоритма решения". Ну, видимо 100 000 000 чисел для тебя мало, давай ты сделаешь на 100 000 000 000 000 чисел.

Ну через строку

Угу. Рандомные и уникальные числа? Через строку? А как именно?

Ну потом контейнер в randomised queue положу и всё

Хе, а влезет? У тебя 640кб памяти.

Да пох

Главное чтобы генерация была последовательная

Ну не влезет, чувак ))) Застопоришься на N числах, которые меньше M (100 000 000).

Застопорюсь - очищу

Буду класть новые

Угу. То есть, ты будешь перемешивать крошечными блоками? У тебя получится примерно так: 3 1 2 5 4 6 8 9 7 Ну, это типа рандомно, но чот ниоч ))

Согласен

А какая сложность алгоритма О(N)?

Не указано - значит пох )) У меня есть вариант решения с O(N), не требующий дополнительной памяти на ЖД.

Достаточно взять некоторую перестановку, которую легко генерировать. Что-то вроде того же random(), только для [0..10^8-1].

Ага. Какие варианты?

На ум приходит FPE, но пока не соображу, как применить.

FPE чисто теоретически должно работать за O(1) на число и потребрять столько же памяти.