вывод float

Hello, Gena Gutnicky! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 14 Jun 2005 09:25:28

+0000 (UTC):

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

GG> В исходном письме был определен диапазон 0...99.9, исходя из

Об этом уже давно забыто. Высказывались мысли о пагубности использования printf вообще, против чего я и возражал. А для такого случая я вообще не понимаю зачем нужно с float связываться хоть при выводе, хоть вообще.

dima

formatting link

Reply to
Dmitry Orlov
Loading thread data ...

Привет!

Mon Jun 13 2005 22:57, Dmitry Orlov wrote to Alexander Golov:

...

DO>>> Эффективно по какому критерию?

AG>> Пустой траты времени.

DO> А for(;;) {...} - эффективная конструкция?

За отсутствием расшифровки "...", смысла в вопросе не вижу.

DO>>> Я с очень большим трудом могу представить себе использование DO>>> printf для чего-то кроме представления данных человеку ну или DO>>> на крайний случай записи в лог для последующего человеком же DO>>> прочтения.

AG>> А я с очень большим трудом представляю себе прибор AG>> занимающийся лишь представлением данных для человека. В

DO> Да по-фиг чем занимается прибор, на преобразование форматов для вывода DO> человеку времени много не нужно.

Несколько милисекунд на процессоре с 1 МГц циклом. Это время отобранное у других задач и энергия потраченная впустую.

...

AG>> Как я уже писал, использую одну и ту же функцию для AG>> целочисленного и плавающего типа, просто преобразовав плавучку AG>> перед отправкой в целый. Причём во многих случаях

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

В данном случае (см. исходный вопрос) речь идёт о выводе значений со вполне конкретным форматом. Это глубоко за 90% всех случаев вывода на средства отображения приборов (как я заметил, многие тут вообще считают, что во всех случаях можно обойтись совсем без ПЗ).

AG>> масштабирование совмещается с приведением единиц. Почему такой AG>> вариант нагляден для целого и не нагляден для плавающего не

DO> Потому что диапазон значений целых мал и обычно заранее известен. У меня DO> это или байт или в крайнем случае слово. А число с плавающей точкой может DO> перекрывать огромный диапазон.

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

AG>> понимаю (уж во всяком случае когда в программе дай бог с AG>> десяток таких операций вывода):

DO> Да хоть один, какая разница?

Что тогда вообще нагляность уходит на 123-й план.

AG>> Out_Number (( large )( Val_Press * 1.0197162e-2 ), 5, 4 ) ; // Давление AG>> кг/см2

DO> И что сие означает? И чем хуже printf("Давление %3.2f атм."); ?

Тем что работает во много раз медленнее.

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Привет!

Mon Jun 13 2005 10:41, Kirill Frolov wrote to Alexander Golov:

...

AG>> Типичная реализация преобразования в составе printf AG>> содержит серии умножений или делений на каждый выводимый разряд. Может AG>> быть есть более эффективные реализации, но когда мне было нужно я их в AG>> составе библиотек для широкораспространённых МК не обнаружил. Поэтому AG>> использование printf с наибольшей вероятностью будет в несколько раз AG>> менее эффективно.

KF> Видимо ещё и потому, что эффективная реализация на языке C не KF> реализуется...

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

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Hello, Alexander Golov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 14 Jun 2005 18:15:12

+0000 (UTC):

DO>>>> Эффективно по какому критерию?

AG>>> Пустой траты времени.

DO>> А for(;;) {...} - эффективная конструкция?

AG> За отсутствием расшифровки "...", смысла в вопросе не вижу.

Да хоть и вообще ничего.

DO>>>> Я с очень большим трудом могу представить себе DO>>>> использование printf для чего-то кроме представления данных DO>>>> человеку ну или на крайний случай записи в лог для DO>>>> последующего человеком же прочтения.

AG>>> А я с очень большим трудом представляю себе прибор AG>>> занимающийся лишь представлением данных для человека. В

DO>> Да по-фиг чем занимается прибор, на преобразование форматов DO>> для вывода человеку времени много не нужно.

AG> Несколько милисекунд на процессоре с 1 МГц циклом. Это время AG> отобранное у других задач и энергия потраченная впустую.

