Вы возвращаете ссылку на массив, а не сумму. Также на каждой итерации вы создаете новый массив, из-за которого предыдущие значения теряются.
Просто переместите инициализацию за пределы цикла:
public static int[] allRowSums() {
int rowSum = 0;
int current = 0;
int[] a = new int[values.length]; // observe this change (only 1 change made)
for (int i = 0; i < values.length; i++) {
for (int j = 0; j < values[current].length; j++) {
rowSum = values[current][j];
a[i] += rowSum;
}
rowSum = 0;
current++;
}
return a;
}
И, как упоминалось в комментариях, вы печатаете ссылку на массив, используйте Arrays.toString()
, чтобы распечатать массив.
System.out.println(Arrays.toString(allRowSums()));
Почему List и Seq определяются в пакете scala и не scala.collection (даже при том, что реализации Seq находятся в подпакетах набора)?
Поскольку их считают столь обычно полезными, что они автоматически импортируются во все программы через синонимы в scala. Predef.
Каков стандартный механизм для инициализации набора и затем замораживания его (который в Java достигается путем обертывания в немодифицируемом)?
Java не имеет механизма для замораживания набора. Это только имеет идиому для обертывания (все еще модифицируемый) набор в обертке, которая выдает исключение. Надлежащая идиома в Scala должна скопировать изменяемый набор в неизменный - вероятно, использование: _ *
Почему некоторые типы набора (например, MultiMap) только определены как изменяемые? (Нет никакого неизменного MultiMap)?
Команда/сообщество просто еще не добралась там. 2,7 ответвления видели, что набор дополнений и 2.8, как ожидают, будет иметь набор больше.
Следующее кажется немного громоздким из-за вынужденных полных объявлений пакета:
Scala позволяет псевдонимы импорта, таким образом, это является всегда менее подробным, чем Java в этом отношении (см., например, java.util. Дата и java.sql. Дата - использующий обе силы один, чтобы быть полностью определенным)
import scala.collection.{Set => ISet}
import scala.collection.mutable.{Set => MSet}
class MyScala {
var mySet: ISet[String] = null
def init(): Unit = {
val s = MSet.empty[String]
s + "Hello"
s + "World"
mySet = Set(s : _ *)
}
}
Конечно, Вы действительно просто записали бы init как def init() { mySet = Set("Hello", "World")}
и сохраните всю проблему или еще лучше просто поместите ее в конструктора var mySet : ISet[String] = Set("Hello", "World")
A couple of random thoughts:
null
, I use Option
, which would then toss a decent error. This practice has gotten rid of a ton NullPointerException
opportunities, and forces people to write decent errors.So, my basic take on your scala example, where you have to initialize the set later, is
class MyScala {
private var lateBoundSet:Option[ Set[ String ] ] = None
def mySet = lateBoundSet.getOrElse( error("You didn't call init!") )
def init {
lateBoundSet = Some( Set( "Hello", "World" ) )
}
}
I've been on a tear recently around the office. "null is evil!"
Обратите внимание, что могут быть некоторые несоответствия в API коллекций Scala в текущей версии; для Scala 2.8 (который будет выпущен позже в 2009 г.) API коллекций подвергается капитальному ремонту, чтобы сделать его более согласованным и гибким.
См. эту статью на веб-сайте Scala: http: //www.scala-lang .org / node / 2060
Чтобы добавить к примеру Тристана Юричека с lateBoundSet: Scala имеет встроенный механизм для отложенной инициализации с использованием ключевого слова "lazy":
class MyClass {
lazy val mySet = Set("Hello", "World")
}
При этом mySet будет инициализирован первым используйте, а не сразу при создании нового экземпляра MyClass.
Изменяемые коллекции иногда полезны (хотя я согласен, что вы всегда должны смотреть сначала на неизменных). Если я использую их, я обычно пишу
import scala.collection.mutable
в верхней части файла и (например):
val cache = new mutable.HashMap[String, Int]
в моем коде. Это означает, что вам нужно написать только «mutable.HashMap», а не scala.collection.mutable.HashMap ». Как упоминал выше комментатор, чрезмерное бремя.
(Кроме того, могу ли я повторить комментарий «избегайте нулей». Это делает код намного более надежным и понятным. Я считаю, что мне даже не нужно использовать Option столько, сколько вы ожидаете. .)