Христо МИРСКИЙ, ... 2015 ...

— — — — —

Замечание:

Оригинальная папка ПИР на других сайтах начинается "Неграмотным миром", который здесь идёт под номером 20, потом идёт "Идея о новом календаре", которая здесь часть (последняя) № 7.Дру.А. моей публицистики, потом следует "Порассуждаем о числах", которая вещь здесь под № 19, потом следует этот 21.А. ПИР, где специально программистские идеи, потом "Правое Кривосудие", которое тоже к публицистике, в № 7.Жур.Г., и потом по очереди следует вторая часть этой папки, 21.Б, где довольно оригинальные идеи для сферы массового обслуживания, а также и длинный перечень кучи разных идей во всём моём творчестве.

— — — — —

Содержание этой книжки А

Компьютерная программа для переноса слов разных языков

Компьютерная программа для сжатия файлов независимо от их типа

Идеи о поиске браузеров в Интернете

— — — — —

КОМПЬЮТЕРНАЯ ПРОГРАММА ДЛЯ ПЕРЕНОСА СЛОВ РАЗНЫХ ЯЗЫКОВ

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

Что важно подчеркнуть, это то, что программа должна работать удовлетворительно хорошо (и оно так и было у меня) для смеси разных языков даже в одном файле, или для пары языков с которыми человек обычно работает, она должна допускать лёгкое настраивание, если в данных языках имеются противоречивые концепции на перенос слов, да и отражать личные предпочтения человека, должна проводить выравнивание по правому краю страницы (justification), и другие моменты. У меня был вариант который работал как отдельную (stand alone) программу, задавался входной файл (.txt), задавался выходной файл (.prt), программа преобразовала один в другой, и потом оставалось лишь распечатать последний файл. А, и я работал только на латинице и кириллице, если кто-то хочет делать перенос, скажем, и на арабском, то там могут быть свои трудности, но специально для греческого алфавита не должно быть особых проблем (с первого взгляда — я этим не занимался). Вот, однако так как в разных языках мнение на перенос слов совершенно разные то я должен сначала сказать пару параграфов об этом.

1. Основные понятия о слогах, типов букв, и универсальных правил переноса

Здесь я не открываю Америку, но тем не менее имеется мой личный вклад в эту тему; я затрагиваю эти вопросы в моей идее об универсальном мировом алфавите, и их нужно иметь в виду, потому что, чётко выражаясь, универсальных правил для переноса слов во всех, хотя бы европейских, языках попросту нету! В русском вещи более или менее простые, но в английском это совсем не так, и там имеются словари где указан перенос для каждого слова, это в основном как бы из соображений слогов, но и здесь могут быть различные мнения. В немецком свои правила, обычно по слогам, но некоторые буквы разбивать совершенно некрасиво, а у них используются нормально по 2-3 знака для одной буквы, а то даже и четыре; в английском (и французском) с другой стороны совершенно некрасиво разбивать гласные, потому что они читаются вместе по несколько подряд. Поэтому я задал себе сначала вопрос: что такое слог, чем он характеризуется, как его отличить?

Ну, выходит что он обычно, не всегда, но в большинстве случаев (скажем, в 90%), начинается согласной и кончается как получится, но благословлены те языки в которых гласные простые. И теперь приходим к моим взглядам о том какие виды гласных звуков вообще (в мире) существуют, потому что нужно как-то распознавать — без словарей, разумеется, ведь не будут же использоваться словари для всех возможных мировых языков — где гласная как бы одна (хотя их несколько), образует слог, и где это несколько отдельных гласных. Скажем: слово "пиано" имеет три слога для нас, но в английском оно имеет два, там "ia" нельзя разбивать, также как и в с слове "ready", или в "beauty". Поэтому я пришёл к выводу, что существуют три типа гласных (в основном, но это можно применить и к согласным), а именно: базисные, модифицированные, и дифтонги или комбинации гласных.

Базисные гласные всего шесть, это: "е", "и", "о", "у", "а", и болгарское "ъ" (здесь не могу впускаться в детальные объяснения, они сделаны при алфавите, но это тот звук как в английском girl). Модифицированные это когда хочешь сказать одно, а говоришь другое, где типичный пример русское "е", которое, собственно говоря, 'и_е' (спрашивайте украинцев, они наверное разъяснят вам почему говорят дивка, жинка, и т.д.), также как и русское "ы" это 'ъ_и' — и я думаю что уже "усекли" почему я даю вторую гласную как суб-индекс — а то ещё можно сказать что русское безударное "о" (как в начале "окно") это 'ъ_а', что встречается также и в английском but. Нет смысла углубляться здесь больше, ибо специально в этой программе я не занимаюсь таким анализом, но он объясняет почему я принял свою концепцию на перенос гласных, которую укажу ниже. И дифтонги, в моём понимании, ибо некоторые, и то лингвисты, называют, для примера, французское "ai", которое читается как 'e' — и я думаю, что вы также замечаете, что я использую одиночные кавычки для указания того как буквы произносятся, в то время как двойные дают выписывание букв —, тоже дифтонгом, это такие комбинации гласных где их несколько, как в английском pear, 'пеъ', каких в русском нет, если не считать "ай", "ей", и прочее, но "й" не совсем гласная.

