Это означает, что при увеличении n, (n^2+n)/2 примерно соответствует росту n^2. Если взять n=1e100 то сумма ряда будет примерно равна 5e199, а n^2 = 1e200. Как можно видеть, числа отличаются всего в 2 раза (почти в 2, там еще +5e99, но это очень мало в сравнении).
Артём Новолодский, скорее всего нет. Когда выполняется настройка частоты - выбирается частота несущего сигнала, на который определённым образом потом накладывается полезный сигнал. То есть, сам полезный сигнал логически не связан с несущим. А красное смещение модулированного сигнала, скорее всего, соответствует увеличению длины волны несущего сигнала, на что и производится поправка в приёмнике. То есть, замедленный голос мы не услышим.
Артём Новолодский, тогда всё будет нормально, но до поры до времени. То есть, технически, вы просто упрётесь в невозможность для антенны принимать на такой частоте. Но если даже это преодолеть, то просто (из-за сдвигов модуляции) информация будет поступать всё медленнее и медленнее. Я не очень разбираюсь в теории радиопередач, но логика мне подсказывает, что приёмник, настроенный на определённую частоту, будет и демодуляцию проводить соответствующим образом, что не должно привести к (сильному) искажению самой звуковой информации. Но это может зависеть от способа модуляции.
freeExec, нет, он создаёт очередной. Нет необходимости устраивать такие проверки, поскольку зачастую лямбды не равны, а если и равны, то стоит программисту переиспользовать одну функцию.
На уровне кода проверить равенство можно было бы обходом дерева в Expression, однако скомпилированные делегаты, вроде, не поддаются превращению в Expression. Поэтому, в общем случае, такая задача либо не решается, либо решается с трудом (анализ IL, например)
Дмитрий Ле, если хотите, чтобы по ссылке на базовый класс у вас всегда можно было получить актуальный Name, то сделайте Name просто автосвойством, например, а в производных классах используйте его же как своё собственное.
Дмитрий Ле, в данной реализации у вас существует 2 независимых поля: одно объявлено в абстрактном базовом классе, а второе объявлено в классах-наследниках и скрывает для них доступ к базовому полю. Иными словами, через ссылку на базовый класс вы можете получить базовую строку по полю и через метод testFF. А вот Name из-за переопределения вернёт вам поле, определённое в производном классе 1 (но не 2, там нет реализации свойства Name). Ну и, естественно, через ссылки на производные классы поле у вас будет с производным значением, а Name будет возвращать базовую строку во 2 реализации, и производную в 1 реализации.
Иерархия ваших классов должна исходить из задачи, а пока что я не понимаю, чего вы хотите добиться.
Несколько поправок.
Во-первых, в интерфейсах не допускаются никакие модификаторы методов. Свойства можно объявлять как int Property { get; }, например.
Во-вторых, автосвойства на практике неотлиличимы от полей (т.е. состояния) объекта: код методов доступа нельзя изменить, а низлежащее поле недоступно из кода. В свою очередь, JIT может инлайнить доступ к таким полям.
Что интересно, в языке Swift есть два типа свойств, которые как раз соответствуют по своему поведнию автосвойствам, и свойствам со вложенным кодом. Но в принципе, снаружи класса свойства всё равно не должны отличаться от полей, и даже методы семантики get и set должны представлять собой состояние, а не поведение. Сквозная же функциональность в этих методах не может считаться поведением, т.к. не меняет (не должна менять) состояние объекта.
Собственно, интересное замечание: у расширения интерфейса IEnumerable есть метод Count, который хоть по своей семантике и мог бы быть свойством для чтения, но по сути не является свойством, т.к. его вызов приводит к перечислению последовательности.
Что можно сказать?
Нужно просто помнить, что некоторые свойства могут являться в сущности методами, и каждый их вызов может сопровождаться определенными вычислениями. Так что такие вещи лучше реализовывать старыми добрыми функциями. А в целом я бы сказал, что всё же свойства - состояние объекта.
1. У вас exp может быть больше, чем 2^64, тогда n будет рассчитан неверно.
2. Создайте несколько result (под количество потоков) и умножайте каждую отдельно, без лока.
3. BigInteger несмотря на мощную оптимизацию всё равно очень медленная штука. Может, существуют более быстрые алгоритмы для вашей задачи?
Дмитрий, там суть в SomeEvent. MemberwiseClone создает копию низлежащего делегата под событием SomeEvent, но у вас логика такова, что обработчик должен присвоиться только в методе EventDemo.Clone. А у событий есть лишь методы add и remove, что не позволит вам избавиться в контексте EventDemo.Clone от уже существующего обработчика из копии (операция += добавляет обработчик в список).
Потому вам следует переделать вашу логику. Например, зачем вы вообще обрачиваете событие в класс MyEvent?
Другой путь
Либо вы можете сделать не авто-событие а руками создать поле делегат, свойство с методами a..., а потом, после вызова MemberwiseClone, присвоить этому полю-делегату null, избавившись от списка вызовов таким образом. Остальное всё остаётся как есть.
Александр: нет, я не владею этими инструментами так, как Керниган, Ритчи и прочие. И не владею знаниями, какими владел Эйнштейн. И я уж точно не посвятил работе всю свою жизнь. Но я обладаю неплохой фантазией и абстрактным мышлением и могу себе представить тот уровень, где все их творения достигаются любым другим человеком. В этом нет ничего заносчивого, это просто реальность.
Алсо, почитал ваши остальные ответы. "Сначала добейся" - крайне плохой аргумент с точки зрения логики. Не обязательно читать ЖЗЛ, чтобы понимать что-то, но вот о логических ошибках знать точно стоило бы.
Александр: Эйнштейн знал много других физических и математических теорий. Всё, что он сделал - придумал идею, что пространство и время связаны в одно пространство-время, кривизна которого зависит от массы-энергии, и описал это математически. Математика здесь - инструмент реализации идеи. Си и чужие проекты - инструмент в реализации какой-то другой идеи. Нет никаких "пионеров". Чтобы что-то создать, нужно знать матчасть и уж точно уметь пользоваться инструментами твоего ремесла.
Если так подумать, то масса - это свойство объекта сопротивляться изменению его скорости. То есть, если растёт энергия, необходимая для придания ускорения телу, то как это отличить от возрастания массы?
moneymakerXA: хм, я даже и не знаю. В гугле полно сайтов можно найти с подробными объяснениями. Вбейте в поиск темы, которые вас интересуют и можете пользоваться любыми, по сути.
NaName: а теперь у вас значения передаются только в первый элемент массивов *buffer.
Во-первых, попробуйте вызывать nc_get_var_double в теле цикла для каждого элемента буфера (а не снаружи). Во-вторых, у вас буфер вообще не нужен, т.к. он просто заполняется, а потом сливается в другой буфер. Можете использовать для этого сразу longitude и latitiude.
В-третьих, неясно, что такое height, т.к. он нигде не объявлен. Это глобальная переменная? В любом случае, если у вас массивы <= SIZE_J, причём всегда, то практически гарантированно у вас будет переполнение. (А если условие не выполнится до момента, когда j станет больше размеров longitude и latitiude?)
Короче, вам нужно тщательно всё переписать.
latitude_buffer и longitude_buffer запоминают значения предыдущих итераций.
Что? Из куска кода видно только, что у вас оба buffer'a заполнены мусором и нигде в них ничего не записывается.
И вы уверены, что у вас longitude и latitude, переданные в параметрах, всегда размера >= SIZE_J ?
