Почему все так сложно?

Здравствуйте! Почему все так сложно в мире программирования, казалось бы простом?

Например, чтобы написать приложение на vue
нужно выдумывать подключение к api
которое нужно писать на django (например) и у которого десятки файлов с "кодом" с моделями, вьюхами, урлами, подключением к postgresql

дальше нужно настраивать синхронизацию, потом писать разрешения и в vue и в django...



Или на php - пишем код, потом берем фронтенд, более менее приличный, получается только на angular, vue, react

пишем отдельно код на php
потом пишем структуру базы данных , схему, саму базу формируем и создаем
потом описываем подключение

хорошо, если программист знает, что нужно сразу писать api к которому подключаться любым фронтом, а если нет... тогда или tpl-ки клепать, или придумывать php+html в котром тоже, гемор еще тот ...

почему до 2010 года был линукс, мягко говоря, "консольный"...
и пока до них дошло, что система должна быть визуальной - как windows - зато теперь красота! ubuntu 18 - почти идеальна!



Также и с программированием!
Зачем все эти сложности?

Теоретически, ведь можно взять принцип моделей от django, которые простым python3 manage.py makemigrations + migrate делает всю работу по моделированию базы данных...

но! Встает вопрос - а как потом работать? Нужно что-то похожее на vue, но только в ЖЕСТКОЙ связке с api с моделями!



Обсудим? Какие есть решения?

Добавлено через 27 минут
по сути, это должно быть простым CRUD приложением
но с возможностью подключения к базе данных

0

Сообщение от Fulcrum_013 Да что вы? Вообще то константа это величина не изменяемая при выполнении алгоритма. При этом вспоминаем первый курс - алгоритм это любая подпрограмма. Соответственно величина вычисляемая одним алгоритмом может быть константой для другого.

Какая практическая польза от определения, согласно которому счётчик цикла является константой, если цикл записан через рекурсию?

0

Shamil1, Огромнейшая. Счетчик не изменяется в теле цикла.

0

Сообщение от Fulcrum_013 Естественно что с использованием изменяемых переменных.

Нет, не естественно. Это только Ваше личное мнение.

Сообщение от Fulcrum_013 На матрицу 8x8? Добавили. Как от этого пешка переместилась с D2 на D4? для этого в ячейку D2 надо записать нолик в ячейку D4 код пешки.

Не понял сути вопроса.
И матрица, кстати, не имеет никакого отношения к задаче. Это всего лишь деталь Вашего решения этой задачи.

0

Shamil1, Так вы так и не ответлили на вопрос - как за O(1) скопируется шахматная доска (модель), а не добавится запись в лог изменений, который не пригоден для нужных алгоритмов без опять же восстановления модели по всему логу, в результате которого опять же нужна матрица с двумя измененными клетками.

0

Сообщение от Fulcrum_013 Огромнейшая. Счетчик не изменяется в теле цикла.

Бессмысленный спор об определениях. Хорошо, пусть вся Ваша изменяемая модель будет константой (для какого-то алгоритма).

Добавлено через 1 минуту

Сообщение от Fulcrum_013 как за O(1) скопируется шахматная доска (модель)

0

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

0

Сообщение от Fulcrum_013 Нет.

Не понял, к чему именно относится Ваше "нет".

0

Сообщение от Shamil1 let position2 = position1 __________________

Либо это не O(1) либо это не копирование. При копировании обеспечивается независимость изменения копий. COW при этом на отмазку не тянет.

Добавлено через 1 минуту

Сообщение от Shamil1 Не понял, к чему именно относится Ваше "нет".

К тому что вы не можете не изменяя данных обеспечить модификацию модели за O(1).

Добавлено через 2 минуты
Shamil1, Еще раз о птичках почему важно произвести изменения именно в этой матрице 8x8. В алгоритме построения списков ходов наиболее используемая и вообще единственная операция связанна непосредственно с моделью - определение занятости клетки, при этом других операций там практически нет. За O(1) эта операция выполняется только по матрице.