Это очень часто абсолютно не критично.

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

AG> В данном случае (см. исходный вопрос) речь идёт о выводе AG> значений со вполне конкретным форматом. Это глубоко за 90% AG> всех случаев вывода на средства отображения приборов (как я AG> заметил, многие тут вообще считают, что во всех случаях можно AG> обойтись совсем без ПЗ).

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

AG>>> масштабирование совмещается с приведением единиц. Почему AG>>> такой вариант нагляден для целого и не нагляден для AG>>> плавающего не

DO>> Потому что диапазон значений целых мал и обычно заранее DO>> известен. У меня это или байт или в крайнем случае слово. А DO>> число с плавающей точкой может перекрывать огромный диапазон.

AG> Какая разница, что может перекрывать число в данном формате, AG> если параметр представленный в нём и который нужно отобразить AG> обладает совершенно определёнными областью значений и AG> точностью представления.

Которые далеко не всегда укладываются в разумный диапазон целых чисел.

AG>>> понимаю (уж во всяком случае когда в программе дай бог с AG>>> десяток таких операций вывода):

DO>> Да хоть один, какая разница?

AG> Что тогда вообще нагляность уходит на 123-й план.

Почему собственно?

AG>>> Out_Number (( large )( Val_Press * 1.0197162e-2 ), 5, 4 ) ; AG>>> // Давление кг/см2

DO>> И что сие означает? И чем хуже printf("Давление %3.2f атм."); DO>> ?

AG> Тем что работает во много раз медленнее.

Я уже говорил, что очень часто это не имеет никакого значения.

dima

formatting link

Reply to
Dmitry Orlov

Tue Jun 14 2005 22:21, Alexander Golov wrote to Kirill Frolov:

AG>>> Типичная реализация преобразования в составе printf AG>>> содержит серии умножений или делений на каждый выводимый разряд. Может KF>> Видимо ещё и потому, что эффективная реализация на языке C не KF>> реализуется... AG> Это вовсе не факт, но даже если и так, что мешает написать библиотечную AG> функцию на асме? Hо переписывание на асм тех же алгоритмнов, что AG> используются сейчас совершенно бессмысленно.

Мешает то, что -- а кто будет это делать? Насколько я понимаю, конторы вроде Hitech или IAR, выпускающие компиляторы под десятки контроллеров, не содержат армии программистов для переписывания libc на асме в N-надцатый раз. Имеется одна единственная версия, которая с небольшими изменениями и ассемблерными "базовыми" функциями компилируется на все версии. Разумеется, всё написано на C.

Reply to
Kirill Frolov

Вообще - для вычислений, а при выводе - пожалуй, таки излишне. Хотя, учитывая, что мы уже связались при вычислениях... - ;)

Reply to
Eugene Zhernovoy

Привет!

Wed Jun 15 2005 09:19, Dmitry Orlov wrote to Alexander Golov:

...

DO>>>>> Эффективно по какому критерию?

AG>>>> Пустой траты времени.

DO>>> А for(;;) {...} - эффективная конструкция?

AG>> За отсутствием расшифровки "...", смысла в вопросе не вижу.

DO> Да хоть и вообще ничего.

В таком случае это неэффективная конструкция, если сравнивать со sleep, на худой конец idle.

...

DO>>> Да по-фиг чем занимается прибор, на преобразование форматов DO>>> для вывода человеку времени много не нужно.

AG>> Hесколько милисекунд на процессоре с 1 МГц циклом. Это время AG>> отобранное у других задач и энергия потраченная впустую.

DO> Это очень часто абсолютно не критично.

Случаев когда это критично, или крайне желательно избежать, также немало.

...

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

AG>> В данном случае (см. исходный вопрос) речь идёт о выводе AG>> значений со вполне конкретным форматом. Это глубоко за 90% AG>> всех случаев вывода на средства отображения приборов (как я AG>> заметил, многие тут вообще считают, что во всех случаях можно AG>> обойтись совсем без ПЗ).

DO> В таких случаях обычно можно. Хотя наглядность и простота написания DO> программы может быть иногда достаточным аргументом для того, чтобы DO> пользоваться плавучкой и форматным выводом.

