Найти уравнение по множеству решений?

jcmvbkbc, не, ну, так-то можно и цепочку из 1000 if-else сделать попиксельно.

if (x==0) y=7;
else if (x==1) y=10.5;
else... и т.д.
else if (x==1280) y=13;

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

Но чем это будет отличаться от самого графика?

К томе же вы сводите проблему к построению многочлена. В случае, например, y=sin(x) у нас будет что? Бесконечный многочлен? Тем не менее, школьник легко определит эту функцию, взглянув на неё. Даже параметры (константы) может распознать типа y=a*sin(x+b)+c

Найти уравнение по множеству решений?

Rsa97, похоже ваш мозг нейронная сеть хорошо обучена.

Как сделать регулярку - 1 или больше символов потом пробел, а потом опять 1 или больше символов?

olya_097, речь была про случайные пробелы. Это опечатки пользователя. Но их можно исправить автоматически. Но это уже не просто проверка, а ещё и преобразования. Что касается чисто проверки, то если она умная, то должна учитывать будущие преобразования и пропускать строки с избытком пробелов. Вот и всё. Конечно, это делать не обязательно. Просто неловкому пользователю было бы удобнее.

Как сделать регулярку - 1 или больше символов потом пробел, а потом опять 1 или больше символов?

olya_097, в смысле?
\s{1,} то же, что и \s+
\s{0,} то же, что и \s*
\s{1} то же, что и \s
Так что зачем фигурные скобки, если можно короче?
Почитайте про квантификаторы, если интересно подробнее.

Ограничения на пробелы в шаблоне приведут к тому, что валдиная, казалось бы, строка не будет проходить валидацию.

Как сделать регулярку - 1 или больше символов потом пробел, а потом опять 1 или больше символов?

olya_097, Это два пробела вместо одного, а также пробелы перед строкой и после строки. Их могут поставить случайно, и они не видны, поэтому их редко исправляют. Умная система должна их учитывать и не выводить ошибку, чтобы Вася долго не втыкал, что же не так в строке

"вася пупкин "
// не пройдёт валидацию по /[а-я]+ [а-я]+/ из-за пробела в конце

Как сделать регулярку - 1 или больше символов потом пробел, а потом опять 1 или больше символов?

Для каких целей? Где используется? Многострочный текст? Нужны все вхождения или одно?

Почему окно не реагирует на действия?

Укажите версию ОС.

Проблема с видеокартой или с процессором?

загрузка затыкается на процессоре

Как вы это поняли?

менял недавно

И с тех пор комп успел нормально поработать или сразу не работал?

Ошибка Cannot set property 'onclick' of null?

Hello00, чтобы ответить на вопрос, нужно заняться отладкой вашего скрипта. Мало того, что это выходит за рамки вопроса и не приветствуется на Q&A сайте, так вы ещё и код картинками вставляете (правила п.3.8).

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

Ошибка Cannot set property 'onclick' of null?

Не правда.
querySelector возвращает единственный элемент.

Как считать вероятность атаки (ранений) в настольной игре Спартак?

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

[2, 2, 2, 1, 1], [1, 1, 1]

Неожиданно.

4: 0.0076

Ещё более неожиданно.
[6, 5, 4, 4, 4] [6, 5, 4]

Как считать вероятность атаки (ранений) в настольной игре Спартак?

longclaps, не знаю, что-то у вас не сходится. Видимо, вы не в том порядке сортируете.

Например, когда вы доходите до
[1, 1, 1, 1, 2]
[1, 1, 1]
то внезапно оказывается, что двойка в конце. В первых трех позициях a > d не срабатывает, и (attack[4] > 2) тоже не срабатывает, конечно же.
Нужно сортировать массивы в другом порядке:
[2, 1, 1, 1, 1]
[1, 1, 1]
Тогда выяснится, что 2 > 1

Как считать вероятность атаки (ранений) в настольной игре Спартак?

longclaps, вы не прочитали это:

Каждый лишний кубик тоже даёт одно ранение, если там значение больше 2.

Плюс там пример есть.

Как считать вероятность атаки (ранений) в настольной игре Спартак?

Если у обороняющегося 6-6-5

Смотря что у атакующего. Если у него 6-6-5-4-4, то не выгодно перебрасывать 4-ку, потому что она уже даёт 1 ранение. Если перебросить, то шанс 1/6, что будет ещё +1 ранение, но шанс 2/3, что будет -1 ранение.

