Здравствуйте, komaz, Вы писали:

K>Аналогично:
K>1. Не зная про базы данных кто-то может клепать какой-нибудь xml-based persistence storage
K>2. Не зная о существовании всяких SOAP, WCF, RMI, etc кто-то может клепать какой-нибудь свой xml-based rpc на сокетах
K>3. Не зная ничего про RSA, SHA, MD5, DES, etc кто-то может изобретать свой rot13
K>и т.п.

Ты действительно не понимаешь разницы между математическими теориями и конкретными технологиями?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, komaz, Вы писали:

K>>Аналогично:
K>>1. Не зная про базы данных кто-то может клепать какой-нибудь xml-based persistence storage
K>>2. Не зная о существовании всяких SOAP, WCF, RMI, etc кто-то может клепать какой-нибудь свой xml-based rpc на сокетах
K>>3. Не зная ничего про RSA, SHA, MD5, DES, etc кто-то может изобретать свой rot13
K>>и т.п.

НС>Ты действительно не понимаешь разницы между математическими теориями и конкретными технологиями?
Ну ты первый начал про электролобзики и шуруповерты вместо уравнений Максвелла
А по теме — так уж ли нужны фундаментальные знания для того, чтобы пользоваться antlr и т.п.? Нельзя ли получить необходимый объем знаний в процессе решения конкретной задачи?

Здравствуйте, hal9000, Вы писали:

H>Здравствуйте, March_rabbit, Вы писали:

M_>>1) именно в этом месте тормозит?
M_>>2) сколько процентов времени проводит программа в этом месте?
M_>>... ну и прочее.

H>Θ(n^2) убъёт машину по сравнению с Θ(n), при больших n. Мощности машины можно наращивать, но парабола рано или поздно сведёт на нет вычислительную мощь.

H>Это в общем случае.
ты не ответил на два приведенных вопроса. Прикинь, надо тебе отсортировать 32-х битные числа. Число n — реально большое. Ок.
1) Хватит ли памяти для сортировки Θ(n^2)? А для сортировки Θ(n)? (ограничение по памяти)
2) Откуда возьмутся эти данные и куда их надо деть? (ограничение по скорости ввода-вывода)
Эти два вопроса могут серьезно повлиять на выбор метода сортировки. Каждый по своему.

И главный вопрос:
3) Сколько элементов данных нужно в отсортированном массиве?
Вопрос несколько странный, но... Если стоит задача вида "получить M наибольших чисел", лучшая оптимизация — не сортировать весь массив.

Ну а первый (и главный) вопрос: "насколько часто нужна эта сортировка?". Если она нужна настолько редко, что это не повлияет на работу пользователя — то не стоит и тратить на ее оптимизацию время. Например, какая-нибудь хитрая сортировка записей в почтовой папке, с огромным числом писем может вообще быть применена пользователем 1 раз в месяц. И далеко не у всех при этом может набраться сколько-нибудь большое количество писем в сортируемой папке. Такое, чтобы разница по времени была бы ощутимой.

Здравствуйте, hal9000, Вы писали:

H>Здравствуйте, komaz, Вы писали:

K>>Именно! На мой взгляд вполне достаточно просто "прокачать" способность к восприятию больших объемов незнакомой и сложной для понимания информации. И вовсе необязательно (хотя, разумеется, явно не повредит) прорешивать все задачи из дистинуальной, тьфу, то есть конкретной математики прежде чем начать работать программистом

H>При более глубоком изучении ключевых концепций математики (т.е. когда изучаешь по настоящему для души, а не для препода в вузе), начинаешь осознавать, что математика это не наука вычисления чего либо, а нечто большее, это можно сказать формальный язык для операций с информационными объектами любого типа. Математика очень развита и в ней много разных моделей и операций с объектами, поэтому как нельзя лучше подходит для развития правильного мышления и умения работать со сложной информацией любой природы.

С этим не поспоришь, но чем в этом плане дискретка лучше функционального анализа или ТФКП?

Здравствуйте, mymuss, Вы писали:

M>Здравствуйте, March_rabbit, Вы писали:

M>>>Тормозит сильно.
M_>>)
M_>>1) именно в этом месте тормозит?
M_>>2) сколько процентов времени проводит программа в этом месте?
M_>>... ну и прочее.