На самом деле далеко не всё можно адекватно решить в целой арифметике, во всяком случае с приемлимыми затратами и без драматической потери наглядности. Но printf в данном случае просто обладает совершенно излишней функциональностью; потребность в выводе значений в экпоненциальной форме или в совершенно неизвестном формате возникает нечасто.

...

AG>> Какая разница, что может перекрывать число в данном формате, AG>> если параметр представленный в нём и который нужно отобразить AG>> обладает совершенно определёнными областью значений и AG>> точностью представления.

DO> Которые далеко не всегда укладываются в разумный диапазон целых чисел.

Если мы говорим от 32-разрядном типе float, т.е. с 24-разрядной мантиссой, то он, естественно, всегда может быть адекватно преобразован в 32-разрядный long. Дополнительные нули справа можно вывести в виде строки, никакой другой полезной информации эти разряды не несут.

AG>>>> понимаю (уж во всяком случае когда в программе дай бог с AG>>>> десяток таких операций вывода):

DO>>> Да хоть один, какая разница?

AG>> Что тогда вообще нагляность уходит на 123-й план.

DO> Почему собственно?

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

...

AG>>>> Out_Number (( large )( Val_Press * 1.0197162e-2 ), 5, 4 ) ; AG>>>> // Давление кг/см2

DO>>> И что сие означает? И чем хуже printf("Давление %3.2f атм."); DO>>> ?

AG>> Тем что работает во много раз медленнее.

DO> Я уже говорил, что очень часто это не имеет никакого значения.

А когда имеет, чем Out_Number хуже printf?

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Привет!

Wed Jun 15 2005 17:41, Kirill Frolov wrote to Alexander Golov:

...

KF>>> Видимо ещё и потому, что эффективная реализация на языке C не KF>>> реализуется...

AG>> Это вовсе не факт, но даже если и так, что мешает написать библиотечную AG>> функцию на асме? Hо переписывание на асм тех же алгоритмнов, что AG>> используются сейчас совершенно бессмысленно.

KF> Мешает то, что -- а кто будет это делать? Hасколько я понимаю, KF> конторы вроде Hitech или IAR, выпускающие компиляторы под десятки KF> контроллеров, не содержат армии программистов для переписывания KF> libc на асме в N-надцатый раз. Имеется одна единственная версия, KF> которая с небольшими изменениями и ассемблерными "базовыми" функциями KF> компилируется на все версии. Разумеется, всё написано на C.

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

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Hello,Dmitry! DO> Об этом уже давно забыто. Высказывались мысли о пагубности использования printf DO> вообще, против чего я и возражал. А для такого случая я вообще не понимаю зачем DO> нужно с float связываться хоть при выводе, хоть вообще.

Вообще-то да. Но а вдруг эти 99.9 получаются путем многостраничного вычисления с экспонентами, логарифмами и гиперболическими тангенсами :-)

WBR G.G

Reply to
Gena Gutnicky

Fri Jun 17 2005 00:47, Alexander Golov wrote to Kirill Frolov:

KF>> Мешает то, что -- а кто будет это делать? Hасколько я понимаю, KF>> конторы вроде Hitech или IAR, выпускающие компиляторы под десятки KF>> контроллеров, не содержат армии программистов для переписывания KF>> libc на асме в N-надцатый раз. Имеется одна единственная версия, KF>> которая с небольшими изменениями и ассемблерными "базовыми" функциями KF>> компилируется на все версии. Разумеется, всё написано на C.

AG> В данном случае это неважно, на что не переписывай тот же вариант вывода AG> %f из printf он заметно быстрее не станет: главные потребители времени -- AG> функции умножения -- и так тщательно прооптимизированы на асме.

В том-то и дело, что не умножения, а деления и взятия остатка. Хорошо ещё если последние две операции умный компилятор объединит. Это при том, что можно обойтись лишь умножением.

Reply to
Kirill Frolov

Hello, Alexander Golov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 16 Jun 2005 20:34:57

+0000 (UTC):

DO>>>>>> Эффективно по какому критерию?