В общем случае 4-6 нет смысла перебрасывать, потому что шанс не менее 50%, что выпадет меньше.

1-2 стоит перебрасывать всегда.

А вот 3-ка проблемная.

Какая есть _очень-очень_ простая программа для учета рабочего времени для Windows 7?

Роман, Разве? Вроде не обязательно. Конечно, можно, но по идее там должна быть возможность тупо старт-стоп. Может и ошибаюсь, давно дело было.

Что будет быстрее работать?

nrgian,

дело в том, что если хэш влазит в регистр, то он полностью эквивалентен индексу.

И что вас смущает? В этом суть хеширования. Мы любые данные (например, ключ), которые "не влазят" в регистр, превращаем в хеш, который уже влазит, чтобы дальше операции сравнения сводились к сравнению хешей, а не исходных данных побайтово. (Конечно, я имею в виду кейс, когда хеширование используется для ускорения поиска, а не для других целей).

Что будет быстрее работать?

nrgian, И хеш мы не считаем, а считываем, то есть учитываем обращение к памяти. Хотя тут вы правы, нужно же ещё посчитать хеш. Я имел в виду, что считываем мы ключ.

Ладно, у нас есть ключ, мы к нему обратились, то есть закешировали, доступ к нему относительно быстрый. Поэтому, далеко не бегая, вычисляем всё на месте - пробегаемся по ключу и считаем хеш. Не забываем, что у нас есть команды процессора (например, старый набор SSE4), и где-то по цене за 0.2 такта на байт мы пробегаемся по небольшому ключу-строке. И нам даже не обязательно все байты проверять, можно ограничиться первыми 50ю байтами к примеру. Вы же помните, что хеш не обязан быть уникальным. В общем, можем добавить еще одно "чтение" к общим затратам. Итого соотношение времени 3 к 5.

Многовато?
А что там с коллизиями на такой длине?

С коллизиями там всё очень хорошо. Шанс коллизии 1/2^64. Именно поэтому, если у нас около 100 ключей для поиска, то имеет смысл размер хеш-таблицы сделать 128 или 256, а индекс у нас - первые (или последние) 8 бит хеша, которые дадут шанс коллизии 1/256, но с учетом размера массива это норм.

Что будет быстрее работать?

nrgian, пусть хеш будет 64 бита, чтобы в регистр поместиться без проблем, хотя это многовато.

Что будет быстрее работать?

nrgian, это вы интересно считаете. А ничего, что ваше "сложение и умножение" может выполняться за пол такта, а чтение - за 150 тактов? С учётом всех L-кешей, конечно. И вообще, все три операции умещаются в одну команду процессора. Точнее, что с чем складываем и умножаем раскидывается по другим регистрам сначала, а вот откуда мы берем смещения - это внезапно ещё больше чтения. То есть нужно прочитать дополнительно: а) переменную с индексом (смещение) б) переменную с указателем на массив (базу). Итого - три чтения, которыми я и предлагаю ограничиться для примерной оценки действия на x86 процессорах, но уже более близкой к правде.

А что хеш-таблица? Также а) считываем сам хеш б) считываем адрес массива. Небольшое вычисление - берем первые N бит хеша и превращаем в число, я даже это считать не буду за операцию. Дальше по сути операция чтения по индексу, т.к. у нас есть смещение. Правда, попадаем мы не на само значение, а на массив коллизий, где нам нужно простым перебором найти нужный элемент. Но массив этот, как правило, состоит из 1-2 элементов. И даже если чуть больше, то он уже у нас весь закеширован в L-кешах, что делает доступ на порядок быстрее. Так что в общем случае это по сути та же операция чтения. Хорошо, если вам угодно, то будем считать это две операции чтения, предположив, что там ещё 10 чтений из кеша.

Итого 3 чтения против 4 чтений. Большая разница?

Это я ещё не учитываю, что в качестве искомых "значений" снова оказываются указатели (на объекты DOM). И другие накладные расходы, которые одинаковы для обоих случаев, на фоне которых способ доступа уже почти не играет роли.

Даже если скорость по хешу в 2-3 раза дольше, по условиям вопроса у нас 4 взятия по индексу. Кстати, плюс ещё 4 поиска по тому же хешу, ведь children - свойство объекта, не забываем про него. Так что если бы querySelector искал класс по хешу из единой хеш-таблицы документа, это наверняка было бы быстрее.

Что будет быстрее работать?

nrgian, и что сложного "раскрутить" хеш? Это практически обращение по индексу.