Большая просьба к знающим этот язык.

 Имеется исходный файл, содержащий данные. Но в файле совершенно непонятная кодировка. AkelPad сообщает, что файл бинарный.
И есть листинг программы на Fortran для извлечения данных из этого файла. 

 Языки программирования почти не знаю , и разобраться как работает эта программа совершенно не получается. Пробовал её скомпилировать в Force 2.0, но выскакивает масса ошибок. По идее, в сам код нужно вносить какие-то параметры для извлечения данных из файла.

 Если вас не затруднит, посмотрите пожалуйста, что именно нужно сделать, чтобы извлечь данные.

 Исходные данные и программа находятся по адресу Area-Mean Values of Free-Air Gravity Anomalies on a Global 5 x 5-Minute Grid 

 Там где написано "5 x 5-Minute Area-Mean Free-Air Gravity Anomaly Grid (Dg01_mean5.0x5.0_EGM08_to2190_WGS84_ell_nh - 36 MB)" - это исходные данные.
 "Program to Read 5-Minute Gravity Anomaly Grid (read_1file_min5.0 - 6 KB)" - текст программы.
 "Output from the Program Above (read_1file_min5.0.out01 - 7 KB)" - пример работы этой программы

Во-первых, то, что на сайте называется "программой", на самом деле представляет собой программу на Фортране, встроенную в скрипт ksh, причем внешняя "обвязочная" часть написана, да простят меня модераторы, через задницу. Неудивительно, что скомпилировать эту химеру не удалось. Похоже, что кто-то когда-то написал код на Фортране, а уже затем кто-то другой, с Фортраном не знакомый, приделал снаружи костыли вместо переделки собственно программы.

Во-вторых, собственно фортрановский исходник также писался как минимум двумя разными людьми, причем первый из них использовал стандарт FORTRAN 77 (и делал все аккуратно), а второй - FORTRAN 90 (и опять-таки через задницу).

Соответственно, если все это зачистить, собрать и запустить, то получается следующее:


Звездочки - там, где результаты не влезли в заданный формат. В принципе, если надо, я могу исправить и это...

Мне на одном форуме также подсказали, что это не листинг.


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





Это сообщение отредактировал(а) spea - 27.10.2012, 17:34

Скорее не ошибка, а особенность интерпретации двоичных данных. Собственно, судя по тексту программы, она должна считывать из файла с данными 2160*4320 вещественных чисел, по 4 байта на число. Проблема в том, что на разных платформах форма хранения вещественных чисел может быть разной (у меня в итоге получаются отсчеты, различающиеся порядков на 60, что, наверное, не слишком осмысленно). 

Можно попробовать подобрать форму, однако для этого нужно знать, какими примерно по величине могут быть данные. Вы можете это сообщить?

 Не совсем понял вопрос. Значения первого столбика от 90 до -90. Значения второго от 0 до 360. Для каждого шаг 0,083333333. В третьем столбике значения не подчиняются какому-либо закону и варьируются где-то от -100 до +100 без резких перепадов.
Или общее количество строк данных нужно знать? 3110400 строк, что соответствует 2160*4320 разделить на 3 столбика.

Если скомпилировать этот код, то получается почти как в примере, только в третьей колонке сначала 0,00000, затем данные смещены вниз на одну строчку.


Это сообщение отредактировал(а) spea - 27.10.2012, 19:10

Я не про вывод. Я про значения во входном файле. Какими они могут быть?

как
Наверно я дико туплю, но в файле должны быть данные такие же как и в примере

 89.9583333333  0.0416666667  3.25491
 89.9583333333  0.1250000000  3.24581
 89.9583333333  0.2083333333  3.23676
 89.9583333333  0.2916666667  3.22776
 89.9583333333  0.3750000000  3.21880
 89.9583333333  0.4583333333  3.20989
 89.9583333333  0.5416666667  3.20103
 89.9583333333  0.6250000000  3.19221
 89.9583333333  0.7083333333  3.18345
 89.9583333333  0.7916666667  3.17473

Вычислил, что в начале должно быть так


Открывается также как и в примере. Вопрос в том, как записать данные в нормальном формате в текстовый файл?

Точнее, в последнем столбце примера. Т.е. что-то порядка единицы?

Тогда байты надо расставлять в обратном порядке.  Получается то, что в примере, но опять-таки со сдвигом 3-го столбца на одну позицию. Если считать, что первые четыре байта в данных пустые (на что очень похоже - файл чуть длиннее, чем требуется), то получается соответствие.
Вот простенькая программа на C99, которая перелопачивает исходный файл (переименованный в  data.dat) в текстовое представление:


Если хотите, могу и результат выслать, но напишите, куда - он и в ужатом виде больше 20М.

Только что её скомпилировал. В результирующем файле почему-то не все точки. Должно быть 3110400 строк, а получается 2562816. 


Напутал я с числом строк, их как раз должно быть 9331200=2160*4320





Это сообщение отредактировал(а) spea - 27.10.2012, 21:54

Откуда? Там в цикле читается 2160*4320 блоков по четыре байта. Соответственно, должно получаться 9331200 строк (столько, собственно, и получается).

Немного подправил код


Теперь строчек, сколько нужно. 

Фантом, огромнейшее спасибо! Вы меня невероятно выручили.

Добавлено @ 22:01

Вот только у меня получается заархивированный 50M, не сжатый 300M. 

Это сообщение отредактировал(а) spea - 27.10.2012, 22:06

По идее разницы быть не должно. Может быть, у Вас оптимизация компилятора хулиганит?


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

 Может быть, я в этом не силён. Пользуюсь Dev-C++.

Столкнулся с такой проблемой. 
Через каждые 4320 точек встречается 2 пары нулей в третьем столбце. И остальные данные получаются смещёнными на 2 строчке и это смещение накапливается.
Вот пример резкого перепада:



 Да, размер исходного файла 2160*4320*4 + 4320*4. Каждые 4322 чисел начинаются и заканчиваются нулём: 
0.00000
далее 4320 нужных значений
0.00000
0.00000
далее 4320 нужных значений
0.00000

и т.д.




Это сообщение отредактировал(а) spea - 28.10.2012, 03:47