E
Привет Ребята! I have problem with casting quoted array to array I tried any solutions in stack, but there all is not worked. Here the example of my quoted array that I need to convert to array<array<array<array<double>>
Size: a a a
2021 February 26
E
Привет Ребята! I have problem with casting quoted array to array I tried any solutions in stack, but there all is not worked. Here the example of my quoted array that I need to convert to array<array<array<array<double>>
[[[[123,123]]]] example
ZM
Привет Ребята! I have problem with casting quoted array to array I tried any solutions in stack, but there all is not worked. Here the example of my quoted array that I need to convert to array<array<array<array<double>>
ΑZ
[[[[123,123]]]] example
provide an example on scastie and share the link
ИК
Всем привет!
Постараюсь внятно описать проблему. Упрощённый код в аттаче, выполняться не будет, многое порезал
Делаю свой spark партишенер. Это не case class, а обычный class, поэтому добавлены методы сериализации (скопированы из образцового класса, RangePartitioner). После добавления одного поля выявилась проблема. Выяснилось, что init класса может выполняться несколько раз, но и в образце - классе из исходников Spark та же ситуация. Это, конечно, плохо, но пока совета по этому кейсу не прошу
Вторая беда в том, что в методе объекта-компаньона возвращается Map с преобразованными значениями. Использую mapValues, но итератор проходит по каждому значению несколько раз, и излишне инкрементит мутабельную переменную, которую я использую для создания глобального индекса. Сами значения в итоге правильные, и их ровно столько, сколько нужно. Это точно происходит при обращении к полю rangeBounds в любом методе или при расчёте других полей. Помогите понять, почему итератор проходит несколько раз! Или что такое может происходить в Map.mapValues, что их нужно обходить несколько раз? Сериализация может быть с этим связана?
https://scastie.scala-lang.org/c7ljRtXiTOaFl5lObybiHQ
Постараюсь внятно описать проблему. Упрощённый код в аттаче, выполняться не будет, многое порезал
Делаю свой spark партишенер. Это не case class, а обычный class, поэтому добавлены методы сериализации (скопированы из образцового класса, RangePartitioner). После добавления одного поля выявилась проблема. Выяснилось, что init класса может выполняться несколько раз, но и в образце - классе из исходников Spark та же ситуация. Это, конечно, плохо, но пока совета по этому кейсу не прошу
Вторая беда в том, что в методе объекта-компаньона возвращается Map с преобразованными значениями. Использую mapValues, но итератор проходит по каждому значению несколько раз, и излишне инкрементит мутабельную переменную, которую я использую для создания глобального индекса. Сами значения в итоге правильные, и их ровно столько, сколько нужно. Это точно происходит при обращении к полю rangeBounds в любом методе или при расчёте других полей. Помогите понять, почему итератор проходит несколько раз! Или что такое может происходить в Map.mapValues, что их нужно обходить несколько раз? Сериализация может быть с этим связана?
https://scastie.scala-lang.org/c7ljRtXiTOaFl5lObybiHQ
M
Всем привет!
Постараюсь внятно описать проблему. Упрощённый код в аттаче, выполняться не будет, многое порезал
Делаю свой spark партишенер. Это не case class, а обычный class, поэтому добавлены методы сериализации (скопированы из образцового класса, RangePartitioner). После добавления одного поля выявилась проблема. Выяснилось, что init класса может выполняться несколько раз, но и в образце - классе из исходников Spark та же ситуация. Это, конечно, плохо, но пока совета по этому кейсу не прошу
Вторая беда в том, что в методе объекта-компаньона возвращается Map с преобразованными значениями. Использую mapValues, но итератор проходит по каждому значению несколько раз, и излишне инкрементит мутабельную переменную, которую я использую для создания глобального индекса. Сами значения в итоге правильные, и их ровно столько, сколько нужно. Это точно происходит при обращении к полю rangeBounds в любом методе или при расчёте других полей. Помогите понять, почему итератор проходит несколько раз! Или что такое может происходить в Map.mapValues, что их нужно обходить несколько раз? Сериализация может быть с этим связана?
https://scastie.scala-lang.org/c7ljRtXiTOaFl5lObybiHQ
Постараюсь внятно описать проблему. Упрощённый код в аттаче, выполняться не будет, многое порезал
Делаю свой spark партишенер. Это не case class, а обычный class, поэтому добавлены методы сериализации (скопированы из образцового класса, RangePartitioner). После добавления одного поля выявилась проблема. Выяснилось, что init класса может выполняться несколько раз, но и в образце - классе из исходников Spark та же ситуация. Это, конечно, плохо, но пока совета по этому кейсу не прошу
Вторая беда в том, что в методе объекта-компаньона возвращается Map с преобразованными значениями. Использую mapValues, но итератор проходит по каждому значению несколько раз, и излишне инкрементит мутабельную переменную, которую я использую для создания глобального индекса. Сами значения в итоге правильные, и их ровно столько, сколько нужно. Это точно происходит при обращении к полю rangeBounds в любом методе или при расчёте других полей. Помогите понять, почему итератор проходит несколько раз! Или что такое может происходить в Map.mapValues, что их нужно обходить несколько раз? Сериализация может быть с этим связана?
https://scastie.scala-lang.org/c7ljRtXiTOaFl5lObybiHQ
Для этого достаточно заглянуть в сам метод mapValues. Тогда все сразу станет ясно. Возвращается обернутая коллекция, которая каждый раз при дергании ключа вытаскивает из старой и по новой применяет функцию
M
никакой трансформации хранимых данных не происходит
ИК
Для этого достаточно заглянуть в сам метод mapValues. Тогда все сразу станет ясно. Возвращается обернутая коллекция, которая каждый раз при дергании ключа вытаскивает из старой и по новой применяет функцию
Благодарю, что взять на замену?
M
Благодарю, что взять на замену?
Котлин? А если без шуток - то стоит поработать над навыком чтения исходного кода. Конкретно в этом случае нет ничего мудреного - пары минут достаточно, чтобы понять что происходит внутри него. Вызови обычный map - получишь новую коллекцию с новыми данными на выходе.
Oℕ
Всем привет!
Постараюсь внятно описать проблему. Упрощённый код в аттаче, выполняться не будет, многое порезал
Делаю свой spark партишенер. Это не case class, а обычный class, поэтому добавлены методы сериализации (скопированы из образцового класса, RangePartitioner). После добавления одного поля выявилась проблема. Выяснилось, что init класса может выполняться несколько раз, но и в образце - классе из исходников Spark та же ситуация. Это, конечно, плохо, но пока совета по этому кейсу не прошу
Вторая беда в том, что в методе объекта-компаньона возвращается Map с преобразованными значениями. Использую mapValues, но итератор проходит по каждому значению несколько раз, и излишне инкрементит мутабельную переменную, которую я использую для создания глобального индекса. Сами значения в итоге правильные, и их ровно столько, сколько нужно. Это точно происходит при обращении к полю rangeBounds в любом методе или при расчёте других полей. Помогите понять, почему итератор проходит несколько раз! Или что такое может происходить в Map.mapValues, что их нужно обходить несколько раз? Сериализация может быть с этим связана?
https://scastie.scala-lang.org/c7ljRtXiTOaFl5lObybiHQ
Постараюсь внятно описать проблему. Упрощённый код в аттаче, выполняться не будет, многое порезал
Делаю свой spark партишенер. Это не case class, а обычный class, поэтому добавлены методы сериализации (скопированы из образцового класса, RangePartitioner). После добавления одного поля выявилась проблема. Выяснилось, что init класса может выполняться несколько раз, но и в образце - классе из исходников Spark та же ситуация. Это, конечно, плохо, но пока совета по этому кейсу не прошу
Вторая беда в том, что в методе объекта-компаньона возвращается Map с преобразованными значениями. Использую mapValues, но итератор проходит по каждому значению несколько раз, и излишне инкрементит мутабельную переменную, которую я использую для создания глобального индекса. Сами значения в итоге правильные, и их ровно столько, сколько нужно. Это точно происходит при обращении к полю rangeBounds в любом методе или при расчёте других полей. Помогите понять, почему итератор проходит несколько раз! Или что такое может происходить в Map.mapValues, что их нужно обходить несколько раз? Сериализация может быть с этим связана?
https://scastie.scala-lang.org/c7ljRtXiTOaFl5lObybiHQ
если сделаете так, чтобы код компилировался, попробуем помочь
ИК
Котлин? А если без шуток - то стоит поработать над навыком чтения исходного кода. Конкретно в этом случае нет ничего мудреного - пары минут достаточно, чтобы понять что происходит внутри него. Вызови обычный map - получишь новую коллекцию с новыми данными на выходе.
ну, эта комбинация мутабельных и иммутабельных способов несколько сбивает меня с толку
Oℕ
По сути нужно избавиться от мутабельности внутри ваших лямбд
M
ну, эта комбинация мутабельных и иммутабельных способов несколько сбивает меня с толку
там нет мутабельности
ИК
и да, Map.map помог, всем спасибо!
Oℕ
технически это должно быть что-то вроде
candidates.groupMap(_.1._1)(_._1._2).iterator.zipWithIndex.map{case ((k,vs), i) => (k, (vs, i))}.toMap
candidates.groupMap(_.1._1)(_._1._2).iterator.zipWithIndex.map{case ((k,vs), i) => (k, (vs, i))}.toMap
Oℕ
вместо всей вот той портянки
ИК
технически это должно быть что-то вроде
candidates.groupMap(_.1._1)(_._1._2).iterator.zipWithIndex.map{case ((k,vs), i) => (k, (vs, i))}.toMap
candidates.groupMap(_.1._1)(_._1._2).iterator.zipWithIndex.map{case ((k,vs), i) => (k, (vs, i))}.toMap
там ещё есть над чем поработать )) Спасибо!
Oℕ
там ещё есть над чем поработать )) Спасибо!
не будете делать скасти?
ИК
таки нет. Попробую сам разобраться
M
и да, Map.map помог, всем спасибо!
Ты изначально выбрал правильный диагноз, что mapValues приводит к повторным вызовам, тебе не хватило буквально немного, чтобы вглядеться в пару строк внутри него. mapValues - это ошибка порожденная человеком, не нужно думать что там кругом сверх люди и никогда не ошибаются. Тяжела и не казиста жизнь простого программиста - поэтому такой навык сэкономит тебе в дальнейшем много нервов и времени.