GotAI.NET

Форум: Проблемы искусственного интеллекта

 

Регистрация | Вход

 Все темы | Новая тема Стр.86 (139)<< < Пред. | След. > >>   Поиск:  
 Автор Тема: На: Смысл.
IvanVlaskin1976
Сообщений: 511
На: Смысл.
Добавлено: 17 май 19 3:32
Изменено: 17 май 19 3:34
Цитата:
Автор: mss

Кстати. Есть задачка для Вани. Ну и для всех желающих.

Дано бинарное далеко не идеальное дерево. Нужно из него выкусить максиальное по размеру идеальное дерево.

Всё. Жду гениального алгоритма. Даю год.

Неидеальное дерево это граф
Да я как-то вырос из возраста "слабо"
Но несколько лет назад один товарисч предложил мне на спор на время написать игру "крестики-нолики", за несколько часов я наваял -

#include<stdio.h>
void main(void) {
int x,y;
char MaccuB[3][3];
a01:
for(x=0;x<3;x++) {
for(y=0;y<3;y++) {
MaccuB[x][y]=' ';
}
}
a02:
printf("BBeguTe X(1-3) u Y(1-3):\n");
scanf("%d %d",&x,&y);
if((x!=1&&x!=2&&x!=3)||(y!=1&&y!=2&&y!=3)||MaccuB[x-1][y-1]!=' ') {
printf("HeBepHblij xog\n");
goto a02;
}
MaccuB[x-1][y-1]='X';
printf("+-+-+-+\n");
for(y=0;y<3;y++) {
printf("|%c|%c|%c|\n",MaccuB[0][y],MaccuB[1][y],MaccuB[2][y]);
printf("+-+-+-+\n");
}
for(x=0;x<3;x++) if(MaccuB[x][0]=='X'&&MaccuB[x][1]=='X'&&MaccuB[x][2]=='X') goto a03;
for(y=0;y<3;y++) if(MaccuB[0][y]=='X'&&MaccuB[1][y]=='X'&&MaccuB[2][y]=='X') goto a03;
if(MaccuB[0][0]=='X'&&MaccuB[1][1]=='X'&&MaccuB[2][2]=='X') goto a03;
if(MaccuB[2][0]=='X'&&MaccuB[1][1]=='X'&&MaccuB[0][2]=='X') goto a03;
printf("Komn xoguT KaK\n");
a04:
x=rand()%3;
y=rand()%3;
if(MaccuB[x][y]!=' ') goto a04;
MaccuB[x][y]='O';
printf("+-+-+-+\n");
for(y=0;y<3;y++) {
printf("|%c|%c|%c|\n",MaccuB[0][y],MaccuB[1][y],MaccuB[2][y]);
printf("+-+-+-+\n");
}

for(x=0;x<3;x++) if(MaccuB[x][0]=='O'&&MaccuB[x][1]=='O'&&MaccuB[x][2]=='O') goto a05;
for(y=0;y<3;y++) if(MaccuB[0][y]=='O'&&MaccuB[1][y]=='O'&&MaccuB[2][y]=='O') goto a05;
if(MaccuB[0][0]=='O'&&MaccuB[1][1]=='O'&&MaccuB[2][2]=='O') goto a05;
if(MaccuB[2][0]=='O'&&MaccuB[1][1]=='O'&&MaccuB[0][2]=='O') goto a05;
goto a02;
a03:
printf("Bbl no6eguJlu\n");
goto a06;
a05:
printf("Bbl npou7paJlu\n");
a06:
printf("CHoBa?(1-Yes 0-No)\n");
scanf("%d",&x);
if(x==1) goto a01;
}
[Ответ][Цитата]
IvanVlaskin1976
Сообщений: 511
На: Смысл.
Добавлено: 17 май 19 3:43
Цитата:
Автор: mss



Про смысловые графы слышал только от вас. Вас уже просили пояснить суть... Могу попросить ещё раз. Но только пож-ста без ссылок на бессмысленные тексты от IvanVlaskin1976 и копипасты.

Попробуйте другими словами что бы вас люди понять могли.

значит вы невнимательно читали эту тему, это было на второй странице этой темы -
Цитата:
Автор: void

Добавлено: 30 янв 16 5:59

В информатике смысл удобней понимать как ссылку на внутреннюю структуру абстракции, входящие связи, а также на ссылающиеся на ней другие абстракции, исходящие связи, а осмысление, понимание – суть синтез системы низкоуровневых абстракций в высокоуровневую абстракцию. Мы имеем семантическую сеть, где узлы - абстракции, а структуру входящих и исходящих связей – их смыслами. Иначе говоря смысл это структура абстракции и её связей с другими абстракциями, что то типа абстрактного класса или интерфейса в ООП, вместе с архитектурой имплементации этой абстракции в проект. В такой концепции, ассоциативное мышление это перемещение через узлы сети, по некоторым наиболее “сильным” связям, с целью обнаружения скрытых взаимосвязей абстракций и затем формирования из них либо новых абстракций, либо “улучшая” существующие, в соответствии с критериями качества отдельных абстракций и всей семантической сети в целом.

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

Цитата:

Могу помочь с началом - приведите пример графа для смысла высказывания - мама мыла раму

вломы проводить семантический анализ, да ещё графическую информацию записывать в виде текста
делал уже как-то подобное -

== 04 == 2010-11-03 ==
3) на всякий случай расскажу как можно создать систему с абстрактным восприятием речи для создания совершенной среды взаимодействия человека с компьютером.Существительные в ней - это узлы графа, глаголы - могут быть связями между узлами, остальные части речи - могут быть характеристиками узлов и связей. Возможно узлы, связи и характеристики смогут динамически менять систему связей и даже свою пренадлежность - связи становиться узлами и прочее

