Средства и методы разработки

Нет два раза. Если подразумевается, что посчитать какую-то дискретную функцию в целых числах проще -- тоже часто нет. Потому, что float не 32-битный и может быть ручным хорошо оптимизированным ассемблерным кодом в libc. MBedder имел ввиду, что корень мол посчитать просто кордиком -- это да. Или арктангенс. Чего-там, всего 32 итерации. На 32-битных CPU float действительно может уступать. На 8-битниках отдельная история. Во-первых собственно разрядность. float короче и из-за этого считается быстрей. У меня был практический опыт, когда вначале писался оптимизированный целочисленный код, а потом на PIC18 то же самое, без всяких извращений, с float заработало в разы быстрей. Ибо 16 бит (16 плюс 8 на порядок) вместо 32 в большинстве операций, и повторюсь, у hitech для STD версии компилятора хорошая libc в части float (по крайней мере быстрая). А 8-битники с 32-битными числами очень медленно ворочаются. Во-вторых не надо забывать, что нет 64-бит (long long) и уже перемножение (возведение в квадрат) вызывает переполнение. И не смотря на то, что мол кордиком легко считается, то просто диапазон представляемых значений достаточно узок, чтоб трудно было работать изначально 12-битными данными, например. Работать можно, но погрешности будут приличные (большой вес младшего бита), либо переполнение, либо придётся вручную придумывать переменную порядка величины -- оно того не стоит, библиотечный float часто работает лучше. При наличии 32-битного CPU (vs 8 бит) и long long жизнь конечно веселее. Но там и объёмы FLASH, и скорость работы такие, что задумываться о "страшно жирном float" смысла нет. Зато есть смысл задуматься о том, что самодельные математические функции чреваты хорошо подложенными граблями в ряде узких случаев. А у вас нет, наверняка, хороших тестов для ваших функций. Библиотечные будут лучше. Хотя, конечно, зависит от библиотеки и компилятора. Многие коммерческие обычно внутри жуткое говно, позитивно выделяется только KEIL из моей памяти. Hitech-C тоже... арифметика с float там действительно быстрая но реализация некоторых функций через разложение в ряды ужасает (при сравнении с бытовым калькулятором впечатление, что "считает с ошибками"), при том, что действительно вручную легко написать целочисленный CORDIC вариант работающей быстрей и точней. Ещё нечисла, про их реализацию часто забывают (а в целочисленном варианте вообще без вариантов, необходимо вручную писать проверки для всех граничных случаев). Вроде как сам себя опроверг, часто в целых числах не так уж и плохо как с некачественной libc.