Ну вдогонку могу добавить, что 2.01276 укладывается к точности десятичных знаков в ~7,2. Всё, что за бортом подлежит округлению для представления в десятичном формате. Число 2,0127599239e+0 является не округлённым числом. Только и всего. Значит, вам надо дополнительно задать округление значения для вывода информации на экран.
vari0us: это зависит от механизма конвертирования и представления. Я решил просто проверить конвертером систем для вещественных чисел. То получаю либо 2.0127599239349365, либо 2.012760. И в обоих случаях в шестнадцатеричном виде выглядит вот так: 0x4000d10f. Так что, программа перевела правильно. Скорее всего, hex-редактор его округляет. Проверять надо в шестнадцатеричном виде, либо в двоичном. А десятичное представление будет всегда округляться. Даже на инженерных калькуляторах.
Salexer: если верить из статьи википедии, то:
- в системах электронного зажигания двигателей внутреннего сгорания;
- в приводах дисководов и двигателях вентиляторов компьютерной техники;
- в смартфонах в качестве физической основы работы электронного компаса;
- в электроизмерительных приборах (токовые клещи, токовые пробники) для бесконтактного измерения силы тока.
Как-то так.
FungusWarrior: да. Это будет работать. Только он побитово сравнивает со значениями x, y и z. В случае положительного сравнения происходит дизъюнкция k с константой из 0x1, 0x2 и 0x4. Я у себя на работе часто так делаю с флагами одного регистра на C#. К dom1n1k можно добавить словарь Dictionary, если нужно точное соответствие с k. Такой подход лучше и быстрей.
tartarelin: сложности всегда будут в первое время. Потом вам намного проще будет. Главное уметь найти выход из этого положения. Я сам лично также буду готовить отдельный компьютер с Linux для специальных задач. Потому что некоторые программы практически не меняются.
Дмитрий Беляев: Это само собой. Для этого и используют длинную арифметику. Я имел ввиду, чтобы оперировать такими большими числами за один такт ради быстродействия уже понадобится 128-битный процессор. Если редко применяется, то достаточно будет и длинной арифметики.
Oxoron: а фиксированный буфер как представляется в C#? Просто мне нужна конкретная структура с соответствующими полями данных, где можно сразу залить или выгрузить набор в 512 байт ровно. При приёме данных получаю 65536 байт и разбиваю по 512 байт. И это всё идёт через множество циклов, функций и методов обработкой побайтно, чтобы собрать всё это в структуру. И всё это 100 раз в секунду выполняется. Хорошо ещё, что у меня четырёхядерный процессор, иначе система совсем бы загнулась. А о таком подходе только недавно задумался. Прочитал в интернете, выяснил, что есть такая возможность. Проверил. Это то, что мне нужно. Это позволит мне выкинуть сразу несколько функций и методов с циклами, а также заменить классы на структуры. Самая первая версия была с использованием исключительно классов сожрала все 500 МБайт памяти. Сейчас после оптимизации около 100-140 МБайт. Но всё равно многовато.
Oxoron: в начале у меня использовался циклический метод. Но по показаниям нагрузки на процессор, что это довольно затратный способ. Процессор нагружался до 17% в пике, или 15% - постоянно. И это программа считывала данные с двух устройств. А в работе-то будет больше двух устройств. Поэтому и решил как-то снизить нагрузку и избавиться от циклов с чередой присваиваний и преобразований. Но структура-то данных практически неизменна Сериализация и десериализация целых структур видится мне наиболее подходящей.
Oxoron: подход годится. Надеюсь, что этот метод не будет занимать столько ресурсов в потоках. Байтовый массив я уже убрал, когда понял в процессе сериализации, что нет необходимости в нём.
Да, я уже это сделал. Забыл это добавить в коде. В конце потом отказался от него в пользу сериализации через указатель. В итоге получается, что надо работать на небезопасном уровне. Только такой вариант даёт нужный мне результат. Только не знаю, какие последствия от него будут. Ни разу не работал на таком уровне.
gold_user: сегментно-страничная организация памяти по сути та же сегментная память, только в дополнение ещё используется страничная организация памяти. Но это эффективно только при памяти выше 16/32 МБ. Потому что для страниц нужны участки в памяти для хранения таблиц трансляций. А в остальном та же память, те же недостатки. Поэтому и не используют их современные операционные системы. Дефрагментировать сегментную или сегемнтно-страничную память - довольно дорогое удовольствие. Проще иметь плоскую модель памяти, где просто со страницами можно выполнить минимум операций.
unixwz: тогда практически новое для себя можно узнать только с помощью материалов в сети. Из книг по VHDL уже мало полезного для себя найдёшь. Разве что справочники по VHDL отлично пригодятся, если что-то забыл, как это пишется. Остальное -- надо изучать документации к микросхемам. Пробовать работать на больших частотах, более 300 МГц. Там можно узнать для себя специфику работы ПЛИС и искать решения по обходу ограничений. Пробуйте работать также на Altera, там почти всё тоже самое, поэтому быстро освоите. Полезно знать сразу изделия сразу двух фирм.
Если говорить простым языком, то лучший учебник -- это практика на реальных задачах.
Станислав Силин: UserControl разместился в Content Статусбара, чем и сломал интерфейс весь. Пардон. Это было для второго варианта. Для первого варианта всё также без изменений. Возможно, я что-то недопонимаю в INotifyPropertyChanged.