Вот, так что теперь приходим к тому, что буквы нужно различать, нужно прикрепить в программе к каждой букве, для обеих алфавитов (а что будем делать с теми где всякие галочки сверху, тоже скажу что-то к концу), характеристику типа, и этих типов должно быть три! То есть, гласные, согласные, и неопределённые, но всё же буквы, а не другие знаки. Эти неопределённые буквы (если я не запамятовал что-то, но в любом случае этот вопрос нужно как-то третировать), скажем, "й", или латинское "h", а то и "w", играют роль модификаторов прежней буквы и должны прицепляться к прежней букве, или принимать ту же характеристику как у неё (но что делать если такой символ в начале слова не припоминаю точно, однако это не принципиально, ибо одна буква не должна оставаться на строчке).

Когда слог более или менее правильно распознан то можно переходить к переносу слова, к отделению полновесного слога, на что остановимся в следующем пункте о моей реализации. Однако хочется подчеркнуть, что эта программа работает, как принято выражаться, эвристически, она даёт некоторое решение, которое достаточно хорошее, но не обязательно идеальное или грамматически правильное. (К примеру, выходит что латинское "ck" следует считать как "kk", и учитывать это при переносе слова оставляя на обе строчки по букве "k", но я думаю что это лишняя роскошь.)

2. Как я реализовал сам перенос слов

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

Разумеется здесь нужны и процедуры для распознавания окончания слова, в фонетическом смысле, такие как интервал, знаки препинания, другие символы; а также, думаю, и пропускать такие слова, которые не чистые слова, т.е. в них числа, или специальные символы, или перемешаны алфавиты — они должны оставаться такими какие они есть, это может быть пароли, новые символы, и прочее. Разумеется также, что нужно задание длины строки, которую хотим получить (по умолчанию, кажется, 70), количество знаков которые можно оставлять в конце или начала строчки (и если слог налицо, ибо иначе продолжается дальше), и несколько других параметров программы. Но нужно и задание ещё нескольких важных вещей, потому что пока мы только указали на то, что не ясно нужно ли разбивать двое гласных (и пусть отмечаем это дальше только заглавной буквой Г), или можно ли прерывать последовательность согласных (тоже будем отмечать только буквой С) или нет, но не сказали как именно поступать, а ведь нельзя оставить программу стоят и думать как осёл Буридана с какого стога сена начать есть. Так что сейчас приступаем к этому.

Здесь я ввёл такие эвристические правила: гласные как правило не разбиваются, если не допустим какого-то исключения, и тогда нужно вводить список исключений (кажется было так, но не уверен на все 100 процентов, может быть вводил список префиксов оканчивающихся на гласную); согласные как правило разбиваются, но нужно ввести список комбинаций согласных, которые нельзя разбивать (здесь уверен что это было); неопределённые символы (ни Г, ни С) должны идти с прежними символами, то есть разбиение только после них. Ввод в досовской программе список вещей которые нужно выполнять не так легко, но я это сделал (на худой конец нужно вводить это как варианты при декларации констант, и проводить новую трансляцию). Так что программе нужно задать список неразделимых комбинаций — таких как немецкое "sch", также "ch", "ck", "sh", "ph", и прочее (10-15 комбинаций, не так уж и много) — и список разделяемых комбинаций, в основном из гласных — скажем "ea" в немецком допустимо разбивать (но "ae" по прежнему нельзя), или может быть хотим чтобы "eu" разбивалось, или "ia".

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

Благо что в ДОС-е нет специальных галок поверх букв, и все буквы моноширинные. Но на экране, а и при печатании в Windows-е или в другой современной операционной системе, все эти проблемы существуют, так что нужно написать и следующий пункт.

3. Что делать если буквы бывают разных шрифтов, типов, и фонтов?

Здесь я в основном буду гадать, так как у меня нет опыта в программировании в другой операционной среде, но думаю, что буду правильно угадывать, т.е. там просто должны существовать специальные процедуры, которые будут делать работу за вас, ибо вы все прекрасно знаете, что когда набираете что-то на файле то пишете на данной строчке пока можно, а когда уже нельзя то автоматично оказываетесь на другой строчке. Вот так-то. Но каковы эти процедуры, где они и как написаны (скорее всего на Visual Basic), как их вызывать (т.е. их имена и параметры) мне не известно, по простой причине, что теперь нужно за всё платить, не важно делаешь ли что-то полезное для других, или хочешь заработать что-то только для себя. Я привык работать для других, но раз с приходом демократии мне пришлось работать только для себя, то я и перестал работать для других, и стал писать всякие вещи per il mio diletto (в своё удовольствие, по итальянски), ведь так?