AG>>>>> Пустой траты времени.

DO>>>> А for(;;) {...} - эффективная конструкция?

AG>>> За отсутствием расшифровки "...", смысла в вопросе не вижу.

DO>> Да хоть и вообще ничего.

AG> В таком случае это неэффективная конструкция, если сравнивать AG> со sleep, на худой конец idle.

Опять же это зависит от условий. Универсального ответа нет.

DO>>>> Да по-фиг чем занимается прибор, на преобразование форматов DO>>>> для вывода человеку времени много не нужно.

AG>>> Hесколько милисекунд на процессоре с 1 МГц циклом. Это время AG>>> отобранное у других задач и энергия потраченная впустую.

DO>> Это очень часто абсолютно не критично.

AG> Случаев когда это критично, или крайне желательно избежать, AG> также немало.

Вот когда критично, тогда и надо думать как избежать. А когда нет, проще применить стандартное средство и не думать вовсе.

DO>> В таких случаях обычно можно. Хотя наглядность и простота DO>> написания программы может быть иногда достаточным аргументом DO>> для того, чтобы пользоваться плавучкой и форматным выводом.

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

Разумеется, это будет закат солнца вручную.

AG> Но printf в данном случае просто обладает совершенно излишней AG> функциональностью; потребность в выводе значений в AG> экпоненциальной форме или в совершенно неизвестном формате AG> возникает нечасто.

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

DO>>>> Да хоть один, какая разница?

AG>>> Что тогда вообще нагляность уходит на 123-й план.

DO>> Почему собственно?

AG> Потому что всего один, и так хорошо известно что он делает, AG> всматриваться, вчитываться, разбираться нет никакой нужды.

Известно когда пишешь, когда читаешь, может быть и не известно.

AG>>> Тем что работает во много раз медленнее.

DO>> Я уже говорил, что очень часто это не имеет никакого DO>> значения.

AG> А когда имеет, чем Out_Number хуже printf?

Когда имеет - лучше.

dima

formatting link

Reply to
Dmitry Orlov

Привет!

Fri Jun 17 2005 11:36, Kirill Frolov wrote to Alexander Golov:

...

AG>> В данном случае это неважно, на что не переписывай тот же вариант вывода AG>> %f из printf он заметно быстрее не станет: главные потребители времени AG>> -- функции умножения -- и так тщательно прооптимизированы на асме.

KF> В том-то и дело, что не умножения, а деления и взятия остатка. KF> Хорошо ещё если последние две операции умный компилятор объединит. KF> Это при том, что можно обойтись лишь умножением.

Hi-Tech обходится именно парой умножений ПЗ и целым, а у Keil'а, и ещё у кого-то смотрел, действительно были деления. Но это вопрос внеязыковой оптимизации.

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Hello Dimmy!

Jun 08 11:57 05, Dimmy Timchenko wrote to Alex Mogilnikov:

DT> отдельные функции типа int2str, float2str (на самом деле их может DT> быть много, с разными возможностями). Тогда и реализация получается DT> более красивой и атомарной, и использование более простым и DT> интуитивным: DT> puts ("On step " + int2str(step) + " value is " + DT> float2str(value) ); Я такое делал стандартными средствами ADA83. Компилировалось и работало в досе и линуксе. В досе компилятор Meridian ADA, в Линуксе - gnat.

DT> Прекрасно! Тогда надо писать на Аде. Hичего, что тяжёлая, проглотят DT> и не поперхнутся. Мнение о "тяжести" Ады - не более чем расхожий штамп. Код после gnat я правда не изучал, а читая в отладчике код после Meridian ADA - восхищался изяществом и эффективностью. В сравнении с Microsoft C 5.10 тех же времен - смотрелось куда как лучше. Единственная особенность - Ада "по умолчанию" тащит с собой рантайм, несколько больше чем у Си. Hо его размер (в досе) был около десятка килобайтов. Интересно, что весь вечер сидишь, пишешь, потом смотришь на размер исполняемого файла - а он совсем незначительно прибавился по сравнению с вообще "пустым" исходником. То есть если разобраться с рантаймом того же Гната и научиться там "выключать" ненужное в проекте - то можно писать и под встроенные системы. Вон, avr-ada делают потихоньку... Правда год назад, когда я на нее смотрел, она была еще неработоспособна при попытке запустить ее не на машине у автора:)

