Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 2 [3]  Все   Вниз
  Печать  
Автор Тема: Прямоугольники на плоскости  (Прочитано 111554 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #60 : 13-01-2011 12:09 » 

Вот примерный рисунок



кроме того можно размещать каждый объект в разных слоях (пружины всегда Кверху), проецируя на одну плоскость

Здесь нужно играться и играться до просветления

* exe1.jpg (12.26 Кб - загружено 2798 раз.)
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #61 : 13-01-2011 12:20 » 

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

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #62 : 13-01-2011 12:36 » 

весом является размер блока (площадь).

Возможны варианты, что площади одинаковые (вес), но ширина больше - выбирается ближайшая точка подвешивания.

Я и говорю - до просветления.
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
overcoder
Участник

ua
Offline Offline

« Ответ #63 : 13-01-2011 12:49 » 

Вот, попытался отобразить элементарный случай.
*привоис = приводим

* анимация.gif (43.57 Кб - загружено 1263 раз.)
« Последнее редактирование: 13-01-2011 12:52 от overcoder » Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #64 : 13-01-2011 12:54 » 

весом является размер блока (площадь).

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

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

Добавлено через 9 минут и 6 секунд:
Вот, попытался отобразить элементарный случай.

Просто изумительно. Теперь можно попробовать произвести оценку "неидеальности" по приведенным в комментариях критериям.
« Последнее редактирование: 13-01-2011 13:03 от Dale » Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #65 : 13-01-2011 13:07 » 

Цитата
Тогда автоматически получается, что при прочих равных условиях бОльшие блоки провисают ниже. Действительно ли такой эффект желателен?
можно играть коэффициентами жесткости.
Например, смотрим на рисунок.
Все что подвешено к верху - висит на нерастяжимой пружине = выравнивание поверху
Широкий блок перекрывает два верхних - подвешиваем на нерастяжимую пружину, но делаем "базой"

нижние блоки вешаем на нерастяжимые относительно базы.

Я не показал момента, когда блоки находятся один под одним.

Сейчас рассматривается только метод.


Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #66 : 13-01-2011 13:17 » 

С пружинами еще вот какая неприятность может возникнуть.

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

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

А решать систему уравнений движения для N тел, связанных пружинами, в вязкой среде для данной задачи несколько хардкорно, IMHO.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #67 : 13-01-2011 13:44 » 

Надо абстрагироваться от "реальной" пружины. Нас интересует только то что она может растягиваться.
Т.е. потянув за нижний блок он тянет тот блок который выше. Тянуть - до полика.

Определение максимальной высоты ЛИСТА.
Определение максимальной ширины ЛИСТА.
Учитываем что шаг поиска фиксирован, и немного меньше минимальной высоты/ширины.
Этот шаг может быть и минимальным расстоянием между блоками.

Я понимаю, что, наверное, эти задачи стояли перед ТС, но хотелось бы их услышать.
Он все напрягает нас на выдачу готового алгоритма Улыбаюсь


зы. (на память)
Кто-то расставляет изначально блоки? Или эти блоки уже размещены автоматически по какому-то оптимальному решению?
В случае "спонсорских" досок Добавление - в очередь. Ушел блок - произвольное покидание очереди.
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
overcoder
Участник

ua
Offline Offline

« Ответ #68 : 13-01-2011 16:39 » 

Просто изумительно. Теперь можно попробовать произвести оценку "неидеальности" по приведенным в комментариях критериям.
Введем определения что бы не путаться.
Подобными считаем те, которы лежат в одной строке или одном столбце, имеют различия по высоте не более Х% от их средней высоты и отличия по ширине не более Y% от средней ширины. Есть три вида подобных элементов - у которых почти совпадает только ширина, почти совпадает только высота, почти совпадает ширина и высота (полностью подобные).
Положим, что
1) подобные элементы разного размера создают неидеальность. Отталкиваться будем от их количества.
Допустим в ряд лежат 3 квадрата со сторонами 100, 99, 101. Они будут полностю подобны между собой, но т.к. все три разные, то "идеальность" будет 0 из 3 (общее количество фигур)
2) элементы, лежащие на полосе в предлах +- Z% от величины (w или h) фигуры должны находится с ней на одной линии. Если одни лежат в этой полосе, но не на одной линии то они тоже создают неидеальность.
можно играть коэффициентами жесткости.
С пружинами все не однозначно потому как они позволяют равномерно распределить блоки , но никак не помогут с выравниванием относительно друг друга.