Да ладно, так и быть, скажу, всё таки, своё мнение и в связи с этими вопросами. Программу нужно будет вызывать нажатием какой-то кнопки на панели редактора или браузера, должна быть возможность для её настройки, введением новых неразбиваемых последовательностей, также новых разбиваемых гласных (или префиксов, слогов), а то и новых гласных или согласных, так как могут быть разные алфавиты. Так что мы пришли к тому что делать с буквами у которых что-то сверху или снизу: программа должна распознавать также и эти буквы, как много бы их и ни было (и они, по идее, распознаются давно, потому что при изготовлении индексов в Word-е они обрабатываются правильно), и то для каждого алфавита. Наверное нужно для каждой буквы поддерживать и принадлежность к алфавиту, чтобы различать смешанные слова; но может быть оставить это, ибо существует куча языков где имеются по паре символов в добавлении к основным (скажем, "i" в украинском). Тогда при встрече непонятной буквы (но не любого символа), программа должна обрабатывать её как неопределённую букву и допускать перенос только после неё.

Касательно всяких шрифтов и возможностей приукрашивания букв, что меняет их размер, то за это должна отвечать сама операционная система, с помощью вызова какой-то функции (скажем, DoesFitInLine (string, linelength) : Boolean). Но чтобы человек мог корригировать то что программа сделала, должна быть возможность вызывать её только для маркированной области, если таковая имеется, при условий на экране (т.е. продолжение параграфа) и понимать все параметры для неё которые должны браться из текущего параграфа (т.е. здесь нужны вызовы других служебных функций и процедур операционной системы или браузера). А, тексты и в таблицах должны быть тоже обработаны в соответствии с их параметрами для параграфов.

Но, обратите внимание, что какой бы и несовершенной ни была такая программа, то она всё же была бы лучше теперешнего положения вещей, на что остановимся в следующем пункте. А если кто-то захочет возразить, что в реальном времени, и когда человек может нажатием одной клавиши (или с помощью мыши) изменить ширину окна и это вызовет переформатирование целого документа, то я отвечу коротко: это вовсе не существенно для современных компьютеров. Я (до 2015 года) работаю на компьютере где только 256 МВ оперативной памяти, не могу смотреть никаких movies, на диске у меня всего лишь 10 ГВ, из которых я держу 1/3 свободными, скорость процессора около 600 МГц, и при этом положении, при редактировании целой книги, примерно из 200 страниц, я могу выполнять грамматическую проверку (spell checking) за пару секунд, а это, положительно сложнее моей программе для переноса слов. Да и даже если на такую обработку нужно время, то если речь идёт о печати это не принципиально, а если для показа на экран, то достаточно обработать первую пару тысяч символов пока заполнится экран, и дальше проводить обработку в фоновом режиме; а к тому же можно спокойно держать пари что современные компьютеры хотя бы на порядок быстрее этого моего. Так что дело не в замедлении, а в нежелании, в необращении внимания на эту проблему.

4. А стоит ли морочить себе головы этим?

Разумеется что стоит, ибо при всей фантастической мощи современных компьютеров и программных продуктов, без такой программы мы как будто находимся в ... каменной эре, или хотя бы пару тысячелетий раньше Христа, где люди выдалбливали на камнях букву за буквой, не признавая ни интервалов, ни знаков препинания, ни параграфов и страниц! Оно ведь в самом деле так. Даже когда высылают сообщения на мобильные телефоны их располагают точно так, и разбивают слова где попадётся без никакого дефиса (скажем, я спокойно мог получить такое сообщение по телефону: "Господин Мирск|ий, у вас имее|тся фактура дл|я использованн|ых услуг на ст|оимость в 12.3|4 левов" ... и так далее). Ведь, даже и без такой программы, нужно только узаконение одного символа как "опциональный дефис" и его правильное интерпретирование любым терминальным устройством, и все сообщения писать вставляя его везде где он может понадобиться — да ничего подобного нет и по сей день.

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

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

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

11.2014

— — — — —

КОМПЬЮТЕРНАЯ ПРОГРАММА ДЛЯ СЖАТИЯ ФАЙЛОВ НЕЗАВИСИМО ОТ ИХ ТИПА

Эта идея реализована мною лет 20 тому назад, когда я работал ещё на 286 компьютере, в ДОС-е, и используя транслятор Паскаля с 1986 года, если не ошибаюсь. И программа работала, и ещё работает у меня, но раз все стали использовать какой-то Winzip то и я в конце концов перешёл к ней. Но я написал её, с одной стороны чтобы использовать лучше дискеты, мои файлы не помещались и нужно было их разбивать на части, а с другой стороны чтобы испробовать своё хеширование, потому что в этом трансляторе нельзя было уделять больше чем 48 КВ на все переменные, а мне был нужен один массив в худшем случае из 64 КВ, лучше вдвое больше, и ещё кажется столько для других массивов. То есть это было для меня вызовом, но не только это. Я решил использовать одну, прямо таки антинаучную идею, делать сжатие не анализируя тип файла (их ведь много, и всё время появляются новые, я не собирался их изучать, да и конкурировать фирменные продукты), а сжимая файл да того размера который ... сам Бог (или естество файла) позволяет при кодировании знаков!