щедрый купец купил на ярморке за монету кольцо у бродяги
преобразование предложения(метод магистра Йоды):
купил купец щедрый кольцо у бродяги за монету на ярморке
[as0001] { [ao0002] {otv(fv5,fsy,foy,ftNpn,fk1,wn,un)"купил"} [ao0003] {ots(fpi,fk1)"купец"[ah0004]{oth(fvh,fk1)"щедрость} } [ao0005] { otos(fpr,fk1)"кольцо"} [ao0006] {otn(fn=1234,fk1)"бродяга"} [ao0007] {otn(fn=1235,fk1)"монета" } [ao0008] {otn(fn=1236,fk1)"ярморка" } }
as - адрес системы
ao - адрес объекта
ah - адрес характеристики
ap - адрес родительской системы
ag - адрес предочной системы

o - object объект

t - type тип объекта

v - verb глагол
s - subject субъект
os - object субъектый объект
o1
o2
o3
o4
o5
o6
o7
o8
h - прилагательное
n - наречие

f - формат

fv - формат валентности
fv0 - глагол с пустой валентностью
fv1 - глагол с 1 валентностью
fv2 - глагол с 2 валентностью
fv3 - глагол с 3 валентностью
fv4 - глагол с 4 валентностью
fv5 - глагол с 5 валентностью
fv6 - глагол с 6 валентностью
fv7 - глагол с 7 валентностью
fvN - глагол с неопределенной валентностью

fs
fsy - глагол с субъектом
fsn - глагол без субъекта

fo
foy - глагол с субъектным_объектом
fon - глагол без субъектного_объекта

ft - формат времени
ftN - неопределенное время
ftNpn - неопределенное время прошедшего или настоящего времени
ftNnf - неопределенное время настоящего или будущего времени
ftp1 -прошедшее время единственного раза
ftpt - прошедшее время продолжительного раза
ftpr - прошедшее время отрезочного раза
ftpN - прошедшее время с неопределенным разом
ftn1 - настоящее время единственного раза
ftnt - настоящее время продолжительного раза
ftnr - настоящее время отрезочного раза
ftnN - настоящее время с неопределенным разом
ftf1 - будущее время единственного раза
ftft - будущее время продолжительного раза
ftfr - будущее время отрезочного раза
ftfN - будущее время с неопределенным разом

fk - формат количества
fkN - неопределенное количество
fk1 - единственным количество
fkK - множественное количество
fkS - одноразовое количество
fkD - дублирующее количество

fg - формат пола(гендерности)
fgN - неопределенный пол
fgNm - неопределенный пол в мужской форме
fgNw - неопределенный пол в женской форме
fgNo - неопределенный пол в средней форме
fgm - мужской пол
fgw - женский пол
fgo - средний пол

wn - вакансии нет
wys - вакансия субъекта
wyo - вакансия субъекного_объекта
wy1 - вакансия 1 объекта(возможно субъекта)
wy2 - вакансия 2 объекта(возможно субъекного_объекта)
wy3 - вакансия 3 объекта
wy4 - вакансия 4 объекта
wy5 - вакансия 5 объекта
wy6 - вакансия 6 объекта
wy7 - вакансия 7 объекта

un - уточнения нет
uys - уточнение субъекта
uyo - уточнение субъекного_объекта
uy1 - уточнение 1 объекта(возможно субъекта)
uy2 - уточнение 2 объекта(возможно субъекного_объекта)
uy3 - уточнение 3 объекта
uy4 - уточнение 4 объекта
uy5 - уточнение 5 объекта
uy6 - уточнение 6 объекта
uy7 - уточнение 7 объекта

fp - формат падежности
fpi - именительный падеж
fpr - родительный падеж
fpd - дательный падеж
fpw - винительный падеж
fpt - творительный падеж
fpp - предложный падеж

fv - формат вида прилагательного
fvv - формат вида глагол
fvo - формат вида объект
fvh - формат вида характеристика
[Ответ][Цитата]
bravo7
Сообщений: 571
На: Смысл.
Добавлено: 17 май 19 4:18
Изменено: 23 май 19 8:19
.
[Ответ][Цитата]
bravo7
Сообщений: 571
На: Смысл.
Добавлено: 17 май 19 4:50
Изменено: 23 май 19 8:19
.
[Ответ][Цитата]
гость
51.15.187.*
На: Смысл.
Добавлено: 17 май 19 5:10
Цитата:
Автор: IvanVlaskin1976


Неидеальное дерево это граф
Да я как-то вырос из возраста "слабо"
Но несколько лет назад один товарисч предложил мне на спор на время написать игру "крестики-нолики", за несколько часов я наваял -

#include<stdio.h>
void main(void) {
int x,y;
char MaccuB[3][3];
a01:
for(x=0;x<3;x++) {
for(y=0;y<3;y++) {
MaccuB[x][y]=' ';
}
}
a02:
printf("BBeguTe X(1-3) u Y(1-3):\n");
scanf("%d %d",&x,&y);
if((x!=1&&x!=2&&x!=3)||(y!=1&&y!=2&&y!=3)||MaccuB[x-1][y-1]!=' ') {
printf("HeBepHblij xog\n");
goto a02;
}
MaccuB[x-1][y-1]='X';
printf("+-+-+-+\n");
for(y=0;y<3;y++) {
printf("|%c|%c|%c|\n",MaccuB[0][y],MaccuB[1][y],MaccuB[2][y]);
printf("+-+-+-+\n");
}
for(x=0;x<3;x++) if(MaccuB[x][0]=='X'&&MaccuB[x][1]=='X'&&MaccuB[x][2]=='X') goto a03;
for(y=0;y<3;y++) if(MaccuB[0][y]=='X'&&MaccuB[1][y]=='X'&&MaccuB[2][y]=='X') goto a03;
if(MaccuB[0][0]=='X'&&MaccuB[1][1]=='X'&&MaccuB[2][2]=='X') goto a03;
if(MaccuB[2][0]=='X'&&MaccuB[1][1]=='X'&&MaccuB[0][2]=='X') goto a03;
printf("Komn xoguT KaK\n");
a04:
x=rand()%3;
y=rand()%3;
if(MaccuB[x][y]!=' ') goto a04;
MaccuB[x][y]='O';
printf("+-+-+-+\n");
for(y=0;y<3;y++) {
printf("|%c|%c|%c|\n",MaccuB[0][y],MaccuB[1][y],MaccuB[2][y]);
printf("+-+-+-+\n");
}

for(x=0;x<3;x++) if(MaccuB[x][0]=='O'&&MaccuB[x][1]=='O'&&MaccuB[x][2]=='O') goto a05;
for(y=0;y<3;y++) if(MaccuB[0][y]=='O'&&MaccuB[1][y]=='O'&&MaccuB[2][y]=='O') goto a05;
if(MaccuB[0][0]=='O'&&MaccuB[1][1]=='O'&&MaccuB[2][2]=='O') goto a05;
if(MaccuB[2][0]=='O'&&MaccuB[1][1]=='O'&&MaccuB[0][2]=='O') goto a05;
goto a02;
a03:
printf("Bbl no6eguJlu\n");
goto a06;
a05:
printf("Bbl npou7paJlu\n");
a06:
printf("CHoBa?(1-Yes 0-No)\n");
scanf("%d",&x);
if(x==1) goto a01;
}
А у Вас случайно генетический алгоритм не завалялся гдето? тут все спрашивают, а ни у кого нет.
[Ответ][Цитата]
IvanVlaskin1976
Сообщений: 511
На: Смысл.
Добавлено: 17 май 19 5:18
Цитата:
Автор: гость

А у Вас случайно генетический алгоритм не завалялся гдето? тут все спрашивают, а ни у кого нет.

я живу по принципу - всех фильмов не пересмотришь, всех песен не послушаешь, всех книг не прочитаешь
я даже не представляю что такое генетический алгоритм, мне он просто не актуален, по крайней мере для проэктов которые я реализую
[Ответ][Цитата]
Влад
Сообщений: 1104
На: Смысл.
Добавлено: 17 май 19 8:03
Изменено: 17 май 19 8:04
Цитата:
Автор: bravo7
На самом деле у Канта два основания - пространство и время, то есть как объём понятия, так и его содержание.

Не понятна логика оснований:
если «Пространство» и «Время», то почему исключены «Материя» и «Пустота»,
если «Единичные», то почему всё, не до обобщено в «Элемент»?
[Ответ][Цитата]
bravo7
Сообщений: 571
На: Смысл.
Добавлено: 17 май 19 8:57
Изменено: 23 май 19 8:19
.
[Ответ][Цитата]
гость
51.15.125.*
На: Смысл.
Добавлено: 17 май 19 9:07
Цитата:
Автор: IvanVlaskin1976


я живу по принципу - всех фильмов не пересмотришь, всех песен не послушаешь, всех книг не прочитаешь
я даже не представляю что такое генетический алгоритм, мне он просто не актуален, по крайней мере для проэктов которые я реализую
Это правильные принципы. Но есть набор алгоритмов без знания которых программист так сказать "не доконца созрел", не возмужал, например алгоритм быстрой сортировки, kNN, MLP, к ним относится и ген-алгоритм, ну или хотябы алгоритм имитации отжига. Советую разобраться чтобы не краснеть в приличном обществе))
[Ответ][Цитата]
IvanVlaskin1976
Сообщений: 511
На: Смысл.
Добавлено: 17 май 19 9:36
Цитата:
Автор: гость

Это правильные принципы. Но есть набор алгоритмов без знания которых программист так сказать "не доконца созрел", не возмужал, например алгоритм быстрой сортировки, kNN, MLP, к ним относится и ген-алгоритм, ну или хотябы алгоритм имитации отжига. Советую разобраться чтобы не краснеть в приличном обществе))

