• Linux говно bc (символ > вписан мною, чтобы отличать ввод от вывода)
    0_ilan@azor /tmp%bc -l
    bc 1.06.95
    Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
    This is free software with ABSOLUTELY NO WARRANTY.
    For details type `warranty'.
    obase=2
    scale=100
    18.9
    10010.1110
    18.9010010.1110011
    18.9000000000000000000010010.11100110011001100110011001100110011001100110011001100110011001\
    10011
    189/1001.111000111101011100001010001111010111000010100011110101110000101000\
    11110101110000101000111101011100001010001111010111000010100011110101\
    11000010100011110101110000101000111101011100001010001111010111000010\
    10001111010111000010100011110101110000101000111101011100001010001111\
    010111000010100011110101110000101000111101011100001010001111010

Replies (26)

  • @tzirechnoy, а что не так-то?
  • @WiseLord, То, что смена obase при вводе 18.9 — даёт совсем не то, что я хочу.
  • @WiseLord, И то, что нули в концэ числа, которые принято отбрасывать, потому что они незначащие — оказываются значащими. ВНЕЗАПНО.
  • @tzirechnoy, Зачем нужен bc, если везде есть питон?
  • @Geladil, Унылый у тебя какой-то троллинг.
  • @tzirechnoy, На данном уровне округления они не значащие, по идее. Другой вопрос, что на каждую десятичную цифру после запятой отводится 4 двоичные — может, это поведение и есть не совсем то, что хочется?
  • @WiseLord, Вот понимаешь, по идее — они не значащие. А по факту — результат отличается очень сильно.
  • @tzirechnoy, Тащемта, я совершенно искренне. Я уже давненько перестал bc использовать, просто запускаю питоношелл.
  • @Geladil, Тащемта, я совершенно искренне.
    Это прискорбно.
  • @tzirechnoy, В том смысле, что если число вроде 0.1110 1111 — то при округлении до четырёх знаков четвёртый ноль нельзя отбрасывать, потому как остаток 0.0000 1111 делает число ближе к 0.1111, чем к 0.1110?
  • @tzirechnoy, И ты еще говорил про унылый троллинг.
  • @tzirechnoy, Хм, почитал про bc. Оказывается, я многого про него знал.
  • @WiseLord, Я только в том смысле, что число 18.8750 (которым является 10010.1110) как-то дофига отличается от 18.9, которое я ввёл.
    И это меня расстраивает.
  • @WiseLord, Хотя, похоже с этой точки зрения bc делает всё правильно. И число 0.1110 1000 он, видимо, округлил бы до 0.1111, а 0.1110 0111 — уже до 0.111, отбросив 4-й ноль как незначащий.
  • @Geladil, Да, я нелюблю бидон.
  • @tzirechnoy, Внутри-то bc считает наверняка правильно, с максимальным числом знаков. Ну а выводит уже, округляя. Стоит проверить.
  • @WiseLord, Нет, я домножал результат на 100. Собственно, в середине экзэрсисов выяснилось.
  • @WiseLord, А, похожэ ты прав — считает он под scale, а выводит, действительно, обрезанным.
  • @tzirechnoy, второй тег можно убирать?
  • @WiseLord, Перебьётся.
  • @WiseLord, Ну, серьёзно. Полез выяснять, как будет будет 18.9 в floating point — а мне такая подлянка.
  • @tzirechnoy, Будь у человека 4 пальца, мы с такими проблемами сегодня вряд ли бы сталкивались.
  • @WiseLord, *на одной руке, естественно. Ну, или 8.
  • @WiseLord, Что самое смешное — с человеческими руками самой вменяемой была бы шэстиричная система исчисления.
    Следующей по вменяемости была бы одиннадцатиричная.
    Как вавилонцы умудрились себе устроить десятиричную и шэстядисятиричную — ну, вот уметь надо.
  • @tzirechnoy, Проблема в твоём scale.

    scale=100
    scale(18.9)
    1
    scale(18.90)
    2
    scale(18.90000000000000000000)
    20
    scale(189/10)
    100
    scale(18.9/1)
    100

    И вывод производится с соответствующей точностью. То есть чтобы введённое число преобразовать в число с точностью по умолчанию — нужно поделить его на единицу.