Я разъясню это дальше, но пока хочу добавить, что не смотря на все возможные трудности с хешированием (я думаю что дефинировал этот основной массив порядка нескольких КВ, т.е. хотя бы раз в десять меньше действительно нужного) программа работала довольно-таки хорошо, для текстовых файлов давала около 45% (а Winzip давал где-то 55%) сжатия, а для некоторых других где изображения даже до 15% основного файла. Что не хорошо, однако, это то что она работает ужасающе медленно, потому что делает несколько итерации, считает всё байт за байтом, сравнивает их, формирует массивы, потом обрабатывает эти массивы с информацией о целом файле, и если файл порядка 100 - 200 КВ (как было в начале в ДОС-е) то всё шло в считанные секунды, но если файл, скажем, 2 МВ, то тогда уходил иногда и битый ... час (зависимость от размера файла наверное экспоненциальная, ни в коем случае не линейная). Так что я, кажется, информировал, то ли офис IBM-а, то ли ещё какой-то фирмы, но решил, что хватит — программа моя, она работает, но я не собираюсь распространять её дальше, ибо теперь все файлы растут очень сильно, и если это видео информация, то кто знает сколько времени программа будет работать.

Это всё так, однако ... Видите ли, у меня часто имеется "однако", особенно при нетрадиционных подходах. Так здесь дело в том, что если не хеширование, если я мог бы уделить целый МВ на переменные, а то и больше, сделать виртуальные массивы для файлов (скажем по пару МВ), и читать блочно в них, то это могло бы спокойно снизить время на целый порядок, если и не больше. Но дело этим не кончается, потому что выходной файл у меня получался как бы ... после мясорубки, я менял сами байты, формировал свои новые "байты" (или слова, правильнее говоря), и это могло бы дать очень хорошее шифрование! А ведь люди всё ещё ищут всякие возможности для лучшего шифрования, оказывается это так для обеспечения секюрити банковских операций, где применялись сверх-большие простые числа (скажем, из несколько сот а то и тысяч цифр, где нахождение их простых множителей довольно трудоёмкая (time consuming) операция, но проверка почти что тривиальная (путём умножения, хотя и не обычного, а целочисленного с неограниченным числом чисел).

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

1. Моя идея сжатия файла до допустимого самим его характером

Всё началось с того, что я заметил, что в одном файле используются далеко не все возможные символы. Скажем, если это текстовой файл на латинице, то обычно остаются около 50 возможных знаков, и даже если на кириллице (в ДОС-е, разумеется, где таблица из 256 знаков, а и в первых Windows-ах) тоже остаются 10-20 знаков; только .exe файлы используют почти на 100 процентов все возможные знаки. Эти знаки можно использовать. Как? Ну, кодированием последовательностей знаков, и то наиболее часто используемых таких! Это всегда составляет мой нулевой пасс (проход). Но это, очевидно, капля в море, это так, чтобы не оставлять ничего неиспользованного. Дальше я просто расширяю размер байтов и делаю свои "байты", из 10 битов, или из 12 (или больше, но эксперименты показали, что 16 битовые "байты" имеют слишком большие размеры, чтобы можно было сэкономить что-то их использованием). Если новые байты у меня из 10 битов, то если первые два бита "00", то это старые знаки, и остаются ещё три варианта, т.е. три знаковых таблиц для кодирования! Это уже кое-что. Теперь остаётся только для каждого конкретного файла находить что ещё добавлять, какие новые символы формировать, и добавлять по одной такой таблице при каждом проходе, анализируя последовательности из старых и новых символов. Но уже видите, что байты смещаются, и не известно что каждый действительный байт означает, так что повторение каких-то байтов не означает действительное повторение символов, здесь вещи перемешаны.

Так, а что добавлять? Ну, то что нужно для каждого файла, то что встречается чаще всего в нём, грубо говоря. По идее я хотел проводить анализ всех возможных последовательностей символов, хотя бы в разумных границах, т.е. сначала из двухбайтовых последовательностей (что не означает разделить файл на пары байтов, а на всех возможных таких последовательностей, т.е. n и n+1, n+1 и n+2, и так далее если нужно), потом из трёх байтов, потом из четырёх, а может быть и из пяти. Потом как-то взвешивать количество встречаний в зависимости от длины, и выбирать наиболее встречаемые последовательности, которые и закодировать добавляя новые символы для них, но один такой символ уже будет означать два (или больше) исходных символов. Понимаете в чём может быть экономия, и почему она зависит от самого файла, не только от его типа, а от конкретного файла? И действительно, при хешировании я вставлял промежуточные печати максимального повторения и сначала они были, кажется, несколько тысяч (если не заблуждаюсь, потому что это будет при условии, что я использую двухбайтовые целые числа как счётчики, а то может использовал однобайтовые), и под конец новой знаковой таблицы они раз в десять меньше.

Скоро, однако, я решил, что это излишне сложно, и так я увеличу время на пару порядков (!), так что оставил только двухбайтовые последовательности, но зато наличие нескольких проходов обязательно, так что при трёх проходов, если в файле часто встречаются, скажем, последовательности шпаций, то в конечном итоге я буду заменять 2^3 = 8 таких шпаций одним новым символом. Кроме того, с каким-то приближением, замена двух непосредственно последовательных символов несколько раз должна быть эквивалентной замене группы из нескольких (4-5) символов. Поэтому число проходов нужно, не годится если я в одном пассе добавил все возможные символы.

Так, а как, всё таки, анализировать последовательности? Обычным подсчётом числа встречаний, разумеется, так что по идее, если хотим обойтись без хеширования вообще, нужно поддерживать массив размерности 2*newbytelength, что в наиболее использованном мною варианте (потому что эксперименты показали, что так лучше) из 10 битов, дало бы размерность в 20 битов, т.е. 1 МВ да и по 2 байта для integer-ов, это 2 МВ. Размерность новых "байтов" должна быть использована и для старых байтов, чтобы можно было при втором проходе использовать, наравне со старыми байтами, и новые, удлинённые "байты", представляющие двухбайтовые последовательности. В этом случае выходит что моё хеширование, в действительности (я ведь сказал, что специально не хочу смотреть как было в самом деле), использовало меньше одного процента реальных массивов, и поэтому у меня и время такое ошеломляющее, да и экономия не такая уж большая (т.е. если начало файла не является достаточно представительным для всего файла то хеш-таблица очень скоро заполняется и дальше даже если появляются более часто встречаемые комбинации они просто пропускаться, нет места для размещения их счётчиков).

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

2. Формирование новых файлов

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

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

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

3. Вариант шифрованного сжатия

Так как без таблиц новых символов и сам чёрт, как говорится, не сможет ничего понять в файле, то ясно, что если их высылать отдельно можно сохранить секретность сжатого файла. Однако я имею в виду не такую секретность, где одна программа (дешифрирующая) может, всё таки, расшифровать разные файлы (имея файлы с ихними новыми таблицами), а новые персональные шифры для каждого потребителя! Это элементарно сделать если перед записи таблицы проводить простую замену (swapping) нескольких пар байтов. Так как байтов 256 или 2 шестнадцатеричных цифры то запись, скажем 6FA7 будет означать что 111-й элемент таблицы (пара символов, из нужного числа битов, для данной итерации) нужно заменить (или заменён) на 167 её элемент. Это действительный шифр, так что дешифрирующую программу можно сделать универсальной и таблиц символов ни к чему записывать на отдельные файлы, но эти замены, для каждой итерации нужно посылать секретно, не по имейле, а в отдельном конверте, что-то такое. Тогда декодирующая и декомпрессирующая программа должна просто спрашивать низы шестнадцатеричных чисел, примерно по четыре пары на итерацию или 12 таких четвёрок цифр как чуть выше, и когда человек введёт их (или скопирует из какого-то файла на его компьютере), то тогда всё будет в порядке, а если не введёт, то будет считаться что нет никаких замен и тогда получится битовый фарш, как сказал в начале.

Возможностей для замен, по идее, и для 10-битовых "байтов" и трёх итераций, даже не 3*256 а на много больше, так можно выполнять несколько замен с участием одного из байтов, что будет результировать в циклические замены. Генерирование шифров случайным образом (скажем, сделав программу, которая запускается и всё время генерирует случайные шестнадцатеричные числа, пока кто-то не нажмёт нужную кнопку) даст возможность обеспечить абсолютную уникальность этих шифров. Единственный минус такого метода будет то, что и запомнить эти последовательности довольно-таки трудно и нужно смотреть куда-то, что значит что шифр может быть обнаружен. Но ведь это всегда так с шифрами, не так ли? Я не занимался такими вещами, да думаю что так. Другой вариант это работа с текущим кодом из какой-то книги, если установить некоторый метод конвертирования букв (из любого алфавита) в шестнадцатеричные числа, что не так уж и сложно (скажем, остатки деления по модулю 16, самое простое — то что будут некоторые повторения, как сказал, не имеет значения). И если это видео файлы, то тогда компрессия может получиться на десятичный порядок, и больше, и время декодирования, при современных компьютерах, будет не существенным.

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

4. Кодирование в новых знаковых таблицах

Сначала я хочу отметить здесь то, что если таблицы уже двухбайтовые, то тогда даже и при классическом варианте стоит ещё на нулевом пассе провести свопинг байтов через двухбайтовое слово, т.е. так, чтобы байты чередовались: І ІІ, ІІ І, І ІІ, ІІ І, ... . Таким образом, как я подозреваю, массивное сжатие получится в І-х байтов, а сами таблицы будут во ІІ-х байтах. Это может привести к чувствительно большей компрессии файлов, а если они не двухбайтовые (что иногда может случиться, я ведь говорю о всяких возможных типов файлов), то это не помешает, просто сравнивание будет проводиться через байт. Я лично давно думаю испробовать это в моей программе, но всё руки не доходят — с тех пор как стал публиковаться по Интеренете, да и переводиться, нет времени на программистскую работу (тем более с трансляторами с 86 года прошлого века).

Однако в этом пункте я имею в виду, то, что раз таблицы такие расширенные, то тогда нет никакой надобности в расширении слов (хотя бы для текстовых файлов, но подозреваю и что для видео, ибо при кодировании цвета в 24 битах выходит, что слова даже и трёхбайтовые), тогда они просто очень слабо использованы и может случиться что останется место для тысячи и больше новых символов! Как это установить? Ну, нужно просто работать двухбайтовыми словами, и весь анализ проводить на уровне двух байтов, что повлечёт за собой необходимость в обязательном хешировании, и работе со словами в два раза длиннее. Это сразу повысить размерность задачи, но, как сказал, это может быть и не будет нужно, если использовать простой трюк с разменой байтов через слово. Тут нужно поэкспериментировать.

И всё зависит от величины файла. Если они по МВ-у и больше, и видео файлы, то хотя соседние пункты и будут очень похожие, всё же, при большом файле будут использованы все возможные цвета. Но может быть для аудио файлов будет вовсе не так много вариантов? Главное по моему это выбрать один универсальный метод чтобы его можно было применят во всех случаях с довольно хорошим результатом, не искать перфекции; тогда и шифрование будет иметь смысл. В конце концов можно поставить некоторый лимит (например из 1-го, или из 10-ти МВ) и каждый файл обрабатывать на таких порциях, и кодировать отдельно, хотя и сохранять в одном файле.

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

12.2014

— — — — —

ИДЕИ О ПОИСКЕ БРАУЗЕРОВ В ИНТЕРНЕТЕ

На этот раз это только идеи, может быть и голые идеи (но в наше время голые вещи разрешены, ведь так?), так что я ничего не требую ни с кого. Я просто делюсь моим мнением. Потому что это большие и сложные программы, они и экспертные системы, и обучаются, и грамматический анализ проводят в разных языках, и поиск по всему web-у всё время проводят и актуализируют свои таблицы доступа, и так далее. Кроме того я вообще не специалист по Интернету, я был лишь программистом лет 25 тому назад, но наше время динамичное, так что я порядочно отстал. Тем не менее имеются очевидные вещи, которые прямо бросаются в глаза если человек не предубеждён в чём-то, если не защищает чью-то частную позицию, хотя здесь трудно сказать, что люди работают неправильно. Нет, они работают, да вроде бы не в нужную сторону идут, делают то, что легче и эффектнее сделать, а не то что нужно. Так что, госпожи и господа, "браузерчики" — а то и клиенты, ибо если потребители затребуют чего-то, то оно скоро появится —, хотите слушать меня, то пожалуйста, а не хотите — я свой долг выполнил.

Так. Тогда начну.

1. Общее впечатление

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

Ну, этому свои причины. В интернете нельзя искать когда люди запросят, нет, ищут всё время и поддерживают таблицы для каждого слова (думаю, предполагаю, но как же иначе?), и потом, при надобности, эти таблицы объединяются или секутся. И искать по частям слов это, в принципе глупо. Но, с другой стороны, ищут же по однобуквенным словам (скажем "и", или английское "a", и т.п.), так что, почему бы не искать, скажем, "много-", или "-брев-", или "англ-"и так далее, но без чёрточки, я её ставлю для того чтобы было ясно что это не целое слово? Но самое большое затруднение для браузеров получается не при поиске, а при показе, найденных встречаний слов. И знаете ли почему? Я лично только теперь задумался, и для меня ясно, что это потому что в вебе не дефинировано отношение порядка (order relation) и нельзя сказать какой сайт перед кем показывать, в принципе! Поэтому выходит, что то, что любой браузер вам показывает, упорядочено далеко не в нужном порядке, а тем более в том порядка, в котором вам бы хотелось (хотя вы и не сказали в каком, но и не имеете такой возможности).

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

Вот, когда вы пишете только одно слово в окошке, всё происходит более или менее хорошо, где "более" означает, что в начале появляется Википедия, и ещё пара других, вроде бы важных сайтов, а что дальше вас не интересует, а "менее" означает, что — так зачем показываются эти сайты, раз они вас не интересуют? Единственный смысл в показе всех встречания данного слова в том, чтобы проверить что правильно, ибо может быть ошибочное исписывание слова, и это в силе и для комбинаций слов (как: "в этом годе", или "в этом году", или ещё ищете как правильнее по английски "depends from", или "depends on", но лучше всего не забывать кавычек). Это очень хорошая возможность (как побочный продукт) но совершенно ни к чему показывать эти встречания, достаточно посмотреть только на статистику использования и выбрать что более используемое. Но ладно, что больше, это не страшно, в конце концов, хотя дело в том, что вовсе не мало сайтов забивают себе место при таких запросах, и когда посмотрите там, то показывают вам всякие рекламы, так что оказывается, что показ ненужных вещей служит рекламе и мешает потребителям, вас ловят на "мякине", как говорится.

Но самая плохая работа браузеров наступает когда ищете несколько слов, ибо тогда, не смотря на всякие ухищрения при выделении корней слов и пропуске (как правило) союзов, т.е. не смотря на проведённого грамматического анализа вашего запроса, и на формировании разных вариантов поиска, применяется, как правило объединение, ИЛИ, а не сечение (И) слов. Таким образом, добавляя больше слов вы не суживаете поиск, а наоборот, расширяете его, что противоречит здравому смыслу. А если вы решите записать слова в кавычках, для дословного поиска, то тогда можете пропустить много сродных слов. А то что потребителю хочется, это какая-то возможность проведя сначала поиск добавить ещё что-что, и сузить его, да почти нечего добавить, ибо даже язык и страна не соответствуют точно названию, это то что расположено на вебе в данной стране, но оно может быть хоть на суахили. Вся аттрактивность браузеров базируется прежде всего на поддерживании множества больших упорядоченных списков наиболее часто встречаемых заявок и на частоту использования данных сайтов; системы кажутся довольно-таки интеллигентными, но их интеллект почти такой как интеллект попугая.

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

2. Достоверность источника, и другие типы страниц

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

Что я имею в виду точнее следующее: нужно ввести тип или достоверность сайта как одно из трёх (хотя бы): a) авторизованные, которые должны выдвинуть свою кандидатуру на такие, должны быть соответствующие показатели, которые должны удовлетворяться ими, но прежде всего некоторое единство и централизация мнения, официальный взгляд на вещи, хотя бы в рамках государства, это официальные учреждения, и даже не все их сайты, могут быть и неавторизированные сайты даже министерств, также официальные академические или учебные заведения, и прочее, но тоже единое и официальное мнение, а не, один думает так, а другой иначе, и здесь, разумеется, и национальный вариант Википедии; b) фирменные, или всякие организации, медии, общества, литературные сайты, и прочее, которые доказывают свою принадлежность к этой категории тем, что они регистрированы как юридические лица; и c) физические лица, т.е. каждый кто хочет (Сулю и Пулю, как говорим в Болгарии), которые ничего не доказывают, и если данный источник ничего не может доказать, то он включается в эту категорию (скажем, блоги, где можно добавлять свои мнения, разговорчики, вопросы и ответы открытые для всех, и прочее). Тогда поиск нужно проводить по умолчанию только для авторизованных инстанций (а таких должно быть не больше одного процента, я полагаю), и показывать только статистику встречаний для второй и третьей категории.

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