Я не приличное общество, я элита
разбираться во всяком ненужном дерьме это как отправить Ньютона варить борщ, и удивляться тому что он не может сделать даже яичницу

==
3.программирование

предупреждение: в написании этого труда похоже участвовало несколько авторов, когда писал я, Власкин Иван Иванович, дата рождения 1976-03-18, то я в начале абзацов писал текст без заглавных букв и в конце абзацев не ставил точки

Понятие алгоритма. Одним из фундаментальных понятий в информатике является понятие алгоритма. Происхождение самого термина «алгоритм» связано с математикой. Это слово происходит от Algorithm - латинского написания имени Мухаммеда аль-Хорезми (787-850), выдающегося математика средневекового Востока.В XII в. был выполнен латинский перевод его математического трактата, из которго европейцы узнали о десятичной позиционной системе счисления и правилах арифметики многозначных чисел. Именно эти правила в то время называли алгоритмами. Сложение, вычитание, умножение столбиком, деление уголком многозначных чисел – вот первые алгоритмы в математике.

=====
программирование включает разные категории программирования:
1.по типу логики решения задания (редукция, индукция, дедукция)
2.по направлению синтеза решения (программирование "сверху", программирование "снизу")
3.по структуре реализации алгоритма (структурное или блочное)
4.по использованию функций (с функциями или без функций)

====
по типу логики решения задания существуют:
1.редукция - когда известны исходные данные и как их надо преобразовать - известно также как нисходящая декомпозиция или пошаговое усовершенствование
2.индукция - когда известен формат результата, формат исходных данных и надо создать алгоритм
3.дедукция - когда есть программа и надо понять смысл её работы - для этого надо абстрагировать алгоритм программы в автомат
в ходе программирования эти типы могут комбинироваться

для каждого типа программирования существует свой тип проверки правильности алгоритма программы
1.для редукции:
- берутся значения для которых известны правильные результаты и сравниваются с результатами программы
- строится обратная функция и по ней проверяются результаты программы
2.для индукции: берутся крайние значения и точки экстремума функций формата исходных данных и сравнивается результат работы программы с требуемым форматом исходных данных
3.для дедукции: представляется алгоритм программы как автомат, и определяется изза чего и в каких областях значений срабатывают переходы этого автомата

====
по направлению синтеза решения существуют:
1.программирование "сверху" или конструирование функции
=
достоинства:
1.Хорошо решает проблемы имеющие иерархический характер
2.Большая группа схожих проблем может быть идентифицирована и замещена одной функцией.
3.Каждая из этих проблем относительно мала и может характеризоваться малым числом параметров.
4.Каждая из проблем отличается от других (иначе говоря, унификация требует многократного использования проекта и его кода в каждой проблеме).
5.Нет включения сложных структур данных (иначе концептуальная автономия каждого прикладного модуля была бы потеряна).

Области, которые соответствуют этим критериям, включают библиотеки математических подпрограмм для решения проблем линейной алгебры и дифференциально-разностных уравнений.
=
недостатки:
1.Функциональную точку зрения трудно развивать.
Каждая реальная система изменяется и эволюционирует. Нисходящий подход создает хорошую программную модель для исходных требований к системе. Но система изменяется, что ведет к появлению новых требований. Поэтому функциональная архитектура постепенно становится неуправляемой. Поскольку программное обеспечение разработано вокруг относительно фиксированной древовидной структуры, изменения обычно требуют длительного сокращения и прививания. Чистый и хорошо разработанный проект быстро становится "ужастиком", повествующим о новых и повисших связях. Сопровождение становится все более трудным, поскольку первоначальная архитектура медленно умирает с каждой новацией или изменением требований.
2.Реальные системы трудно охарактеризовать функционально.
Многие из больших систем не имеют верхнего уровня. Например, система управления базой данных включает инструментальные средства для запроса данных, изменение данных, хранение непротиворечивых данных, и т.д. Нет какой-либо функции, являющейся самым важным звеном в этой системе. Определение этой системы в терминах одной функции верхнего уровня искусственно и приводит к чрезмерно сложным и неадаптивным архитектурам.
"Одним из наиболее важных решений, принимаемым при разработке системы, является предположение о том, как сделать декомпозицию верхнего уровня. При нисходящем подходе это решение необходимо принять в начале процесса проектирования, то есть тогда, когда имеется минимум информации... Возможно, наиболее серьезная слабость в том, что нисходящее функциональное проектирование требует, чтобы система характеризовалась одной функцией наверху. Это сомнительное требование для многих современных систем, управляемых событиями".
3.Фокусирование на функциональности теряет из виду данные.
Нисходящий проект не фиксирует информацию о данных, используемых в программе. Функции же всегда что-то делают с данными. Обычно, одни и те же данные разделены между функциями (например, модификации, удаления, вставки и запроса, работающих с таблицей базы данных). Так как декомпозиция только высвечивает функциональные аспекты проблемы, влияние структур данных на проблему оказывается потерянным.
4.Функциональная ориентация производит код, менее пригодный для многократного использования.
При нисходящем проектировании осуществляется непрерывное дробление проблемы на все более простые части. Каждый кусок анализируется и специфицируется отдельно без сильной связи между ним и остальной частью системы. Это является одной из причин, по которой проектирование "сверху вниз" так эффективно на этапе анализа проблемы. Данный метод работает хорошо при начальном проектировании системы, и помогает получить спецификации для выявления и решения проблемы. Однако каждый элемент программы разработан только с ограниченными требованиями к памяти. Так как маловероятно, что точно такие же требования встретятся при решении следующей проблемы, проект программы и код не могут быть обобщены для многократного использования.
=
проблемы:
1.Когда необходимо иметь дело с более сложными проблемами приходится иметь индивидуальные подпрограммы со многими параметрами
Большое число параметров будет делать подпрограмму трудно используемой и трудно сопровождаемой. Код, скорее всего, будет включать многочисленные вложения операторов if или case. Это кошмар при таких модификациях, как новые добавления к пространству состояний.
2.Когда необходимо иметь дело с более сложными проблемами приходится иметь много малых подпрограмм с небольшим числом параметров.
Большое количество подпрограмм будет затруднять их запоминание, что затрудняет использование. Более того, будет иметься много общего кода, рассеянного среди этих многих подпрограмм (так как многие из них будут очень похожи). Этот общий код будет трудно модифицировать и поддерживать. Библиотеки подпрограмм полезны в некоторых областях, но они не решают общих проблем, присущих синтезу.
3.Синтез не препятствует созданию общих подпрограмм, которые разделяются между многими программами; но оно не поощряет этот процесс.