0

Сообщение от Fulcrum_013 При копировании обеспечивается независимость изменения копий.

Для неизменяемых типов данных эта независимость обеспечивается автоматически.

Сообщение от Fulcrum_013 К тому что вы не можете не изменяя данных обеспечить модификацию модели за O(1).

Я писал про копирование, а не про изменение.

Сообщение от Fulcrum_013 Еще раз о птичках почему важно произвести изменения именно в этой матрице 8x8.

Использование матрицы - это всего лишь предложенный Вами способ решения задачи. Вполне можно обойтись и без матрицы.

Сообщение от Fulcrum_013 В алгоритме построения списков ходов наиболее используемая и вообще единственная операция связанна непосредственно с моделью - определение занятости клетки, при этом других операций там практически нет.

Четыре вложенных цикла один в другом - это всего лишь предложенный Вами способ построения списков ходов.

Сообщение от Fulcrum_013 За O(1) эта операция выполняется только по матрице.

1) эта операция может не понадобиться.
2) за O(1) она выполняется не только на матрице.
3) может оказаться более выгодным выполнять эту операцию медленнее, зато другую быстрее.
4) может оказаться, что чуть более медленное выполнение этой операции вообще не влияет на скорость решения задачи

0

Сообщение от Shamil1 Использование матрицы - это всего лишь предложенный Вами способ решения задачи. Вполне можно обойтись и без матрицы.

Предложите другой способ проверки занятости клетки за O(1). Эта операция выполняется на несколько порядков чаще модификации позиции.

Добавлено через 1 минуту

Сообщение от Shamil1 Я писал про копирование, а не про изменение.

НУ вы же обещали скопировать байконур за O(1) при замене винтика.

Добавлено через 28 секунд

Сообщение от Shamil1 за O(1) она выполняется не только на матрице.

Способ в студию

Добавлено через 5 минут

Сообщение от Shamil1 Для неизменяемых типов данных эта независимость обеспечивается автоматически.

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

0

Сообщение от Fulcrum_013 НУ вы же обещали скопировать байконур за O(1) при замене винтика.

В каком из моих сообщений я это обещал?
Копирование и изменение - это две разные операции.

Сообщение от Fulcrum_013 Предложите другой способ проверки занятости клетки за O(1). Эта операция выполняется на несколько порядков чаще модификации позиции.

Как Вы можете утверждать, что чаще, если можно вообще не выполнять её ни разу?

Сообщение от Fulcrum_013 Способ в студию

Словарь, в котором ключом являются координаты фигур.

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

Набор ложных высказываний, показывающий Вашу некомпетентность в теме "Структуры данных".

Сообщение от Fulcrum_013 вы можете только что то добавить в хвост списка, но не заменить

Зависит от того, какой структурой данных реализован список.

Сообщение от Fulcrum_013 при этом даже при просто добавлении в хвост вы получите связный список

Зависит от того, какой структурой данных реализован список.

Сообщение от Fulcrum_013 связный список во первых тормозящий при последовательном доступе

Тормозит или не тормозит - зависит от того, что Вы делаете с каждым элементом. Поэтому, в общем случае Ваше утверждение не верно.
Интересно, что такое нужно делать с каждым элементом, чтобы разыменовывание указателя на фоне этого стало тормозящей операцией?

Сообщение от Fulcrum_013 не пригодный к произвольному доступу, и как следствие не пригодный к распараллеливанию его обработки

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

0

Сообщение от Shamil1 чтобы разыменовывание указателя на фоне этого стало тормозящей операцией?

Разыменовывать указатель. Промахи кеша очень дорого стоят. Матрица при этом помещается в линию кеша.

Добавлено через 2 минуты

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

Следует. GPU принимает на вход буфера но никак не списки.

Добавлено через 3 минуты

Сообщение от Shamil1 Словарь, в котором ключом являются координаты фигур.