Далее нужно более строгое слежение за языками и странами на каждом сайте, т.е. нужно будет требовать введение таких параметров в начале каждой страницы. Скажем, эту вещь я пишу на русском, и размещаю в России, но может быть размещу и в другой стране и опять на русском, а может быть (как оно и бывает у меня) и то, что я размещу что-то на болгарском, или на английском, или на немецком, и так далее, на русском сайте; это справедливо и для реклам, ибо несмотря на все усилия компьютерных переводчиках, язык всё ещё самый главный параметр каждого текстового материала. По сути дела Интернету можно верить только насчёт даты появления вещей, здесь всё точно, а иначе, всё условно.

3. Поиск по соседству

Как сказал, я не специалист в области Интернета (лишь около этого), но не слышал чтобы говорилось о vicinity search, а без него проводить более или менее хороший поиск больше одного слова получается довольно неудачным из за отсутствия отношения порядка, а такой поиск вводит какой-то порядок. Что я имею в виду следующее: введение, скажем путём квадратных скобок, последовательностей слов, которые если без кавычек будут размножаться во всевозможные падежные и прочие формы, но иначе не будут, которые будут искаться на расстоянии одно от другого, или на максимальном расстоянии если их больше двух слов, где сама величина этого расстояния (в словах) будет задаваться последним параметром (а может быть и ещё один параметр для всей группы). По умолчанию нужно понимать 3 слова, или через два налево или направо, но не больше пяти для всей группы. К примеру

