Лабы в курсе были ванильные, там думать даже не надо было. Заполнить в редких местах пробелы и только. Вы же её тупо перепечатали на другом ЯП (тем более в случае спарка интерфейсы скалы и питона почти полностью совпадают). Судя по листингам, тупо var val проставлено у переменных и местами скобочки.
for (alpha <- Array(1e-5, 10)) {
for (numIter <- Array(5, 500)) {
val model = tuneModel(numIterations = numIter, stepSize = alpha, regParam = bestRegParam).run(parsedTrainData)
val rmseVal = calcError(model, parsedValData)
println(f"alpha = $alpha%.0e, numIters = $numIter, RMSE = $rmseVal%.3f")
}
}
Кабздец. Уже на второй день изучения скалы никто так не напишет. Переделка питоновского кода.
С учетом нарушения просьбы не распространять лабы, вы получаетесь бесчестный копипастер.
Не могу обещать. Труд большой, а с литературным изложением у меня проблемы. Статья больше обзор идеи, чем готовый рецепт. Незнание F# не помеха.
В довесок можно еще две статьи (с дебатами в комментариях) уже на скале привести:
_http://underscore.io/blog/posts/2015/02/13/error-handling-without-throwing-your-hands-up.html
_http://underscore.io/blog/posts/2015/02/23/designing-fail-fast-error-handling.html
В случае fail fast (тем более с собственными исключениями), имхо, стэктрейс не столь важен. Конечно, если это повсеместный подход в проекте. По идее исключения нужны только для обозначения ситуаций, когда контекст покинул область определения функции и это надо обрабатывать в рамках самой функции. Саму же логику строить «прямолинейно», словно всё хорошо. И лишь в конце кейса сделать выбор что сделать с результатом: просто вернуть корректный ответ или вернуть ответ-ошибку, если такая имела место.
Для упрощения разве что сделать вспомогательный метод на фильтр, где можно задать своё сообщение. Исключение все равно бросается в контексте, почему он теряется? И опять же исключение в Try — fast fail. Не вижу оверхеда.
p.s. в тему обсуждения _http://fsharpforfunandprofit.com/posts/recipe-part2/
scala> res7.filter(x => x.x >=0 && x.y >= 0)
res8: scala.util.Try[F1] = Failure(java.util.NoSuchElementException: Predicate does not hold for F1(-4,3))
При необходимости можно сделать recover и задать собственное исключение.
После первого фейла уже масштаб проблемы должен был прояснить головы. Решение же типовое безотносительно языков и фреймворков, это первое что в голову должно прийти. Люди банально не понимали как работает выбранный инструмент (особенно печально, что после 2х лет использования).
Эта статья должна быть предупреждением для бизнеса, о качестве кадров и иметь соответствующий заголовок.
Это специфичная вещь, упоминания о которой в последних доках не вижу вдобавок. Реализовать свой ящик один из вариантов (если хочется аналог редо логов в реляционках).
Кабздец. Уже на второй день изучения скалы никто так не напишет. Переделка питоновского кода.
С учетом нарушения просьбы не распространять лабы, вы получаетесь бесчестный копипастер.
В довесок можно еще две статьи (с дебатами в комментариях) уже на скале привести:
_http://underscore.io/blog/posts/2015/02/13/error-handling-without-throwing-your-hands-up.html
_http://underscore.io/blog/posts/2015/02/23/designing-fail-fast-error-handling.html
p.s. в тему обсуждения _http://fsharpforfunandprofit.com/posts/recipe-part2/
scala> Try(res3)
res7: scala.util.Try[F1] = Success(F1(-4,3))
scala> res7.filter(x => x.x >=0 && x.y >= 0)
res8: scala.util.Try[F1] = Failure(java.util.NoSuchElementException: Predicate does not hold for F1(-4,3))
При необходимости можно сделать recover и задать собственное исключение.
require(x >= 0 && y >= 0, «x and y must be positive»)
}
В конкретном примере, имхо, лучше так.
Эта статья должна быть предупреждением для бизнеса, о качестве кадров и иметь соответствующий заголовок.
Ничего не хочу сказать против или за go, но divan0 типичный фанатик, со всеми вытекающими.