Это O(n) от количества фигур а не O(1). при этом вектор фигур имеет свойство изменяться точно так же как матрица. Т.е. обеспечить изменения словаря вы точно так же не можете. Лог изменений на каждую фигуру тоже не отмазка, потому что придется хранить изменяемый вектор хвостов логов.

Добавлено через 4 минуты

Сообщение от Shamil1 Набор ложных высказываний, показывающий Вашу некомпетентность в теме "Структуры данных".

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

Добавлено через 5 минут

Сообщение от Shamil1 Как Вы можете утверждать, что чаще, если можно вообще не выполнять её ни разу?

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

Добавлено через 3 минуты

Сообщение от Shamil1 В каком из моих сообщений я это обещал? Копирование и изменение - это две разные операции.

вот в этом Почему все так сложно?

0

Сообщение от Fulcrum_013 вот в этом Почему все так сложно?

Ваш вопрос: всю коллекцию копировать?
мой ответ: Да. За О(1).
Где тут про изменение коллекции?

Сообщение от Fulcrum_013 Даже допустим что будет алгоритм сравнимый по скорости на сопоставлении координат фигур. Но во первых он не будет работать без модификации данных. А в главных при модификации самого словаря при очередном ходе будут те же грабли что с матрицей.

Это всё Ваши предположения. Причём, лишённые смысла, так как я не конкретизировал алгоритм, который собираюсь использовать. Даже структуры данных не конкретизировал.
Если хотите, можем написать функцию выбора оптимального хода Move MiniMax(State state, int depth) и сравнить.
Для простоты все фигуры будут ходить как ладья, а функция оценки позиции будет возвращать количество фигур.

Сообщение от Fulcrum_013 Либо у вас есть вариации не тему вектора, который без изменения счетчика и реаллокаций буфера не работает, либо у вас связный список. третьего не дано.

Если Вы не знаете третьего, то это не значит, что его "не дано".

Сообщение от Fulcrum_013 Это O(n) от количества фигур а не O(1).

Каким образом проверка, есть ли в словаре запись с заданным ключом, может занимать O(n)?

Сообщение от Fulcrum_013 Следует. GPU принимает на вход буфера но никак не списки.

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

Сообщение от Fulcrum_013 Разыменовывать указатель. Промахи кеша очень дорого стоят. Матрица при этом помещается в линию кеша.

Согласен, промахи кэша стоят дорого. Поэтому Вы со своим изменяемым массивом на определённых операциях с матрицей для размеров, кратных некоторым степеням двойки, можете получить замедление на 2-3 порядка.
А что касается последовательного доступа к связанному списку, то на моём компьютере список из 100 миллионов инт32 чисел суммируется в одном потоке за 70-100 мс (дот.нет код на эфшарп). Так что "тормоза" никак не могут превышать одной миллионной секунды на итерацию.

1

Shamil1, Выше по тексту. Вопрос был о том что вам придется копировать всю коллекцию при изменении одного элемента

Добавлено через 1 минуту

Сообщение от Shamil1 Поэтому Вы со своим изменяемым массивом на определённых операциях с матрицей для размеров, кратных некоторым степеням двойки, можете получить замедление на 2-3 порядка.

Каким образом? Байта на код фигуры выше крыши 8*8=64 байта размер матрицы. Аккурат линия кеша. Она как в кеш сядет так оттуда и не выйдет. Особенно изменяемая.
А вот у вас придется каждый раз новые данные в кеш подтягивать.

Добавлено через 4 минуты

Сообщение от Shamil1 А что касается последовательного доступа к связанному списку, то на моём компьютере список из 100 миллионов инт32 чисел суммируется в одном потоке за 70-100 мс (дот.нет код на эфшарп). Так что "тормоза" никак не могут превышать одной миллионной секунды на итерацию.

Линейный поиск со вставкой в связном списке медленнее линейного поиска со ставкой в векторе. Это при полной неприспособленности вектора к вставке если без учета кеширования.

Добавлено через 4 минуты

Сообщение от Shamil1 Если Вы не знаете третьего, то это не значит, что его "не дано"