===
2.программирование "снизу":
=
достоинства:
1.Хорошо объединеняет повторно используемые программы и подпрограммы в систему
=
недостатки:
1.сложность программы, с увеличением числа переменных, функций и их комбинаций, возрастает в геометрической прогрессии, изза чего:
- сложно запомнить предназначение переменных, функций и адресных меток блоков
- с увеличением количества строк уходит много времени на поиск требуемого текста программы и перемотку к нему

====
по структуре реализации алгоритма существуют:
1.структурное программирование - представление программы в виде одной структуры с ветвением на подструктуры с помощью оператров if, for, case, switch, while, do
2.блочное программирование - представление программы в виде адресованных метками(label) блоков с переходами к ним по оператору goto

==
1.структурное программирование
=
позволяет:
1.возможность легкого заимстования кода в другие программы
2.возможность легкого мелкого улучшения программ
=
создает проблемы:
1.при большой вложенности циклов теряется читабельность программы
2.при большой вложенности циклов неудобно редактировать программу в связи с большим количеством символов отступов показывающих степень вложенности команд в ядре цикла
3.для проверки приходится в мозгу переводить все структуры в автомат

==
2.блочное программирование
=
позволяет:
1.возможность блочного программирования и как подраздел его - программирование автоматов (можно вместо goto использовать switch do и break, но это усложняет программу, теряет её наглядность и увеличивает количество её строк)
2.быструю скорость программирования
3.легкость понимания алгоритма кода
4.легкость проверки кода на корректность работы алгоритмов
5.возможность масштабных переходов, когда можно перейти сразу в конец программы без учета всяких закрывающих ковычек, слабую возможность этого делает break
=
создает проблемы:
1.можно потерять данные
2.можно потерять указатели
3.можно перепутать переменную изза использования одной и той же переменной для разных задач
4.если ваш работадатель узнает что вы в своем коде ставите goto вас могут уволить за якобы непрофессионализм, или если при приёме на работу в вашем тестовом задании увидят goto вам могут отказать в приёме на работу
5.вас могут презирать ваши коллеги программисты за использование goto как непрофессионала
6.ваш заказчик, если кто-нибудь ему сообщит что вы используете goto в программе, может отказать вам в заказе
7.ваша репутация может быть испорчена

====
по использованию функций существуют:
1.программирование с функциями
2.программирование без функций
=
достоинства функций:
1.более понятный текст программы, особенно если название функции описывает её действие
2.более короткий исходный код
3.экономия памяти ОЗУ
=
недостатки функций:
1.изза функций сложно использовать такой мощный инструмент как рекурсия, поскольку работающая со стеком функция использует изза рекурсии слишком много памяти, расходуемой стеком на передачу адреса возврата функции, либо вообще возможна утечка памяти
2.функция - это потеря времени на переходы и работу со стеком, потеря времени на резервное хранение параметров функции, потеря памяти на работу стека функции и её переменных

=====
Основное различие между традиционными структурными методологиями проектирования и более новыми объектно-ориентированными методологиями находится в их первичном фокусировании:
Структурные методы проектирования фокусируются на функциях системы: "Что она делает".
Объектно-ориентированные методы фокусируются на данных (объектах) системы: "Что делается с...".

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

=====
параметры программы:
1.Корректность (правильность) - Обеспечивает правильную обработку на правильных данных
2.Устойчивость - "Элегантно" завершает обработку ошибок
3.Расширяемость(масштабируемость) - Может легко адаптироваться к изменяющимся требованиям
4.Многократность использования(кроссплатформенность) - Может использоваться и в других системах, а не только в той, для которой было создано.
5.Совместимость - Может легко использоваться с другим программным обеспечением
6.Эффективность - Эффективное использование времени, компьютерной памяти, дискового пространства и т.д.
7.Переносимость(кроссплатформенность) - Можно легко перенести на другие аппаратные и программные средства
8.Верификация - Простота проверки, легкость разработки тестов при обнаружении ошибок, легкость обнаружения мест, где программа потерпела неудачу, и т.д.
9.Поддержка целостности - Защищает себя от неправильного обращения и неправильного употребления
10.Легкость использования(интуитивно-понятный интерфейс) - Для пользователя и для будущих программистов
11.Читабельный код - Для легкости использования программистом алгоритма кода с целью его изменения или заимствования

====
1.Корректность
2.Устойчивость
Легко спутать термины "Корректная программа" и "Устойчивая программа". Корректная программа работает, когда поданы на вход правильные данные. Она отвечает всем требованиям к спецификации данных и не терпит неудачу внутри заданного диапазона. Устойчивость подразумевает не только правильность. Устойчивая программа способна обработать ситуации, не запланированные проектом. Эти ситуации включают некорректный ввод пользователя, аппаратный отказ и ошибки во время выполнения программы. Устойчивые системы терпят неудачу элегантно, без потери критических данных. Легко увидеть, что обе характеристики необходимы для любой системы, которая будет оценена как высококачественное программное обеспечение. Если система некорректна, то она бесполезна. Если система неустойчива, то она окажется неспособной справиться с задачей в реальной ситуации.