M>1) Вся программа один большой цикл, в котором перебирается много-много записей. (Ну не считая в самом конце крохотной ф-ции, которая генерирует XML/HTML с отчетом)
M>Нах, спрашивается, вкладывать в него еще один цикл, который в худшем случае будет перебирать то же самое кол-во элементов? Я не уверен, что мне удалось аффтару проги объяснить разницу, точнее я почти уверен, что он продолжает думать что там как было 2*n, так и осталось.

M>2) Не знаю, 99.999% наверное.

M>На 200 млн записей разница очень заметна.
в данном примере есть ровно один вопрос: насколько часто должна применяться эта программа? Если раз в неделю — тогда ИМХО время ей выполнения не важно (если оно меньше недели ).

Здравствуйте, Anton Batenev, Вы писали:

AB>Напомнило байку про кошку и привязанную к ее хвосту консервную банку
Вопрос о том с какой скоростью она должна бежать чтобы не слышать грохот? или что-то другое?

Здравствуйте, Ikemefula, Вы писали:

I>Чушь. Смотри внимательно, одна из первых моих фунцый. Половина того, что в этом коде, нет ни в каком справочнике комманд, зато есть во многих книгах по ассемблеру.
ну а теперь по пунктам: что твой листинг говорит о кеше? Об архитектуре процессора? Можно ли в ней увидеть принцип работы стека?

I>Ну, хорошо, ты знал его на уровне комманд процессора. Сам виноват. Так устраивает ?
ну, вообще-то нормальные люди воспринимают ассемблер именно как систему команд + архитектуру процессора, а не набор макросов компилятора.

Здравствуйте, March_rabbit, Вы писали:

M_>ты не ответил на два приведенных вопроса. Прикинь, надо тебе отсортировать 32-х битные числа. Число n — реально большое. Ок.
M_>1) Хватит ли памяти для сортировки Θ(n^2)? А для сортировки Θ(n)? (ограничение по памяти)

Стратегия выбора алгоритма зависит от ресурсов машины и от частоты выполнения этого участка кода. Чаще всего имеют ввиду время работы алгоритма.

M_>2) Откуда возьмутся эти данные и куда их надо деть? (ограничение по скорости ввода-вывода)
M_>3) Сколько элементов данных нужно в отсортированном массиве?

Дополнительный анализ зависит от особенностей конкретной реализации.

Я говорил о том, что нужно всего лишь уметь пользоваться базовыми инструментами анализа, а углублятся на основе базовых знаний по ситуации в каждом отдельном случае.

Любая нормальная книга по ассемблеру содержит вводный курс по архитектуре процессора.

Здравствуйте, komaz, Вы писали:

K>С этим не поспоришь, но чем в этом плане дискретка лучше функционального анализа или ТФКП?

Ничем, просто когда ещё не знаешь математику, но она понадобилась для прочтения какой либо книжки по программированию, то хочется прочесть какой нибудь маленький мануальчик и всё. Ближе всего дискретка и это первое что приходит на ум. По прочтению дискретки начинает нравится (если понимаешь и литература удачна подобрана), и где-то через несколько месяцев изучения начинаешь осознавать, что любая математика развивает мышление и в принципе можно было начать с любого раздела. Во всяком случае у меня так было.

Здравствуйте, komaz, Вы писали:

K>Да я тоже не читал, более того — в обозримом будущем и не планирую, и по мне полезность этой книги примерно такая же, как у частично упорядоченных множеств, теории графов и конечных автоматов. Все же склад мышления первичен, а знания — дело наживное, есть, конечно, какой-то минимум (вполне холиварный вопрос, что подтверждает и этот топик), но в остальном лучше стараться применять lazy initialization по отношению к новым знаниям

Изучение фундаментальных концепций может сильно изменить образ мышления к лучшему, правда если изначально есть предрасположенность. Можно сказать, что фундаментальные концепции повышают уровень восприятия окружающего мира.

Здравствуйте, hal9000, Вы писали:

H>Изучение фундаментальных концепций может сильно изменить образ мышления к лучшему, правда если изначально есть предрасположенность. Можно сказать, что фундаментальные концепции повышают уровень восприятия окружающего мира.

Абсолютно согласен, но как это соотносится с необходимостью знать именно дискретку или теорию алгоритмов? Очевидно, что у этих знаний есть бонус в том, что, помимо собственно поднятия на следующий уровень восприятия, сушествует вероятность что они пригодятся на практике. Однако это всего лишь бонус, но не определяющий фактор.

Здравствуйте, March_rabbit, Вы писали:

I>>Чушь. Смотри внимательно, одна из первых моих фунцый. Половина того, что в этом коде, нет ни в каком справочнике комманд, зато есть во многих книгах по ассемблеру.
M_>ну а теперь по пунктам: что твой листинг говорит о кеше? Об архитектуре процессора? Можно ли в ней увидеть принцип работы стека?

По пунктам — листинг был приведен для того, что бы показать что ассемблер не сводится к коммандам процессора. Так понятно ?

Для того, что бы понять как работает кеш нужно уметь писать на ассемблере на отлично. И тоже самое с архитектурой и стеком.

I>>Ну, хорошо, ты знал его на уровне комманд процессора. Сам виноват. Так устраивает ?
M_>ну, вообще-то нормальные люди воспринимают ассемблер именно как систему команд + архитектуру процессора, а не набор макросов компилятора.

Вообще то для одного процессора много ассемблеров и даже одни и те же комманды там могут писаться по разному.

Здравствуйте, komaz, Вы писали:

k> AB>Напомнило байку про кошку и привязанную к ее хвосту консервную банку
k> Вопрос о том с какой скоростью она должна бежать чтобы не слышать грохот? или что-то другое?

Ага, оно самое.

Здравствуйте, March_rabbit, Вы писали:

M_>в данном примере есть ровно один вопрос: насколько часто должна применяться эта программа? Если раз в неделю — тогда ИМХО время ей выполнения не важно (если оно меньше недели ).

Согласен. Она запускается раз в сутки и рекорд был около 8 часов (я не помню, сколько тогда было записей в базе). После чего ее оптимизировали.

Ок, я готов тут признать (надеюсь, мой босс еще не выучил русский и этого не читает). Человек, написавший эту прогу, живет в Индии и получает денег мин раз в 10 меньше, чем я. Если бы он мог писать качественный софт, с которым не возникает подобных проблем, то не знаю, сколько бы я продержался на этой работе. ))) Вот такая диалектика. Но это все бизнес. Большие боссы так решили, им виднее.

В контексте же топика, как я и говорил, считаю, что понимание фундаментальных концепций необходимо для "тру программирования" (с). Для "фаст-фуд программирования" оно не обязательно.

Здравствуйте, komaz, Вы писали:

K>Абсолютно согласен, но как это соотносится с необходимостью знать именно дискретку или теорию алгоритмов? Очевидно, что у этих знаний есть бонус в том, что, помимо собственно поднятия на следующий уровень восприятия, сушествует вероятность что они пригодятся на практике. Однако это всего лишь бонус, но не определяющий фактор.

Дискретная математика и теория алгоритмов наиболее близки к непосредственному программированию и изучая их я стал более глубоко осознавать, то что написал ранее. Сомневаюсь, что это просто бонус, так как при попытке прорваться на более высокий уровень, рано или поздно придётся читать литературу умных людей, чтобы не изобретать велосипед, а подобная литература просто напичкана математическими выкладками.

Здравствуйте, hal9000, Вы писали:

H>Нужно ли понимание общих теоретических концепций для тру программирования?

Для Тру Программирования нужно сначала понимание предметной области. А потом уже можно думать, нужен ли в этой области асимптотический анализ, и если да, то в каком объеме.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>Без знания ассемблера ты просто не сможешь пощупать кеш, вряд ли поймешь что такое SIMD, а про арифметику с переполнением можешь просто забыть.
G>>С чего бы? я многократно рассказывал людям про архитектуру процессоров без упоминания ассемблерных команд.

I>Я выделил глаголы. Предположим, люди тебя слушали раз ты им рассказывал.
И они поняли, а как вообще пощупать кеш — вопрос интересный. Увидепть его влияние можно только профайлером или снимать показания счетчиков.

I>>>Справочник комманд это не ассемблер. И ассеблер это не справочник комманд.
G>>Ты выше написал что ассемблер — это язык. Язык определяется синтаксисом и семантикой. И то и другое можжно в справочнике команд найти.

I>Чушь. Смотри внимательно, одна из первых моих фунцый. Половина того, что в этом коде, нет ни в каком справочнике комманд, зато есть во многих книгах по ассемблеру.

К самому языку это отношения не имеет. Даже к ассемблеру как таковому мало относится.
вся это туча кода выполняет копирование части буфера в видеопамять. Даже можно рассказать о тонкостях адресации видеопамяти в текством и графическом режимах, не упоминая при этом ассемблер.
Еще раз: ассемблер как язык — не более чем набор мнемонических обозначений команд процессора. Сам по себе ассемблер ни чем не поможет без знания архитектуры системы.