[Мирский "Христо" 2]

или ещё

[население численность мир 3 7]

или ещё

[ ["Христо" Мирски 1] [религия коммунизм 2] болгарский 100 ]

и прочее варианты которые положительно не так уж и трудны, чтобы и домохозяйки, как говорится, могли писать похожие заявки к браузеру; если нет кавычек, подразумевается что можно варьировать слово, получая "Мирский", "Комунизмът като религия" и где нибудь слово болгарский (коли нужно можно написать и 10,000). Базисная работа браузеров при поиске при этом не измениться, но изменится способ упорядочивания при показе, и результаты могут свестись буквально к одному (т.е. к возможным копиям на разных сайтах). Кроме того так можно задавать и более широкие заявки, которые потом можно будет суживать меняя некоторые числа, или добавляя новые слова, а это очень существенно, потому что я сказал, что человек должен суживать количество полученных результатов, а не увеличивать их.

4. Поиск по важным параметрам страницы

Значит, как посмотришь на возможности современных браузеров, можно подумать, что люди всегда делали так как делают и браузеры, да оно вовсе не так. Библиотеки существуют уже тысячи лет, но нигде и никогда нельзя было искать книги по встречанию в них определённых слов (скажем: коммунизм, партия, правительство, гражданский долг, и прочее)! То что можно было делать, а и теперь можно делать в любой библиотеке, это проводить поиск по автору, по заглавию, на кириллице или латинице, по индексу на какой полке они расположены, и ещё по тематическому каталогу (когда не знаешь точно автор или заглавие, или тебя интересуют несколько схожих книг). Вот так то. А не по тому встречается ли в них слово, да простят меня читатели, "жопа" (или только "попа"). Я согласен что новое не всегда должно смотреть на старое, но оно должно как-то согласовываться, нельзя отречь всю историю до нас и начать жить сначала (как многие из молодых, наверное, думают). Раз так работалось до сих пор, то такие возможности должны быть налицо и теперь, а то что может и ещё что-то быть возможным — ну, тем лучше, но вертикальная надстройка с сохранением старых возможностей. Это не я придумал, это правильный метод работы в любой области.

