Доброго всем времени суток!

Есть таблица элементов (скажем частот), в котором каждое последующее значение отличается от предыдущего на 1%, например:

и есть текущее значение частоты, например 10354.

Нужно частотам (как бы это по русски выразиться ) присвоить "индексы", например: если текущее значение лежит в диапазоне от 10000 до 10099 - то индекс = 0, при текущем значении в диапазоне от 10100 до 10200 - индекс = 1, при значении = 10477 индекс = 4 и т.д.
Самое тривиальное что приходит в голову - это проход по всей таблице и банальное сравнение, но этот вариант не подходит - слишком много времени тратится. Можно ли нахождение индекса представить в виде формулы?

Прошу прощения если вопрос не в тему и не по адресу.

100.5 * log(x/10000)

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

Внимание вопрос, простое сравнение значит долго будет вычисляться, а логарифм при помощи рядов и деление быстро.
Автору полагаю лучше использовать деление и вычитание. Самая дорогая операция деление на 100.
10723 - 10000 = 723 /100 = 7
Если в микроконтроллере здесь быстрая процедура деления на 10 http://forum.easyelectronics.ru/viewtopic....f=4&t=13470

Сообщение отредактировал twix - Apr 4 2018, 14:52

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

это будет работать если только в таблице меньше 15 частот, дальше будут ошибки.
вычисление логарифма не такое и медленное, несколько десятков тактов.

Вы правы) Поторопился я немного с выводом.

Ну да, но зато вы можете применить быстрые вычисления логарифмов, и решить вопрос с минимальными потерями.

Сообщение отредактировал twix - Apr 4 2018, 18:02

забыли про метод половинного деления ( или как правильно называется ? )

Та нее, все "под контролем" : _pv, бинарный поиск

Я бы тоже бинарным поиском искал и не парился.
Ведь значения в массиве отсортированы уже по условию задачи.

ну не хранить же весь массив в памяти для этого, а вместо того чтобы на каждом шаге поиска считать 1.01^N, один раз вычислить логарифм будет куда быстрее.