Техникум: Распознавание Вещественного Числа из Строчки

Непонятно, почему scanf или подобные функции работают медленнее. Автор точно сравнивал с широко используемыми вариантами? Кстати, я бы вообще начал с того, что нашёл исходник какой-то известной функции, делающей то же самое, если уж нельзя по каким-то причинам использовать стандартную библиотеку.

Не ясно откуда такой оверхед (может это из-за логов, которые вы почему-то оставили?), у меня решение на Rust справляется также быстро и потребляет максимум 2.2mb (0ms 2.1mb, 4ms 2.2mb).

Также, не думаю, что \n и \r - легальные символы. Но они, собственно, в коде и задействуются как условия завершения работы.

Может case '1' ... case '9' стоило поместить в default ветку и сравнить два раза (с '1' и '9' соответственно)?

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

Кому интересно, код на Rust можно посмотреть тут

Почему не sscanf? Железка настолько сурова, что недоступна libc?

оказалось быстрее всех решений на языке программирования Си!

Ну тк в задаче на Leetcode требуется определить валидность/невалидность числа, а не зачитать его в double, то можете выбросить все арифметические операции из вашего решения и получить ещё более быстрое...

(Upd: не обновил комменты перед ответом)

Можно упростить себе задачу: передавать в МК только нормированные целые числа (милливольты вместо вольтов, микроамперы вместо амперов етц) и не закатывать солнце вручную.

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

Я так понимаю что весь вышеописанный гемморой связан именно с этим? Настолько часто надо вводить, что нужно рожать решение, которое быстрее всех что-то делает?

Потом часто надо анализировать текстовые логи с SD-карты. Надо выхватывать вещественные числа из CSV строчек.

наши погромисты настолько суровы, шо не помнят, как пишут текстовые (!) логи на SD карту? Или какая религия запрещает использовать xprintf/xscanf с одним и тем же (ну или почти) форматом?

И что это вообще получается, боремся за быстрее всех распознавание текстовых логов, но при этом безбожно тормозим при записи этих логов в текстовом виде и на SD карту?

Или вообще речь идет о борьбе за наносекунды при анализе логов на компе, где обычно и ядер и памяти до и больше?

И вообще, как минимум по моему опыту, при анализе логов проблема не с засасыванием CSV, а с визуализацией данных для больших логов. Если эксель или LibreOffice еще как-то способны засасывать логи под 100k строк, то с построением графиков в этом случае у них все плохо и как раз тут надо городить свою приблуду на чистом Це/Це++

вариант на Lua

function nkff(S)
z0=string.byte('0'); z9=string.byte('9');
zE=string.byte('E'); zp=string.byte('+');
zm=string.byte('-'); zt=string.byte('.');
len=string.len(S);
for j=1,len do
	m=string.byte(S,j);
	if m>32 then
		if m>=z0 and z9>=m then
			z2=true s1=true;
		else
			m=m&0xdf;
			if s1 then
				if m==zp or m==zm then
					if s1==nil or z1==zE then s1=true; end
				else
					if m==ze and (z1==zp or z1==zm) then  s1=nil; break else s1=true; end
				end
			else
				if m~=ze then s1=true; end
			end
			z1=m;
		end
		z1=m;
	end
end
if z1==ze or z1==zp or z1==zm or z2==nil then s1=nil end
return s1;
end

вариант на C

char nkff(char *ps) {
	char f=0; char z1=0; char s1=0; char z2=0;
	long len=strlen(ps);
	long j=0; while(len>j) { char m=ps[j]; 
	if (m>32){
		if(m>='0' && m<='9'){ s1=1; z2=1;}
		else { 	m=m&0xdf;
			if(s1){
                    if (m=='+' || m=='-') s1=1; 
			        else { if(m=='E' && (z1=='+' ||z1=='-')){ s1=0;break;} else s1=1; }
			} else { if (m!='E') s1=1;}
		}
		z1=m;}
	j++;}
	if (z1=='E' ||z1=='+' || z2==0)s1=0; 
return s1;}