Его не дано по определению. Либо данные лежат последовательным буфером, либо непоследовательными так или иначе связанными кусками. В любом случае добавление данных в сегментированный массив требует изменения счетчика элементов самого массива как минимум. Так что не изменяя уже существующий список сделать его копию с добавлением элемента можно только одним способом - создать пару - указатель на предыдущую копию и новый элемент. Так что только связный список у вас остается.

Добавлено через 7 минут

Сообщение от Shamil1 Каким образом проверка, есть ли в словаре запись с заданным ключом, может занимать O(n)?

Дерево бинарного поиска или хеш без изменения данных не построить. Так что для поиска в словаре-векторе фигур у вас остается только линейный поиск. Даже если построите - логарифмическое время а не O(1).
Опять же словарик придется перестраивать каждый ход. Это далеко не О(1) в отличии от матрицы-доски, которая является двумерным индексом и модифицируется за O(1) вперед и за О(1) обратно не покидая кеша.

Добавлено через 38 минут

Сообщение от Shamil1 Ваш вопрос: всю коллекцию копировать?

Shamil1, НЕ пытайтесь увильнуть.
мой вопрос

Сообщение от Fulcrum_013 Если захотите где то винтик поменять будете всю коллекцию копировать?

0

Сообщение от Fulcrum_013 Каким образом? Байта на код фигуры выше крыши 8*8=64 байта размер матрицы.

Я написал "на определённых операциях", имея ввиду общий случай, а не конкретную задачу. Можете, например, потестировать транспортирование матрицы, увеличивая размер в 2 раза и измеряя время. (Правда, я это делал лет 10 тому назад).

Сообщение от Fulcrum_013 Линейный поиск со вставкой в связном списке медленнее линейного поиска со ставкой в векторе.

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

Сообщение от Fulcrum_013 Его не дано по определению.

Дерево.

Сообщение от Fulcrum_013 В любом случае добавление данных в сегментированный массив требует изменения счетчика элементов самого массива как минимум.

Переменные неизменяемого типа данных нельзя изменить. Результатом "изменения" является новый объект. Этот новый объект конструируется из частей старого, так что создать придётся только небольшое количество "фрагментов".

Сообщение от Fulcrum_013 Дерево бинарного поиска или хеш без изменения данных не построить.

Можно построить что угодно, даже массив. Вопрос в том, сколько будет занимать операция добавления элемента. Но причём здесь неизменяемые или изменяемые типы данных? Вы сказали, что без матрицы вообще никак не получить О(1). Я привёл способ, как получить О(1) без матрицы. Или Вы что-то другое имели ввиду?
Кстати, обычный (изменяемый) массив длиной 64 элемента копируется за О(1).

0

Сообщение от Shamil1 Чтобы опровергнуть Ваше утверждение "не пригодный к распараллеливанию" достаточно привести один опровергающий пример.

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

Добавлено через 7 минут

Сообщение от Shamil1 Дерево.

Дерево это многосвязный список. От того как построены взаимосвязи суть не меняется.

Сообщение от Shamil1 Вы сказали, что без матрицы вообще никак не получить О(1). Я привёл способ, как получить О(1) без матрицы.

Либо ваш словарь организован в виде матрицы либо это не O(1). Опять же построить его без полного копирования вы его не можете потому что не можете изменять его элементы а только добавлять.
Суть аналога именно в демонстрации этого факта. Не копируя полностью саму модель вы можете вести только лог команд модификации, а не модифицировать модель. Но между ведением этого лога и построением данных, необходимых для следующих шагов, разница как между обещаниями построения коммунизма к 80-му году и интернетом.

1

Сообщение от Fulcrum_013 Можно запустить 50 потоков с синхронизацией доступа к списку, которые реально выполняются последовательно и называть это распараллеливанием. Но распараллеливанием это не является.

Можно сделать неправильно. Но можно сделать правильно. И есть примеры того, как это сделано правильно. И это работает - проверено.

