Вверх ↑
Этот топик читают: Гость
Разработчик
Ответов: 26061
Рейтинг: 2120
#16: 2019-06-15 19:39:56 ЛС | профиль | цитата
flint2 писал(а):
Соединял я кучу выходов в одну точку, ну я вам доложу...

Оригинально, неужели это настолько проблематично?
flint2 писал(а):
Короче, точка зрения Леонид`а логична, даже не с точки зрения концепции HiAsm, а с точки зрения логики. + удобства.

Никакого удобства, просто частный случай. Если разделенные точки можно без проблем объединить, то вот алгоритмически объединенные в компоненте точки уже просто так не разъединишь. И если некоторым нужно полученные данные впоследствии объединять, то некоторым нужно именно разделенные данные.
карма: 22

0
Ответов: 2059
Рейтинг: 131
#17: 2019-06-16 15:09:40 ЛС | профиль | цитата
nesco, Всё зависит от задачи.
Сейчас у меня такого компонента нет и мне трудно судить.
По идее нужны два компонента - разновидности.
Изначально, как он был сделан, он очень подходил под множество задач.
Помню, задаёшь список "условий-масок" и получаешь на выходе совпадения.
Очень удобно.
В последствии надо было задавать выходные точки на каждое условие.
Это хорошо для каких то задач, если десяток-два условий, но когда список имеет под сотню - выглядит не презентабельно.

Редактировалось 4 раз(а), последний 2019-06-16 15:38:21
карма: 6

0
Разработчик
Ответов: 26061
Рейтинг: 2120
#18: 2019-06-16 18:16:28 ЛС | профиль | цитата
flint2 писал(а):
Помню, задаёшь список "условий-масок" и получаешь на выходе совпадения.
Очень удобно.

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

Редактировалось 2 раз(а), последний 2019-06-16 18:17:24
карма: 22

0
Ответов: 2059
Рейтинг: 131
#19: 2019-06-17 20:16:51 ЛС | профиль | цитата
nesco писал(а):
последовательную загрузку TagList-а с одной выходной точкой...

Я просто сделал компонент - Хеш-табли́ца. https://ru.wikipedia.org/wiki/%D0%A5%D0%B5%D1%88-%D1%82%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D0%B0
И гораздо быстрей работает. Скорее всего это вторая часть задачи, или часnь этой задачи поиска по списку.
А кто мешает, и так и эдак сделать? В смысле старый и новый.
"Мы должны приносить пользу людям." - "Его звали Роберт"(старый фильм).
Кубиков должно быть много и разных.
Если стремиться к математической логики, то всё равно, подавляющее большинство кубиков не отвечает этому условию.
Вся печаль в том, что не наделать кубиков на все случаи жизни, но стремиться к этому надо!
...
Вот сейчас скажу, что надо писать то что хочется в Инлайн коде(IC) и грех на душу возьму.
Надо не паскаль изучать.
Надо другие языки учить!

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

Редактировалось 2 раз(а), последний 2019-06-17 20:19:02
карма: 6

0
Разработчик
Ответов: 26061
Рейтинг: 2120
#20: 2019-06-17 22:44:39 ЛС | профиль | цитата
flint2 писал(а):
Скорее всего это вторая часть задачи, или часnь этой задачи поиска по списку.

Вот именно, что поиск по списку, где каждому элементу соответствует какой-то вполне определенный индекс, те набор данных уже структуирован. Млин, но каким боком это относится к поиску в тексте, который не имеет структуирования, когда сегодня он может быть одним, а завтра совершенно другим? Да, цепочный поиск в неструктуированном тексте по блокам поиска (тегам) это долго, но для этого этот компонент и разрабатывался, в основном, для парсирования HTML-страниц.
flint2 писал(а):
Вот сейчас скажу, что надо писать то что хочется в Инлайн коде(IC) и грех на душу возьму.

Да никто и спорить не будет, что IC (не важно на каком языке) будет эффективнее. Но построение кубиками тоже своего рода интересное занятие, и некоторым гораздо интереснее строить кубиками, чем писать на IC. Это чистое IMHO.
карма: 22

0
Ответов: 2059
Рейтинг: 131
#21: 2019-06-17 23:09:30 ЛС | профиль | цитата
Ну вот и развлеклись.

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

Была у меня такая задача, как раз по литературным текстам для снятия омонимии.
И что первым в голову приходит, это искать по списку.
Но задача решается иначе, совсем другой алгоритм. По этому я и упомянул Хеш-табли́цу машинально.
И то она нужна при списках более 1000.
Примерно так: Выделяем очередное слово(это отдельная процедура) и если оно в списке, то ..., иначе итерация - выделяем слово...
Для понимания, Vandjer нужно самому решить задачу до конца, тогда и не будет предположений, что кубики бракованные.

А на счёт кубика, что в лоб, что по лбу - только вид с боку.

Редактировалось 6 раз(а), последний 2019-06-17 23:48:12
карма: 6

0
Разработчик
Ответов: 26061
Рейтинг: 2120
#22: 2019-06-17 23:48:38 ЛС | профиль | цитата
flint2 писал(а):
Для понимания, нужно самому решить задачу до конца, тогда и не будет предположений, что кубики бракованные.

Буквально недавно я решал именно такую задачу, с поисками меняющихся данных на HTML-странице, и вот именно MultiBlockFind оказался подошел для этой цели как нельзя лучше, он сэкономил мне кучу места и сократил немаленькое количество компонентов.
Да, этот компонент мало подойдет для словарей и поиска в большом книжном тексте, алгоритм медленный изначально, да и не предназначен он для поиска и замены тонны слов. Но такой задачи и не стояло, стояла задача заменить кучу элементов BlockFind. Да и мало кто у нас парсирует книжные тексты, больше парсируют стандартные HTML-страницы.
карма: 22

0
Ответов: 2059
Рейтинг: 131
#23: 2019-06-17 23:52:57 ЛС | профиль | цитата
Я в xml разметке(тегах) точно так-же делаю, как и ты.
карма: 6

0
Разработчик
Ответов: 26061
Рейтинг: 2120
#24: 2019-06-18 00:18:16 ЛС | профиль | цитата
flint2 писал(а):
Я в xml разметке(тегах) точно так-же делаю, как и ты.

xml разметка обладает одним отличием, там присутствуют постоянные теги блоков, которые можно единожды ословарить, и их не так много. А что делать, если нужно найти сложную конструкцию, для каждой страницы составлять словарь? А нужна ли такая овчинка? Ну вот как вот такое ословарить, я не догоняю, к примеру
{**s}
class="fact__temp-wrap" {**i} class="fact__props fact__props_position_middle" {**n}
class="temp fact__temp fact__temp_size_s" {**i} class="link__feelings fact__feelings" {**n}
<span class="temp__value"> {**x} </span>
{**e}
Это поиск температуры у yandex провайдера, а вот тоже самое у gismeteo
{**s}
<div class="js_meas_container temperature tab-weather__value" {**i} </span> {**n}
<span class="js_value tab-weather__value_l"> {**x} <
{**e}
И что, мне для каждого провайдера составлять словари поиска? А тут написал один раз скрипт поиска и забыл.

Редактировалось 2 раз(а), последний 2019-06-18 00:23:35
карма: 22

0
Ответов: 2059
Рейтинг: 131
#25: 2019-06-18 01:21:34 ЛС | профиль | цитата
Но скрипт-то тоже по каким то правилам патсит.
Честно говоря, я сразу не въезжаю.
В глаза только бросается <span class= и {**x}

Редактировалось 1 раз(а), последний 2019-06-18 01:23:43
карма: 6

0
Разработчик
Ответов: 26061
Рейтинг: 2120
#26: 2019-06-18 03:39:08 ЛС | профиль | цитата
flint2 писал(а):
Честно говоря, я сразу не въезжаю.

Да там все просто:

{**s}...{**e} -- блок цепочного поиска
class="fact__temp-wrap" -- начало первого звена поиска, class="fact__props fact__props_position_middle" -- конец первого звена поиска, {**i} -- не вырезать начало и конец поиска, {**n} -- продолжить цепь с найденными данными.
class="temp fact__temp fact__temp_size_s" -- начало второго звена поиска, class="link__feelings fact__feelings" -- конец второго звена поиска, {**i} -- не вырезать начало и конец поиска, {**n} -- продолжить цепь с найденными данными.
<span class="temp__value"> -- начало последнего звена поиска, </span> -- конец последнего звена поиска, {**x} -- вырезать начало и конец поиска. Тк это последнее звено, то выдаем остаток на выход, если внутри предпоследнего звена несколько последних звеньев, то формируем MT-поток, чтобы было только одно событие с данными, а не несколько, как у BlockFind-а. Если предпоследних звеньев тоже несколько в первом звене, а в предпоследнем несколько последних, то все равно формируется один последовательный MT-поток.
Три эти строчки заменяют три последовательных компонента BlockFind

Редактировалось 1 раз(а), последний 2019-06-18 03:53:17
карма: 22

1
Голосовали:strannik_nebes
Ответов: 2059
Рейтинг: 131
#27: 2019-06-18 10:42:50 ЛС | профиль | цитата
Честно говоря у меня нет опыта в разборе HTML.
От слова совсем.
Только один раз делал извлечение иконок сайтов.
И тоже единых правил не наблюдал.
карма: 6

0
27
Сообщение
...
Прикрепленные файлы
(файлы не залиты)