====
3.Расширяемость
Требований меняются. Это - один из бесспорных фактов процесса разработки программ. Высококачественная программа способна иметь дело с этими изменениями относительно безболезненно. Этот сорт адаптируемости - не является существенным для малых проектов, но становится определяющим, когда происходит "программирование в большом".
Два основных принципа создания расширяемого программного обеспечения:
=
3.1.сложность проекта.
Более простые проект и архитектура позволяют произвести изменения намного быстрее и легче, чем при сложном проекте.
термины сложность(вкл. аспекты - требования к эффективности алгоритмов,
емкость проектной задачи, наукоёмкость), ёмкость(объём работ и кол-во задач), наукоёмкость(исп. технологии).
Сложность бывает аналитическая, архитектурная и практическая.
Аналитическая - на стадии анализа задач и подбора алгоритмов. Самые сложные - недетерминированные и наукоёмкие алгоритмы.
Архитектурная - на стадии разработки\выбора архитектуры проекта.
Практическая - на стадии реализации(кодирования).
=
3.2.Декомпозиция.
Разбиение сложных проблем на малые. Управляемость и независимость фрагментов, означающая, что они могут быть поделены внутри себя. Это значит, что изменения, могут быть выполнены без перекраивания других частей системы.
=
Эти принципы позволяют нам понять проблему в частях без опасения затеряться в несметном количестве непостижимых подробностей.

====
4.Многократность (повторность) использования и совместимость
Многократное использование может просматриваться на различных уровнях: при анализе, проектировании, и реализации.
Оно поддерживает качество следующими способами:
=
Если проекты и код могут повторно использоваться, то мы можем начинать с уже проверенных, опробованных и правильных компонент, качество которых уже является высоким.
=
Время и энергия, сохраненные через многократное использование, могут применяться для улучшения других характеристик качества программы (например, корректности или устойчивости).

====
5.Совместимость программного обеспечения
Мера того, насколько просто объединить различные программные изделия вместе для нового применения. Основы совместимости вытекают из общих проектных решений. Например, файловая система UNIX разработана таким образом, чтобы позволить малым инструментальным средствам хорошо работать вместе при решении сложных проблем.
Противоположным примером является типичный беспорядок при совместной подготовке текстов и графических изображений. В этом случае, большие усилия должны быть затрачены на создание транслятора, которые позволяет одной программе работать с другой.

Совместимость и многократное(повторное) использование идут "взявшись за руки", потому что повторно используемое программное обеспечение (например, plug&play компоненты) должно быть совместимо с его новым окружением. Совместимое программное обеспечение поддерживает качество посредством использования прошлых усилий и подпорок при формировании новых систем. Программное обеспечение с низким коэффициентом совместимости требует огромных усилий, чтобы настроить систему на необходимое использование(кастомизация). Это усилие могло быть потрачено на проектирование лучшей системы или на улучшение эффективности кода.

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

=====
В работе "Научные основы доказательного программирования" А.П.Ершов выделял три вида программирования:
1.Синтезирующее (автоматическое, автоматизированное или ручное манипулирование знанием о задаче с синтезом соответствующей программы)
2.Сборочное (построение программы из уже существующих и корректных фрагментов)
3.Конкретизирующее (построение специализированных программ из универсальных заготовок). Их отображение на распространенные ныне парадигмы и языки программирования имеет следующий вид.
=
1.Синтезирующее программирование:
императивное (Паскаль, Си);
логическое (Пролог);
функциональное (Лисп);
параллельное (параллельный Паскаль, Оккам).
=
2.Сборочное программирование:
модульное (Модула-2, Ада);
компонентное (Эйфель, Component Pascal).
=
3.Конкретизирующее программирование:
объектно-ориентированное (Smalltalk, Си++, Оберон, Java);
шаблонно-ориентированное (Си++, Clarion).

=====
Литература:
1.Гари Уорен Кинг (Gary Warren King) - статья "Объектно-ориентированный подход действительно лучше структурного"
2.А.П.Ершов "Научные основы доказательного программирования"
3.Руслан Богатырев "Об автоматном и асинхронном программировании"
4.Зюбин В.Е. статья "Графические и текстовые формы спецификации сложных управляющих алгоритмов: непримиримая оппозиция или кооперация?"

==========
изучить:
Одной из таких удобных абстракций могут служить конечные автоматы, среди разновидностей которых стоит выделить трансдюсеры (transducer), автоматы Мили и Мура.
..
Однако при этом надо четко себе представлять, в чем их недостатки, а для этого придется обратиться к истокам программирования, к идеям "механического" вычисления. Как известно, они воплотились в таких формальных моделях, как машины Тьюринга (1936), комбинаторные процессы Поста (1936), нормальные алгоритмы Маркова (1951).
..
Чтобы ответить на этот вопрос и определить место конечных автоматов среди других абстракций, рассмотрим сети Петри, занимающие промежуточное положение между машинами Тьюринга и конечными автоматами. Сети Петри работают в терминах условий и событий, где первым сопоставлены позиции (особые узлы - емкости для хранения фишек связаны ориентированными дугами с переходами), а последним - переходы (особые узлы-действия, перемещающие фишки и связанные ориентированными дугами с позициями). Конечные автоматы являются частным случаем сетей Петри и эквивалентны автоматным сетям Петри - сетям, в которых каждый переход может иметь точно одну входную и выходную позицию.

Сети Петри лучше всего подходят для описания любых асинхронных систем (асинхронное программирование), тогда как конечные автоматы - лишь для сугубо последовательных систем (автоматное программирование). (Система взаимосвязанных автоматов реализует параллельные системы - замечание Шалыто А.А.). Наглядность динамики и композиционные возможности сетей Петри выше (при различии понятий "позиция" и "состояние", что требует построения графа достижимых маркировок для определения функциональных возможностей сети Петри - замечание Шалыто А.А.), чем у конечных автоматов, но при этом компактность представления предпочтительнее у последних. Что касается отношения к машине Тьюринга, то достаточно расширить сеть Петри сдерживающими дугами (позволяющими определять отсутствие фишек в данной позиции), как она же становится эквивалентной машине Тьюринга. Очевидно, что чем "мощнее" абстракция, чем больше она позволяет синтезировать возможностей, тем хуже у нее дело обстоит с анализом. Иными словами, конечные автоматы анализировать гораздо проще, чем классические сети Петри и уж тем более чем машины Тьюринга.
==========
сырой материал

что узнать -
редукция
индукция
дедукция

трансдюсеры (transducer)
автоматы Мили и Мура
машины Тьюринга
комбинаторные процессы Поста
нормальные алгоритмы Маркова
сети Петри
==========