Пружины 1 и 3 будут расятнуты одинаково, а пружина 2 будет растянута больше, что сместит блок 5 ниже блока 4 и никак не поможет в решении.
Их можно использовать для равномерного распределения множества разных блоков по площади, а не в данном случае.
С пружинами еще вот какая неприятность может возникнуть.
Груз на пружине - это маятник. Толкнешь его - он начнет раскачиваться.
Ясное дело что никто не будет это моделировать, т.к. это излишне. От свойств пружины нам "нужно" только то, что у нее есть длинна, устойчивое положение (УП), положение сжатия (меньше УП), когда она расталкивает блоки на своих концах и положение растягивания, когда она стягивает блоки на концах (больше УП).
Я понимаю, что, наверное, эти задачи стояли перед ТС, но хотелось бы их услышать.
Кто-то расставляет изначально блоки? Или эти блоки уже размещены автоматически по какому-то оптимальному решению?
Он все напрягает нас на выдачу готового алгоритма Улыбаюсь
Я не напрягаю вас на выдачу готового алга, а обращаюсь за советом и помощью, т.к. длительное время проведенное над этой задачей, дало только общие принципы что надо ровнять и приводить подобные, но задача до сих пор не решена.
Задача сформулирована (дословно) "подровнять и красивенько расположить блоки которые стоят криво или залазят друг на друга".
Изначально эти блоки располагают преимущественно девушки от 20 до 30 лет вообще не задумываясь что в PowerPoint есть встроенные удобные функции подравнивания выделенных элементов по всем мыслимым сторонам, распределения по поверхности и прочее.
По поводу досок спонсоров - давайте не будем их трогать, это не основная задача, но именно в ней надо использовать пружины в том виде как они были предложены.

* пруж1.png (11.02 Кб - загружено 2837 раз.)
« Последнее редактирование: 13-01-2011 16:44 от overcoder » Записан
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #69 : 13-01-2011 17:48 » 

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

Думаю, с 1D случаем справиться будет легче. По крайней мере полученное таким образом решение будет некой основой, которую можно попробовать улучшать. Решать сразу 2D случай - сложнее и мозгов участвующих может не хватить.

Добавлено через 2 часа, 13 минут и 2 секунды:
Пусть у нас страница выглядит примерно так: вертикальное размещение приемлемое, горизонтальное - нет. Будем считать, что каждый блок имеет вес 1 (если хочется, весом можно взять высоту блока). Тогда проекция блоков по горизонтали создаёт ступенчатую "функцию" от ширины листа. Все вертикальные границы блоков как бы продлены на всю высоту листа.



Это можно кодировать массивом точек, что наглядно, но требует много данных:
(0, 0, 1, 2, 2, 1, 1, 0, 1, 1, 1, 1, 0)

Либо (что актуально для больших страниц, имеющих метрические размеры), её можно кодировать массивом структур вида (уровень, длина):
((0, 2), (1, 1), (2, 2), (1, 2), (0, 1), (1, 4), (0, 1)). Это менее наглядно, зато удобнее для алгоритмической обработки.

Предположим, что нормальным расстоянием между краями блоков является 2 и более. Тогда во втором представлении элементарно находятся проблемные места: (+, (1, 1), +, +, (0, 1), +, (0, 1)). Если расстояние меньше допустимого, значит в этом проблемном месте нужно "склеить" или "растолкать" границы блоков. Делать это в каждом случае можно двумя способами: либо уменьшить длину левого хорошего участка и увеличить длину текущего плохого на нужную величину, либо уменьшить длину правого плохого участка и увеличить длину текущего плохого на нужную величину. Каждая такая перестановка может:
- превратить соседний хороший участок в участок 0-й длины - такой участок можно смело выкинуть, если его уровень 0, иначе это потребует ликвидации блоков, что неприемлемо;
- превратить соседний участок в плохой, оставив плохим текущий участок - если при этом суммарный дефицит длин участков уменьшился, это хорошее преобразование, иначе - плохое (вроде бы не должен уменьшаться дефицит);
- превратить соседний участок в плохой, сделав текущий участок хорошим (вроде бы это не даст уменьшения дефицита);
- сохранить соседний участок хорошим, сделав текущий участок тоже хорошим - однозначно положительное преобразование, устраняющее дефицит.

В рассматриваемом примере исходный дефицит длин составляет 3.

Возможные в данном случае варианты модификаций.
((0, 1), (1, 2), (2, 2), (1, 2), (0, 1), (1, 4), (0, 1)) - дефицит 3, бесполезно, не принимается
((0, 2), (1, 2), (2, 1), (1, 2), (0, 1), (1, 4), (0, 1)) - дефицит 3, бесполезно, не принимается
((0, 3), (1, 0), (2, 2), (1, 2), (0, 1), (1, 4), (0, 1)) - ликвидация блока, не принимается
((0, 2), (1, 1), (2, 2), (1, 1), (0, 2), (1, 4), (0, 1)) - дефицит 3, бесполезно, не принимается
((0, 2), (1, 1), (2, 2), (1, 2), (0, 2), (1, 3), (0, 1)) - дефицит 2, полезно, принимается
((0, 2), (1, 1), (2, 2), (1, 2), (0, 1), (1, 3), (0, 2)) - дефицит 2, полезно, принимается

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