DT> Зато надёжность и безопасность - не чета "супу из топора" - C++. Это точно! Компилятор просто не дает сделать ошибку! Ругается и мешается как только может. Правда такое его поведение не понравится сторонникам "свободного стиля" в программировании:-)

Zahar

Reply to
Zahar Kiselev

Привет!

Fri Jun 17 2005 12:21, Dmitry Orlov wrote to Alexander Golov:

...

DO>>>>> А for(;;) {...} - эффективная конструкция?

AG>>>> За отсутствием расшифровки "...", смысла в вопросе не вижу.

DO>>> Да хоть и вообще ничего.

AG>> В таком случае это неэффективная конструкция, если сравнивать AG>> со sleep, на худой конец idle.

DO> Опять же это зависит от условий. Универсального ответа нет.

Для указанных выше условий ответ очевиден, разве что случай когда sleep и idle не поддерживается.

...

AG>>>> Hесколько милисекунд на процессоре с 1 МГц циклом. Это время AG>>>> отобранное у других задач и энергия потраченная впустую.

DO>>> Это очень часто абсолютно не критично.

AG>> Случаев когда это критично, или крайне желательно избежать, AG>> также немало.

DO> Вот когда критично, тогда и надо думать как избежать.

Когда мне это стало критично, я подумал и пришёл к приведённым ранее выводам. Теперь особенно думать не о чем можно брать и применять, тем более, что решение простое.

DO> А когда нет, проще применить стандартное средство и не думать вовсе.

Стандартность printf весьма относительна: опции вывода чисел в ПЗ далеко не всегда поддерживаются библиотеками для МК. Поток вывода нужно адаптировать к своим средствам (или наоборот). Кроме того, лично меня принципиально не устраивает вывод точки в качестве десятичной запятой, а создатели вроде как стандартного средства не позаботились о соответствующей настройке. Принципиально ничего не мешало бы использовать в качестве Out_Number тот же printf, но опять же создатели стандартного средства не позаботились о выводе чисел с фиксированной запятой.

...

AG>> Hо printf в данном случае просто обладает совершенно излишней AG>> функциональностью; потребность в выводе значений в AG>> экпоненциальной форме или в совершенно неизвестном формате AG>> возникает нечасто.

DO> Возникает тем не менее.

Когда возникает -- берём и применяем, если доступно, конечно.

DO> Hо главное его преимущество - он уже готовый. А DO> что до излишней функциональности, то в embedded библиотеках она обычно DO> изрядно ограничена и вовсе не столь излишня.

При выводе числа в жёстко определённой форме вида "99,9", возможность отображения этого числа в формате 9,99e+1 совершенно излишня тем более, что требует многократно бОльших ресурсов.

DO>>>>> Да хоть один, какая разница?

AG>>>> Что тогда вообще нагляность уходит на 123-й план.

DO>>> Почему собственно?

AG>> Потому что всего один, и так хорошо известно что он делает, AG>> всматриваться, вчитываться, разбираться нет никакой нужды.

DO> Известно когда пишешь, когда читаешь, может быть и не известно.

Разве что ты вообще ниразу не видел как этот прибор работает, чем занимается и что выводит. Потому что если видел, то вот оно это самое значение тут и выводится именно так как ты видел.

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Hello, Alexander Golov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Mon, 20 Jun 2005 19:10:11

+0000 (UTC):

DO>>>>>> А for(;;) {...} - эффективная конструкция?

AG>>>>> За отсутствием расшифровки "...", смысла в вопросе не AG>>>>> вижу.

DO>>>> Да хоть и вообще ничего.

AG>>> В таком случае это неэффективная конструкция, если AG>>> сравнивать со sleep, на худой конец idle.

DO>> Опять же это зависит от условий. Универсального ответа нет.

AG> Для указанных выше условий ответ очевиден, разве что случай AG> когда sleep и idle не поддерживается.

Или не хочется непереносимые конструкции лепить, или еще какие соображения.