более подробно -
Трактат о развитии мозга - http://forum.tomsk.ru/forum/12/1613742/?p=5 - Трактат о развитии мозга
[Ответ][Цитата]
Влад
Сообщений: 1104
На: Смысл.
Добавлено: 17 май 19 9:45
Цитата:
Автор: bravo7
Не понял вопроса, перефразируйте пошире.

«Пространство», «Время», «Материя», «Пустота», это элементы, хоть и разной природы,
объединенные в одно целое, через сосуществование, дологическая база, если раскрыть
это сосуществование.
[Ответ][Цитата]
гость
51.15.125.*
На: Смысл.
Добавлено: 17 май 19 9:47
Цитата:
Автор: IvanVlaskin1976


Я не приличное общество, я элита
разбираться во всяком ненужном дерьме это как отправить Ньютона варить борщ, и удивляться тому что он не может сделать даже яичницу

==
3.программирование

предупреждение: в написании этого труда похоже участвовало несколько авторов, когда писал я, Власкин Иван Иванович, дата рождения 1976-03-18, то я в начале абзацов писал текст без заглавных букв и в конце абзацев не ставил точки

Понятие алгоритма. Одним из фундаментальных понятий в информатике является понятие алгоритма. Происхождение самого термина «алгоритм» связано с математикой. Это слово происходит от Algorithm - латинского написания имени Мухаммеда аль-Хорезми (787-850), выдающегося математика средневекового Востока.В XII в. был выполнен латинский перевод его математического трактата, из которго европейцы узнали о десятичной позиционной системе счисления и правилах арифметики многозначных чисел. Именно эти правила в то время называли алгоритмами. Сложение, вычитание, умножение столбиком, деление уголком многозначных чисел – вот первые алгоритмы в математике.

=====
программирование включает разные категории программирования:
1.по типу логики решения задания (редукция, индукция, дедукция)
2.по направлению синтеза решения (программирование "сверху", программирование "снизу")
3.по структуре реализации алгоритма (структурное или блочное)
4.по использованию функций (с функциями или без функций)

====
по типу логики решения задания существуют:
1.редукция - когда известны исходные данные и как их надо преобразовать - известно также как нисходящая декомпозиция или пошаговое усовершенствование
2.индукция - когда известен формат результата, формат исходных данных и надо создать алгоритм
3.дедукция - когда есть программа и надо понять смысл её работы - для этого надо абстрагировать алгоритм программы в автомат
в ходе программирования эти типы могут комбинироваться

для каждого типа программирования существует свой тип проверки правильности алгоритма программы
1.для редукции:
- берутся значения для которых известны правильные результаты и сравниваются с результатами программы
- строится обратная функция и по ней проверяются результаты программы
2.для индукции: берутся крайние значения и точки экстремума функций формата исходных данных и сравнивается результат работы программы с требуемым форматом исходных данных
3.для дедукции: представляется алгоритм программы как автомат, и определяется изза чего и в каких областях значений срабатывают переходы этого автомата

====
по направлению синтеза решения существуют:
1.программирование "сверху" или конструирование функции
=
достоинства:
1.Хорошо решает проблемы имеющие иерархический характер
2.Большая группа схожих проблем может быть идентифицирована и замещена одной функцией.
3.Каждая из этих проблем относительно мала и может характеризоваться малым числом параметров.
4.Каждая из проблем отличается от других (иначе говоря, унификация требует многократного использования проекта и его кода в каждой проблеме).
5.Нет включения сложных структур данных (иначе концептуальная автономия каждого прикладного модуля была бы потеряна).

Области, которые соответствуют этим критериям, включают библиотеки математических подпрограмм для решения проблем линейной алгебры и дифференциально-разностных уравнений.
=
недостатки:
1.Функциональную точку зрения трудно развивать.
Каждая реальная система изменяется и эволюционирует. Нисходящий подход создает хорошую программную модель для исходных требований к системе. Но система изменяется, что ведет к появлению новых требований. Поэтому функциональная архитектура постепенно становится неуправляемой. Поскольку программное обеспечение разработано вокруг относительно фиксированной древовидной структуры, изменения обычно требуют длительного сокращения и прививания. Чистый и хорошо разработанный проект быстро становится "ужастиком", повествующим о новых и повисших связях. Сопровождение становится все более трудным, поскольку первоначальная архитектура медленно умирает с каждой новацией или изменением требований.
2.Реальные системы трудно охарактеризовать функционально.
Многие из больших систем не имеют верхнего уровня. Например, система управления базой данных включает инструментальные средства для запроса данных, изменение данных, хранение непротиворечивых данных, и т.д. Нет какой-либо функции, являющейся самым важным звеном в этой системе. Определение этой системы в терминах одной функции верхнего уровня искусственно и приводит к чрезмерно сложным и неадаптивным архитектурам.
"Одним из наиболее важных решений, принимаемым при разработке системы, является предположение о том, как сделать декомпозицию верхнего уровня. При нисходящем подходе это решение необходимо принять в начале процесса проектирования, то есть тогда, когда имеется минимум информации... Возможно, наиболее серьезная слабость в том, что нисходящее функциональное проектирование требует, чтобы система характеризовалась одной функцией наверху. Это сомнительное требование для многих современных систем, управляемых событиями".
3.Фокусирование на функциональности теряет из виду данные.
Нисходящий проект не фиксирует информацию о данных, используемых в программе. Функции же всегда что-то делают с данными. Обычно, одни и те же данные разделены между функциями (например, модификации, удаления, вставки и запроса, работающих с таблицей базы данных). Так как декомпозиция только высвечивает функциональные аспекты проблемы, влияние структур данных на проблему оказывается потерянным.
4.Функциональная ориентация производит код, менее пригодный для многократного использования.
При нисходящем проектировании осуществляется непрерывное дробление проблемы на все более простые части. Каждый кусок анализируется и специфицируется отдельно без сильной связи между ним и остальной частью системы. Это является одной из причин, по которой проектирование "сверху вниз" так эффективно на этапе анализа проблемы. Данный метод работает хорошо при начальном проектировании системы, и помогает получить спецификации для выявления и решения проблемы. Однако каждый элемент программы разработан только с ограниченными требованиями к памяти. Так как маловероятно, что точно такие же требования встретятся при решении следующей проблемы, проект программы и код не могут быть обобщены для многократного использования.
=
проблемы:
1.Когда необходимо иметь дело с более сложными проблемами приходится иметь индивидуальные подпрограммы со многими параметрами
Большое число параметров будет делать подпрограмму трудно используемой и трудно сопровождаемой. Код, скорее всего, будет включать многочисленные вложения операторов if или case. Это кошмар при таких модификациях, как новые добавления к пространству состояний.
2.Когда необходимо иметь дело с более сложными проблемами приходится иметь много малых подпрограмм с небольшим числом параметров.
Большое количество подпрограмм будет затруднять их запоминание, что затрудняет использование. Более того, будет иметься много общего кода, рассеянного среди этих многих подпрограмм (так как многие из них будут очень похожи). Этот общий код будет трудно модифицировать и поддерживать. Библиотеки подпрограмм полезны в некоторых областях, но они не решают общих проблем, присущих синтезу.
3.Синтез не препятствует созданию общих подпрограмм, которые разделяются между многими программами; но оно не поощряет этот процесс.

