Comments 49
Типичный Enterprise-подход. 2 дополнительных класса чтобы читать/записывать матрицу, которые к тому же не решают проблему многих видов матриц и многих форматов хранения. Как вы собираетесь матрицу в координатном формате записывать? Три вызова writeInt(), а затем маркер элемента чтобы три числа в нужном порядке из буфера сбросилось? То есть, детали формата MatrixMarket плавно перетекли в класс разрежённой матрицы? Или ваш MMOutputStream — это просто такой навороченный (и бесполезный) буфер данных?
Проблема решается. Пройдите по ссылке (http://code.google.com/p/la4j/source/browse/trunk/la4j/src/main/java/la4j/io/). Посмотрите полную реализацию. В статье приведена только часть.
Новые типы матриц тоже добавляются без проблем. Однако если если говорить о новом формате — то возникают некоторые ограничения. Например, как вы заметили. Для того-же XML будет что то вроде:
Для плотных:
rows
columns
Для разреженных:
rows
columns
nonzero
Коненчно, чем то приходится жертвовать в замену универсальности.
Новые типы матриц тоже добавляются без проблем. Однако если если говорить о новом формате — то возникают некоторые ограничения. Например, как вы заметили. Для того-же XML будет что то вроде:
Для плотных:
rows
columns
Для разреженных:
rows
columns
nonzero
Коненчно, чем то приходится жертвовать в замену универсальности.
Ой, все теги съелись:
1)
2)
1)
rows
columns
2)
rows
columns
nonzero
В том-то и дело, что я прочитал. Классы матриц передают в поток числа (индексы и значения) в определённом форматом MatrixMarket порядке, а класс потока — это такой странный буфер. То есть, классы матриц знают про MatrixMarket. Какой тогда смысл в этом всём?
Нет-нет. Еще раз. Классы матриц ничего незнаю про формат. Они вообще ничего, кроме того, что их можно сериализовать незнают.
Есть формат. Он знает что:
Есть матрицы. Матрицы нужно писать в файл. Файл делится на заголовок, мету, и данные. Маркеры разделяют эти секции. Может я так непонятно объясняю. Дайте ссылку на код, где «матрица знает о формате»
Есть формат. Он знает что:
Есть матрицы. Матрицы нужно писать в файл. Файл делится на заголовок, мету, и данные. Маркеры разделяют эти секции. Может я так непонятно объясняю. Дайте ссылку на код, где «матрица знает о формате»
Матрица знает о формате там, где она передаёт в поток вывода тройки <i, j, a_ij>, но не в виде какой-то явно определённой структуры данных, которая задаёт контракт, а просто тремя не связанными вызовами методов. А с другой стороны эти данные именно в этом порядке кладутся в буфер и затем бефер неизменным записывается в файл.
Ну это не значит — знает. Эти последовательности можно восспринимать как контракт. Для любого другого формата она будет передовать точно такиеже последовательности. Это не зависит от формата.
… просто в потоках вывода для немного других форматов файлов (как я привёл пример ниже — CSC) нужно делать преобразователь с буферизированием всей матрицы.
Проблема в том, что вы путаете внутреннее представление внешние. Почитайте стандарт MatrixMarket например. Есть ли там хоть одно упоминание о внутреннем представлении?
Я не просто его читал, я его реализовывал.
Тем более. Тогда должны прекрасно понимать, что записав CSR или CSC матрицы в MM мы получим один и тот же файл. С точностью до байта.
Посмотрите внимательно, я говорил о «файле формата CSC», то есть не MatrixMarket.
Не знаю такой формат. Знаю такое внутреннее представление. Все равно что записать в формате «hasttable».
Формат файла CSC — это файл, в котором записано три массива: VAL, ICOORD, IPTR. Продолжать или уже понятно?
Ну вы описываете внутреннее представление. Ссылку ну то что есть такой внешний формат можно?
Harwell Boeing people.sc.fsu.edu/~jburkardt/data/hb/hb.html
То же, что я описываю, только сложнее (просто так не прочитать, там прямо в файл сначала записываются спецификаторы ввода/вывода для Fortran, которыми числа в этом файле нужно читать).
То же, что я описываю, только сложнее (просто так не прочитать, там прямо в файл сначала записываются спецификаторы ввода/вывода для Fortran, которыми числа в этом файле нужно читать).
Контр пример :) Вы выйграли. Формат «фигразбери какой» ориентированный на фортран, я уж точно не смогу реализовать по приведенной выше схеме для Java.
Простите. Но пример явно не показательный.
Простите. Но пример явно не показательный.
Если из формата выбросить всю фортран-специфичность, останется обычный CSC (как в памяти), только на диске в виде трёх массивов.
Ну да все правильно. Только вот зачем так связывать внутреннее и внешниее представление. Какая цель? Например.
У меня есть библиотека котороая хранит матрицы в CSC, и пишет их также. (примерно как вы сказали). Я хочу эти записанные матрицы открыть в Маткаде или еще где то. А Маткад — понятия не имеет что есть какие-то там CSR/CSC (ирония) и понимает лишь высокоуровнево — плотные/разреженые. Как прикажете быть?
У меня есть библиотека котороая хранит матрицы в CSC, и пишет их также. (примерно как вы сказали). Я хочу эти записанные матрицы открыть в Маткаде или еще где то. А Маткад — понятия не имеет что есть какие-то там CSR/CSC (ирония) и понимает лишь высокоуровнево — плотные/разреженые. Как прикажете быть?
Цель — исключить необходимость преобразования. Если мы читаем координатный MM, то значения там могут лежать в произвольном порядке. Если нам удобно обрабатывать в памяти CSC, то нам нужно сначала отсортировать считанные тройки по номеру столбца (чтобы числа из одного стрлбца были рядом), а затем ещё сформировать дополнительные массивы. Если бы в файле сразу был CSC, это всё было бы не нужно.
Ну да. Все верно. Только вот разработчики формата так не думали. Так проблема то не в посте оказыавется а в формате MM получается?
Разработчики формата, видимо, хотели хоть какой-то не очень сложный в реализации способ хранения матриц чтобы матрицы от одного приложения были пригодны для другого. Я не знаю какие именно задачи они решали и что они думали.
Но формат задокументирован в виде одной статьи, у которой в названии к тому же есть «Initial Design», что возможно указывает на недостаток времени для разработки.
Мне кажется, если бы они собирались сделать именно стандарт (который был бы утверждён какой-либо организацией), то кроме плотного и координатного способа записи в MM были бы и CSR, и CSC, и ленточный, и даже блочный.
Но формат задокументирован в виде одной статьи, у которой в названии к тому же есть «Initial Design», что возможно указывает на недостаток времени для разработки.
Мне кажется, если бы они собирались сделать именно стандарт (который был бы утверждён какой-либо организацией), то кроме плотного и координатного способа записи в MM были бы и CSR, и CSC, и ленточный, и даже блочный.
По поводу открытия в Маткаде формата, о котором он не знает: очевидно, использовать преобразователь.
И насчёт точности до байта вы не правы. Строки данных в координатном формате MM можно переставлять как вздумается, они не обязаны быть сортированы.
И детали формата никак не перетекают в реализацию потока. Т.е мыслить нужно так. Есть матрицы — плотные и разреженные. Это сущности «реального мира». Мы всегда для пишем плотные мартрицы как просто «value» и разреженные как «row col value», как формат это преобразует — это уже его задача.
Попробуйте написать для существующих матриц поток вывода для формата CSC (compressed sparse columns) не меняя кода в классах матриц. У вас в классе потока вывода внезапно появится буфер размером со всю матрицу, потому что сейчас матрица передаёт элементы не по столбцам.
Неправда. Никакой разницы между CSR и СSC нет с точки зрения формата — это одна и также разреженная матрица. Только для CSC нужно будет реалихзовать свою пару readExternal/writeExternal.
Вот то, что я хотел услышать. Захотели формат файла CSC — получили новую пару методовreadExternal/writeExternal в классе матриц.
К слову сейчас la4j поддерживает CSR.
Матрица может быть CSR или в координатном виде, а записать хотим в CSC.
СSR/CSC — это внутренние представления. Ничего общего с внешними форматами хранения они не имеют.
Вот смотрите. Сейчас поток вывода получает тройки (строка, столбец, значение). Чтобы записать это в файл как CSR или CSC нужно будет буферизировать всю матрицу в потоке вывода. Согласны?
Да нет такого понятия файл CSR или CSC :) Для форматов есть только разреженые и плотные матрицы. Они пониятия не имеют как там кто их хранит. Я мог хранить хоть в хеш таблице. В формате MM явно написано что записать должна вестить по строкам: строка, столбец, значение.
Если мне надо будет записаывать CSC матрицу. То моя задача так написать матод writeExternal() чтобы он отдавал в поток тройки «строка стобец значени». Для любого другого формата эти тройки будут идентичны в рамках терминологии «разреженная — плотная матрица».
Если мне надо будет записаывать CSC матрицу. То моя задача так написать матод writeExternal() чтобы он отдавал в поток тройки «строка стобец значени». Для любого другого формата эти тройки будут идентичны в рамках терминологии «разреженная — плотная матрица».
[оффтопик]
Вот интересный на хабре народ (40 коментов к посту). Вот видит человек (А), что другой (автор топика — Б), занимается пожожей темой что и он, Причем занимается на энтузиазме, бесплатно. И топик писать его никто не заставлял. Так нет чтобы написать что то вроде «Чувак, я тоже самое делаю. Давай вот вместе подумаем, может что-нибудь еще более изящное придумаем, а то у тебя тут вот как то непонятно сделано… » и т.д. А нееет. Он пишет. «Каво. Все фуфло! Я уже стораз такое все писал. Как ты ваще такое фуфло пидумал.»
[/оффтопик]
При всем уважении к gribozavr. Я не против. Он хотябы заинтересовался темой :)
Вот интересный на хабре народ (40 коментов к посту). Вот видит человек (А), что другой (автор топика — Б), занимается пожожей темой что и он, Причем занимается на энтузиазме, бесплатно. И топик писать его никто не заставлял. Так нет чтобы написать что то вроде «Чувак, я тоже самое делаю. Давай вот вместе подумаем, может что-нибудь еще более изящное придумаем, а то у тебя тут вот как то непонятно сделано… » и т.д. А нееет. Он пишет. «Каво. Все фуфло! Я уже стораз такое все писал. Как ты ваще такое фуфло пидумал.»
[/оффтопик]
При всем уважении к gribozavr. Я не против. Он хотябы заинтересовался темой :)
Sign up to leave a comment.
Идея реализации пакета I/O в Java