DO>> Вот когда критично, тогда и надо думать как избежать.

AG> Когда мне это стало критично, я подумал и пришёл к приведённым ранее выводам. AG> Теперь особенно думать не о чем можно брать и применять, тем AG> более, что решение простое.

Ну а мне пока что критично не было, и я вывожу плавучку sprintf'ом и не вижу в этом ничего плохого. Более того, сколько-то заметного увеличения объема кода это не вызвало, да и до его экономии еще очень далеко.

DO>> А когда нет, проще применить стандартное средство и не думать DO>> вовсе.

AG> Стандартность printf весьма относительна: опции вывода чисел в AG> ПЗ далеко не всегда поддерживаются библиотеками для МК.

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

AG> Поток вывода нужно адаптировать к своим средствам (или наоборот).

Есть sprintf.

AG> Кроме того, лично меня принципиально не устраивает вывод точки AG> в качестве десятичной запятой, а создатели вроде как

Ну это уже твои личные проблемы, меня вплоне устраивает этот общепринятый вариант.

AG> Принципиально ничего не мешало бы использовать в качестве AG> Out_Number тот же printf, но опять же создатели стандартного AG> средства не позаботились о выводе чисел с фиксированной AG> запятой.

Мы вообще-то про числа с плавающей говорили...

AG>>> Hо printf в данном случае просто обладает совершенно AG>>> излишней функциональностью; потребность в выводе значений в AG>>> экпоненциальной форме или в совершенно неизвестном формате AG>>> возникает нечасто.

DO>> Возникает тем не менее.

AG> Когда возникает -- берём и применяем, если доступно, конечно.

Вот именно.

DO>> Известно когда пишешь, когда читаешь, может быть и не DO>> известно.

AG> Разве что ты вообще ниразу не видел как этот прибор работает,

Запросто, мало ли зачем читается исходник?

dima

formatting link

Reply to
Dmitry Orlov

Привет!

Mon Jun 20 2005 23:57, Dmitry Orlov wrote to Alexander Golov:

...

AG>>>> В таком случае это неэффективная конструкция, если AG>>>> сравнивать со sleep, на худой конец idle.

DO>>> Опять же это зависит от условий. Универсального ответа нет.

AG>> Для указанных выше условий ответ очевиден, разве что случай AG>> когда sleep и idle не поддерживается.

DO> Или не хочется непереносимые конструкции лепить,

С какого условия они вдруг непереносимее printf стали?

DO> или еще какие соображения.

Всё это к эффективности никакого отношения не имеет.

...

AG>> Кроме того, лично меня принципиально не устраивает вывод точки AG>> в качестве десятичной запятой, а создатели вроде как

DO> Hу это уже твои личные проблемы, меня вплоне устраивает этот общепринятый DO> вариант.

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

AG>> Принципиально ничего не мешало бы использовать в качестве AG>> Out_Number тот же printf, но опять же создатели стандартного AG>> средства не позаботились о выводе чисел с фиксированной AG>> запятой.

DO> Мы вообще-то про числа с плавающей говорили...

И мы... Если бы стандартное средство умело выводить числа с фиксированной запятой, то автоматически и решалась бы проблема эффективного вывода значений в ПЗ в предопределённом формате.

...

DO>>> Известно когда пишешь, когда читаешь, может быть и не DO>>> известно.

AG>> Разве что ты вообще ниразу не видел как этот прибор работает,

DO> Запросто, мало ли зачем читается исходник?

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

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Hello, Alexander Golov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 30 Jun 2005 20:12:44

+0000 (UTC):

AG>>>>> В таком случае это неэффективная конструкция, если AG>>>>> сравнивать со sleep, на худой конец idle.

DO>>>> Опять же это зависит от условий. Универсального ответа нет.

AG>>> Для указанных выше условий ответ очевиден, разве что случай AG>>> когда sleep и idle не поддерживается.

DO>> Или не хочется непереносимые конструкции лепить,

AG> С какого условия они вдруг непереносимее printf стали?

Printf, даже урезанный, штука стандартная, а sleep или idle - команды процессора, которые или есть или их нет.

