На чем написан калькулятор

Программирование на калькуляторе

Здравствуйте, хабражители. Думаю, многие из вас слышали о программируемых калькуляторах (а некоторые даже использовали их). Как ни странно, здесь я не нашел ни одной статьи, рассказывающей о такой интересной вещи, и поэтому решил восполнить этот пробел и рассказать об основах программирования на калькуляторах.

Некоторое время назад я нашел у себя в кладовке старый «Электроника МК-61», принадлежавший моему папе. Естественно, я не мог упустить такой шанс освоить не совсем «стандартное» программирование на калькуляторе. (В случае, если у вас нет программируемого калькулятора, вы можете скачать эмулятор здесь)

Память

Прежде всего необходимо понять, как устроена память в этом калькуляторе. В распоряжении пользователя имеется 4 стековых регистра: X, Y, Z, T. Содержимое регистра X всегда показывается на экране (в режиме расчетов), ввод чисел тоже идет в него. По сути, стековая память после включения калькулятора выглядит так:

то после значения станут

Команда [] меняет содержимое регистров X и Y местами.

Команда [CX] стирает содержимое регистра X.

Важно помнить, что после выключения калькулятора значения всех регистров стираются.

Расчеты

После нажатия клавиш [2] [В↑] [3] :

Программирование

Основы

Безусловный и условный переходы

С помощью команды [БП] (51) можно осуществить безусловный перезод (goto) по нужному адресу. Для этого в режиме программирования нужно нажать [БП] а затем две цифры адреса, по которому мы хотим перейти. Когда калькулятор при выполнении программы дойдет до этого оператора, он продолжит выполнение уже с команды по указанному адресу. Например:

В данном случае после шага 12 калькулятор перейдет сразу к шагу 42.

Циклы

Заключение

Конечно, эта статья — далеко не полное руководство по программированию на МК-61. Интересующимся в более глубоком освоении этой темы рекомендую почитать инструкцию (pdf, 6 MB) к этому замечательному калькулятору.

Источник

Делаем более-менее универсальный калькулятор услуг для сайта

Беглый анализ открытых данных показывает, что ежедневно в среднем 5 человек оставляют заявки на создание калькулятора на биржах фриланса — а еще несколько сотен интересуются вопросом в поиске. Часто запросы стандартны — и, конечно, на рынке сложился целый набор готовых предложений: от плагинов для конкретных CMS до калькуляторов, которые можно приобрести у студий. Рекорд, обнаруженный нами (см. в первом комментарии) — 24 999 рублей за довольно обычное решение.

Да, рынок есть рынок. Но поскольку мы в основном работаем с людьми, чьи сайты сделаны на конструкторах, у них нет 25 тысяч на один виджет. Вот и возникло желание написать калькулятор, которым они смогли бы пользоваться самостоятельно — и без изучения HTML, JS, JQuery и CSS.

В процессе работы над проектом нам удалось реализовать несколько находок в логике работы и дизайне калькулятора. Ими, а также полезными инструментами, и хотим поделиться с сообществом.

По сути, у нас получился довольно универсальный онлайн-конструктор калькуляторов, результат работы в котором можно встроить на любую платформу, поддерживающую вставку HTML.

Как устроен конструктор калькуляторов

Пишем свою адаптивность

Лайфхак: как упростить формулы до азбуки

Чистим код с GULP (а не тем, о чем вы могли подумать)

Есть ли жизнь после жизни?

Как устроен конструктор калькуляторов

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

В начале было пустое поле. Регистрируясь на сервисе впервые, человек действительно видит пустую страницу с единственной кнопкой добавления нового проекта-калькулятора.

В будущем на этой странице будут появляться снимки-ссылки на калькуляторы пользователя, вот как тут:

Для создания скриншота-превью калькулятора в кабинете мы использовали PhantomJS. Штука очень удобная, когда ты уже создал несколько калькуляторов, — при входе в кабинет сразу понятно, где какой из проектов.

