Pull to refresh
0
0
Башкатов Андрей @Workanator

Пользователь

Send message
UFO landed and left these words here

Почему бы вместо дерева не использовать обычный двумерный массив? А нужная ячейка в таком массиве ищется обычным дилением позиции чего бы то ни было, будь то позиция курсора или другой координаты, на заранее известную константу. При это вы экономите кучу памяти только на том, что вам не нужны разные дополнительные поля для организации дерева. И вы экономите время на поиск нужного квадрата, потому вам не надо перебирать элементы структуры данных; вы находите нужный элемент простым математическим вычислением его позиции.


const BOX_HEIGHT = 100, BOX_WIDTH = 160;

// Распределяем места по массиву. Предполагается, что если место пересекает границу
// одной или более области, то добавляем место в смежные области.
let boxes = [];
for (let seat in seatList) {
  let topX = int(seat.X/BOX_WIDTH),
      topY = int(seat.Y/BOX_HEIGHT),
      bottomX = int((seat.X+seat.Width)/BOX_WIDTH),
      bottomY = int((seat.Y+seat.Height)/BOX_HEIGHT);

  boxes[topY][topX].push(seat);
  if (bottomX != topX) boxes[topY][bottomX].push(seat);
  if (bottomY != topY) boxes[bottomY][topX].push(seat);
  if (bottomX != topX && bottomY != topY) boxes[bottomY][bottomX].push(seat);
}

// Ищем ячейку массива, в которой есть нужное место.
let boxX = int(point.X/BOX_WIDTH), boxY = int(point.Y/BOX_HEIGHT);
if (boxes[boxY][boxX]) {
  for (let seat in boxes[boxY][boxX]) {
    if (seat.Contains(point)) {
      alert("Вы выбрали ряд " + seat.Row + " место " + seat.Number); 
    }
  } 
}

// Прошу прощения за возможные огрехи в синтаксисе, JS не мой основной инструмент.

Если у вас не вся область вмещается на "экран", то добавьте к point.X и point.Y смещение, если масштабирование — то умножьте/разделите на коэффициент масштабирования.

Также, вместо того, чтобы создавать переменную h_in_gorotine, её можно передать, как параметр функции.
А как же «разбиение»? Возьмите перевод того же Disk space partitioning — Разбиение диска.
Программа и статья очень понравились. Спасибо. Думаю, в качестве плюшки, а может быть нового приложения, вам надо добавить Диалоги со спамерами. :)
После прочтения статьи осталось ощущение, что автор рассказывает о том, что они написали большой монолитный плохо спроектированный кусок кода, и оправдывается теперь за это. Не хочу сказать, что сам проект плохо работает или еще что-то в этом роде, но с позиции программиста у меня закрадываются некоторые опасения.

Например, чего только стоит такое объяснение, где автор объясняет стабильность и качество системы, выбором языка.
Я думаю, что многое зависит от языка. Компания, в которой я работал до Canonical, имела миллион строк кода C#, и оно довольно часто падало с «null reference» исключениями и прочими необработанными исключениями.
По-моему, не самый удачный выбор, ибо практика и статистика показывает, что ошибка в 99% случаев именно в «вашем» коде.
Спасибо за интересную статью. Никогда не думал о том, чтобы разбивать сущности настолько мелко, хоть и стараюсь провести полную нормализацию БД. Но по опыту могу сказать, что во всех проектах боязнь получить большое количество таблиц «душит» только вначале, а потом, когда уже все нормализовано, становится очень даже удобно и просто.

У меня к вам вопрос, влияет ли на скорость выполнение запроса (по сравнению с «обычной» БД) такое количество таблиц, например, когда надо за раз выбрать ФИО + ИНН + еще какие-то персональные данные?
Не уверен, какие именно функции автор имеет в виду (отдельные функции, функции-члены, методы?), но он, по-моему, забывает еще одну очень важную вещь, что функции, почти все, контекстно зависимые, и этот контекст необходимо передавать в функцию, либо делать глобальным.

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

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

Я, конечно, утрирую, но, думаю, смысл понятен; маленькие функции по… гмм… «методологии» автора могут в такой же степени злом, как и добром.

Information

Rating
Does not participate
Location
Россия
Registered
Activity