Здравствуйте, wallaby, Вы писали:
К>>А вот для вещественных типов, ЕМНИП, можно сделать априори-мусорное значение (элементарно: денормализовать мантиссу).
W>Но как, Холмс? ЕМНИП мантисса вещественного числа хранится без старшего бита (который подразумевается единичным для всех значений экспоненты кроме 0 (0) и 3ff (NaN)) и не может быть ненормализованной. "Испортить" вещественное число наверно можно например записав в экспоненту 0 а в мантиссу не 0, хотя в этом случае FPU скорее всего просто проигнорирует биты мантиссы.
Здравствуйте, samius, Вы писали:
S>мы "готовы" значит что программист, прочитавший спецификацию, предупрежден о том что там может быть не true и не false.
а... ну так это относится ко всем типам, в общем-то, не только к bool.
И если программист пишет програму так, чтоб не возникало UB, то ему и не надо быть ни к чему готовым.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, samius, Вы писали:
S>>мы "готовы" значит что программист, прочитавший спецификацию, предупрежден о том что там может быть не true и не false.
J>а... ну так это относится ко всем типам, в общем-то, не только к bool.
не совсем. Испортить ссылку нам в шарпе не дадут. Хотя подменить тип ссылки можно тем же способом.
J>И если программист пишет програму так, чтоб не возникало UB, то ему и не надо быть ни к чему готовым.
Или ко всему готовым?
Здравствуйте, samius, Вы писали:
S>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, samius, Вы писали:
S>>>мы "готовы" значит что программист, прочитавший спецификацию, предупрежден о том что там может быть не true и не false.
J>>а... ну так это относится ко всем типам, в общем-то, не только к bool. S>не совсем. Испортить ссылку нам в шарпе не дадут. Хотя подменить тип ссылки можно тем же способом.
Я про плюсы.
J>>И если программист пишет програму так, чтоб не возникало UB, то ему и не надо быть ни к чему готовым. S>Или ко всему готовым?
Не вижу смысла быть ко всему готовым.
Имхо, вполне достаточно писать в терминах корректной программы, иначе вместо нормальной программы будут сплошные проверки типа this != NULL.
Ко всему готовым нужно быть только при валидации внешних данных.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, samius, Вы писали:
J>>>а... ну так это относится ко всем типам, в общем-то, не только к bool. S>>не совсем. Испортить ссылку нам в шарпе не дадут. Хотя подменить тип ссылки можно тем же способом. J>Я про плюсы.
аа, ну в плюсах все по-другому воспринимается, т.к. там никто не защищает от хождения по граблям, потолку и т.п. А в шарпе нас от всего "защищают", но как-бы не до конца.
J>>>И если программист пишет програму так, чтоб не возникало UB, то ему и не надо быть ни к чему готовым. S>>Или ко всему готовым? J>Не вижу смысла быть ко всему готовым. J>Имхо, вполне достаточно писать в терминах корректной программы, иначе вместо нормальной программы будут сплошные проверки типа this != NULL. J>Ко всему готовым нужно быть только при валидации внешних данных.
Согласен. Если мы внутри сами случайно данные не сломаем, а таки чтобы сломать в шарпе bool, надо приложить некоторые усилия, то внутри бояться мусора в bool-е не следует.
Проверять ли внешние bool параметры на мусор? Имхо — не стоит. Но стоит вообще аккуратнее относитсья к сравнению bool-ов, а так же не использовать метку true в switch-е (только false и default).
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, wallaby, Вы писали:
К>>>А вот для вещественных типов, ЕМНИП, можно сделать априори-мусорное значение (элементарно: денормализовать мантиссу).
W>>Но как, Холмс? ЕМНИП мантисса вещественного числа хранится без старшего бита (который подразумевается единичным для всех значений экспоненты кроме 0 (0) и 3ff (NaN)) и не может быть ненормализованной. "Испортить" вещественное число наверно можно например записав в экспоненту 0 а в мантиссу не 0, хотя в этом случае FPU скорее всего просто проигнорирует биты мантиссы.
К>Возможно, что здесь как раз мне изменила память :shuffle:
Наверняка. В реализациях с принудительной нормализацией (как IEEE754 и он на x86) такое невозможно из-за скрытого старшего, а в реализациях без этого (long double на x86, S/360 и так далее) денормализованное представление является штатным.
Поэтому, априори-мусорное на них выделяется отдельно (в том же IEEE754 — NaN содержит область целого параметра, который должен быть не равен 0, и тем самым может передавать много разных ситуаций).
Здравствуйте, jazzer, Вы писали:
N>>1. То, о чём ты говоришь, фактически означает не "целое число градусов", а "целое конкретное число градусов из набора фиксированных значений, которые имеют свой отдельный смысл" (180 — пол-круга, 90 — четверть круга или прямой угол, и так далее). Потому что поворот на 180, например, чётко определён именно в градусах как половина круга и это имеет смысл тем, что упрощает реализацию; а вот поворот на 25 или 26 градусов у тебя будет одинаково трудоёмок что в радианах, что в градусах. J>ну то есть в основном одинаково трудоемко, но в градусной мере есть выделенные точки, в которых радикально менее трудоемко.
Да.
J>Стало быть, градусы лучше, чем радианы; непонятно, почему ты говоришь, что идея неприемлема :xz:
Потому что это 1) не специфика градусов (это не основное), 2) не основание считать градусы только целочисленными (а вот это уже основное). Точно так же вместо градусной меры можно было передавать долю круга в float (то есть 1.0 соответствует 360 градусам): так как 1/4 точно представимо и в двоичной, и в десятичной плавучке — результат достигается и определить случай простого поворота можно точно.
J>>>Естественность для человека тут ни при чем, просто целые радианы практического смысла не имеют никакого, в отличие от целых градусов (именно потому что круг поделили на целое количество частей). N>>Целые радианы имеют значительно больше практического смысла, чем целые градусы. Радианы не только не зависят от того, сколько у тебя пальцев или чем ты думаешь — они упрощают практически все тригонометрические формулы. Иначе бы их не вводили. А градусы — это индивидуальны. J>Да ладно. Все наоборот. Раз ты завёл речь о тригонометрии — чему равен синус 180 градусов? а синус 3.1415926?
Последнее — что-то около 0.0000000535..., потому что синус на таких углах — практически линейная функция. А что? ;))
J> а синус 3.1415926535?
Аналогично 0.000000000089... только зачем ты путаешь локальную практику человечества последних ~500 лет с фундаментальными основами?
J>Формулам пофиг, там все с точностью до множителя, а вот в реальной машинной жизни все сильно портится, потому что этот множитель иррационален и непредставим в десятичной записи (вернее, ни в какой разрядной записи непредставим).
Не, ты не понял. Формулам не пофиг, потому что в них множителя этого вообще нет. Как считается синус в радианах? x — x**3/fact(3) + x**5/fact(5) — x**7/fact(7)... А как в градусах? Вот тут собственно появляется множитель, а затем берётся всё та же формула для радианов. (Машинные оптимизации этих формул давай тут не обсуждать) Вот я про это.
N>>А в компилируемых языках можно это возложить на компилятор. Просто не припекло. J>Мороки много просто. Есть же Boost.Parameter.
Здравствуйте, netch80, Вы писали:
J>>Стало быть, градусы лучше, чем радианы; непонятно, почему ты говоришь, что идея неприемлема
N>Потому что это 1) не специфика градусов (это не основное), 2) не основание считать градусы только целочисленными (а вот это уже основное). Точно так же вместо градусной меры можно было передавать долю круга в float (то есть 1.0 соответствует 360 градусам): так как 1/4 точно представимо и в двоичной, и в десятичной плавучке — результат достигается и определить случай простого поворота можно точно.
Да, это тоже решение, в этом смысле аналогичное градусам (определенные углы становятся представимыми точно).
Но у радианов и того нету.
1 радиан не имеет никакого практического смысла.
J>>Да ладно. Все наоборот. Раз ты завёл речь о тригонометрии — чему равен синус 180 градусов? а синус 3.1415926? N>Последнее — что-то около 0.0000000535..., потому что синус на таких углах — практически линейная функция. А что? ) J>> а синус 3.1415926535? N>Аналогично 0.000000000089... только зачем ты путаешь локальную практику человечества последних ~500 лет с фундаментальными основами?
Да потому что мы говорим о реальных системах,а не о фундаментальных основах. Потому что в фундаментальных основах наличие или отсутствие множителя ну никакой роли не играет вообще. А вот на практике — играет, и еще какую.
Типа синус 180 градусов равен точно нулю, а не вот эти все циферки после запятой, что ты нарисовал.
А особенно это заметно будет, когда мы поделим на этот синус.
J>>Формулам пофиг, там все с точностью до множителя, а вот в реальной машинной жизни все сильно портится, потому что этот множитель иррационален и непредставим в десятичной записи (вернее, ни в какой разрядной записи непредставим).
N>Не, ты не понял. Формулам не пофиг, потому что в них множителя этого вообще нет. Как считается синус в радианах? x — x**3/fact(3) + x**5/fact(5) — x**7/fact(7)... А как в градусах? Вот тут собственно появляется множитель, а затем берётся всё та же формула для радианов. (Машинные оптимизации этих формул давай тут не обсуждать) Вот я про это.
Ну так одно лишнее умножение — и считай себе в радианах.
Но при этом для определенных углов ты можешь вычислить формулы точно, безо всяких рядов, а для всех остальных юзать ряды.
Я не могу понять, с чем ты споришь, при том что сам признаешь, что у градусов/градов/долей круга есть преимущество перед радианами благодаря наличию особых точек, в которых нечто можно посчитать оптимально.
И вообще все это офтопик, мы тут типа булевские аргументы обсуждаем
J>>Мороки много просто. Есть же Boost.Parameter. N>Оно достаточно эффективно?
Понятия не имею, не юзал.
Думаю, особого оверхеда там не должно быть.
Здравствуйте, jazzer, Вы писали:
J>Да, это тоже решение, в этом смысле аналогичное градусам (определенные углы становятся представимыми точно). J>Но у радианов и того нету. J>1 радиан не имеет никакого практического смысла.
Как это не имеет? У него длина дуги равна радиусу. Вот ты едешь по МКАД, проехал 22 километра — проехал около радиана.
N>>Аналогично 0.000000000089... только зачем ты путаешь локальную практику человечества последних ~500 лет с фундаментальными основами? J>Да потому что мы говорим о реальных системах,а не о фундаментальных основах. Потому что в фундаментальных основах наличие или отсутствие множителя ну никакой роли не играет вообще. А вот на практике — играет, и еще какую. J>Типа синус 180 градусов равен точно нулю, а не вот эти все циферки после запятой, что ты нарисовал. J>А особенно это заметно будет, когда мы поделим на этот синус.
Зачем на него делить в окрестностях нуля??? Я резко возражаю против этого безумия. Задача с таким делением некорректна и требует переделки начиная с постановки.
J>Но при этом для определенных углов ты можешь вычислить формулы точно, безо всяких рядов, а для всех остальных юзать ряды. J>Я не могу понять, с чем ты споришь, при том что сам признаешь, что у градусов/градов/долей круга есть преимущество перед радианами благодаря наличию особых точек, в которых нечто можно посчитать оптимально.
Изначально я возражал на твоё утверждение, что "градусы хороши своей целочисленностью". Если бы ты сделал в данном случае API с приёмом только градусов и только целыми, это, может, и работало бы для разворота "кру-гом!", но для мягких корректировок курса уже работать не будет, и у тебя автопилот будет слишком грубым.
Далее, геометрические расчёты курса наверняка ведутся именно в радианах. Никто их ради такого API в градусы пересчитывать не будет. И опять-таки аргумент в пользу представления в радианах (не обязательно только в них).
J>И вообще все это офтопик, мы тут типа булевские аргументы обсуждаем :beer:
Я не знаю, что там обсуждать в булевских аргументах. Обсуждение "какие языки умеют что-то ещё кроме true и false и чем это грозит", конечно, познавательно, но мне в нём смысла ноль целых фиг десятых. Кривизну API и желательность передавать дополнительные слова вроде бы уже все утвердили. Пусть себе обсуждают где какой bool, это не моя тема.
J>>>Мороки много просто. Есть же Boost.Parameter. N>>Оно достаточно эффективно? J>Понятия не имею, не юзал. J>Думаю, особого оверхеда там не должно быть.
Ну осталось найти за пределами C++ достойный аналог. ;)
Здравствуйте, jazzer, Вы писали: J>Да ладно. Все наоборот. Раз ты завёл речь о тригонометрии — чему равен синус 180 градусов? а синус 3.1415926? а синус 3.1415926535?
Если тебе нужна 100% точность — ты никуда не сбежишь от символьных вычислений, а там что π, что 180 — один фиг.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, jazzer, Вы писали: J>>Да ладно. Все наоборот. Раз ты завёл речь о тригонометрии — чему равен синус 180 градусов? а синус 3.1415926? а синус 3.1415926535? MC>Если тебе нужна 100% точность — ты никуда не сбежишь от символьных вычислений, а там что π, что 180 — один фиг.
180 градусов — это точное значение. И в формате с плавающей запятой оно точно представимо.
В отличие от.
Здравствуйте, jazzer, Вы писали: J>180 градусов — это точное значение. И в формате с плавающей запятой оно точно представимо.
И как ты этот факт собираешься использовать? Сравнивать некое значение с константой 180? Чем это будет отличаться от сравнения с константой M_PI?
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, jazzer, Вы писали: J>>180 градусов — это точное значение. И в формате с плавающей запятой оно точно представимо. MC>И как ты этот факт собираешься использовать? Сравнивать некое значение с константой 180? Чем это будет отличаться от сравнения с константой M_PI?
Например, тем, что M_PI может пострадать при компиляции от конверсии из текстового вида в плавучку и дать ошибку в каком-то знаке после запятой. И тут уже надо думать не про сравнение на равенство, а сравнение на abs(a-b)<min_delta, как принято для плавучки. А выбор delta сильно зависит от задачи.
Здравствуйте, netch80, Вы писали: N>Например, тем, что M_PI может пострадать при компиляции от конверсии из текстового вида в плавучку и дать ошибку в каком-то знаке после запятой. И тут
уже надо думать не про сравнение на равенство, а сравнение на abs(a-b)<min_delta, как принято для плавучки. А выбор delta сильно зависит от задачи.
Ну так и со 180.ровно тоже нельзя просто так сравнивать.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, netch80, Вы писали: N>>Например, тем, что M_PI может пострадать при компиляции от конверсии из текстового вида в плавучку и дать ошибку в каком-то знаке после запятой. И тут MC>уже надо думать не про сравнение на равенство, а сравнение на abs(a-b)<min_delta, как принято для плавучки. А выбор delta сильно зависит от задачи. MC>Ну так и со 180.ровно тоже нельзя просто так сравнивать.
Если оно возникло именно как 180, а не результат сложных вычислений — то можно и нужно.
Здравствуйте, netch80, Вы писали: N>Если оно возникло именно как 180, а не результат сложных вычислений — то можно и нужно.
Если нечто возникто как 180, то сравнивать его со 180, пожалуй, нет смысла.
Но вот в осмысленном случае, когда одно возникло как результат вычислений, а другое — 180 — то сравнивать просто на равенство, как ты сам сказал, не получится.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, jazzer, Вы писали: J>>180 градусов — это точное значение. И в формате с плавающей запятой оно точно представимо. MC>И как ты этот факт собираешься использовать? Сравнивать некое значение с константой 180? Чем это будет отличаться от сравнения с константой M_PI?
Иди почитай где-нть про сравнение чисел с плавающей запятой на равенство, в сети море информации на эту тему....
Здравствуйте, jazzer, Вы писали:
MC>>И как ты этот факт собираешься использовать? Сравнивать некое значение с константой 180? Чем это будет отличаться от сравнения с константой M_PI?
J>Иди почитай где-нть про сравнение чисел с плавающей запятой на равенство, в сети море информации на эту тему....
Сравнивать вычисленные значения нельзя, присвоенные — можно (если осторожно). И то, и другое относится как к сравнению со 180.0, так и к сравнению с M_PI.
Пока ты оставался с целочисленным 180, у тебя была хоть какая-то (полувразумительная) почва под ногами, после того, как ты перешел к значению с плавающей запятой 180.0, в пользу градусов остался пожалуй единственный аргумент: некоторое удобство при отладке. Но оно сильно субъективно, а тормоза при вычислениях объективны.
Здравствуйте, jazzer, Вы писали: J>Иди почитай где-нть про сравнение чисел с плавающей запятой на равенство, в сети море информации на эту тему....
Вот ведь как — достаточно обвинить оппонента в невежестве и его сообщения можно не читать. Да?
Перекуём баги на фичи!
)
