Когда-то всё то же самое писали про Java - универсальный кроссплатформенный байт-код в своей песочнице. И Net опять же. И вот новая серебряная пуля. А ведь ARM'ы в своё время даже нативно java байт-код поддерживали.
А web4.0 это получается, когда не только данные, но и ПО сервера будет на стороне пользователя работать? И представляете, его можно будет преобразовать в нативный код, и запускать вообще без браузера! Вот это будет прорыв, я считаю, революционная идея!
-- Вот тестовое задание, это же не сложно, вполне делается за неделю, мы хотим посмотреть, соответствуют ли ваши навыки нашим ожиданиям
-- А вот номер моей банковской карты, вас же не затруднит перевести на нее тестовую зарплату, это не сложно, всего за неделю. Я хочу посмотреть, соответствует ли ваш уровень зарплаты моим ожиданиям.
Тю, я думал с нормальной теорией будет, про регулярные грамматики расскажут, конечные автоматы. А тут просто идут по строке и символы сравнивают. Есть же хорошо развитая теория, и довольно простая. И поняв ее принцип - написать нужный токенизатор на любом языке - простая задача.
У райфа сейчас же вроде дикая комиссия на входящие usd? 50%, но не меньше $1000 и не больше суммы перевода. В евро нормально, 500₽ с перевода, помимо комиссии Свифта.
А что не так? Вполне себе работал с sqlite базами одновременно из нескольких процессов. Ограничение одно - пишущий лочит всю базу, остальным приходится ждать в очереди. При небольшом количестве записей это не критично. А если все процессы локальные, то при wal ещё и читатели не мешают писать, в rollback режиме журнала сложнее - писателю приходится ждать, пока старые читатели почитают, новым читателям ждать, пока писатель допишет.
Сейчас все наоборот стараются побольше инлайнить, а у вас наоборот. Возможно для каких-нибудь микроконтроллеров, где память ценный ресурс, имеет смысл. А так - ваш mov cx, 1 который вы вынесли в call, в большинстве случаев был бы бесплатным, проц бы его спараллелил с другими инструкциями. А в таком виде увы.
Дико извиняюсь, но для данной задачи не надо ни хеш-таблиц, ни бинарного поиска.
Так как массивы упорядочены, достаточно проходить одновременно по двум массивам, сравнивая их элементы, продвигаясь в том массиве, в котором текущий элемент меньше, чем в другом массиве (если упорядочение по возрастанию). Если равны - печатаем дубль и продвигаемся в обоих массивах. Время O(max(M, N)), память О(1).
Когда-то всё то же самое писали про Java - универсальный кроссплатформенный байт-код в своей песочнице. И Net опять же. И вот новая серебряная пуля. А ведь ARM'ы в своё время даже нативно java байт-код поддерживали.
Потому что дотягивается.
Ограничат до трёх мегатьюрингов?
Насчёт mrt в GLES 2.0 вы таки ошибаетесь, это только с GLES 3.0.
Да и на мобильных картах отложенный рендеринг - сильный удар по производительности, из-за тайловой архитектуры.
А web4.0 это получается, когда не только данные, но и ПО сервера будет на стороне пользователя работать? И представляете, его можно будет преобразовать в нативный код, и запускать вообще без браузера! Вот это будет прорыв, я считаю, революционная идея!
-- Вот тестовое задание, это же не сложно, вполне делается за неделю, мы хотим посмотреть, соответствуют ли ваши навыки нашим ожиданиям
-- А вот номер моей банковской карты, вас же не затруднит перевести на нее тестовую зарплату, это не сложно, всего за неделю. Я хочу посмотреть, соответствует ли ваш уровень зарплаты моим ожиданиям.
Тю, я думал с нормальной теорией будет, про регулярные грамматики расскажут, конечные автоматы. А тут просто идут по строке и символы сравнивают. Есть же хорошо развитая теория, и довольно простая. И поняв ее принцип - написать нужный токенизатор на любом языке - простая задача.
После мускусной ночи все ИИ мощнее трёх мегатьюрингов будут уничтожены.
Я конечно дилетант в скалолазании, но почему бы не подняться на гору на вертолете?
У райфа сейчас же вроде дикая комиссия на входящие usd? 50%, но не меньше $1000 и не больше суммы перевода. В евро нормально, 500₽ с перевода, помимо комиссии Свифта.
Да как обычно, путают code point и code unit. Code unit в utf16 всегда два байта, а code point кодируется одним или двумя code unit'ами.
Эх, помню на Yamaha MSX в Бейсике команда DRAW была, примерно с таким же синтаксисом. Конец 80ых прошлого века.
А что не так? Вполне себе работал с sqlite базами одновременно из нескольких процессов. Ограничение одно - пишущий лочит всю базу, остальным приходится ждать в очереди. При небольшом количестве записей это не критично. А если все процессы локальные, то при wal ещё и читатели не мешают писать, в rollback режиме журнала сложнее - писателю приходится ждать, пока старые читатели почитают, новым читателям ждать, пока писатель допишет.
Собственно партиционирование и шардирование примерно по этому принципу "унутре" и работают. Только без "закатывания солнца вручную".
Сейчас все наоборот стараются побольше инлайнить, а у вас наоборот. Возможно для каких-нибудь микроконтроллеров, где память ценный ресурс, имеет смысл. А так - ваш mov cx, 1 который вы вынесли в call, в большинстве случаев был бы бесплатным, проц бы его спараллелил с другими инструкциями. А в таком виде увы.
Краткость сообщений там привела к такому уродливому явлению, как текст картинкой.
Триста тридцать пять....
Уважаемый автор, если не ошибаюсь, ещё с начала нулевых убийцу 1С пишет, ещё с 7.7 :)
Тогда примерно раз в неделю очередной убийца на мисте начинался.
"Многие ждали меня в лесу, возле выкопанной ямы, видишь как всем им теперь к лицу, пиджачок деревянный".
Дико извиняюсь, но для данной задачи не надо ни хеш-таблиц, ни бинарного поиска.
Так как массивы упорядочены, достаточно проходить одновременно по двум массивам, сравнивая их элементы, продвигаясь в том массиве, в котором текущий элемент меньше, чем в другом массиве (если упорядочение по возрастанию). Если равны - печатаем дубль и продвигаемся в обоих массивах. Время O(max(M, N)), память О(1).