Преобразование типов в Матлаб Опции

[AlexMad]

Есть некоторый файл, в котором хранится структура параметров другого файла.

В матлабе я считываю этот файл, как массив байтов, потом пытаюсь разгрести.

Вот часть описания этой стуктуры

Код

struct VARIATIONAL_PARS_1
  {
     char TimeString[26];            // 26 байт - число и время завершения ввода данных
     WORD ChannelsMax;          // 2 байта - общее число каналов для выбранной платы
     WORD RealChannelsQuantity; // 2 байта - число введенных (активных) каналов
     QWORD  RealKadrsQuantity;    // 8 байт - число собранных кадров в формате 'unsigned __int64' (< 18.446.744.073.709.551.614)
     QWORD  RealSamplesQuantity;  // 8 байт - число собранных отсчетов в формате 'unsigned __int64' (< 18.446.744.073.709.551.614)
     long double TotalTime;       // 10 байт - время ввода в cекундах в формате 'LONG DOUBLE'
     double AdcRate;             // 8 байт - частота АЦП в кГц в формате 'DOUBLE'
     double InterkadrDelay;      // 8 байт - межкадровая задержка в млс в формате 'DOUBLE'
     double ChannelRate;         // 8 байт - частота сбора данных с одного канала в кГц в формате 'FLOAT'
     BOOL  ActiveAdcChannelArray[MAX_ADC_CHANNEL_QUANTITY];      // 4байта*32 - массив, каждый элемент
                                                // которого равен нулю или единице, единичное значение
                                                // соответствует тому, что данный вход активен

Строки и целые числа из считанного массива получить не проблема. А вот как преобразовать массив байтов в double средствами именно матлаб?

[Xenia]

long double TotalTime; // 10 байт - время ввода в cекундах в формате 'LONG DOUBLE'

Формат long double МатЛаб не поддерживает. И вообще этот тип данных попал под тотальный запрет, хотя и продолжает поддерживаться аппаратно в архитектуре x86. Однако я не об этом, а об избыточности применения такого типа данных в данном случае.
Даже если время измеряется с точность до 1 МИКРОсекунды, то это 6 десятичных знаков после запятой. В то время как обычный double (не long!) держит 16 десятичных знаков мантиссы. Это означает, что на целые секунды нам остается 16-6=10 десятичных знаков. А 10 в 10-ой степени это такое большое число секунд, которого хватит на 317 лет!
Поэтому можно смело менять в стуктуре тип long double на просто double, не опасаясь, что в ближайшие 317 лет потеряется 6-ой знак после запятой. А если автор темы доживет до тех лет, то ему останется еще 5 знаков после запятой, которых хватит на следующие 3 тысячелетия.

[AlexMad]

Даже если время измеряется с точность до 1 МИКРОсекунды, то это 6 десятичных знаков после запятой. 

Я с Вами совершенно согласен, что это не нужно. Просто, есть накопленные данные, считанные устройством L-Card 14-440. В прилагаемой софтине данные именно так и хранятся (так что 317 лет жить собираются разработчики L-Carda, а не я), а сейчас я просто решил все их пересмотреть, заодно и с матлабом поразбираться. К слову сказать, само время записи мне не особо и нужно знать, его всегда можно получить, зная количество сэмплов и частоту АЦП.


Кстати - про неподдерживаемость long double спасибо за информацию, а то я долго не мог понять, почему у меня и написанная на Си утилита конвертирования не всегда правильно это время распознает.




Ну а про

У вас какой-то бардак. Что мешает привети файл в тексторый вид, и работать уже с ним? Небольшая прога-перекодировщик и все.

Да ничего не мешает, просто захотелось разобраться с возможностями матлаба и сделать все в одном месте.

[Xenia]

Просто, есть накопленные данные, считанные устройством L-Card 14-440. В прилагаемой софтине данные именно так и хранятся (так что 317 лет жить собираются разработчики L-Carda, а не я), а сейчас я просто решил все их пересмотреть, заодно и с матлабом поразбираться.
Кстати - про неподдерживаемость long double спасибо за информацию, а то я долго не мог понять, почему у меня и написанная на Си утилита конвертирования не всегда правильно это время распознает.

Это смотря какой С-компилятор, есть и такие, которые понимают тип long double в 10-байтной кодировке. Это Borland С/Delfi и их потомки. Компилятор от Intel тоже может работать с таким форматом, только под этот тип он отводит 16 байт (из них 6 пустые). Может и еще какие есть, только мне они не известны. А остальные придерживаются соглашения не использовать типов данных, размер которых не кратен степени двойки. 10-ка сюда не входит. Поэтому они понимают long double как просто double. А Intel исхитрился не нарушить соглашение, но оставить этот тип, т.к. он есть в их процессорах.