Здравствуйте, Андрей Ушаков, Вы писали:
АУ>Здравствуйте, altmenn, Вы писали:
A>>А как насчёт второго аспекта — стоит ли тоскать 128х64х90х700 в виде обычного масства?
АУ>Если перемножить эти числа и еще умножить результат на 16 — длина double, то получится что-то типа 8 Gb... Платформа у Вас какая?
Есть библиотека, такая как например netCDF, которая умеет хитро читать файлы в особом формате. Но, функции этой библиотеки устроены так, что структуры данных, в которые читем, определены жёстко. Конкретно в этом примере, функция readData(или в номенклатуре самой netCDF — nc_get_var_double) требует на входе ссылку на 4 мерный массив большого размера (например [128, 64, 90, 735]).
Но тут же возникает проблема. Не хочется возиться с такими струтурами как есть — хочется избавится от гемора хотя бы в своей проге. ибо таскание такого массива представляется неудобным... Может это и не так и я чего-то недопонимаю!?
Вопрос: можно ли как-то обхитрить библиотеку и совать ей не голый массив, а, например, stl vector?
Или стоит ли всё же заводить такой массив для считывания, расспихивать прочитаное по членам класса, например, и затем, как можно быстрее, удалять этот Жуть4D?
АУ>Ну, в netcdf.h эта функция определена, как:
АУ>EXTERNL int nc_get_var_double(int ncid, int varid, double *ip);
АУ>т.е. значения переменной копируются в обычный одномерный массив...
Вообще то да — это наверное удобнее, рассматривать как одномерный массив. Хотя в примерах, поставляемых вместе с библиотекой показан именно многомерный массив. Ну, да ладно, с этим я теперь разберусь, спасибо!
А как насчёт второго аспекта — стоит ли тоскать 128х64х90х700 в виде обычного масства? С непривычки (до сих пор не приходилось работать с большими объёмами данных) возникают сомнения насчёт размера структуры. Может ли это стать проблемой при определённых обстоятельствах? Тогда при каких? (Приложение предполагается быть многоплатформенным.) Спасибо!
Здравствуйте, Fwiffo, Вы писали:
F>double'ов? Это 4 Gb, может в память не влезть
Точнее, не может в память влезть.
Что-то мне все это сомнительно. Это не влезет в память ни на какой платформе под x86, как ни представляй. Поищи пример, где эта функция используется и разберись, как там сделано.
Здравствуйте, Fwiffo, Вы писали:
F>Здравствуйте, altmenn, Вы писали:
A>>А как насчёт второго аспекта — стоит ли тоскать 128х64х90х700 в виде обычного масства?
F>double'ов? Это 4 Gb, может в память не влезть
Вот! Это уже прочувствовали, когда компилили тот самый пример из netCDF с собственным файлом! У них там всё на стеке!
Здравствуйте, altmenn, Вы писали:
A>Вот! Это уже прочувствовали, когда компилили тот самый пример из netCDF с собственным файлом! У них там всё на стеке!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Fwiffo, Вы писали:
F>>double'ов? Это 4 Gb, может в память не влезть
PD>Точнее, не может в память влезть.
PD>Что-то мне все это сомнительно. Это не влезет в память ни на какой платформе под x86, как ни представляй. Поищи пример, где эта функция используется и разберись, как там сделано.
Что конкретно есть тут сомнительно? Пожалуйста поконкрентее — нужна информация!
Про пример я пишу уже... Там все намного проще, ибо представлен массивчик поменьше! Обратитесь к моим предидущим постам, плиз! Спасибо!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, altmenn, Вы писали:
A>>Вот! Это уже прочувствовали, когда компилили тот самый пример из netCDF с собственным файлом! У них там всё на стеке!
PD>Что на стеке ? МАссив в 4 GB ?
Aha!
/* This is part of the netCDF package.
Copyright 2006 University Corporation for Atmospheric Research/Unidata.
See COPYRIGHT file for conditions of use.
This is a simple example which reads a small dummy array, which was
written by simple_xy_wr.c. This is intended to illustrate the use
of the netCDF C API.
This program is part of the netCDF tutorial:
http://www.unidata.ucar.edu/software/netcdf/docs/netcdf-tutorial
Full documentation of the netCDF C API can be found at:
http://www.unidata.ucar.edu/software/netcdf/docs/netcdf-c
$Id: simple_xy_rd.c,v 1.9 2006/08/17 23:00:55 russ Exp $
*/#include <stdlib.h>
#include <stdio.h>
#include <netcdf.h>
/* This is the name of the data file we will read. */#define FILE_NAME "simple_xy.nc"/* We are reading 2D data, a 6 x 12 grid. */#define NX 6
#define NY 12
/* Handle errors by printing an error message and exiting with a
* non-zero status. */#define ERRCODE 2
#define ERR(e) {printf("Error: %s\n", nc_strerror(e)); exit(ERRCODE);}
int
main()
{
/* This will be the netCDF ID for the file and data variable. */int ncid, varid;
int data_in[NX][NY];
/* Loop indexes, and error handling. */int x, y, retval;
/* Open the file. NC_NOWRITE tells netCDF we want read-only access
* to the file.*/if ((retval = nc_open(FILE_NAME, NC_NOWRITE, &ncid)))
ERR(retval);
/* Get the varid of the data variable, based on its name. */if ((retval = nc_inq_varid(ncid, "data", &varid)))
ERR(retval);
/* Read the data. */if ((retval = nc_get_var_int(ncid, varid, &data_in[0][0])))
ERR(retval);
/* Check the data. */for (x = 0; x < NX; x++)
for (y = 0; y < NY; y++)
if (data_in[x][y] != x * NY + y)
return ERRCODE;
/* Close the file, freeing all resources. */if ((retval = nc_close(ncid)))
ERR(retval);
printf("*** SUCCESS reading example file %s!\n", FILE_NAME);
return 0;
}
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Fwiffo, Вы писали:
F>>double'ов? Это 4 Gb, может в память не влезть
PD>Точнее, не может в память влезть.
Здравствуйте, Fwiffo, Вы писали:
F>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Здравствуйте, Fwiffo, Вы писали:
F>>>double'ов? Это 4 Gb, может в память не влезть
PD>>Точнее, не может в память влезть.
F>Под 64 бита может и влезть.
Может и влезет, но более интересный вопрос о том, как это будет влиять на дальнейшую работу програмы? Интуитивно представляеться, что эту память нужно как можно скорее освобождать. Так? Но как это сделать грамотно? Создавать большой массив в куче, читать в него, скоренько выбирать из него нужное и быстренько чистить память? Какие конечные струкруры есть хорошая альтернатива громадному массиву, если практически всё его содежимое нужно в процессе работы программы?
Спасибо!
Здравствуйте, altmenn, Вы писали:
A>Здравствуйте, Fwiffo, Вы писали:
F>>Здравствуйте, altmenn, Вы писали:
A>>>А как насчёт второго аспекта — стоит ли тоскать 128х64х90х700 в виде обычного масства?
F>>double'ов? Это 4 Gb, может в память не влезть
A>Вот! Это уже прочувствовали, когда компилили тот самый пример из netCDF с собственным файлом! У них там всё на стеке!
A>А как? A>Заранее спасибо!
По кускам читать и обрабатывать Как именно по кускам зависит от того, что вы с ним делать собираетесь, расскажите про задачу подробней.
F>По кускам читать и обрабатывать Как именно по кускам зависит от того, что вы с ним делать собираетесь, расскажите про задачу подробней.
Да, задача кажеться интересной. Но на самом деле — банальное считывание и переписывание в файл с другим форматом.
Единственое, нужно по ходу например, умножить все значения на опредённый коэфф., который вычисляеться по значениям самой матрицы... В последнем то и есть проблема, ибо вычисление хочестся сдласть в другом классе, умножение тоже...а таскать массив неохото...
По кускам — впринципе правильно. Например по кускам 128х64хсреднее(90)х1. И так же правилтно, что про куски надо подумать...Они действительно выделяються только учиьывая специфику задачи...
Спасибо !