===
2.программирование "снизу":
=
достоинства:
1.Хорошо объединеняет повторно используемые программы и подпрограммы в систему
=
недостатки:
1.сложность программы, с увеличением числа переменных, функций и их комбинаций, возрастает в геометрической прогрессии, изза чего:
- сложно запомнить предназначение переменных, функций и адресных меток блоков
- с увеличением количества строк уходит много времени на поиск требуемого текста программы и перемотку к нему

====
по структуре реализации алгоритма существуют:
1.структурное программирование - представление программы в виде одной структуры с ветвением на подструктуры с помощью оператров if, for, case, switch, while, do
2.блочное программирование - представление программы в виде адресованных метками(label) блоков с переходами к ним по оператору goto

==
1.структурное программирование
=
позволяет:
1.возможность легкого заимстования кода в другие программы
2.возможность легкого мелкого улучшения программ
=
создает проблемы:
1.при большой вложенности циклов теряется читабельность программы
2.при большой вложенности циклов неудобно редактировать программу в связи с большим количеством символов отступов показывающих степень вложенности команд в ядре цикла
3.для проверки приходится в мозгу переводить все структуры в автомат

==
2.блочное программирование
=
позволяет:
1.возможность блочного программирования и как подраздел его - программирование автоматов (можно вместо goto использовать switch do и break, но это усложняет программу, теряет её наглядность и увеличивает количество её строк)
2.быструю скорость программирования
3.легкость понимания алгоритма кода
4.легкость проверки кода на корректность работы алгоритмов
5.возможность масштабных переходов, когда можно перейти сразу в конец программы без учета всяких закрывающих ковычек, слабую возможность этого делает break
=
создает проблемы:
1.можно потерять данные
2.можно потерять указатели
3.можно перепутать переменную изза использования одной и той же переменной для разных задач
4.если ваш работадатель узнает что вы в своем коде ставите goto вас могут уволить за якобы непрофессионализм, или если при приёме на работу в вашем тестовом задании увидят goto вам могут отказать в приёме на работу
5.вас могут презирать ваши коллеги программисты за использование goto как непрофессионала
6.ваш заказчик, если кто-нибудь ему сообщит что вы используете goto в программе, может отказать вам в заказе
7.ваша репутация может быть испорчена

====
по использованию функций существуют:
1.программирование с функциями
2.программирование без функций
=
достоинства функций:
1.более понятный текст программы, особенно если название функции описывает её действие
2.более короткий исходный код
3.экономия памяти ОЗУ
=
недостатки функций:
1.изза функций сложно использовать такой мощный инструмент как рекурсия, поскольку работающая со стеком функция использует изза рекурсии слишком много памяти, расходуемой стеком на передачу адреса возврата функции, либо вообще возможна утечка памяти
2.функция - это потеря времени на переходы и работу со стеком, потеря времени на резервное хранение параметров функции, потеря памяти на работу стека функции и её переменных

=====
Основное различие между традиционными структурными методологиями проектирования и более новыми объектно-ориентированными методологиями находится в их первичном фокусировании:
Структурные методы проектирования фокусируются на функциях системы: "Что она делает".
Объектно-ориентированные методы фокусируются на данных (объектах) системы: "Что делается с...".

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

=====
параметры программы:
1.Корректность (правильность) - Обеспечивает правильную обработку на правильных данных
2.Устойчивость - "Элегантно" завершает обработку ошибок
3.Расширяемость(масштабируемость) - Может легко адаптироваться к изменяющимся требованиям
4.Многократность использования(кроссплатформенность) - Может использоваться и в других системах, а не только в той, для которой было создано.
5.Совместимость - Может легко использоваться с другим программным обеспечением
6.Эффективность - Эффективное использование времени, компьютерной памяти, дискового пространства и т.д.
7.Переносимость(кроссплатформенность) - Можно легко перенести на другие аппаратные и программные средства
8.Верификация - Простота проверки, легкость разработки тестов при обнаружении ошибок, легкость обнаружения мест, где программа потерпела неудачу, и т.д.
9.Поддержка целостности - Защищает себя от неправильного обращения и неправильного употребления
10.Легкость использования(интуитивно-понятный интерфейс) - Для пользователя и для будущих программистов
11.Читабельный код - Для легкости использования программистом алгоритма кода с целью его изменения или заимствования

====
1.Корректность
2.Устойчивость
Легко спутать термины "Корректная программа" и "Устойчивая программа". Корректная программа работает, когда поданы на вход правильные данные. Она отвечает всем требованиям к спецификации данных и не терпит неудачу внутри заданного диапазона. Устойчивость подразумевает не только правильность. Устойчивая программа способна обработать ситуации, не запланированные проектом. Эти ситуации включают некорректный ввод пользователя, аппаратный отказ и ошибки во время выполнения программы. Устойчивые системы терпят неудачу элегантно, без потери критических данных. Легко увидеть, что обе характеристики необходимы для любой системы, которая будет оценена как высококачественное программное обеспечение. Если система некорректна, то она бесполезна. Если система неустойчива, то она окажется неспособной справиться с задачей в реальной ситуации.

====
3.Расширяемость
Требований меняются. Это - один из бесспорных фактов процесса разработки программ. Высококачественная программа способна иметь дело с этими изменениями относительно безболезненно. Этот сорт адаптируемости - не является существенным для малых проектов, но становится определяющим, когда происходит "программирование в большом".
Два основных принципа создания расширяемого программного обеспечения:
=
3.1.сложность проекта.
Более простые проект и архитектура позволяют произвести изменения намного быстрее и легче, чем при сложном проекте.
термины сложность(вкл. аспекты - требования к эффективности алгоритмов,
емкость проектной задачи, наукоёмкость), ёмкость(объём работ и кол-во задач), наукоёмкость(исп. технологии).
Сложность бывает аналитическая, архитектурная и практическая.
Аналитическая - на стадии анализа задач и подбора алгоритмов. Самые сложные - недетерминированные и наукоёмкие алгоритмы.
Архитектурная - на стадии разработки\выбора архитектуры проекта.
Практическая - на стадии реализации(кодирования).
=
3.2.Декомпозиция.
Разбиение сложных проблем на малые. Управляемость и независимость фрагментов, означающая, что они могут быть поделены внутри себя. Это значит, что изменения, могут быть выполнены без перекраивания других частей системы.
=
Эти принципы позволяют нам понять проблему в частях без опасения затеряться в несметном количестве непостижимых подробностей.

