Вот собственно именно так я и думал, что метод toArray() — это абсолютно легальный способ подтолкнуть программиста работать со структурами не эффективно и идеологически не правильно.
Остановлюсь на таком подходе: преобразование в массив — операция свойственная только плотным матрицам. Если же программист захочет преобразовывать разреженные матрицы в массив — пусть пишет реализацию сам — на основе тех-же функторов или произвольном доступе, но при этом, вся ответственность по производительности полностью ложится на его плечи.
Итераторы — это вещи совершенно не свойственные матрицам вот в чем дело. Все базовые алгоритмы линейной алгебры построены именно на произвольном доступе по (i, j). Итераторы для коллекций применимы в большей степени. Т.е. там где хранимый объект имеет бОльший смысл чем сама коллекция и может быть обработан автономно. С матрицами все не так. Отдельные значения мало кого интересую — интересна вся матрица целиком. Сложно назвать обычную матрицу с double значениями коллекцией чисел — это скорее самостоятельный, неделимый объект.
Честно сказать, я встречал итераторы по матрицам у Apache Common Math. Но там другая история — Матрица там дейтсвительно коллекция с generic типом. Т.е. может хранить обычные объекты. В таком случае сложно представить использование такой матрицы в каком-нибудь SVD разложении. С la4j ситуация другая — это чистой воды математическая библиотека для матриц вещественных чисел.
Да, я согласен с тем, что toArray() имеет некоторый смысл для разреженных матриц, но все таки не думаю что он будет широко использоваться. Если говорить о сериализации — то я поддерживаю ее на уровне Java Serialization API.
Что касается интерфейсов. Пример со списками не очень удачный. И ArrayList и LinedList — это реализации. В то время как, SparseMatrix и DenseMatrix — интерфейсы различный видов матриц, которые имею реализации. Например CSR (Compressed Sparse Row) для разреженные и 1D Array — реализация плотной матрицы на основе одномерного массива. Т.е. реализаций может быть много для каждого отдельного вида.
Не совсем. Контакт у хеш функции такой:
1) Равенство/одинаковость объектов значит, что хеши равны.
2) Неравенство/неодинаковость объектов не означает, что хеши разные.
Вот собственно именно так я и думал, что метод toArray() — это абсолютно легальный способ подтолкнуть программиста работать со структурами не эффективно и идеологически не правильно.
Остановлюсь на таком подходе: преобразование в массив — операция свойственная только плотным матрицам. Если же программист захочет преобразовывать разреженные матрицы в массив — пусть пишет реализацию сам — на основе тех-же функторов или произвольном доступе, но при этом, вся ответственность по производительности полностью ложится на его плечи.