I>Из примера выш функцию можно вызвать вот так
I>call wintobuffer sx,sy,ex,ey,buf
I>вот чудеса, комманда call умеет ажно аргументы всякие ! Вот так процессор Не подскажешь, что за код комманды ткой умной, в справочнике комманд это должно быть.
Вау, круто, макросы.
Какое отношение они имеют к ассемблеру?


I>>>Тебя испугал сигнальный микропросцессор что ли ?
G>>Ничем не испугал. Просто мои знания ассеблера x86 как языка (со всеми сопуствующими паттернами, архиетктурой) оказались бесполезными.
I>архитектура будет бесполезна, это так. Разумеется, все наработки придётся оставить, особенно библиотечки всякие.
I>Прикинь, при переходе с java на C# или наоборот все точно так же !
I>Зато опыт, разумеется, никуда девать не надо. Время на адаптацию и вперёд.
И имиенно поэтому знать принципы полезнее, чем знать отдельные языки.
Даже если это ассемблер.

I>>>Но сильно думаю, это потому что ассеблера ты и не знал вобщем то.
G>>Да придумывать недостатки оппоненту — это круто.

I>Я не придумал, ты свел ассемблер к системе комманд процессора. О чем говорить ?
О том чир то правда. Твой пример выше это подтвеждает.

I>Ну, хорошо, ты знал его на уровне комманд процессора. Сам виноват. Так устраивает ?
Ассемблер и есть команды процессора.

Здравствуйте, hal9000, Вы писали:

L>>Нет, из этого не следует тот вывод, который вы сделали.

H>Почему не следует?

Из того, что перечисленные книги не очень нужны основной массе программистов, не следует, что они не нужны никому.

Здравствуйте, gandjustas, Вы писали:

G>>>С чего бы? я многократно рассказывал людям про архитектуру процессоров без упоминания ассемблерных команд.

I>>Я выделил глаголы. Предположим, люди тебя слушали раз ты им рассказывал.
G>И они поняли, а как вообще пощупать кеш — вопрос интересный. Увидепть его влияние можно только профайлером или снимать показания счетчиков.

Для чего профайлер и счетчики ? Секундомера хватит. Берешь и вычисляешь функцию сто тысяч миллионов раз, а потом её же исправляешь и снова выполняешь столько же раз.
Сравниваешь время/кол.во выполнений и узнаешь результат.

I>>Чушь. Смотри внимательно, одна из первых моих фунцый. Половина того, что в этом коде, нет ни в каком справочнике комманд, зато есть во многих книгах по ассемблеру.

G>К самому языку это отношения не имеет. Даже к ассемблеру как таковому мало относится.

Ну ка, объясни, а код на си будет ли относиться к сишному коду ?

G>вся это туча кода выполняет копирование части буфера в видеопамять. Даже можно рассказать о тонкостях адресации видеопамяти в текством и графическом режимах, не упоминая при этом ассемблер.

Можно. Только что бы пощупать видеобуфер всерьез надо опять же знать ассемблер.

G>Еще раз: ассемблер как язык — не более чем набор мнемонических обозначений команд процессора. Сам по себе ассемблер ни чем не поможет без знания архитектуры системы.

Я уже понял — код на языке программирования не является кодом на этом языке программирования. Ага.

I>>Из примера выш функцию можно вызвать вот так
I>>call wintobuffer sx,sy,ex,ey,buf
I>>вот чудеса, комманда call умеет ажно аргументы всякие ! Вот так процессор Не подскажешь, что за код комманды ткой умной, в справочнике комманд это должно быть.
G>Вау, круто, макросы.
G>Какое отношение они имеют к ассемблеру?

Это и есть ассемблер. Язык ассемблера не сводится к коммандам.

G>И имиенно поэтому знать принципы полезнее, чем знать отдельные языки.
G>Даже если это ассемблер.

Конечно. Мне например давали эти общие принцыпы, а ты долбил конкретный язык и архитектуру.

I>>Я не придумал, ты свел ассемблер к системе комманд процессора. О чем говорить ?
G>О том чир то правда. Твой пример выше это подтвеждает.

Ну да. Как там было, код на языке программирования не является кодом на этом языке программирования

I>>Ну, хорошо, ты знал его на уровне комманд процессора. Сам виноват. Так устраивает ?
G>Ассемблер и есть команды процессора.

Ассемблер, кстати говоря, может быть ассемблером и при этом в нем не будет ни единой комманды процессора. Загадка для тебя.