mayton2019

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

Без этих данных - очень сложно строить гипотезы.

Дробные числа можно рассматривать как те-же самые целые только с множителем 10 в степени -1
и потом -2 и так далее. Результаты - объединить.

Все языки программирования (может быть кроме SQL) имеют поддержку булевой алгебры и битовых операций.

В языке С++ например твоя формула будет такая.

int C = A && B || !A;

Здесь я пользуюсь аналогией между int/boolean. Предполагается что 0 == false и любое не нулевое число
будет true.

Есть еще битовые операции когда каждый бит числа рассматривается как независимый
аргумент для булевых операций. С помощью битов обычно на целые числа можно накладывать
маску или включать и выключать биты и реализоывать криптографию.

Например

int C = A ^ B;

Здесь С равно сложению по модулю 2 для всех битов из А и Б.

Тоесть грубо говоря в языке С++ не тип а операция определяет семантику результата.
Везде - целые числа но если я работаю с ними логическими операциями то получаю
логический результат а если побитовыми - то он и трактуется как побитовый.

Аналогичный похожий набор операций есть и в JavaScrip и в Python.

Тоже самое можно спросить про синус или логарифм. Все они вычисляются через числовые ряды.
Делая итерации.

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

Вот тебе и будет почти точный метод.

Похоже на диофантово уравнение. Не по математическому виду а скорее по подходу.
Можно попробовать генетические алгоритмы. Хромосома (a,b,c).

Я плохо знаю вышку. Но я-бы смотрел на эту задачу с точки зрения инструментов инженерной графики.
А инструменты там такие. Полигоны. Вокселы. И particles (частицы).

Для вокселов проще всего наверное. У тебя есть напреженность поля как функция F(x,y,z). Вот и рисуй
воксел когда напряженность выше уровня и не рисуй иначе. Будет такая картинка вроде Minecraft.

Для двумерного случая - тоже самое. Рисуй квадратик.

Автор вот ты написал СДНФ или СКНФ. Это означает что ты уже читаешь булеву алгебру. И ты уже прошел
основы булевой алгебры. Я не помню где это написано. Честно не помню. Но разве тебя не удивляет что в
математике целое число можно представить в виде суммы других чисел. Или гладкая функция - представима
в виде суперпозиции других гладких функций.

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

Максимум?

Ну в твоем уравнении x = π .

Чисто π является трансцедентным числом. Также как и число e. Их алгоритм расчета - бесконечные ряды
поэтому под определение это вполне себе подходит.

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

Все зависит от твоих собственных амбиций. Современные фреймворки машинного обучения не требуют
от тебя знания тройных интегралов и систем дифуров. В простейшем случай ты - читаешь документацию.
Настрашиваешь параметры (гипер-параметры) и наблюдаешь как идет процесс обучения). Где и в какой
части этот фреймворк требует интегралов - непонятно. Вроде нигда. С амбициями дата-инженера
тебе будет просто достаточно знать внешний API этих фреймворков.

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

Ну для floating point чисел ничего интересного не происходит. Результат будет - бесконечность (Inf).
И эта бесконечность - это вполне себе реальная константа для таких чисел.

Ответ - это решение уравнения

x + 0.05x = 950

Дружище Корень. Вижу прошло пару месяцев а ты все тот-же Ферматист :)

Я не знаком с пакетом Вольфрам. Но его делал очень умный человек. И я думаю что символьные
вычисления там тоже поддерживаются.

Но такие вычисления обычно подходят под расчеты с дробями. Например 1/2 + 1/3 = 1
в символьных вычислениях поддерживаются. Это позволяет точнее посчитать
пределы например.

То что ты посчитал - это трансцедентное число.

z = exp((1/3)*log(664572³ + 257118³))

Из-за логарифма внутри.
Везде где есть синусы, логарифмы (ряды Тейлора) мы можем говорить об этом
свойстве чисел. Грубо говоря это число которое мы не можем в общем случае
получить путем конечного числа операций над рациональными числами.

И обычно в физике и в инженерном деле логарифмы и экспоненты считают приближенно.
Используя float, double и extended (80bit). И этого хватает чтоб запускать ракеты на Марс.

Их никто не считает точно, просто по той причине что их нельзя представить точно.
У нас не хватит памяти всех датацентров чтоб точно такое считать.