Ну, насчёт автора и заголовка материалов, то они, разумеется, будут найдены если ищутся все возможные слова (хотя будут найдены и много упоминаний о них, что не совсем то), но где остаются ключевые слова, по которым, собственно, нужно проводить поиск (а не по союзам и случайным словам), и тематика? Здесь я тоже не корифей, но существует же библиотечное образование и там люди знают эти вещи, это азбучные истины для них, иначе нельзя. Насчёт ключевых слов то уже все знают слово keyword и используют (как и я на некоторых сайтах), но и это не правильно, это самодеятельность, каждый ставит какие хочет ключевые слова, так не делается, хотя можно допустить (за неимением лучшего). И потом не забывайте, что если эти ключевые слова на языке повествования в документе то тогда не отличить их встречание как слова в тексте от их появления как keywords. Поэтому их нужно предшествовать чем-то, что не должно отделяться от них, скажем слово Index, или Theme (как ThemeDemocracy что моя излюбленная тема). Это уже лучше, но недостаточно.

Да ладно, а как правильно, может воскликнуть кто-то, и тогда я скажу опять: спрашивайте специалистов по библиотечному делу. Они должны вам сказать, что нужно иметь установленные индексы или тематики для всей библиотеки (а Интернет это и есть одна огромная библиотека), которые даже нужно записывать в начале книги, на второй странице (как я, если не ошибаюсь, видел на некоторых американских книгах, что они каталогизированы в ихнем каталоге). Так что здесь, повторяю, должен быть какой-то административный орган для всего мира, который представляет Интернет, скажем, Комиссия по Интернету к ООН, и они просто должны выработать нужные требования и на одном языке, пусть это будет английский на пока (хотя он оставляет желать много лучшего). В общих чертах должны быть утверждены специальные таблицы с тематиками во всех возможных областях, для которых должны быть переводы на все возможные языки и способ вызова их в любом браузере, чтобы копировать точные слова, также и какие-то стандарты для задания автора, заголовка, короткого резюме, вот такие вещи. Но если сейчас я начну объяснять подробно что нужно сделать я могу ... лишить ценных специалистов их заслуженного заработка, не так ли? Ну, шутки в сторону, но это не область для энтузиастов.

И всё таки я рискну предложить одну гениальную идею в следующем пункте, ибо иначе я не буду Мирским, ведь так?

5. Введение хоть одного специального знака в качестве буквы во всех алфавитах

Здесь нечего долго искать, это известный знак для подчёркивания "_" (underscore). Он удобен тем что он как бы чёрточка, но не знак переноса, а используется для слияния нескольких слов. В таком случае если начать какое-то слово даже только ими, то это уже будет отличать его во всех языках, но куда лучше если будет записываться, скажем Ind_word, или I_word, где слово "word", очевидно, означает любое слово любого языка. Я лично использую второй вариант в моей уникальной книге Urrh, чтобы можно было проводить поиск только таким образом маркированных слов. Аналогично можно ввести ещё пару других специальных обозначений, как: Au_name, или Tit_title, или The_theme. А можно будет вставлять и несколько таких знаков, если имеются подтемы к данной теме. Вот видите как элементарно всё.

Но чтобы все могли хоть сразу воспользоваться этим предложением нужно небольшое усилие разработчиков (и поддерживающих этих софтверных продуктов), нужно лишь чтобы они обрабатывали этот символ со всеми алфавитами (хоть в арабском или суахили), а не выбрасывали его и не считали как разделительный знак оканчивающий прежнее слово. Тогда можно сделать и то, о чём я упомянул в начале, что Word может, а в Интернете нельзя, а именно: проводить поиск до каждого знака (скажем, написать только "The_math*" и искать все возможные варианты как mathematics, mathematical, только math, и прочее). Такой люкс можно будет себе позволить для всего веба, потому что это будет не слово какого-нибудь языка, оно будет встречаться десятков тысяч (а то и миллионов) раз реже, чем все эти перечисленные варианты слов; нужно просто для всех слов в которых встречается знак "_" поддерживать индексы до любого символа из этого комбинированного слова.

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

12.2014

— — — — —

Сконвертировано и опубликовано на http://SamoLit.com/

Сконвертировано и опубликовано на https://SamoLit.com/