DO>> или еще какие соображения.

AG> Всё это к эффективности никакого отношения не имеет.

Не имеет, я собственно об эффективности и не говорю. У меня, к примеру, все критичное живет в прерывании, что там в остальное время делается - мне глубоко по-фиг. Электричества в розетке много и памяти в pic18F2620 завались (это тестер для проверки наших балластов). И я совершенно незадумываясь пишу там sprintf(str, " %1.2f kV"CEOL, (exp(0.4*log(Vign_Max))/8.77)); причем только для того, чтобы на опциональном терминале увидеть какие-то похожие на реальность цифры. Причем формула эта просто высосана из пальца и реально проверяется что Vign_Max в неких пределах, никак с тем, что показывается на экране не связанных. Более того, я даже не могу сам точно сказать что же именно я меряю, но знаю, что полученная величина довольно неплохо отражает даже не само напряжение поджига, а способность балласта зажигать лампу.

AG>>> Кроме того, лично меня принципиально не устраивает вывод AG>>> точки в качестве десятичной запятой, а создатели вроде как

DO>> Hу это уже твои личные проблемы, меня вплоне устраивает этот DO>> общепринятый вариант.

AG> Общепринято использовать десятичную запятую, а заморочки

Запятой общепринято порядки отделять...

AG> программистов действительно лишь их личные проблемы.

Ну-ну...

AG>>> Принципиально ничего не мешало бы использовать в качестве AG>>> Out_Number тот же printf, но опять же создатели стандартного AG>>> средства не позаботились о выводе чисел с фиксированной AG>>> запятой.

DO>> Мы вообще-то про числа с плавающей говорили...

AG> И мы... Если бы стандартное средство умело выводить числа с AG> фиксированной запятой,

А что, есть такие числа? Я всегда думал, что это разновидность целого.

AG> то автоматически и решалась бы проблема эффективного вывода значений в ПЗ в AG> предопределённом формате.

И почему ты так уверен в эффективности этого гипотетического стандартного средства?

dima

formatting link

Reply to
Dmitry Orlov

Hello Alexander!

Jul 01 00:12 05, Alexander Golov wrote to Dmitry Orlov:

AG>>> Кроме того, лично меня принципиально не устраивает вывод точки AG>>> в качестве десятичной запятой, а создатели вроде как DO>> Hу это уже твои личные проблемы, меня вплоне устраивает этот DO>> общепринятый вариант. AG> Общепринято использовать десятичную запятую, Ты сходу можешь назвать хоть один _прибор_, выводящий именно запятую в качестве разделителя? Hе надо все-таки путать книжную полиграфию и метрологию... AG> а заморочки программистов действительно лишь их личные проблемы. В ГОСТах - тоже "личные заморочки"?

Zahar

Reply to
Zahar Kiselev

Пpивет, Alexander!

*** 30 Jun 05 23:12, Alexander Golov wrote to Dmitry Orlov:

DO>> Hу это уже твои личные проблемы, меня вплоне устраивает этот DO>> общепринятый вариант.

AG> Общепринято использовать десятичную запятую, а заморочки программистов AG> действительно лишь их личные проблемы.

Десятичная запятая "общепринята" лишь в России и еще немногих странах, в основном в мире (в Штатах, Европе) используют точку. Да и в СССР иной раз использовали точку - вот у меня на шкале генератора Г4-102 (75-го года) - точки (на остальных приборах 70..80гг, впрочем, запятые). Посмотри, что у калькуляторов в цифровом поле, и какой символ в цифровом поле у тебя справа...

с уважением Владислав

Reply to
Vladislav Baliasov

Пpивет, Alexey!

*** 01 Jul 05 15:30, Alexey V Bugrov wrote to Vladislav Baliasov:

VB>> генератора Г4-102 (75-го года) - точки (на остальных приборах VB>> 70..80гг, впрочем, запятые). Посмотри, что у калькуляторов в VB>> цифровом поле, и какой символ в цифровом поле у тебя справа...

AB> Зато в СССР не отделяли запятыми десятичные порядки - то еще AB> извращение.

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

с уважением Владислав

Reply to
Vladislav Baliasov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.