Люди любят ползунок. Это стало понятно, когда мы запустили первых людей на сервис, и они стали выбирать, из каких элементов создать виджет.

Сам интерфейс создания калькулятора устроен похоже с ЛК — есть большое пустое поле, на которое можно добавлять элементы из боковой панели. Для старта мы выбрали 8 элементов. Пять отвечают непосредственно за калькулятор — это ползунок, выпадающий список, галочка, текстовое поле (для сбора почт, адресов и т.д.) и переключатель. Еще три — за привлекательность (картинка) и опцию заказа — текстовый блок и кнопка. Самым востребованным элементом из всех оказался ползунок.

Сначала для создания ползунка мы выбрали расширения jQuery Scrollbar, но штука странно себя вела на мобильных. Поэтому мы взяли и модифицировали расширение JQuery-Range-Slider. Остальные элементы написали и стилизовали сами

Манипуляции с элементами и данными калькуляторов производятся на клиентской части проекта — поэтому в процессе важно было придумать, как максимально экономить ресурсы браузера.

Этот момент стал одним из самых хлопотных при отладке. Но зато сейчас запись процессов, происходящих на странице, когда человек перетаскивает элемент в калькулятор (это самый ресурсозатратный момент), выглядит так:

Мы максимально порезали обработчики, оставив только необходимый минимум. С оптимизацией на клиентской части нам здорово помог инструмент Timeline из Google Chrome Developer Tools.

Исходно все элементы хранятся в объекте FIELDS — у каждого есть типовой HTML-шаблон и список опций. После перетаскивания элемента в рабочую область, нужные опции прилетают с сервера и подставляются в шаблон — например, на кнопку навешены отправка информации о заказе владельцу и клиенту: по почте через наш сервер, либо по смс — пока через API SmsSimple, но мы ищем другой сервис (и будем рады рекомендациям).

Чтобы подставлять опции, к прототипу строки мы написали свой метод Signe. Работает он так:

Drag’n’drop по-своему. Идея «бери больше — кидай дальше», на наш взгляд, это самый удобный способ сборки чего бы то ни было для обычного пользователя. Ну хотя бы потому, что красиво.

Когда мы рассматривали существующие решения для создания калькуляторов, в них смущала некая «прибитость элементов гвоздями» — факт, что элементы можно расположить довольно строго определенным образом: например, только друг под другом, а не рядом. Хотелось уйти от этого, для чего мы придумали систему точек.

Cетка невидимых пользователю точек

Перед перетаскиванием нового элемента мы формируем карту точек, в которые можно добавить новое поле — для этого скрипт обращается ко всем элементам рабочей области и оценивает их границы.

Что это дает? Пользователь сразу может выбрать между таким:

И вот таким вариантом расположения элемента:

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

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

Для создания самих визуальных эффектов при сборке калькулятора мы использовали jQuery UI и Animate.css

Абстрагируемся от системы мер и весов. Поскольку решение хотелось сделать универсальным и простым, мы отказались от дополнительных полей, в которых при создании калькулятора человек бы выбирал метры, граммы или рубли. Условные обозначения можно вписать — но чисто для удобства и ориентира. Для всех текстовых элементов мы использовали движок Medium Editor – очень удобный и простой текстовый редактор.

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

«Шаблон «расчет количества мяса» — просто убил: по картинке понятно, что шашлык, а по градациям — такое впечатление, будто из всех этих людей собрались шашлык делать) Ржали всем отделом».

Пощупать калькулятор-шаблон, который развеселил целый отдел, можно здесь

Картинки — это важно. Для лучшего знакомства с товаром или услугой логично добавить изображения над теми же галочками или иным полем, отвечающем за выбор. Благодаря сетке точек, получилось реализовать вставку картинки в любую область рабочего поля. Иногда это полезно:

За тему с ёлочками спасибо Владимиру Гынгазову, автору канала “Adobe Muse по-русски”

Сама реализация загрузки картинок сделана через FileSystem API&File API — весь процесс отлично описан в этой статье.

«А поиграться с. » Логично дать пользователю возможность подстроить цвета текстов, кнопок, фона и т.д. под цвета сайта. Для вызова и создания цветовой палитры мы использовали виджет Spectrum.

Хранение данных и автосохранение. Данные о клиентской части калькулятора хранятся в формате JSON. Вы можете увидеть их структуру, просто написав в консоли SAVER.json на сервисе.

Автосохранение происходит при каждом действии, если в калькуляторе есть активность. Изменения параллельно сохраняются и в DOM, причем каждый раз мы проверяем:

Если же в пределах 4 секунд ничего не происходит, калькулятор останавливает автосохранение до новых правок — так мы избавляемся от бессмысленных запросов к серверу.

Превью. Чтобы не затрачивать ресурсы браузера клиента, мы решили не анимировать интерфейс предпросмотра с помощью jQuery — поскольку с анимацией отлично справляется и CSS3: достаточно поменять класс в корне интерфейса, и у области просмотра изменится ширина и наружное оформление, стилизованное под смартфон и планшет.

Внимание на консоль

Само создание адаптивной версии калькулятора стало отдельной песней.

Div-ная верстка: пишем свою адаптивность

В конструкторе сайтов uKit, для которого исходно создавался наш проект, используется сетка Twitter Bootstrap — популярное и заслуженное решение, чтобы адаптировать веб-элементы под экран посетителя. Но бутстреп предполагает два варианта дизайна: таблицу или колонку. Поэтому мы разработали собственный вариант адаптации калькулятора.

Т.к. структура калькулятора хранится в JSON, у нас есть родительский массив со строками, а в каждой строке — массив ячеек. Помимо этого, в ячейке есть массив суб-строк (и суб-ячеек), чтобы внутри было не одно поле, а несколько. Структура ячеек показана ниже:

У калькулятора есть родительский блок со стилем display: table, внутри у него есть table-row и table-cell, соответственно. Сам калькулятор отрисовывается на сайте во фрейме. Внутри фрейма размещены стили для адаптации — и когда фрейм становится достаточно узким, калькулятор без изменения HTML-сетки перебрасывает поля на новые строки. Сделано это с помощью изменения стиля display: если на широком калькуляторе это table-cell, то на узком становится block, и наше поле оказывается на новой строке.

Исходно-десктопный вид калькулятора зависит от ширины контейнера, в котором он находится, а калькулятор стремится показать в одной строке как можно больше полей. При сужении экрана функция, которая перестраивает сетку, проходит по всем строкам калькулятора, и если в строке есть «лишние» ячейки, ниже создается новая строка.

Упрощаем работу с формулами

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

Вместо этого всего в отдельной вкладке есть элементы калькулятора в виде схемы. Схема содержит названия переменных и диапазоны значений для каждого из элементов калькулятора.

Чтобы задействовать какое-то поле в расчете, достаточно указать его переменную в окошке слева. Формул может быть несколько: в этом случае в калькуляторе отображается несколько результатов, например “Обычная цена” и “Цена со скидкой”.

Переменные начинаются с буквы “A”. Если полей больше, чем букв в латинском алфавите, к имени переменной добавится еще одна буква: “AA” и так далее. Каждая буква связана с числовым id конкретного поля в калькуляторе. Найти готовое решение для преобразования числа в латинские буквы и комбинации букв нам не удалось. Поэтому мы написали следующий метод:

DAT.varName(9) // I
DAT.varName(39) // AM
DAT.varName(9650215) // UCALC

Будем рады, если он вам пригодится (с вопросами можно стучаться к condor-bird).

Оптимизируем скорость загрузки

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

То есть, пора было отрезать ломоть калькулятор от сервиса. Встал выбор между двумя путями:

Быстрым. В том же превью грузится виджет калькулятора — можно скрыть все элементы интерфейса конструктора, оставив поля, сетку и калькулирование — и вот он, по сути, виджет для стороннего сайта.

Но быстрый путь был отвергнут — потому что он замедлял загрузку: мы получили бы 1959 килобайт, 269 из которых заняли бы все CSS-ки, используемые в сервисе. А ведь одно из главных требований к виджету на сайте — чтобы он грузился быстро.

И правильным. Тут мы пошли к GULP — чтобы обрезать все лишнее, вроде переноса строк, и собрать один минифицированный файл с максимально чистым кодом. Почему GULP? На то есть важная причина — у нас был 41 файл (и, соответственно, 41 запрос к серверу), а мы хотели уместить все в один запрос. И мы получили то, что хотели.

Это наш дефолтный шаблон. Была скорость загрузки курильщика

Стала скорость загрузки здорового человека

Теперь мы оставляем от 140 до 180 килобайт — в зависимости от числа полей. Для каждого типа поля есть две версии: короткая и вдвое короче — для стороннего сайта.

А что насчет скорости исполнения скрипта, спросите вы?

Это огромный калькулятор расходов на свадьбу, созданный реальным пользователем. Было так.

Тот же проект. Стало так

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

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

Упрощаем автообновление калькулятора, встроенного на сайт

В идеальном случае пользователь собрал калькулятор, получил код для встраивания на сайт — и наступило счастье.

Но установка на сайт не всегда значит, что человек больше не будет трогать готовый калькулятор. Самый очевидный случай, когда требуется внести изменения, — это рост или снижение цены на услугу.

Поэтому для каждого встроенного калькулятора мы делаем две версии:

Именно для этого в системе присутствует большая зеленая кнопка «Сохранить» — пока вы её не тронули, мы не переносим на сайт изменения, сделанные в версии для редактирования, а просто запоминаем их через автосохранение.

Первые выводы

Состоят в том, что при создании онлайн-калькулятора и его админки, — задаче, имеющей массу готовых решений, — много места для новинок. Кому-то в новинку все, как brizing — конструктор калькуляторов стал первым боевым проектом, в котором ему доверили работу джуниора. Но и остальные открыли для себя много нового.

Открытий явно станет больше — и вы можете подкинуть нам еще идей и задачек: uCalc находится на стадии открытого тестирования, и мы будем благодарны всем, кто найдет время пощупать решение и отписать мысли и ощущения в комментариях, либо в личку мне, brizing и condor-bird.

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

Источник

Пишем «калькулятор» на C#. Часть I. Вычисление значения, производная, упрощение, и другие гуси

Калькулятор у нас почему-то ассоциируется с чем-то, что должен написать каждый новичок. Возможно потому, что исторически компьютеры с той целью и создавались, чтобы считать. Но мы будем писать непростой калькулятор, не sympy конечно, но чтобы умел базовые алгебраические операции, типа дифференциирования, симплификации, а также фичи типа компиляции для ускорения вычислений.

Сборка выражения

Что такое «выражение»?

Конечно, это не строка. Довольно очевидно, что математическая формула — это либо дерево, либо стек, и здесь мы остановимся на первом. То есть каждая нода, каждый узел этого дерева, это какая-то операция, переменная, либо константа.

Операция — это либо функция, либо оператор, в принципе, примерно одно и то же. Ее дети — аргументы функции (оператора).

Иерархия классов в вашем коде

Разумеется, реализация может быть любой. Однако идея в том, что если ваше дерево состоит только из узлов и листьев, то они бывают разными. Поэтому я называю эти «штуки» — сущностями. Поэтому верхним классом у нас будет абстрактный класс Entity.

А также будет четыре класса-наследника: NumberEntity, VariableEntity, OperatorEntity, FunctionEntity.

Как построить выражение?

Для начала мы будем строить выражение в коде, то есть

Если объявить пустой класс VariableEntity, то такой код выкинет вам ошибку, мол не знает как умножать и суммировать.

Переопределение операторов

Очень важная и полезная фича большинства языков, позволяя кастомизировать выполнение арифметических операций. Синтаксически реализуется по-разному в зависимости от языка. Например, реализация в C#

(Не)явное приведение типов

В компилируемых языках типа C# такая штука обычно присутствует и позволяет без дополнительного вызова myvar.ToAnotherType() привести тип, если необходимо. Так, например, было бы удобно писать

Подвешивание

Класс Entity имеет поле Children — это просто список Entity, которые являются аргументами для данной сущности.

Когда у нас вызывается функция или оператор, нам стоит создать новую сущность, и в ее дети положить то, от чего вызывается функция или оператор. К примеру, сумма по идее должна выглядить примерно так:

То есть теперь если у нас есть сущность x и сущность 3, то x+3 вернет сущность оператора суммы с двумя детьми: 3 и x. Так, мы можем строить деревья выражений.

Вызов функции более простой и не такой красивый, как с оператором:

Подвешивание в репе реализовано тут.

Отлично, мы составили дерево выражений.

Подстановка переменной

Здесь все предельно просто. У нас есть Entity — мы проверяем является ли он сам переменной, если да, возвращаем значение, иначе — бежим по детям.

В этом огромном 48-строчном файле реализована столь сложная функция.

Вычисление значения

Собственно то, ради чего все это. Здесь мы по идее должны добавить в Entity какой-то такой метод

Листик без изменений, а для всего остального у нас кастомное вычисление. Опять же, приведу лишь пример:

Если аргумент — число, то произведем численную функцию, иначе — вернем как было.

Number?

Это самая простая единица, число. Над ним можно проводить арифметические операции. По умолчанию оно комплексное. Также у него определены такие операции как Sin, Cos, и некоторые другие.

Если интересно, Number описан тут.

Производная

Численно производную посчитать может кто угодно, и такая функция пишется поистине в одну строку:

Но разумеется нам хочется аналитическую производную. Так как у нас уже есть дерево выражений, мы можем рекурсивно заменить каждый узел в соответствии с правилом дифференциирования. Работать оно должно примерно так:

Вот, к примеру, как реализованна сумма в моем коде:

А вот произведение

А вот сам по себе обход:

Это метод Entity. И как видим, что у листа всего два состояния — либо это переменная, по которой мы дифференциируем, тогда ее производная равна 1, либо это константа (число либо VariableEntity), тогда ее производная 0, либо узел, тогда идет отсылка по имени (InvokeDerive обращается к словарю функций, где и находится нужная (например сумма или синус)).

Заметьте, я здесь не оставляю что-то типа dy/dx и сразу говорю, что производная от переменной не по которой мы дифференциируем равна 0. А вот здесь сделано по-другому.

Все дифференциирование описано в одном файле, а больше и не надо.

Упрощение выражения. Паттерны

Упрощение выражения в общем случае в принципе нетривиально. Ну например, какое выражение проще: или ? Но мы придерживаемся каких-то представлений, и на основе них хотим сделать те правила, которые точно упрощают выражение.

Можно при каждом Eval писать, что если у нас сумма, а дети — произведения, то переберем четыре варианта, и если где-то что-то равно, вынесем множитель… Но так делать конечно же не хочется. Поэтому можно догадаться до системы правил и паттернов. Итак, что мы хотим? Примерно такой синтаксис:

Вот пример дерева, в котором нашлось поддерево (обведено в зеленый), отвечающее паттерну any1 + const1 * any1 (найденное any1 обведено в оранжевый).

Как видим, иногда нам важно, что одна и та же сущность должна повторяться, например чтобы сократить выражение x + a * x нам необходимо, чтобы и там и там был x, ведь x + a * y уже не сокращается. Поэтому нам нужно сделать алгоритм, который не только проверяет, что дерево соответсвует паттерну, но и

А в tree.PaternMakeMatch мы рекурсивно наполняем словарь ключами и их значениями. Вот пример списка самих паттерных Entity:

Когда мы будем писать any1 * const1 — func1 и так далее, у каждой ноды будет номер — это и есть ключ. Иначе говоря, при заполнении словаря, ключами выступят как раз эти номера: 100, 101, 200, 201, 400… А при постройке дерева мы будем смотреть на значение, соответствующее ключу, и подставлять его.

Упрощение. Сортировка дерева

Паттерны не работают?

Вообще, то, что мы сделали до этого, паттерны — чудовищно замечательная штука. Она позволит вам сокращать и разность квадратов, и сумму квадрата синуса и косинуса, и другие сложные штуки. Но элементарную пальму, ((((x + 1) + 1) + 1) + 1), она не сократит, ведь здесь главное правило — коммутативность слагаемых. Поэтому первый шаг — вычленить «линейных детей».

«Линейные дети»

Собственно для каждой ноды суммы или разности (и, кстати, произведения/деления) мы хотим получить список слагаемых (множителей).

Это в принципе несложно. Пусть функция LinearChildren(Entity node) возвращает список, тогда мы смотрим на child in node.Children: если child — это не сумма, то result.Add(child), иначе — result.AddRange(LinearChildren(child)).

Не самым красивым образом реализовано тут.

Группировка детей

Итак, у нас есть список детей, но что дальше? Допустим, у нас есть sin(x) + x + y + sin(x) + 2 * x. Очевидно, что наш алгоритм получит пять слагаемых. Далее мы хотим сгруппировать по похожести, например, x похож на 2 * x больше, чем на sin(x).

Вот хорошая группировка:

Так как в ней паттерны дальше справятся с преобразованием 2*x + x в 3*x.

То есть мы сначала группируем по некоторому хешу, а затем делаем MultiHang — преобразование n-арного суммирования в бираное.

Хеш узла

С одной стороны, и следует поместить в одну группу. С другой стороны, при наличии помещать в одну группу с бессмысленно.

Поэтому мы реализовываем многоуровневую сортировку. Сначала мы делаем вид, что — одно и то же. Посортировали, успокоились. Потом делаем вид, что можно помещать только с другими . И вот уже наши и наконец объединились. Реализовано достаточно просто:

Как видим, функция по-любому влияет на сортировку (разумеется, ведь с вообще никак в общем случае не связана). Как и переменная, с ну никак не получится смешать. А вот константы и операторы учитываются не на всех уровнях. В таком порядке идет сам процесс упрощения

«Компиляция» функций

В кавычках — так как не в сам IL код, а лишь в очень быстрый набор инструкций. Но зато очень просто.

Проблема Substitute

Чтобы посчитать значение функции, нам достаточно вызвать подстановку переменной и eval, например

Но это работает медленно, около 1.5 микросекунды на синус.

Инструкции

Чтобы ускорить вычисление, мы делаем вычисление функции на стеке, а именно:

1) Придумываем класс FastExpression, у которого будет список инструкций

2) При компиляции инструкции складываются в стек в обратном порядке, то есть если есть функция x * x + sin(x) + 3, то инструкции будут примерно такими:

Далее при вызове мы прогоняем эти инструкции и возвращаем Number.

Пример выполнения инструкции суммы:

Вызов синуса сократился с 1500нс до 60нс (системный Complex.Sin работает за 30нс).
В репе реализовано тут.

Фух, вроде бы пока все. Хотя рассказать еще есть о чем, но мне кажется объем для одной статьи достаточный. Интересно ли кому-нибудь продолжение? А именно: парсинг из строки, форматирование в латех, определенный интеграл, и прочие плюшки.

Ссылка на репозиторий со всем кодом, а также тестами и самплами.

Источник