Ну, вам проще, значит :)
В Москве 4 рубля с газовой, 2.8 — с электрической. В Подмосковье, по-моему, еще выше цены бывают. Родители мои, кажется, больше платят, чем 4 рубля :(
Посмотрите Gauss. Они тоже очень хорошо светят и в Интернет-магазинах сопоставимы по цене с энергосберегающими.
4 Вт за 320 рублей можно найти.
Тоже наша компания разрабатывает. изготовление, как и у Навигаторов, в Китае.
Сравнение только с точки зрения экономической эффективности на самом деле некорректно.
Есть еще такие вещи как цветопередача и комфортность освещения.
Наиболее приятными глазу остаются лампы накаливания. Для хорошей светоотдачи лучше брать галогенные — будет дороже (50-150 рублей вместо 10), но заметно ярче. При хорошем освещении лампами накаливания глаза устают меньше всего.
Самые ужасные — люминесцентные. При чтении сильно устают глаза, цветопередача ужасна даже у дорогих ламп с заявленной температурой 2700К.
Промежуточный вариант — светодиодные лампы. С их использованием можно добиться более яркого света, чем с лампами накаливания, и если брать хорошие (дорогие, да) лампы, то «теплый белый» свет — очень даже комфортный и глаз не режет.
По моему мнению, не заморачиваясь со ввозом ламп из-за границы, светодиодки стоит использовать только в точечном освещении (GU10, GU5.3 и т.п.), где можно поставить большое количество точек и добиться равномерного яркого света. В Е27 то, что доступно у нас или в Китае, я бы ставить не стал. Хорошие лампы Е27 делают только известные производители, а у нас они почему-то продаются по абсолютно конским ценам. В тех же США хорошие Филлипсовские LED-лампы почему-то стоят в два-три раза дешевле, чем у нас Китай.
По поводу экономической эффективности могу привести расчет для своей квартиры.
Сейчас у меня в сумме (кухня, холл, санузел, коридор) 26 точечных диодных светильников по 4 Вт (Gauss, Navigator), которые можно заменить галогенками по 50 Вт или энергосберегающими лампами по 9 Вт.
Допустим, в день горит 15 светильников в течение 4 часов, т.е. 2190 часов освещения (15 шт. * 4 ч * 365 дней)
Расход энергии:
а) диодные лампы 87.6 кВт*ч.
б) энергосберегающие 197.1 кВт*ч.
в) галогенные 1095 кВт*ч.
Стоимость для квартир с электроплитой (2.81 р/кВт*ч) составит: 246, 554 и 3076 рублей соответственно.
Для квартир с газопроводом (4.01 р/кВт*ч) стоимость составит: 351, 790 и 4390 рублей.
Стоимость ламп (возьму лампы одного производителя Gauss под разъем GU5.3 или GU10) по средней цене в интернет-магазинах:
диодные 350 рублей (50000 ч), энергосберегающие 190 рублей (8000 ч), галогенные 60 рублей (1500 ч).
26 точек обойдутся в 9100, 4940 и 1560 рублей соответственно.
При таком раскладе замена галогенных на диодные лампы окупается за пару лет.
На первый взгляд люминесцентные выгоднее, т.к. окупаются уже за год, но я бы не назвал их эталоном надежности и уж тем более комфорта. А если еще допустить, что диодные лампы на самом деле служат хотя бы в два раза дольше люминесцентных, то лидеры по экономичности уже они, причем опережают люминесцентные меньше, чем за 4 года.
Насчет проводки: по-моему, если есть проблемы и напряжение нестабильное, то лучше ставить стабилизатор или оставаться на лампах накаливания. Дешевле выйдет.
Посмотрите на диодные лампы Gauss — у них появились диммируемые лампы, доступны различные цоколи, по-моему, даже Е27 есть.
То есть можно ставить самый обыкновенный диммер для управления яркостью диодной лампы.
Минус один — пока нет вариантов со встроенным рассеивателем, то есть диоды будет видно. Если хочется смотреть на лампу, лучше ставить плафон.
По спектру у светодиодок все более-менее в порядке, он ровный, с одним пиком в «голубой» части спектра. На дорогих лампах (некитайских, да) этот пик часто убирают светофильтрами.
Рюкзак, особенно, объемистый, могут заставить сдать.
Лучше заранее узнавать особенности авиакомпаний. К сожалению иногда получается это сделать только путем экспериментов.
Летел из Пекина в Москву через Амстердам, в Китае рюкзак (такой же примерно) пропустили, в Амстердаме заставили сдать.
Эффективнее иметь небольшой чемоданчик с вещами/ботинками + рюкзак или сумку с техникой и ценностями, чем пихать все в рюкзак.
Передвижение совсем налегке, кстати, может вызывать подозрения, что приводит к задержкам на таможне.
В СШП негр-таможенник примотался, когда я с одной ноутбучной сумкой и парой футболок/трусов/носков на две недели туда прилетел. :)
Не диспетчеризация, а объединение данных и методов для работы с ними. Это все-таки разные вещи. В ООП методы, необходимые для работы с типом, включаются в его интерфейсы, т.е. объединяются с данными.
В других подходах (при «диспетчеризации») каждый «диспетчер» при добавлении новых типов придется править.
В процедурном подходе для выгула надо реализовать функцию, которая на вход принимает тип животного. Функция должна содержать диспетчер (в Си switch — case), который выбирает правильный метод выгула (вызовом функции или кодом — не суть важно).
В ООП метод выгула содержится в самом типе животного. В виде интерфейса, который в частности может быть указателем на правильную функцию, например, как это сделано Вами в коде на Си.
Соответственно, в ООП при расширении списка животных надо добавить тип и правильно реализовать его интерфейсы.
В процедурном программировании надо править все процедуры, которые должны работать с этим животным.
При большом количестве методов и расширяемом списке типов первый подход оказывается удобнее. В более-менее стационарном коде удобным может оказаться второй подход.
Я нигде не упоминал диспетчеризацию по типам, кстати, — это уже Ваше понимание. Привязка данных и методов для работы с ними подразумевала их объединение в единое целое — объект. Не надо придираться к словам, а то это на троллинг смахивает.
В отпуск уезжаю, поэтому, чтобы подытожить то, что я говорил (и не говорил :))
1) ООП подразумевает объединение данных и методов для работы с ними и оформление в виде единого целого — объекта.
2) приемы, внесенные в ООП, могли появиться до выделения его в отдельную парадигму, но именно с оформлением парадигмы ООП и появлением языков, предоставляющих удобные средства реализации этой парадигмы, ООП получило распространение и популярность.
3) использование ООП-языка не гарантирует наличия парадигмы ООП.
4) парадигма ООП может применяться в не ООП языках.
5) наличие всех формальных «признаков ООП» — не обязательно для следования парадигме ООП.
Мне кажется, Вы уже должны были понять, о чем я говорю. Вы слишком формально относитесь к признакам и пытаетесь поставить знак равенства между ООП парадигмой и ООП языком. Это неправильно.
В любом случае, как говорил мой преподаватель по ТОЭ, я кончил (с)
Все-таки Вы где-то путаете теплое с мягким.
Как бы ни использовалась привязка к данным до появления парадигмы ООП, именно с ее формализацией стиль проектирования и разработки с объединением данных и операций над ними получил отдельное наименование, и следование этому стилю многие считают хорошим тоном.
На самом деле всему свое место. Думать надо в любом случае, и одна лишь парадигма ООП панацеей не является.
По поводу «задачи». Я не предлагал ТЗ, а задал простой вопрос: как без использования ООП подхода реализовать выгул любого животного?
В ООП каждый новый вид животных (тип объектов) будет иметь конкретную реализацию функции выгула.
В процедурном стиле заводится одна функция выгула, которая «знает», как выгуливать каждый из известных видов животных и, возможно, умеет выполнять некий выгул по умолчанию. Функцию переделывать придется, если при введении нового вида животного метод его выгула отличен от метода выгула по умолчанию.
Я, если что, именно про процедурную парадигму, а не про Ваш ООП-код на процедурном языке.
Вы не поняли!
Вопрос был не о языках, а о парадигмах. Вы слишком привязываетесь к языку и смешиваете язык и парадигму в своих рассуждениях.
Я продолжаю утверждать, что использование ООП-языка не гарантирует наличия ООП парадигмы. И использование ООП-парадигмы возможно вне языков, считающихся ООП-языками.
Мой же вопрос был о том, как в процедурной парадигме реализовать привязку данных и действий с ними. Вы привели некорректный с точки зрения процедурного подхода ответ. :)
В процедурном подходе надо завести функцию «гулять», в которую передается тип животного и для каждого животного заводить метод выгула. Причем придется переделывать функцию каждый раз, когда список «поддерживаемых животных» расширяется.
В ООП-парадигме для добавления нового животного Вам достаточно завести новый тип, наследующий интерфейс «животное» и правильно определить методы интерфейса.
Вы своим примером показываете, что средства Си позволяют разработать ООП-программу.
Я, собственно, только «за».
Показательные примеры в огромном количестве на сайте Khronos Group. Практически все SDK (OpenGL, OpenCL, etc.) — реализуют парадигму ООП. Средствами Си.
Без разницы, что там идет первым параметром. В С++ можно считать, что всегда есть параметр this, который передается неявно.
Речь о том, что это уже не процедурное проектирование.
Как только вы начинаете рассматривать данные в совокупности с действиями над ними, вы начинаете мыслить категориями объектов.
А средства, предоставляемые языком, в данном случае вторичны.
А это уже не процедурный подход. ;)
На Си, как я уже сказал, можно применять парадигму ООП, что Вы и продемонстрировали.
В процедурном подходе «мухи — отдельно, котлеты — отдельно».
Автор, мне кажется, Вы слишком формально привязались к «признакам ООП».
По большому счету, если не привязываться к формализму, ООП-подход возможен и активно применяется даже в старом добром Си.
С другой стороны даже в Java можно программировать «процедурно», если записать все в одном огромном классе.
Вопрос применения ООП — не в использовании «признаков ООП» в своей программе, а в методах проектирования и построения кода.
ООП — это в первую очередь манипуляция совокупностью данных как целым (объектом). Причем, совокупность данных для правильного доступа к ним и управления ими должна предоставлять набор методов (интерфейс), возможно, не один.
Необходимость наличия полиморфизма, абстракции, инкапсуляции, наследования как непременных свойств ООП языка вдалбливается для упрощения понимания ООП начинающими. Мне кажется, подобный формализм только путает и приводит к заблуждению, что само использование, например, Java делает код следующим парадигме ООП. В реальности парадигма ООП не требует обязательного наличия ВСЕХ перечисленных свойств, больше того, только наличие этих свойств не делает программу основанной на ООП («раздутые классы», getters/setters, раскрывающие структуру объекта, и т.п.).
Я, кстати, предпочитаю в первую очередь продумывать интерфейсы (абстрактные) и взаимодействие объектов, а потом уже думаю, объекты с какими свойствами мне нужны для реализации интерфейсов. Объекты могут предоставлять несколько интерфейсов — каждый, выполняющий определенную функциональность. Первичным все равно остается интерфейс.
В отличие от процедурного подхода интерфейс привязан к данным, с которыми он работает.
В отличие от функционального подхода поведение интерфейса зависит от текущего состояния объекта.
В отличие от модульного подхода интерфейсы являются свойствами объектов и могут выноситься в различные модули. Или же один модуль может включать несколько объектов с различными интерфейсами.
Если посмотреть на Ваш пример с объектом «собака», то она предоставляет интерфейсные методы «выгулять» и «накормить», которые могут, например, принимать место прогулки и вид пищи в качестве параметров. А какой собака породы, возраста и здоровья — внутренние свойства объекта, которые могут использоваться для реализации интерфейсов и возврата ошибки, если, например, объект типа «той-терьер» с интерфейсом «собака» отправить по болотам бегать.
При этом для реализации интерфейса «собака» с методами «выгулять» и «накормить» такие свойства как «окрас» и «кличка» не нужны, хотя в санитарной книжке они есть.
Если совсем уж абстрагироваться от конкретного объекта, можно объявить интерфейс «домашнее животное» с теми же методами (выгулять, накормить) и тогда с одним и тем же интерфейсом будут совместимы «кошки», «куры» и «коровы». Только вот реализация будет зависеть от конкретного объекта.
Расскажете, как в процедурном или функциональном подходе создать обобщенный «выгуливающий» метод для «домашних животных»?
Это, видимо, из FPGA?
На «обычных» процессорах разрядности максимум в 16 раз сейчас отличаются (128 bit vs. 8 bit)
Если по сути вопроса, то есть уточняющий вопрос:
в Вашем FPGA вычислитель любой разрядностью оперирует или есть ограничения?
Т.е. он может перемножить числа максимальной требуемой разрядности и полностью сохранить результат в регистре?
Если да, то хитростей никаких нет.
в моей/матлабовской нотации запись выглядит так:
QN1.M1 x QN2.M2 = Q(N1 + N2).(M1 + M2), то есть имеем число с (N1 + N2) значащих бит с (M1 + M2) бит на дробную часть числа. Дальше следует округлить результат до желаемой точности.
Постараюсь уместить во вторую часть статьи вариант для перемножения чисел, которые не влезают в регистр.
ЗЫ. На подготовку и вычитку текста у меня немало времени уходит, поэтому второй части пока нет.
1) Извините, нажал «Написать», не дописав ответ, когда ребенок проснулся/заплакал.
По оставшимся моментам:
q12.4 — ошибка, сейчас поправлю. С учетом знака правильно q11.4.
Со знаком, кстати, вообще путаница может возникнуть — приведенные мной нотации не предусматривают беззнаковых чисел.
2) Насчет «показателя степени» — достаточно часто встречается выражение «экспоненциальная запись числа» или «запись числа с экспонентой». Поэтому, не думаю, что прямо путаница возникнет, но на всякий случай внесу Ваше замечание в статью.
Ну, я сразу извинился за «фиксированную точку» :)
По-русски, наверное, правильнее в обоих случаях «запятая» — у нас именно запятая разделяет целую и дробную части десятичных дробей.
Ну, мне сложно судить, насколько сложный у Вас алгоритм был реализован, но раз работало на 8МГц PIC16, то, видимо, не очень.
Я в свое время Герцелем где-то по 10-и полосам мощность 8кГц звукового сигнала в плавающей точке считал, 200МГц ARMv5E не хватало.
В Москве 4 рубля с газовой, 2.8 — с электрической. В Подмосковье, по-моему, еще выше цены бывают. Родители мои, кажется, больше платят, чем 4 рубля :(
4 Вт за 320 рублей можно найти.
Тоже наша компания разрабатывает. изготовление, как и у Навигаторов, в Китае.
Есть еще такие вещи как цветопередача и комфортность освещения.
Наиболее приятными глазу остаются лампы накаливания. Для хорошей светоотдачи лучше брать галогенные — будет дороже (50-150 рублей вместо 10), но заметно ярче. При хорошем освещении лампами накаливания глаза устают меньше всего.
Самые ужасные — люминесцентные. При чтении сильно устают глаза, цветопередача ужасна даже у дорогих ламп с заявленной температурой 2700К.
Промежуточный вариант — светодиодные лампы. С их использованием можно добиться более яркого света, чем с лампами накаливания, и если брать хорошие (дорогие, да) лампы, то «теплый белый» свет — очень даже комфортный и глаз не режет.
По моему мнению, не заморачиваясь со ввозом ламп из-за границы, светодиодки стоит использовать только в точечном освещении (GU10, GU5.3 и т.п.), где можно поставить большое количество точек и добиться равномерного яркого света. В Е27 то, что доступно у нас или в Китае, я бы ставить не стал. Хорошие лампы Е27 делают только известные производители, а у нас они почему-то продаются по абсолютно конским ценам. В тех же США хорошие Филлипсовские LED-лампы почему-то стоят в два-три раза дешевле, чем у нас Китай.
По поводу экономической эффективности могу привести расчет для своей квартиры.
Сейчас у меня в сумме (кухня, холл, санузел, коридор) 26 точечных диодных светильников по 4 Вт (Gauss, Navigator), которые можно заменить галогенками по 50 Вт или энергосберегающими лампами по 9 Вт.
Допустим, в день горит 15 светильников в течение 4 часов, т.е. 2190 часов освещения (15 шт. * 4 ч * 365 дней)
Расход энергии:
а) диодные лампы 87.6 кВт*ч.
б) энергосберегающие 197.1 кВт*ч.
в) галогенные 1095 кВт*ч.
Стоимость для квартир с электроплитой (2.81 р/кВт*ч) составит: 246, 554 и 3076 рублей соответственно.
Для квартир с газопроводом (4.01 р/кВт*ч) стоимость составит: 351, 790 и 4390 рублей.
Стоимость ламп (возьму лампы одного производителя Gauss под разъем GU5.3 или GU10) по средней цене в интернет-магазинах:
диодные 350 рублей (50000 ч), энергосберегающие 190 рублей (8000 ч), галогенные 60 рублей (1500 ч).
26 точек обойдутся в 9100, 4940 и 1560 рублей соответственно.
При таком раскладе замена галогенных на диодные лампы окупается за пару лет.
На первый взгляд люминесцентные выгоднее, т.к. окупаются уже за год, но я бы не назвал их эталоном надежности и уж тем более комфорта. А если еще допустить, что диодные лампы на самом деле служат хотя бы в два раза дольше люминесцентных, то лидеры по экономичности уже они, причем опережают люминесцентные меньше, чем за 4 года.
Насчет проводки: по-моему, если есть проблемы и напряжение нестабильное, то лучше ставить стабилизатор или оставаться на лампах накаливания. Дешевле выйдет.
То есть можно ставить самый обыкновенный диммер для управления яркостью диодной лампы.
Минус один — пока нет вариантов со встроенным рассеивателем, то есть диоды будет видно. Если хочется смотреть на лампу, лучше ставить плафон.
Лучше заранее узнавать особенности авиакомпаний. К сожалению иногда получается это сделать только путем экспериментов.
Летел из Пекина в Москву через Амстердам, в Китае рюкзак (такой же примерно) пропустили, в Амстердаме заставили сдать.
Эффективнее иметь небольшой чемоданчик с вещами/ботинками + рюкзак или сумку с техникой и ценностями, чем пихать все в рюкзак.
Передвижение совсем налегке, кстати, может вызывать подозрения, что приводит к задержкам на таможне.
В СШП негр-таможенник примотался, когда я с одной ноутбучной сумкой и парой футболок/трусов/носков на две недели туда прилетел. :)
Оперативно принятое решение.
МС как раз гайки закручивает, чтобы улучшить секьюрность.
В других подходах (при «диспетчеризации») каждый «диспетчер» при добавлении новых типов придется править.
В процедурном подходе для выгула надо реализовать функцию, которая на вход принимает тип животного. Функция должна содержать диспетчер (в Си switch — case), который выбирает правильный метод выгула (вызовом функции или кодом — не суть важно).
В ООП метод выгула содержится в самом типе животного. В виде интерфейса, который в частности может быть указателем на правильную функцию, например, как это сделано Вами в коде на Си.
Соответственно, в ООП при расширении списка животных надо добавить тип и правильно реализовать его интерфейсы.
В процедурном программировании надо править все процедуры, которые должны работать с этим животным.
При большом количестве методов и расширяемом списке типов первый подход оказывается удобнее. В более-менее стационарном коде удобным может оказаться второй подход.
Я нигде не упоминал диспетчеризацию по типам, кстати, — это уже Ваше понимание. Привязка данных и методов для работы с ними подразумевала их объединение в единое целое — объект. Не надо придираться к словам, а то это на троллинг смахивает.
В отпуск уезжаю, поэтому, чтобы подытожить то, что я говорил (и не говорил :))
1) ООП подразумевает объединение данных и методов для работы с ними и оформление в виде единого целого — объекта.
2) приемы, внесенные в ООП, могли появиться до выделения его в отдельную парадигму, но именно с оформлением парадигмы ООП и появлением языков, предоставляющих удобные средства реализации этой парадигмы, ООП получило распространение и популярность.
3) использование ООП-языка не гарантирует наличия парадигмы ООП.
4) парадигма ООП может применяться в не ООП языках.
5) наличие всех формальных «признаков ООП» — не обязательно для следования парадигме ООП.
Мне кажется, Вы уже должны были понять, о чем я говорю. Вы слишком формально относитесь к признакам и пытаетесь поставить знак равенства между ООП парадигмой и ООП языком. Это неправильно.
В любом случае, как говорил мой преподаватель по ТОЭ, я кончил (с)
Как бы ни использовалась привязка к данным до появления парадигмы ООП, именно с ее формализацией стиль проектирования и разработки с объединением данных и операций над ними получил отдельное наименование, и следование этому стилю многие считают хорошим тоном.
На самом деле всему свое место. Думать надо в любом случае, и одна лишь парадигма ООП панацеей не является.
По поводу «задачи». Я не предлагал ТЗ, а задал простой вопрос: как без использования ООП подхода реализовать выгул любого животного?
В ООП каждый новый вид животных (тип объектов) будет иметь конкретную реализацию функции выгула.
В процедурном стиле заводится одна функция выгула, которая «знает», как выгуливать каждый из известных видов животных и, возможно, умеет выполнять некий выгул по умолчанию. Функцию переделывать придется, если при введении нового вида животного метод его выгула отличен от метода выгула по умолчанию.
Я, если что, именно про процедурную парадигму, а не про Ваш ООП-код на процедурном языке.
Вопрос был не о языках, а о парадигмах. Вы слишком привязываетесь к языку и смешиваете язык и парадигму в своих рассуждениях.
Я продолжаю утверждать, что использование ООП-языка не гарантирует наличия ООП парадигмы. И использование ООП-парадигмы возможно вне языков, считающихся ООП-языками.
Мой же вопрос был о том, как в процедурной парадигме реализовать привязку данных и действий с ними. Вы привели некорректный с точки зрения процедурного подхода ответ. :)
В процедурном подходе надо завести функцию «гулять», в которую передается тип животного и для каждого животного заводить метод выгула. Причем придется переделывать функцию каждый раз, когда список «поддерживаемых животных» расширяется.
В ООП-парадигме для добавления нового животного Вам достаточно завести новый тип, наследующий интерфейс «животное» и правильно определить методы интерфейса.
Вы своим примером показываете, что средства Си позволяют разработать ООП-программу.
Я, собственно, только «за».
Показательные примеры в огромном количестве на сайте Khronos Group. Практически все SDK (OpenGL, OpenCL, etc.) — реализуют парадигму ООП. Средствами Си.
Но можно, как показывают библиотеки OpenMAX AL, OpenCL, OpenGL, которые написаны на Си, но используют парадигму ООП.
Речь о том, что это уже не процедурное проектирование.
Как только вы начинаете рассматривать данные в совокупности с действиями над ними, вы начинаете мыслить категориями объектов.
А средства, предоставляемые языком, в данном случае вторичны.
На Си, как я уже сказал, можно применять парадигму ООП, что Вы и продемонстрировали.
В процедурном подходе «мухи — отдельно, котлеты — отдельно».
По большому счету, если не привязываться к формализму, ООП-подход возможен и активно применяется даже в старом добром Си.
С другой стороны даже в Java можно программировать «процедурно», если записать все в одном огромном классе.
Вопрос применения ООП — не в использовании «признаков ООП» в своей программе, а в методах проектирования и построения кода.
ООП — это в первую очередь манипуляция совокупностью данных как целым (объектом). Причем, совокупность данных для правильного доступа к ним и управления ими должна предоставлять набор методов (интерфейс), возможно, не один.
Необходимость наличия полиморфизма, абстракции, инкапсуляции, наследования как непременных свойств ООП языка вдалбливается для упрощения понимания ООП начинающими. Мне кажется, подобный формализм только путает и приводит к заблуждению, что само использование, например, Java делает код следующим парадигме ООП. В реальности парадигма ООП не требует обязательного наличия ВСЕХ перечисленных свойств, больше того, только наличие этих свойств не делает программу основанной на ООП («раздутые классы», getters/setters, раскрывающие структуру объекта, и т.п.).
Я, кстати, предпочитаю в первую очередь продумывать интерфейсы (абстрактные) и взаимодействие объектов, а потом уже думаю, объекты с какими свойствами мне нужны для реализации интерфейсов. Объекты могут предоставлять несколько интерфейсов — каждый, выполняющий определенную функциональность. Первичным все равно остается интерфейс.
В отличие от процедурного подхода интерфейс привязан к данным, с которыми он работает.
В отличие от функционального подхода поведение интерфейса зависит от текущего состояния объекта.
В отличие от модульного подхода интерфейсы являются свойствами объектов и могут выноситься в различные модули. Или же один модуль может включать несколько объектов с различными интерфейсами.
Если посмотреть на Ваш пример с объектом «собака», то она предоставляет интерфейсные методы «выгулять» и «накормить», которые могут, например, принимать место прогулки и вид пищи в качестве параметров. А какой собака породы, возраста и здоровья — внутренние свойства объекта, которые могут использоваться для реализации интерфейсов и возврата ошибки, если, например, объект типа «той-терьер» с интерфейсом «собака» отправить по болотам бегать.
При этом для реализации интерфейса «собака» с методами «выгулять» и «накормить» такие свойства как «окрас» и «кличка» не нужны, хотя в санитарной книжке они есть.
Если совсем уж абстрагироваться от конкретного объекта, можно объявить интерфейс «домашнее животное» с теми же методами (выгулять, накормить) и тогда с одним и тем же интерфейсом будут совместимы «кошки», «куры» и «коровы». Только вот реализация будет зависеть от конкретного объекта.
Расскажете, как в процедурном или функциональном подходе создать обобщенный «выгуливающий» метод для «домашних животных»?
На «обычных» процессорах разрядности максимум в 16 раз сейчас отличаются (128 bit vs. 8 bit)
Если по сути вопроса, то есть уточняющий вопрос:
в Вашем FPGA вычислитель любой разрядностью оперирует или есть ограничения?
Т.е. он может перемножить числа максимальной требуемой разрядности и полностью сохранить результат в регистре?
Если да, то хитростей никаких нет.
в моей/матлабовской нотации запись выглядит так:
QN1.M1 x QN2.M2 = Q(N1 + N2).(M1 + M2), то есть имеем число с (N1 + N2) значащих бит с (M1 + M2) бит на дробную часть числа. Дальше следует округлить результат до желаемой точности.
Постараюсь уместить во вторую часть статьи вариант для перемножения чисел, которые не влезают в регистр.
ЗЫ. На подготовку и вычитку текста у меня немало времени уходит, поэтому второй части пока нет.
Запись короче. И так слов больше, чем кода/формул :)
По оставшимся моментам:
q12.4 — ошибка, сейчас поправлю. С учетом знака правильно q11.4.
Со знаком, кстати, вообще путаница может возникнуть — приведенные мной нотации не предусматривают беззнаковых чисел.
2) Насчет «показателя степени» — достаточно часто встречается выражение «экспоненциальная запись числа» или «запись числа с экспонентой». Поэтому, не думаю, что прямо путаница возникнет, но на всякий случай внесу Ваше замечание в статью.
По-русски, наверное, правильнее в обоих случаях «запятая» — у нас именно запятая разделяет целую и дробную части десятичных дробей.
Я в свое время Герцелем где-то по 10-и полосам мощность 8кГц звукового сигнала в плавающей точке считал, 200МГц ARMv5E не хватало.