Если сделать x с нулевым средним, то операция возведения в квадрат будет съедать минус, соответственно, да, зависимость будет портится, но если учесть знак исходной выборки — то все починится. Пример — x = rand(1,1000);
mean(x)
ans =
0.5001
x1 = x - mean(x);
corrcoef(x1, x1 .^ 2)
ans =
1.0000 -0.0316
-0.0316 1.0000
А как на счет сравнить 10GBe и QDR Infiniband? Ведь в HPC это стандарт…
И как обстоят дела с проблемой высокой латентности Ethernet, в смысле латентности CSMA/CD — в 10GBe эту проблему как-то решили?
«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте» — Мартин Голдинг. Если об этом помнить то с именами будет попроще.
А еще есть подход, утверждающий, что правильные имена переменных и функций заменяют 95% комментариев.
Да полностью согласен, я сейчас всячески продвигаю идею использования питона в качестве первого языка в вузе, вместо турбо паскаля — морально устаревшего еще в прошло веке.
Но — python-style завершения блока меня честно говоря немного напрягает, C-style имхо лучше. И это единственное, с чем сложно согласиться, все остальное в питоне доставляет удовольствие.
В далеком 1995 (в школе еще) изучая TASM 1.0 ужасно мучился с именованием переменных, товарищ решал проблему проще — @1, @2, @3...., еще было совсем не понятно, зачем делать отступы в коде. Теперь же когда вижу код с переменной izobrazhenie или, (не дай бог!) не корректные отступы — все, спазм мозга…
Просто сопоставление двух фактов.
1. В одной знакомой типографии стоит достаточно древний фотонаборный автомат — Dolev 800 (где-то 2003-4 года), так вот, у него RIP — растрирующая станция, на PowerPC 400Mhz, с пассивным охлаждением, OC — AIX 4.3. Так вот, все это великолепие справляется с растрированием на А2 формат на 300dpi, лопатит eps-ы в несколько гигабайт и вполне себе без лагов в X-овом графическом интерфейсе…
2. А в это время, телефону!, чтобы не лагать нужен Quad 1.4Ghz.
Куда катится мир…
Про чистый С для микроконтроллеров понятно. Мне просто кажется, что в ряде случаев сопрограммный подход будет выигрывать и на «больших машинах». По крайней мере, обработка сложных структур данных — типа вашего примера с XML или реализации FSM логики, мне представляется более читабельным/сопровождабельным в сопрограммной формулировке, не знаю, так это или нет, надо попробовать…
Спасибо, статья хорошая и подход как продолжений так и замыканий хороший.
Задумался над следующим — в принципе, это все реализуемо через ООП, но, ИМХО «сопрограммный» подход более читабельный, и по идее, должен быть меньше оверхед связанный с ООП (VMT и проч.). Однако, для ООП есть паттерны, методики TDD…
Соответственно, интересно мнение сообщества — насколько велик предполагаемый оверхед и какие еще видятся достоинства/недостатки в паре ООП/сопрограммы.
Постгре не хуже для кучи задач, mysql хорош — я их люблю и использую, НО:
1. Разрабов mysql ~150, разрабов оракла — думаю в 50-100 раз больше, разрабы мускула признают, что опыт в оракл несравнимо больше.
К тому же, имхо, качество реально сложного софта достигается потом и кровью и большим количеством времени…
2. Enterprise сектор, база ~400 таблиц, по размеру небольшая 3-4Гб, вариант на посгре на в среднем(на различных операциях) на 30% медленнее, на бесплатной версии DB2 где-то те же результаты.
3. Mysql, innodb движок, таблица 80млн записей — а попробуйте удалить из них 55млн — на это может уйти неделя! А в MS SQL — в пределах минут…
А по поводу Бренда и лицензий — как повергала меня в ужас политика лицензирования MS, Oracle и (особенно!) Cisco так и будет повергать…
Еще раз — каждому свое — Photoshop несравнимо лучше GIMP для полиграфии, RHEL несравнимо лучше всех кластерных изысков виндов для HPC, Oracle лучшая СУБД в корпоративном секторе, а SSH лучшее впн решение для тех кто умеет им пользоваться…
Интеллектуальной собственности не бывает — как говорили в зАиБи и также говорит Ричард. И рассчитывать на интеллектуальную собственность в стартапе, имхо, не особо стоит.
Однако — внутренний мир СУБД Oracle и MS SQL храниться за семью печатями и договорами о неразглашении. И это вообщем помогает им сохранять нехилое преимущество перед глубокоуважаемыми и любимыми postgers и mysql.
Как говорится — jedem das siene…
corrcoef(x1, sign(x1) * x1 .^ 2)понимать как
corrcoef(x1, sign(x1) .* x1 .^ 2)не тот кусок скопировал
x = rand(1,1000);
mean(x)
ans =
0.5001
x1 = x - mean(x);
corrcoef(x1, x1 .^ 2)
ans =
1.0000 -0.0316
-0.0316 1.0000
corrcoef(x1, sign(x1) * x1 .^ 2)
ans =
1.0000 0.9672
0.9672 1.0000
corrcoef(x1, x1 .^ 3)
ans =
1.0000 0.9141
0.9141 1.0000
Как видно в последнем примере — возведение в куб знак не съедает и величина корреляции остается существенное.
Если y = x^2, то корреляция между ними будет и достаточно высокая!
Как пример, код на matlab
x = rand(1,10);
y = x.^2;
corrcoef(x,y)
ans =
1.0000 0.9846
0.9846 1.0000
Т.е. в нашем случае коэффициент корреляции 0.9846, что говорит о наличии зависимости с очень большой степенью достоверности.
И как обстоят дела с проблемой высокой латентности Ethernet, в смысле латентности CSMA/CD — в 10GBe эту проблему как-то решили?
А еще есть подход, утверждающий, что правильные имена переменных и функций заменяют 95% комментариев.
Но — python-style завершения блока меня честно говоря немного напрягает, C-style имхо лучше. И это единственное, с чем сложно согласиться, все остальное в питоне доставляет удовольствие.
1. В одной знакомой типографии стоит достаточно древний фотонаборный автомат — Dolev 800 (где-то 2003-4 года), так вот, у него RIP — растрирующая станция, на PowerPC 400Mhz, с пассивным охлаждением, OC — AIX 4.3. Так вот, все это великолепие справляется с растрированием на А2 формат на 300dpi, лопатит eps-ы в несколько гигабайт и вполне себе без лагов в X-овом графическом интерфейсе…
2. А в это время, телефону!, чтобы не лагать нужен Quad 1.4Ghz.
Куда катится мир…
Задумался над следующим — в принципе, это все реализуемо через ООП, но, ИМХО «сопрограммный» подход более читабельный, и по идее, должен быть меньше оверхед связанный с ООП (VMT и проч.). Однако, для ООП есть паттерны, методики TDD…
Соответственно, интересно мнение сообщества — насколько велик предполагаемый оверхед и какие еще видятся достоинства/недостатки в паре ООП/сопрограммы.
1. Разрабов mysql ~150, разрабов оракла — думаю в 50-100 раз больше, разрабы мускула признают, что опыт в оракл несравнимо больше.
К тому же, имхо, качество реально сложного софта достигается потом и кровью и большим количеством времени…
2. Enterprise сектор, база ~400 таблиц, по размеру небольшая 3-4Гб, вариант на посгре на в среднем(на различных операциях) на 30% медленнее, на бесплатной версии DB2 где-то те же результаты.
3. Mysql, innodb движок, таблица 80млн записей — а попробуйте удалить из них 55млн — на это может уйти неделя! А в MS SQL — в пределах минут…
А по поводу Бренда и лицензий — как повергала меня в ужас политика лицензирования MS, Oracle и (особенно!) Cisco так и будет повергать…
Еще раз — каждому свое — Photoshop несравнимо лучше GIMP для полиграфии, RHEL несравнимо лучше всех кластерных изысков виндов для HPC, Oracle лучшая СУБД в корпоративном секторе, а SSH лучшее впн решение для тех кто умеет им пользоваться…
Однако — внутренний мир СУБД Oracle и MS SQL храниться за семью печатями и договорами о неразглашении. И это вообщем помогает им сохранять нехилое преимущество перед глубокоуважаемыми и любимыми postgers и mysql.
Как говорится — jedem das siene…