Задачка
А зачем мне думать о том, что мне совершенно не нужно?
Это уже вам решать. Но вы делаете это постоянно, поэтому, если разик сделаете для меня, вам это не составит большого труда. ))
Это уже вам решать. Но вы делаете это постоянно, поэтому, если разик сделаете для меня, вам это не составит большого труда.
Вообще-то это моя поляна! Здесь я ставлю задачки! (поменяй название темы!). Все должны думать для меня!
Что это получается, сейчас разик подумают для тебя, второй... тебе понравится, переобуешься в менеджеры?
А потом вовсе начнёшь пользоваться ИИ, пойдёшь в Криптоиндустрию, придётся с тобой миллиардами делится?
Виталику такой расклад не нравится, сиди в сишарпной студии: стыдная машина, стыдная яхта, стыдный самолёт!

А потом вовсе начнёшь пользоваться ИИ, пойдёшь в Криптоиндустрию, придётся с тобой миллиардами делится?
"Если я туда войду, ты оттуда выйдешь".
если разик сделаете для меня
для этой задачи нужен или интерес или время убить.
Пока могу выставить ответ ИИ.
Можно хранить направление отдельно, например, через флаг direction = ±1
, который определяет, идём ли мы от A
к B
или наоборот. Тогда формула становится универсальной:
[ \frac{P - A}{(B - A) \times direction} ]
Это избавляет от необходимости менять знаки координат и даёт более гибкую систему.
но если есть функция F(p1,p2) , то для обратного подсчёта нужно просто вызвать F(p2,p1)
Блин, да всё проще. На отрезке идём от минуса к плюсу, и вычисляем относительное положение точки внутри отрезка в виде числа от 0 до 1, где 0 соответствует началу отрезка, а 1 - концу. Это и есть доля. Тогда при смене направления движения (от плюса к минусу) достаточно отнять от единицы вычисленную раньше долю. Получим другую долю, или первую же долю, но инвертированную относительно направления отсчёта.
Например, точка 2 на отрезке [-1; 3] даёт с таким подходом 0,75 - доля в три четверти. Тогда при обратном движении, от 3 к -1, доля будет 0,25 - т.е. 1 - 0,75. Т.е. при смене направления оставляем старую формулу нахождения доли, но просто вычитаем результат из единицы.
Хотя, с таким подходом мы же увеличиваем вычисления на одно действие. Щас приведу свой код для расчёта доли. У меня там проверки ещё (кстати, забыл проверку на равенство минимума и максимума, иначе в знаменателе будет ноль), что не позволяет сделать расчёт универсальным.
public static float Fraction(float min, float max, float current) { if (min > max) throw new ArgumentOutOfRangeException($"Min value {min} should be less than or equal to max value {max}."); if (current < min || current > max) throw new ArgumentOutOfRangeException( $"Current value {current} should be greater than or equal to min value {min} and less than or equal to max value {max}."); return MathF.Abs(current - min) / Math.Abs(max - min); }
Надо сделать проще - позволить минимуму быть больше максимума, тогда это будет считаться обратным направлением. И поменять названия параметров, чтобы не было привязки к понятию минимум и максимум, а было просто А и В, которые могут быть как началом, так и концом.
При вычислении доли важна лишь длина отрезка, а для неё не важно, является ли первый параметр началом или концом. Важно, чтобы один был больше другого и всё. Тогда просто сравниваешь два параметра - какой из них больше, и потом из большего вычитаешь меньший, и получаешь знаменатель. Если первый параметр оказался меньше второго, то идёт в одном направлении, если первый больше второго, то в противоположном. Тогда и числитель будет либо (current - А), либо (current - В). Но это надо добавить в описании метода, иначе непонятно, как вычисляется доля, и пользователь может получить неожиданный результат.
Тут дилемма. Если делать метод слишком универсальным, то он будет слишком сложным, и надо обмазать его кучей комментариев. А если делать метод узкозаточенный, то на другую, но похожую задачу, нужно делать другой метод, типа моего "1 минус результат первого метода".
Как бы сделать так, чтобы и метод был один, и был он не сильно сложным, и дополнительных параметров не вводить, и сложных пояснений не делать...
Ну нужно просто поболтать немного
Давай сформулируем универсальную функцию, которая будет:
- Поддерживать движение в любом направлении.
- Без лишних параметров, но с понятным принципом работы.
- Интуитивно понятной для пользователя.
Вот готовый вариант:
public static float Fraction(float a, float b, float current)
{
if (a == b)
throw new ArgumentException("A и B не должны быть равны, иначе длина отрезка будет нулевой.");
return (current - Math.Min(a, b)) / Math.Abs(b - a);
}
🔄 Как это работает?
- Отрезок может быть задан в любом порядке (
a
иb
), то естьa
не обязан быть меньшеb
. - Определяем начальную точку (
Math.Min(a, b)
) → от неё считаем долю. - Используем абсолютную длину отрезка (
Math.Abs(b - a)
), чтобы не было привязки к направлению.
📌 Примеры работы:
Fraction(-1, 3, 2); // 0.75 (обычное направление)
Fraction(3, -1, 2); // 0.25 (обратное направление)
Fraction(10, 5, 7); // 0.6 (считаем от 5 к 10)
Fraction(5, 10, 7); // 0.4 (считаем от 10 к 5)
Теперь длина отрезка всегда положительна, направление определяется само собой, а функция остаётся универсальной и понятной. Никаких дополнительных параметров, но логика счёта полностью прозрачна.
Если current
выходит за пределы [a, b]
, то в текущем варианте результат может выйти за границы [0,1]. Например:
Fraction(-1, 3, 5); // 1.5 (current больше b)
Fraction(-1, 3, -3); // -0.5 (current меньше a)
🛠 Как исправить?
Если нужно ограничить результат диапазоном [0,1]
, можно добавить Clamp
:
public static float Fraction(float a, float b, float current)
{
if (a == b)
throw new ArgumentException("A и B не должны быть равны.");
float fraction = (current - Math.Min(a, b)) / Math.Abs(b - a);
return Math.Clamp(fraction, 0, 1); // Ограничение от 0 до 1
}
📌 Теперь:
Fraction(-1, 3, 5); // 1 (больше b → прижмётся к 1)
Fraction(-1, 3, -3); // 0 (меньше a → прижмётся к 0)
Теперь функция не выйдет за пределы и гарантированно вернёт значение от 0
до 1
.
Вы понимаете, что я гораздо круче вас? Вы работаете с ИИ, а я работаю с ЕИ, который работает с ИИ. Это следующая ступень эволюции. ))
(скопировал себе результаты выше)
Почему выражение "current - Math.Min(a, b)" не под модулем?
Почему выражение "current - Math.Min(a, b)" не под модулем?
Отличный вопрос! В выражении:
(current - Math.Min(a, b)) / Math.Abs(b - a)
Модуль в числителе не нужен, потому что Math.Min(a, b)
уже автоматически выбирает начальную точку отсчёта. Вот почему:
🔍 1️⃣ Если a < b
, то Math.Min(a, b) == a
, и формула превращается в:
[ \frac{\text{current} - a}{b - a} ] Это стандартное вычисление доли.
🔄 2️⃣ Если a > b
, то Math.Min(a, b) == b
, и формула превращается в:
[
\frac{\text{current} - b}{a - b}
]
То есть теперь b
играет роль начальной точки, а a
конечной, и результат автоматически переворачивается.
💡 Почему не нужен Math.Abs(current - Math.Min(a, b))
?
Если взять модуль, то всегда будет положительное число, и направление исчезнет. А нам нужно сохранить порядок расчёта, чтобы естественно получать 0...1
или 1...0
в зависимости от порядка a
и b
.
Таким образом, модуль в числителе убрал бы информацию о направлении движения, а текущая формула всё решает сама, без лишних операций.
Это всё копилот под виндой, ставьте и играйтесь.
Чего играться, если у него объяснения дурацкие?
Если взять модуль, то всегда будет положительное число, и направление исчезнет. А нам нужно сохранить порядок расчёта, чтобы естественно получать0...1
или1...0
в зависимости от порядкаa
иb
.
Таким образом, модуль в числителе убрал бы информацию о направлении движения
Вот это чушь полная. Модуль потому не нужен, что current по определению лежит между a и b, независимо от направления отсчёта. И если мы выбираем минимальное из a и b, то current становится автоматически больше этого минимального.
Тут вся суть в том, что направление отсчёта важно только в части Min(a, b). Дальше для вычисления относительной доли нам направление не нужно, а важны лишь абсолютные величины - что полной длины отрезка в знаменателе, что его доли - в числителе. В знаменателе мы принудительно ставим модуль, т.к. может быть отрицательное число, а нам важна лишь абсолютная величина. А в числителе всегда будет положительное число, и там мы модуль не ставим, но если бы могло быть отрицательное число, то поставили бы. Поставили бы, потому что нам именно что не важен знак (направление), а лишь абсолютная величина. Т.е. нам всё равно, что во всём числителе потеряется информация о направлении - она важна только при определении минимума между концами отрезка - т.е. только в этой части числителя. И больше нигде не важна. В этом суть определения относительной доли отрезка - в конечном счёте мы избавляемся от информации о направлении, т.е. знаков. Т.е. это противоположно тому, что объяснил ИИ.
ИИ нихрена не понимает, а лишь угадывает, как плохой студент, которому повезло правильно ответить на часть вопроса, но дальше он посыпался.
ИИ тут считает правильно, но местами порет чушь в объяснениях. А когда вам показывают правильный результат, но неправильный или не совсем правильный путь его достижения, ВЫ ТУПЕЕТЕ. У вас логика не сходится, вы забываете про это дело, не в силах до конца понять, и просто принимаете на веру. С этого момента эта технология становится для вам магией.
Чёта эти ИИ (пробовал гопоту и копилота) не работают со ссылками или картинками, если не зареган. Точнее, вроде ссылку кинул, но он сказал, что не может прочитать. Хотя там картинка открывется с графиками.
Вобщем, спросил
what do you mean about the black graph for the year 2025 in comparing with another years
и кинул ссылку
Хотел, чтобы он сам подумал и ответил что-то. Для этого нужно у себя самого в башке что-то иметь, чтобы не было, что тебе эта картинка ни о чём не говорит. Т.е. ИИ должен иметь какой-то бэкграунд. А он ведь имеет - он же типа весь интернет прошерстил. Так вот, по моей задумке, у ИИ должны были глаза на лоб полезть и он должен был ответить что-то типа "Ого! Это явный исключительный случай за последние года! Такого ещё не было! Что-то явно происходит с климатом, раз такое резкое падение!". А он мне ничего не ответил, а только банальщину на несколько абзацев развёл, типа график чёрный, рассказывает про объём льда, и там мол есть другие графики, какие-то выше, какие-то ниже. Короче, просто прочитал картинку. Никаких выводов, никаких намёков и связей с другими явлениями - никакого контекста. Пока сам его не направишь на нужную мысль, он будет тупить и говорить очевидные вещи.
Какой же это интеллект, если без пинка он будет стоять на месте как истукан и тупить? У него своих мыслей нет.
Ещё раз про аналогию с плохим студентом на экзамене. Преподаватель видит, что вроде человек перед ним стоит, типа ум должен быть какой-то. А плохой студент тупо бубнит что-то зазубренное, но не понимает, что это. И своих мыслей соответственно нет по этой теме. Ну и какой интерес преподавателю с таким плохим зубрилкой общаться? Зазубрить можно хоть весь курс лекций, и даже выдавать иногда правильные ответы на стандартные вопросы именно по курсу, цитируя эти лекции аж кусками. Но ни шагу в сторону не отступать и никакого понимания не иметь, что цитируешь.
Так никто кстати правильно и не ответил на первый вопрос темы. А главное, не ответил, почему.
Ладно, отвечу тут некоторых охламонам. ))
Оператор присваивания в сишарпе возвращает результат правого выражения. Причём это написано в МСДНе в одном месте парой слов, и больше нигде не упоминается. Или не в МСДНе, а в спецификации языка - не помню. Но важно, что про многие другие вещи талдычат из статьи в статью, и они оскомину набили, а вот этот факт фиг раскопаешь ещё. И он не совсем самоочевиден. Ну а return соответственно вернёт результат оператора присваивания - т.е. его правого выражения. А результат левого будет похерен и забыт где-то в стеке, после чего удалён сборщиком мусора. Поэтому неважно, что такое Validate, и что стоит в геттере.
Я с этим столкнулся, когда писал код типа такого
result = ...
return result;
И решил, чего это я лишние строчки пишу - дай-ка отрефакторю для компактности. И сделал
return result = ...
Только вот если result не просто переменная, а свойство какое, то это уже не рефакторинг, а изменение логики. Неправильное.
Вернёмся к нашим баранам. Перетрясём устои, так сказать.
Я задолбался писать тестовые методы в отдельном проекте. А ещё и заводить отдельный тестовый проект на каждый проект, который тестируешь. Т.е. для каждого ProjectN надо ProjectNTests. Это дико неудобно, и заставляет прыгать между открытыми окнами - с тестируемым кодом и тестирующим кодом.
Что мешает писать тестовые методы прямо под тем методом, который тестируешь? Ну мне тут говорили, что это де захламляет код, становится трудно разобраться, где тесты, а где логика. Ничего не понял - разве нельзя просто свернуть метод и ничего не будет захламляться? Зато не надо искать тестовые методы в других проектах. А просто под методом с логикой пишешь MethodNameTests и сворачиваешь его, если сильно глаза мозолит.
Пообсуждаем?
Программист ленив, пора таких как ты выгонять! Тоесть заменить на ИИ-Ассистента,
ИИ не ноет, про Майями и доски на мозги не капает, ИИ не болеет! Дешевле! Меняем!