Сообщение от Fulcrum_013 Дерево это многосвязный список. От того как построены взаимосвязи суть не меняется.

В списке доступ по индексу и изменение по индексу - О(N), как Вы сами писали. В дереве эти операции - O(logN), а в некоторых случаях - О(1). Так что суть меняется. Или Вы, когда писали "О(N)", имели ввиду дерево?

Сообщение от Fulcrum_013 Либо ваш словарь организован в виде матрицы либо это не O(1). Опять же построить его без полного копирования вы его не можете потому что не можете изменять его элементы

Но причём здесь неизменяемые или изменяемые типы данных? Вы сказали, что без матрицы вообще никак не получить О(1). Я привёл способ, как получить О(1) без матрицы.

0

Сообщение от Shamil1 Вы сказали, что без матрицы вообще никак не получить О(1). Я привёл способ, как получить О(1) без матрицы.

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

Сообщение от Shamil1 Но причём здесь неизменяемые или изменяемые типы данных?

При том что это всего лишь аналог. Словарь/матрица - не суть важно. Важно что это модель данных. Либо вы можете ее модифицировать без полного копирования при выполнении очередной команды модификации, либо не можете. Если не можете то и без копирования всего Байконура винтик не замените. Вернее даже не сам винтик а команду на добавление винтика.

Добавлено через 3 минуты

Сообщение от Shamil1 Например, очередь на основе связанного неизменяемого списка - вставляем с одной стороны, а удаляем с другой - и всё равно О(1).

Для очередей есть гораздо более подходящая и надежная структура данных - кольцевой буфер.

Добавлено через 3 минуты

Сообщение от Shamil1 Этот новый объект конструируется из частей старого, так что создать придётся только небольшое количество "фрагментов"

Но для этого придется изменять метаданные. Это точно такое же изменение данных. С таким же успехом любой вектор указателей можно назвать неизменяемой коллекцией на основе того что только указатели в векторе меняются а не объекты на которые они указывают. Но это точно такая же смена состояний.

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

Добавлено через 1 час 5 минут

Сообщение от Shamil1 В дереве эти операции - O(logN), а в некоторых случаях - О(1).

Вы часом не спутали деревянный индекс с древовидным списком копий который вы пытаетесь городить?

Добавлено через 2 часа 52 минуты

Сообщение от Shamil1 . В дереве эти операции - O(logN), а в некоторых случаях

В сбалансированном дереве. Оно для своего построения требует операции поворота узлов - т.е. изменения метаданных. У вас же данные неизменяемые поэтому и сбалансированные деревья у вас не получатся.

0

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

Показательный пример.
Список, который становится деревом. Причём, очевидно, что когда Вы писали про список "Это O(n) от количества фигур", Вы не имели ввиду дерево. Но позже, чтобы не признавать свои ошибки, Вам потребовалось назвать его деревом - и Вы назвали.

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

Вы написали: "вам придется копировать всю коллекцию при изменении одного элемента". При этом, очевидно, подразумевается, что так делать очень плохо. Логично предположить, что под "копировать всю коллекцию" Вы подразумеваете физическое дублирование соответствующих областей памяти, так как в копировании нескольких ссылок на эту память ничего ужасно страшно нет. Но Вы, ведь, обязательно придумаете этой фразе какое-нибудь новое объяснение, рассчитывая, что никто не помнит, в каком контексте она была написана?

2. Вы используете не логические методы ведения дискуссии.

Придумываете свой алгоритм решения задачи другим, не Вашим методом, критикуете его... и делаете вывод, что решать можно только Вашим методом.

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

Постоянно вбрасываете необоснованные и обычно ложные высказывания, выдавая их за абсолютную истину.

Приписываете мне какие-то слова и начинаете их критиковать.

Сообщение от Fulcrum_013 Вы часом не спутали деревянный индекс с древовидным списком копий который вы пытаетесь городить?

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

0

Сообщение от Shamil1 что Вы называете "деревянным индексом"

деревянный = дерево

древовидный = множество вложенностей ?!

0