Так-то и быструю сортировку можно написать в 10-20 строчек, но так обычно не делают. А все потому, что на самом деле эффективный алгоритм - это далеко не «наколеночное» решение.
В случае с FFT, то тут целый простор для улучшений и реализаций, начиная от поддержки произвольных длин, заканчивая локальными оптимизациями, поддержкой команд SSE, AVX и т.д. Скорее всего в реальном проекте (не лабораторной работе для студентов) вы не захотите тратить время на это все, а подключите тот же FFTW.
Разница сортировки и FFT в том, что сортировка уже встроена в поставляемую стандартную библиотеку, а FFT нет. Но это не повод для написания собственных реализаций. Конечно, все зависит от ситуации.
type mapImpl[A, B] struct {
s Stream[A]
v A
fn func(A) B
}
func (m *mapImpl[A, B]) Next() bool {
return s.Next()
}
func (m *mapImpl[A, B]) Scan(v *B) {
m.s.Scan(&m.v)
*v = m.fn(m.v)
}
// ...
Увеличилась ли тут сложность? Вроде нет.
Есть простор для оптимизации? Да.
Привычно ли использование? Да, аналогично тому же sql.Rows, к примеру.
Вообще ничего против не имею вашей библиотеки. Но ошибок все-таки не хватает (того же Err()). Для продакшена такую библиотеку неудобно будет использовать, так как придётся поверх этого всего городить велосипед, чтобы ошибки поддержать (а это нормально, например когда нам пользователь что-то в сокет кладёт или ещё что).
Вообще это все сугубо мое личное мнение и я могу быть где-то не прав. Но немножко грустно, что с появлением generic-ов частенько мелькают библиотеки с как минимум сотнями звёздочек, реализующие всякие Result[T, E], Optional[T] и type Map[K, V] map[K]V. Неужели стандартные возможности языка не позволяют этого? Или у нас путь как с npm пакетами (плохое сравнение, но все же) - проще строчку в go.mod, чем одну/две в *.go
Не знаю откуда вы это взяли и от кого, но заявление странное. Наверняка кто-то и пользуется, но такое можно сказать практически про любой сервис в любой компании.
Изменять в рантайме размеры может и не нужно, но выделять, к примеру, матрицу размера, определённого в compile time, выглядит не всегда разумно. Вообще, как мне кажется, не нужно делать преждевременные оптимизации в ущерб читаемости кода, так как может оказаться, что проседания производительности не в лишних аллокациях. Да не спорю, круто писать сразу оптимальный во всех смыслах код, но кажется, что это может оказаться сильно дороже, чем хотелось бы.
На самом деле я использовал некоторые наиболее мне понравившиеся идеи из xBB. Раньше я работал с xBB и даже разобрался как он работает, потом у меня появились новые идеи, возможно не самые лучшие, и я решил написать свой.
Так-то и быструю сортировку можно написать в 10-20 строчек, но так обычно не делают. А все потому, что на самом деле эффективный алгоритм - это далеко не «наколеночное» решение.
В случае с FFT, то тут целый простор для улучшений и реализаций, начиная от поддержки произвольных длин, заканчивая локальными оптимизациями, поддержкой команд SSE, AVX и т.д. Скорее всего в реальном проекте (не лабораторной работе для студентов) вы не захотите тратить время на это все, а подключите тот же FFTW.
Разница сортировки и FFT в том, что сортировка уже встроена в поставляемую стандартную библиотеку, а FFT нет. Но это не повод для написания собственных реализаций. Конечно, все зависит от ситуации.
Ну к примеру как бы выглядела реализация Map:
Увеличилась ли тут сложность? Вроде нет.
Есть простор для оптимизации? Да.
Привычно ли использование? Да, аналогично тому же sql.Rows, к примеру.
Вообще ничего против не имею вашей библиотеки. Но ошибок все-таки не хватает (того же Err()). Для продакшена такую библиотеку неудобно будет использовать, так как придётся поверх этого всего городить велосипед, чтобы ошибки поддержать (а это нормально, например когда нам пользователь что-то в сокет кладёт или ещё что).
Вообще это все сугубо мое личное мнение и я могу быть где-то не прав. Но немножко грустно, что с появлением generic-ов частенько мелькают библиотеки с как минимум сотнями звёздочек, реализующие всякие Result[T, E], Optional[T] и type Map[K, V] map[K]V. Неужели стандартные возможности языка не позволяют этого? Или у нас путь как с npm пакетами (плохое сравнение, но все же) - проще строчку в go.mod, чем одну/две в *.go
Интересно, а чем подход как в sql.Rows не устроил, то есть сделать:
Не понимаю, для чего Option, зачем создавать себе проблемы.
Не знаю откуда вы это взяли и от кого, но заявление странное. Наверняка кто-то и пользуется, но такое можно сказать практически про любой сервис в любой компании.
Изменять в рантайме размеры может и не нужно, но выделять, к примеру, матрицу размера, определённого в compile time, выглядит не всегда разумно. Вообще, как мне кажется, не нужно делать преждевременные оптимизации в ущерб читаемости кода, так как может оказаться, что проседания производительности не в лишних аллокациях. Да не спорю, круто писать сразу оптимальный во всех смыслах код, но кажется, что это может оказаться сильно дороже, чем хотелось бы.
Если вы говорите про более эффективные средства, то хотя бы их перечисляйте. А пока это выглядит как попытка поумничать.