Повторяя аналогичный процесс, получим ещё более хорошую конфигурацию:
((0, 2), (1, 1), (2, 2), (1, 2), (0, 2), (1, 2), (0, 2))
с дефицитом 1. После чего вышеизложенным способом дальнейших улучшений не получить.

Тогда нужно уточнить правило удаления блоков. Всякий блок может получить длину 0 и быть удалённым только при условии, что его длина будет прибавлена к блоку с более высоким уровнем.

В данном случае:
((0, 3), (1, 0), (2, 2), (1, 2), (0, 2), (1, 2), (0, 2)) - неприемлемо, так как увеличился блок меньшего уровня 0 за счёт блока большего уровня 1.
((0, 2), (1, 0), (2, 3), (1, 2), (0, 2), (1, 2), (0, 2)) - приемлемо, так как увеличился блок большего уровня 2 за счёт блока меньшего уровня 1. При этом дефицит стал 0.

Итак, найдено одно из возможных оптимальных решений:
((0, 2), (2, 3), (1, 2), (0, 2), (1, 2), (0, 2))
или
(0, 0, 2, 2, 2, 1, 1, 0, 0, 1, 1, 0, 0)


* pagemake.png (2.03 Кб - загружено 3142 раз.)
* pagemake1.png (2.05 Кб - загружено 2796 раз.)
« Последнее редактирование: 13-01-2011 20:01 от dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
overcoder
Участник

ua
Offline Offline

« Ответ #70 : 13-01-2011 20:53 » 

Возможно я чего то не понял, но как производить декодирование?
Если у нас будет в столбце лежать 4 блока, после расчета модификаций как мы поймем который из них изменять?
Записан
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #71 : 14-01-2011 09:08 » 

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

На будущие ожидаемые вопросы вида:
- А что делать, если блоки накладываются или пересекаются - ведь на проекции этого не видно?
- А что делать с вложенными блоками?
- ...

Сразу отвечу: "А может тебе ещё и ключ от квартиры дать, где деньги лежат?" (c) Остап Бендер

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #72 : 14-01-2011 09:59 » 

С пружинами еще вот какая неприятность может возникнуть.
Груз на пружине - это маятник. Толкнешь его - он начнет раскачиваться.
Ясное дело что никто не будет это моделировать, т.к. это излишне. От свойств пружины нам "нужно" только то, что у нее есть длинна, устойчивое положение (УП), положение сжатия (меньше УП), когда она расталкивает блоки на своих концах и положение растягивания, когда она стягивает блоки на концах (больше УП).

А вот не факт, что сумеете обойтись без такого моделирования.

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

Двигаясь влево, блок 2 сильнее натягивает пружину 2-3. Поскольку натяжение пружины 3-4 еще не менялось, блок 3 тоже едет влево, пока не придет в равновесие. Дальше по цепочке едут влево блоки 4 и т.д. до конца цепочки. Но это еще не все.

Вычисляя положение блока 2 по равновесию пружин 1-2 и 2-3, мы использовали старое положение блока 3. Поскольку блок 3 также сместился, натяжение пружины 2-3 становится слабее, и блок 2 продолжает свое движение влево, но уже на меньшую величину. И так далее. Сказка про белого бычка продолжается. Правда, на каждой итерации смещение становится меньше, поэтому есть надежда, что за конечное число итераций процесс сойдется. Насколько это число велико, судить не берусь.

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

Как видите, никакого специального моделирования колебаний не потребуется. Пружинная модель сама по себе достаточно неустойчива.
« Последнее редактирование: 14-01-2011 10:01 от Dale » Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #73 : 14-01-2011 12:36 » 

Dale, колебания физической системы грузов на пружинах обусловлено, как мне кажется, наличием инертной (не тяжёлой) массы. Её вовсе необязательно тащить в модель. Без инертной массы, если силы сделать пропорциональными координате, а не её второй производной, если каждое дискретное движение каждого блока будет пропорционально разнице сил действующих на этот блок пружин, система без колебаний придёт в равновесие - это сходящийся процесс. Окончание этого процесса происходит при условии, что разница сил становится меньше минимального порога (погрешности). И это мною проверялось на практике - когда-то я писал AI для игры в "Сапёра" и таким методом балансировал вероятности закрытых клеток Улыбаюсь Поэтому и говорю, что пружины и штрафы - это очень похожие задачи.