====
4.Многократность (повторность) использования и совместимость
Многократное использование может просматриваться на различных уровнях: при анализе, проектировании, и реализации.
Оно поддерживает качество следующими способами:
=
Если проекты и код могут повторно использоваться, то мы можем начинать с уже проверенных, опробованных и правильных компонент, качество которых уже является высоким.
=
Время и энергия, сохраненные через многократное использование, могут применяться для улучшения других характеристик качества программы (например, корректности или устойчивости).

====
5.Совместимость программного обеспечения
Мера того, насколько просто объединить различные программные изделия вместе для нового применения. Основы совместимости вытекают из общих проектных решений. Например, файловая система UNIX разработана таким образом, чтобы позволить малым инструментальным средствам хорошо работать вместе при решении сложных проблем.
Противоположным примером является типичный беспорядок при совместной подготовке текстов и графических изображений. В этом случае, большие усилия должны быть затрачены на создание транслятора, которые позволяет одной программе работать с другой.

Совместимость и многократное(повторное) использование идут "взявшись за руки", потому что повторно используемое программное обеспечение (например, plug&play компоненты) должно быть совместимо с его новым окружением. Совместимое программное обеспечение поддерживает качество посредством использования прошлых усилий и подпорок при формировании новых систем. Программное обеспечение с низким коэффициентом совместимости требует огромных усилий, чтобы настроить систему на необходимое использование(кастомизация). Это усилие могло быть потрачено на проектирование лучшей системы или на улучшение эффективности кода.

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

=====
В работе "Научные основы доказательного программирования" А.П.Ершов выделял три вида программирования:
1.Синтезирующее (автоматическое, автоматизированное или ручное манипулирование знанием о задаче с синтезом соответствующей программы)
2.Сборочное (построение программы из уже существующих и корректных фрагментов)
3.Конкретизирующее (построение специализированных программ из универсальных заготовок). Их отображение на распространенные ныне парадигмы и языки программирования имеет следующий вид.
=
1.Синтезирующее программирование:
императивное (Паскаль, Си);
логическое (Пролог);
функциональное (Лисп);
параллельное (параллельный Паскаль, Оккам).
=
2.Сборочное программирование:
модульное (Модула-2, Ада);
компонентное (Эйфель, Component Pascal).
=
3.Конкретизирующее программирование:
объектно-ориентированное (Smalltalk, Си++, Оберон, Java);
шаблонно-ориентированное (Си++, Clarion).

=====
Литература:
1.Гари Уорен Кинг (Gary Warren King) - статья "Объектно-ориентированный подход действительно лучше структурного"
2.А.П.Ершов "Научные основы доказательного программирования"
3.Руслан Богатырев "Об автоматном и асинхронном программировании"
4.Зюбин В.Е. статья "Графические и текстовые формы спецификации сложных управляющих алгоритмов: непримиримая оппозиция или кооперация?"

==========
изучить:
Одной из таких удобных абстракций могут служить конечные автоматы, среди разновидностей которых стоит выделить трансдюсеры (transducer), автоматы Мили и Мура.
..
Однако при этом надо четко себе представлять, в чем их недостатки, а для этого придется обратиться к истокам программирования, к идеям "механического" вычисления. Как известно, они воплотились в таких формальных моделях, как машины Тьюринга (1936), комбинаторные процессы Поста (1936), нормальные алгоритмы Маркова (1951).
..
Чтобы ответить на этот вопрос и определить место конечных автоматов среди других абстракций, рассмотрим сети Петри, занимающие промежуточное положение между машинами Тьюринга и конечными автоматами. Сети Петри работают в терминах условий и событий, где первым сопоставлены позиции (особые узлы - емкости для хранения фишек связаны ориентированными дугами с переходами), а последним - переходы (особые узлы-действия, перемещающие фишки и связанные ориентированными дугами с позициями). Конечные автоматы являются частным случаем сетей Петри и эквивалентны автоматным сетям Петри - сетям, в которых каждый переход может иметь точно одну входную и выходную позицию.

Сети Петри лучше всего подходят для описания любых асинхронных систем (асинхронное программирование), тогда как конечные автоматы - лишь для сугубо последовательных систем (автоматное программирование). (Система взаимосвязанных автоматов реализует параллельные системы - замечание Шалыто А.А.). Наглядность динамики и композиционные возможности сетей Петри выше (при различии понятий "позиция" и "состояние", что требует построения графа достижимых маркировок для определения функциональных возможностей сети Петри - замечание Шалыто А.А.), чем у конечных автоматов, но при этом компактность представления предпочтительнее у последних. Что касается отношения к машине Тьюринга, то достаточно расширить сеть Петри сдерживающими дугами (позволяющими определять отсутствие фишек в данной позиции), как она же становится эквивалентной машине Тьюринга. Очевидно, что чем "мощнее" абстракция, чем больше она позволяет синтезировать возможностей, тем хуже у нее дело обстоит с анализом. Иными словами, конечные автоматы анализировать гораздо проще, чем классические сети Петри и уж тем более чем машины Тьюринга.
==========
сырой материал

что узнать -
редукция
индукция
дедукция

трансдюсеры (transducer)
автоматы Мили и Мура
машины Тьюринга
комбинаторные процессы Поста
нормальные алгоритмы Маркова
сети Петри
==========

более подробно -
Трактат о развитии мозга - http://forum.tomsk.ru/forum/12/1613742/?p=5 - Трактат о развитии мозга
MLP и геналгоритм - не дерьмо, возьмите свои слова обратно
[Ответ][Цитата]
mss
Сообщений: 1967
На: Смысл.
Добавлено: 17 май 19 10:59
Ваня. Я вас не тороплю. У вас есть 1 год минус 1 день что бы решить задачку с идеальным бинарным деревом. Мне ваш код впрочем и все ваши копипасты на хер не нужны. Дело в принципе.
[Ответ][Цитата]
bravo7
Сообщений: 571
На: Смысл.
Добавлено: 17 май 19 11:13
Изменено: 23 май 19 8:20
.
[Ответ][Цитата]
гость
188.170.173.*
На: Смысл.
Добавлено: 17 май 19 12:25
Цитата:
Автор:mss

Кстати. Есть задачка для Вани. Ну и для всех желающих.

Дано бинарное далеко не идеальное дерево. Нужно из него выкусить максимальное по размеру идеальное дерево.

Всё. Жду гениального алгоритма. Даю год.


Идеальное в смысле идеально сбалансированное? Переборная задача (с отсечениями, скорее всего) какая-то, несложная. Ваня справится за неделю, если не меньше.
[Ответ][Цитата]
 Стр.86 (139)1  ...  82  83  84  85  [86]  87  88  89  90  ...  139<< < Пред. | След. > >>