Иногда в очень-очень редких случаях математический пакет может упростить формулу
аналитически (exp(log(x)) и получить более простые цифры без свойства трансцедентности.
Почитай документацию по MathCad, MatLab, может там такое тоже есть.

Я также упрекаю тебя в невнимательности. Я тебе в прошлый раз делал акцент на типах
данных. И ты это благополучно проигнорировал. И снова ты полез в теорию чисел и Ферма
даже не понимая с каким типом данных работает Вольфрам. Разберись сначала с этим вопросом.
Иначе будешь всегда выглядеть почемучкой.

Я сразу попробую ответить на главный вопрос.

написать хэш-таблицу без коллизий

Написать такую таблицу можно если мы заранее знаем весь набор данных (в случае автора это
множество ключей (K). Здесь для простоты предполагаем что ключи - это целые числа int32 (DWORD).

Алгоритм примерно такой:
1) Берем размер хеш-таблицы в n = size(K). Метод открытой адресации.
2) Берем любую хеш-функцию (по области определения больше чем n
SHA1, MD5, xxhash, mur-mur-hash)
3) Начинаем наполнять таблицу.
4) Как только детектирована коллизия - удаляем старую таблицу и создаем новую
с размером например 120% от исходного n.
5) Повторяем алгортм до тех пор пока не будут расставлены все ключи.

Profit.

Если мы не знаем наши данные изначально (у нас их нет и мы не знаем количество и тип данных)
то мы не можем гарантировать отсустствие коллизий хотя-бы потому что у нас
нету такой хеш функции которая бы гарантировала отсутствие коллизий на вариативном
типе данных.

Изучать хеширование на базе целых чисел - вобщем-то не интересно. Более общий случай - это
строки (String) и я-бы делал эксперименты со строками и с реальными данными (мобильные
телефоны емейлы налоговые номера и прочее). Целые числа - это .... слишком синтетические
тесты и их результаты потом никуда натянуть нельзя.

UPD: Алгоритм в таком виде не работает. По крайней мере от коллизий мы не избавились.
Не голосуйте здесь пока.

Что надо делать.?
Не понимаю, с чего начать.

Вообще если у тебя так много непоняток - то начни не с изображений а с 1-мерного графика.
Курс валют например. Или ход температуры за сезон. Разберешся - дальше пойдешь.
А если ты сейчас даже какую-то фигню закодишь
- то как ты проверишь что правильное преобразование сделал?

Начни с контракта. Что приходит тебе на вход? Вот это вот
double[] x, double[]y

С моей точки зрения - тут должна быть картинка. Image. На следующем уровне ты ее разбиваешь
на цветовые слои. Красный зеленый ит.д. Потом эти слои разбиваешь на фреймы (8х8 пикс как в jpg).
Потом их нормируешь от цвета пиксела до вещественного значения. И вот уже когда ты получишь
матрицу вещественных значений - тогда и можно приступать к Фурье. Усек? У тебя хедер
функции должен иметь такие параметры чтобы тебе было все кристально ясно что за аргументы и как.

А так конешно у тебя каша в голове.

Да. И по контракту Фурье преобразования ты получаешь комплесную
вещественную матрицу на выходе. Тоесть две матрицы. Размер их не обязательно должен быть 8х8.
Он может быть любым. Но обычно нижние коэффициенты матрицы (левый верхний угол - самые
ценные для Фурье формулы).

И дальше - делаешь все в обратном направлении. От Фурье к картинке. Получиться картинка - молодец.
Значит правильно сделал.

Парадокс Зенона?

Скалярное произведение СП - это математическая абстракция. Математика - вообще не обязана иметь какой-то материальный смысл. Если заходить в теорию чисел - то там точно нет физики. Там - игры разума.

Но вот СП на некотором софистическом языке. Почленно перемножаем все компоненты вектора и складываем.

def scalar_prod(a:List[Double],b:List[Double]) : Double = a.zip(b).map(_*_).sum

В резулльтате получаем тип - СКАЛЯР. Число. Именно поэтому операция так и называется.
Для векторного произведения формула и суть будут другие.

Если вектор а например - это различные валюты в твоем кошельке а вектор б - это курсы валют по отношению
к какой-то единой условной единице - то твой кошелек стоит СКАЛЯРНОЕ произведение валют на их курсы.

Если в Excel вы считаете стоимость сметы - то СП цен на количества даст нужную величину. Да много чего можно придумать. В теор-вере там.. Тоже можно придумать.

Есть геометрическая формула через модули и косинус угла. Но я ее смысл щас честно не помню.

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

Если функция более хитрая (не гладкая) то к ней надо с хитростью подходить.