В данном случае точность определяется либо пикселями (целыми числами, при диапазоне в 4 десятичных порядка), либо метрическими единицами, но даже в худшем случае вряд ли будет DPI большее 600 (для печати на принтере).
« Последнее редактирование: 14-01-2011 12:40 от Dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
overcoder
Участник

ua
Offline Offline

« Ответ #74 : 14-01-2011 12:42 » 

Dimka, у вас было очень подробное объяснение, и только этот момент вызвал вопрос. Теперь все понятно, спасибо за идею.
Решать за меня задачу конечно же не нужно, скажите только, можно ли где то прочитать про пружины которые вы впервые упомянули еще в 15-м ответе?
Dale, согласен с вами, но это уже зависит от того, как мы будем обрабатывать положения блоков и натяжения пружин. Если последовательно то действительно велика вероятность что система дестабилизируется и даже могут возникнуть незатухающие колебания. Другое дело если мы будем расчитывать положение каждого блока в определенный момент времени, затем сдвигать все, затем снова проводить оценку и так же введем минимальны порог для остановки. В этом случае, мне кажется, негативных явлений произойти не должно.

Всем, большое спасибо за активную помощь, вы подсказали мне несколько новых подходов и открыли глаза на некоторы важные вещи. Теперь мне требуется обдумать что же выбрать и попытаться реалиовать, так что пока что отписываться не буду.
Если вдруг у кого то вдруг возникнет еще какая то умная мыслЯ - изложите, пожалуйста, тему просматривать я буду регулярно.
По результатам (любым) обещаю отписаться.
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #75 : 14-01-2011 13:05 » 

Dale, колебания физической системы грузов на пружинах обусловлено, как мне кажется, наличием инертной (не тяжёлой) массы. Её вовсе необязательно тащить в модель.

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

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

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

Добавлено через 16 минут и 59 секунд:
Dale, согласен с вами, но это уже зависит от того, как мы будем обрабатывать положения блоков и натяжения пружин. Если последовательно то действительно велика вероятность что система дестабилизируется и даже могут возникнуть незатухающие колебания. Другое дело если мы будем расчитывать положение каждого блока в определенный момент времени, затем сдвигать все, затем снова проводить оценку и так же введем минимальны порог для остановки. В этом случае, мне кажется, негативных явлений произойти не должно.

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

Но это все умозрительно. Нужно ставить эксперимент, а заодно продумать перспективы перехода от одномерной пружинной модели к двумерной и возможные ловушки. Например: при перемещении блока по горизонтали он попадает в другую вертикальную группу, где другие правила выравнивания. Не потребуется ли при этом изменение структуры блоков/пружин, а если потребуется, какие это будет иметь последствия?
« Последнее редактирование: 14-01-2011 13:22 от Dale » Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #76 : 14-01-2011 13:23 » 

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

Добавлено через 12 минут и 52 секунды:
По поводу наложения горизонтальных слоёв по вертикали. Одномерные выравнивания можно поочерёдно проводить для горизонтали и вертикали. Но вот здесь уже в сходимости я не уверен - это надо думать и проверять.

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

Добавлено через 7 минут и 59 секунд:
overcoder, кстати, для досок с сертификатами, партнёрами и т.д. пружины не подойдут. Дело в том, что для пружин нужно априори иметь некую раскладку, которую остаётся только подровнять. На таких досках априори нет никакой раскладки, есть только множество прямоугольных (или даже многоугольных) блоков, которые нужно компактно разложить на определённой площади - это задача укладки мозаики, и решается она совсем иначе.
« Последнее редактирование: 14-01-2011 13:35 от dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #77 : 14-01-2011 13:47 » 

Dale, не надо там тщательно параллелить. Ты же сам признал, что штрафы (или напряжения в пружинах) будут с каждым движением уменьшаться - процесс сходится.

Насчет сходимости утверждать не рискну, тут на меня можно не ссылаться. Если взять ряд 1/n, то с увеличением n каждый следующий член уменьшается, но при этом ряд не сходится. Одного уменьшения мало - важна еще скорость убывания. Может, повезет, а может, и нет.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
baldr
Команда клуба

cy
Offline Offline
Пол: Мужской
Дорогие россияне


WWW
« Ответ #78 : 31-10-2011 14:27 » new

Подниму топик вверх: на хабре сегодня нашел статью по теме.
http://habrahabr.ru/sandbox/37498/
"JQuery Masonry — динамический layout, верстаем без «дыр»"

Сам плагин: http://masonry.desandro.com/
Записан

Приличный компьютер всегда будет стоить дороже 1000 долларов, потому что 500 долларов - это не вполне прилично
Страниц: 1 2 [3]  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines