Алгоритмическая составляющая есть, но не без исключений.
Один и тот же текст, начитанный актером в аудиокнигу, и прочитанный диктором новостей, может иметь совершенно разную интонационную окраску.
Однако вы правы: запрограммировать это крайне непросто, особенно учитывая, что программа не просто пару соседних слов должна анализировать, а все предложение с учетом частей речи, а иногда и абзац или даже несколько.
То есть фактически искусственный интеллект получится. Чат-бот здесь не прокатит.
Красивая идея и реализация, тыкать мышкой понравилось.
Смущают только пара нюансов.
К самому движку и посту претензий особых нет. Убрать подсказку по выделению текста и обфусцировать передаваемое в JQuery запросах — это просто технические исправления.
Сейчас наверное фигню напишу, не уверен, что многие меня поймут, момент довольно тонкий, но…
1. для режима экзамена неплохо бы написать авторский текст, никому не известный. Ибо с тем же Булгаковым просто выделяем мышью пару предложений, поиск в Гугле, и видим оригинал текста.
2. если брать тексты писателей художественной литературы, неважно, Булгакова, Толстого, или кого-то еще, получаем кучу моментов, где приходится буквально угадывать мысли автора.
Попробую объяснить. Бывают места, где запятая «плавающая». Она может ставиться, а может не ставиться на усмотрение автора. Где запятая не потому, что например железное правило «перед НО ставим всегда», а где она регулирует смысл либо акценты. Обычно это даже не одна запятая, а совокупность запятых в предложении.
Пример. Сразу скажу, он далеко не самый удачный, но зато ближайший, и на мой взгляд для разъяснения худо-бедно подходит.
По ссылке а посте возьмем первое же предложение:
«Однажды весною, в час небывало жаркого заката, в Москве, на Патриарших прудах, появились два гражданина.»
И перепишем его так:
«Однажды весною, в час небывало жаркого заката в Москве, на Патриарших прудах появились два гражданина.»
Я могу ошибаться, но ИМХО оба предложения являются валидными с точки зрения правил. Отличаются лишь расстановкой акцентов.
В первом случае акцентирование понятно: так как это самое первое предложение в книге, автор дает читателю что-то вроде работы сайта гугл-мапс. Помните, в картах постепенно приближаемся, начиная с обзора карты мира, и до конкретного места. Вот тут то же самое, в начале книги автор дает читателю представление о месте и времени событий, а заодно и о погоде, начиная так же издалека, как в картах: Весна->небывало жаркий закат->Москва->Патриаршие->два гражданина. Почти как «Девушка, фонарь, аптека» )))
Во втором случе расстановка запятых другая, т.к. по акценту(который зависит от желания автора, но не читателя) слова «в час небывало жаркого заката в Москве» будут являться уточняющим членом предложения, который выделяется запятыми, но при этом может быть практически безболезненно вырезан из самого предложения: «Однажды весною на Патриарших прудах появились два гражданина.»(здесь, кстати, тоже можно придраться и выделить запятыми «на Патриарших прудах», говорю же — пример не очень удачный).
Надеюсь вы поняли, о чем я хотел сказать: акценты в предложениях изначально расставляет автор и только от его желания зависит само формирование предложения. Автор имеет свои мысли и акценты, и исходя из них формирует текст предложения.
В данной же программе мы занимаемся как бы reverse engineering'ом, то есть по тексту без запятых расставляем эти самые запятые. Большую часть из них мы расставим по правилам, но в какой-то части нам нужно знать(угадать) мысли автора. Мы смотрим как бы с обратной, по отношению к автору, стороны: видим текст(готовый продукт) и пытаемся распознать акценты автора.
Еще раз просьба, не смотрите на сам пример, он не особо удачен. Зрите в корень: из одной и той же последовательности слов иногда можно составить два разных по смыслу либо акцентам предложения.
За удачным же примером далеко ходить не надо, все знают пример «казнить нельзя помиловать».
То есть если данный движок использовать для экзаменационных целей, то необходимо составить тексты, исключающие неоднозначности в акцентах, а не брать их из художки.
Фотографий вблизи бы добавить. Не таких, где показывается фон разной местности и размытый ноут, на котором деталей не разберешь. И не таких, как на промо-сайтах, на которых показан пусть и детальный, но не настоящий ноут, а рендер модели из 3D-редактора.
Накрайняк эти же фотки сделать кликабельными со ссылками на полное изображение. Может этого хватит.
Сначала не хотел, но коль вы упомянули, на всякий случай добавлю, а то смотрю в тредах ниже люди и на этот счет местами заблуждаются:
В A-GPS уже после старта может использоваться онлайн режим, предполагающий использование мощностей вышек для рассчета своих координат. Это значит, что мобильное устройство может принятые PRN коды со спутников передавать на вышки для рассчетов и обратно от них получать уже вычисленные координаты. Это делается, чтобы разгрузить процессорные мощности мобильного устройства и тем самым заодно сэкономить энергию аккумуляторов. К LBS это тоже не относится, хотя использует те же транспортные механизмы.
Использование этого онлайн режима возможно только при достаточно плотном покрытии сотовой сети с достаточно модернизированным для использования этих возможностей оборудованием.
В LBS точно так же расчет координат может происходить как самим устройством, так и передаваться для вычисления на вышки.
Собственно частичное перекрытие данных технологий(например использование одних и тех же каналов связи) — это одна из причин, когда по невнимательности иногда эти технологии путают между собой.
Суть вашего первого комментария из его текста не читается вообще.
Уж извините, не хочу обидеть(правда), но вы постоянно оправдываетесь и «плаваете» в определениях.
Чтобы не продолжать этот занудный непродуктивный разговор, предлагаю следующее: давайте попытаемся сформулировать поточнее и на этом закончим.
Итак:
LBS используется только для того, чтобы пользователю как можно быстрее показать на экране хоть что-то. То есть для удобства.
Холодный старт GPS(или A-GPS) модуля — период времени с момента его активации(включения) до получения ним же его собственных координат посредством спутников.
Более раннее определение приблизительных координат с помощью LBS на время холодного старта не влияет никак.
Получение альманаха через любое доступное подключение к интернету, от сотовых или WiFi вышек, значительно уменьшает время холодного старта A-GPS.
>> я же описывал как работает A-GPS на iOS устройствах — там для начала используются данные от LBS
что ж вы упертый-то такой )))) LBS не относится к A-GPS. Это две разные технологии и системы. В случае с той же iOS — заключенные в одном устройстве. Но все-равно разные.
>> Вы еще забыли, что расчет позиции может происходить за пределами телефона. Это тоже часть A-GPS.
Да. Это онлайн режим A-GPS. Снижает нагрузку на вычислительные мощности мобильного устройства и как следствие на батарею. LBS здесь тоже не участвует.
С чего мне об этом забывать? К контексту не относится, я и не упоминал ))
>> Даже если я не прав насчет использования данных LBS, это никак не утвержает, что человек начавший тред прав — так как он не прав в корне.
Именно. Он просто плохо знает, как работает навигация. И именно для этого человека ваш ответ вообще никакой полезной информации не нес. Просто набор слабосвязанных между собой фраз.
Это уже позже в треде вы что-то объяснили, продолжая кстати по сей момент упираться и утверждать, что LBS хоть как-то относится к A-GPS )
Попробуйте глазами плохо знающего о GPS человека прочитать вот эту часть вашего сообщения(собственно весь смысл-то в ней): «телефон определяет координаты через соты и уже знает какие спутники ему искать».
У меня на его месте сразу возникнет вопрос — с какого это перепугу, узнав свои координаты, телефон вдруг сразу будет знать какие спутники ему искать?
Собственно это мотив первого моего ответа на ваш комментарий — я и рассказал про альманах. А иначе с того вашего ответа человек ничего бы не понял.
Хорошо. Давайте я объясню.
Это может быть вам понятно, что вы написали и что имели в виду под каждым словом.
Обычный человек видит так: «A-GPS это не определение координат через соты. Но чтоб не жрать батарею, он сначала определяет координаты через соты.»
То есть во-первых это может быть понято как «Определяет не через соты, но таки определяет через соты.» Это что за парадокс?
Предположим, что вы хотели сказать об использовании LBS. Мол LBS используется для ускорения холодного старта. Собственно вы и сейчас это утверждаете(двумя сообщениями выше). Это тоже в корне не верно.
LBS — отдельная технология. Она действительно например в той же iOS показывает юзеру приблизительные координаты еще до того, как A-GPS раздуплится. Но это — исключительно для удобства юзера. К A-GPS эта технология не имеет никакого отношения, хотя в большинстве случаев и используется параллельно(это действительно удобно).
Холодный старт в A-GPS ускоряется только за счет быстрого получения альманаха по сотовым или WiFi сетям.
То, что я упоминал о возможной оптимизации обработки альманаха с помощью LBS — забудьте. Это я просто предположил. Во-первых, это не даст значимого прироста скорости определения первичных координат, во-вторых, если где и используется, то уже в софтовой, относительно высокоуровневой, части самого девайса(коммуникатора или навигатора). Да и польза от этого сомнительна. Сейчас объясню почему(это кроме того, что эти системы пока еще нечасто находятся в одном чипе, LBS в большинстве случаев имеет вообще софтовую реализацию):
Технически еще до получения полного альманаха, при наличии достаточного количества памяти(нужно не так уж много), девайс может параллельно заранее начать прием PRN кодов от спутников. До получения альманаха он может ничего не знать о самих спутниках, но уже будет знать их ID(PRN номера), временные метки и разницу во времени приема.
Соответственно как только он примет альманах, ему ничего не стоит сразу же из накопленных пакетов сопоставить спутники с альманахом и моментально рассчитать текущие координаты. Данные LBS ему здесь не нужны вообще. Они могут помочь уже высокоуровневому софту более стабильно определить координаты при нахождении в городских условиях или вообще в зданиях. Там, где прием сигналов спутников затруднен либо идет с большим «шумом» погрешностей из-за отражения.
Сорри, я немного заврался.
В первом каменте написал «определение приблизительных координат по вышкам хотя и входит в технологию A-GPS, но не является главной функцией».
Не в A-GPS оно входит, а в блок навигации девайса. То есть ее чаще всего используют совместно с A-GPS — грех не реализовать, коль уже есть GSM-модуль.
>> «A-GPS это не определение координат через соты. Просто перед тем как начать жрать батарею и искать спутники (холодный старт) телефон определяет координаты через соты»
Вы уж определитесь в этом вопросе, через соты или не через соты )
Определение координат по сотовым и WiFi вышкам — это LBS(Location Based Service). К GPS и A-GPS эта технология отношения не имеет. Используется лишь как вспомогательная в дополнение к ним.
Есть еще один нюанс. На сколько я понимаю систему Assisted GPS, кроме попытки определения приблизительных координат по сотовым и WiFi-вышкам, девайс так же пытается альманах(расписание спутников) скачать через доступное интернет подключение. А если не получается, тогда уже тупит от полминуты и более, пока альманах из ловимых пакетов с самих спутников соберется(он там периодически передается кусками).
Кроме этого, после получения альманаха он может за счет предварительно определенного по базовым станциям местоположения самостоятельно отсечь из расписания «невидимые» в данный момент спутники и ловить только нужные частоты. Такая небольшая оптимизация. Хотя в большинстве случаев это не столь важно, ибо если на момент получения альманаха видно достаточно спутников, свои координаты девайс определит уже относительно быстро(пара секунд) и опять же — отсечет лишние частоты в соответствии с расписанием.
То есть определение приблизительных координат по вышкам хотя и входит в технологию A-GPS, но не является главной функцией. В первую очередь цель технологии на порядки быстрее получать альманах по альтернативным каналам связи(не с самих спутников). Именно эта функция ускоряет «холодный старт» вплоть до пары секунд. Остальное тоже плюс, но уже второстепенный.
Угу… понятно… хотя и не очень…
Так что у PHP-то с этим плохо? Кроме того, что большинство библиотек работы с БД блокируют скрипт на время выполнения своих вызовов? Например от отсылки запроса до момента, когда первый fetch можно будет делать. Дальше fetch'ить можно вроде как вперемежку с чем-то еще, но опять же — каждый fetch будет блокироваться.
Я имею в виду, что нельзя реализовать что-то вроде try_fetch с предварительной проверкой, есть ли уже чего fetch'ить в локальном буффере.
БД вообще самое узкое место получается — это та часть, работу которой контролировать изнутри нельзя. И если база затупила в ответе на любой вызов — придется ждать.
У меня как раз это частично решено выносом работы с БД в отдельный демон — он тупит вместе с базой, если что, а основной продолжает работать. Тут получается такая шняга: пока с асинхронного сокета связи с демоном БД не соберется полноценный ответ, основной демон не блокирован и ничем не ограничен делать любую другую работу.
Получается именно тот случай, когда вышеописанный в соседних ветках метод ввода отдельного демона(демона связи с БД в данном случае) не столько добавляет задержки в работу скрипта, сколько наоборот, спасает от залипаний и тупняков при обращениях к БД.
Ровно так же конечный скрипт может отправлять к демону серию запросов, ответы на которые за счет асинхронности могут возвращаться вовсе не в том порядке, в каком были отправлены, а в соответствии с требуемым временем на обработку. То есть ответы на более тяжелые запросы придут позже или типа того.
Так же никто не мешает скрипту работать в синхронном режиме — он просто не будет отправлять следующий запрос, пока не дождется ответа на предыдущий.
Вот как-то так.
По хорошему, у меня с этими асинхронно-ПХПшными экспериментами накопилось материалов на целую статью, а то и на несколько. Все времени нет заняться этим, заодно и задокументировать свои библиотечки…
А что у PHP не очень в этом плане?
Мож я чего не знаю…
У меня есть пара демонов, целиком написанных на PHP и использующих только либы из штатной поставки. Работают в одном потоке(один процесс, один тред), запросы асинхронны — сокеты (и серверный слушающий и акцептированные клиенты) полноценные(не локальные), толпой опрашиваются select'ами без блокировки. Работают и жрать не просят.
Там правда не сотня запросов в секунду, на большие нагрузки оно и не расчитывалось, но при паре-тройке сотен запросов в минуту даже не вспотеют(бывают такие пики во время СМС-рассылок по клиентам).
Логика внутри не сказать чтоб сложная, но посложнее предложенного варианта для кеширования данных.
И как-то на веб-морде никаких видимых задержек не наблюдается.
P.S. Я конечно понимаю, что далеко не все PHP-программисты вообще понимают, как на PHP можно написать асинхронный демон(штука нестандартная для PHP, да). Да и писать я его в свое время начал по приколу, сам думал бред на выходе получится. Просто время было, а за Си лень было приниматься. Ан нет. Работает зараза )
Точно )
Я наконец доехал до инета. Про нефтяную вышку я немного запамятовал — это было исследовательское судно, трансформирующееся в поплавок для нечувствительности к волнам на поверхности: www-mpl.ucsd.edu/resources/flip.intro.html
Тут видео трансформации: www.youtube.com/watch?v=QL8gMwNLW9g
Ну и еще по ходу дела нарыл вот такую ветро-платформу: gisee.ru/articles/windenergy/2905/
Совместить все это дело с якорными системами, и думаю проблемы решаемы )
А это в общем-то не важно. Это мелкие особенности реализации, к основной идее имеющие уже мало отношения.
Я не сомневаюсь, что реализаторы так или иначе решат и проблему размещения ветряков, и проблему ограждения зоны мешков )))
При хорошем запасе глубины ветрякам фундамент не особо нужен — я видел в сети проекты плавучих нефтяных вышек, которые «на месте» в рабочий режим поворачиваются вертикальной «свечкой» и за счет ухода этого «поплавка» корпусом в глубину стоят достаточно стабильно, не реагируя на волнения на поверхности. Это просто как вариант реализации, я не настаиваю )))
К сожалению сейчас привести пруф-ссылки могу, я в разъездах и пишу с автомобиля в мобильном режиме, не до поисков. Но если вам интересно, как доберусь до стационарного инета, могу вам найти и показать.
Трудно спорить о чем либо, с чем частично согласен и так )
Но только частично )))
Никто не мешает снять с демона функцию расшифровки, оставив ее в скрипте логина. В таком случае демон может работать кешем чего угодно статичного. Он становится более универсальным. Учитывая, что он хранит все в своей области ОЗУ, это довольно безопасно.
При разнесении нагрузки демонов по экземплярам(по серверам), например по принципу CRC идентификатора сессии, чтоб по возможности скрипт сразу сам вычислял без доп.запросов, к какому именно демону ему обращаться за данными конкретного юзера, это тоже может добавить плюс к производительности.
В общем при желании рулить можно многими вещами.
И опять же — все зависит от конкретики проекта, я не настаиваю на единственности и правильности решения. Где-то это вполне себе неплохое решение, а где-то оно явно лишнее и не нужное.
3. Вы под вызовом подразумеваете время коннекта или отдельного запроса в ту же БД?
Ок. Конкретный пример. Демон не имеет связи с БД. Скрипт, обрабатывающий страницу логина пользователя, берет данные из БД, пихает их демону на расшифровку и хранение. Остальные скрипты пользовательские данные из БД не берут, запрашивают их только у демона и уже в расшифрованном виде. Ну кроме скриптов, которые меняют эти данные(установить новый пароль, поменять имя и т.п.). Демон работает только со своей оперативкой. БД работает что с файлами, что с кешем, что с кучей скриптов(даже с теми, кому user data не нужны). Проблемы с временем коннектов частично решаемы персистент-коннектами. Тут все весьма неоднозначно и зависит опять же от конкретики проекта.
4. Опять упираемся в конкретику. Вот все стремится к одному и тому же )))
5. >> (кроме расчетов, они и так делаются, в том или другом месте)
То есть мое предложение заниматься расшифровыванием только во время логина пользователя или изменении его данных вы как бы пропустили, да? ))))
Один и тот же текст, начитанный актером в аудиокнигу, и прочитанный диктором новостей, может иметь совершенно разную интонационную окраску.
Однако вы правы: запрограммировать это крайне непросто, особенно учитывая, что программа не просто пару соседних слов должна анализировать, а все предложение с учетом частей речи, а иногда и абзац или даже несколько.
То есть фактически искусственный интеллект получится. Чат-бот здесь не прокатит.
Смущают только пара нюансов.
К самому движку и посту претензий особых нет. Убрать подсказку по выделению текста и обфусцировать передаваемое в JQuery запросах — это просто технические исправления.
Сейчас наверное фигню напишу, не уверен, что многие меня поймут, момент довольно тонкий, но…
1. для режима экзамена неплохо бы написать авторский текст, никому не известный. Ибо с тем же Булгаковым просто выделяем мышью пару предложений, поиск в Гугле, и видим оригинал текста.
2. если брать тексты писателей художественной литературы, неважно, Булгакова, Толстого, или кого-то еще, получаем кучу моментов, где приходится буквально угадывать мысли автора.
Попробую объяснить. Бывают места, где запятая «плавающая». Она может ставиться, а может не ставиться на усмотрение автора. Где запятая не потому, что например железное правило «перед НО ставим всегда», а где она регулирует смысл либо акценты. Обычно это даже не одна запятая, а совокупность запятых в предложении.
Пример. Сразу скажу, он далеко не самый удачный, но зато ближайший, и на мой взгляд для разъяснения худо-бедно подходит.
По ссылке а посте возьмем первое же предложение:
«Однажды весною, в час небывало жаркого заката, в Москве, на Патриарших прудах, появились два гражданина.»
И перепишем его так:
«Однажды весною, в час небывало жаркого заката в Москве, на Патриарших прудах появились два гражданина.»
Я могу ошибаться, но ИМХО оба предложения являются валидными с точки зрения правил. Отличаются лишь расстановкой акцентов.
В первом случае акцентирование понятно: так как это самое первое предложение в книге, автор дает читателю что-то вроде работы сайта гугл-мапс. Помните, в картах постепенно приближаемся, начиная с обзора карты мира, и до конкретного места. Вот тут то же самое, в начале книги автор дает читателю представление о месте и времени событий, а заодно и о погоде, начиная так же издалека, как в картах: Весна->небывало жаркий закат->Москва->Патриаршие->два гражданина. Почти как «Девушка, фонарь, аптека» )))
Во втором случе расстановка запятых другая, т.к. по акценту(который зависит от желания автора, но не читателя) слова «в час небывало жаркого заката в Москве» будут являться уточняющим членом предложения, который выделяется запятыми, но при этом может быть практически безболезненно вырезан из самого предложения: «Однажды весною на Патриарших прудах появились два гражданина.»(здесь, кстати, тоже можно придраться и выделить запятыми «на Патриарших прудах», говорю же — пример не очень удачный).
Надеюсь вы поняли, о чем я хотел сказать: акценты в предложениях изначально расставляет автор и только от его желания зависит само формирование предложения. Автор имеет свои мысли и акценты, и исходя из них формирует текст предложения.
В данной же программе мы занимаемся как бы reverse engineering'ом, то есть по тексту без запятых расставляем эти самые запятые. Большую часть из них мы расставим по правилам, но в какой-то части нам нужно знать(угадать) мысли автора. Мы смотрим как бы с обратной, по отношению к автору, стороны: видим текст(готовый продукт) и пытаемся распознать акценты автора.
Еще раз просьба, не смотрите на сам пример, он не особо удачен. Зрите в корень: из одной и той же последовательности слов иногда можно составить два разных по смыслу либо акцентам предложения.
За удачным же примером далеко ходить не надо, все знают пример «казнить нельзя помиловать».
То есть если данный движок использовать для экзаменационных целей, то необходимо составить тексты, исключающие неоднозначности в акцентах, а не брать их из художки.
Возражения и критика приветствуются.
Накрайняк эти же фотки сделать кликабельными со ссылками на полное изображение. Может этого хватит.
В A-GPS уже после старта может использоваться онлайн режим, предполагающий использование мощностей вышек для рассчета своих координат. Это значит, что мобильное устройство может принятые PRN коды со спутников передавать на вышки для рассчетов и обратно от них получать уже вычисленные координаты. Это делается, чтобы разгрузить процессорные мощности мобильного устройства и тем самым заодно сэкономить энергию аккумуляторов. К LBS это тоже не относится, хотя использует те же транспортные механизмы.
Использование этого онлайн режима возможно только при достаточно плотном покрытии сотовой сети с достаточно модернизированным для использования этих возможностей оборудованием.
В LBS точно так же расчет координат может происходить как самим устройством, так и передаваться для вычисления на вышки.
Собственно частичное перекрытие данных технологий(например использование одних и тех же каналов связи) — это одна из причин, когда по невнимательности иногда эти технологии путают между собой.
Уж извините, не хочу обидеть(правда), но вы постоянно оправдываетесь и «плаваете» в определениях.
Чтобы не продолжать этот занудный непродуктивный разговор, предлагаю следующее: давайте попытаемся сформулировать поточнее и на этом закончим.
Итак:
LBS используется только для того, чтобы пользователю как можно быстрее показать на экране хоть что-то. То есть для удобства.
Холодный старт GPS(или A-GPS) модуля — период времени с момента его активации(включения) до получения ним же его собственных координат посредством спутников.
Более раннее определение приблизительных координат с помощью LBS на время холодного старта не влияет никак.
Получение альманаха через любое доступное подключение к интернету, от сотовых или WiFi вышек, значительно уменьшает время холодного старта A-GPS.
По-моему достаточно )
что ж вы упертый-то такой )))) LBS не относится к A-GPS. Это две разные технологии и системы. В случае с той же iOS — заключенные в одном устройстве. Но все-равно разные.
>> Вы еще забыли, что расчет позиции может происходить за пределами телефона. Это тоже часть A-GPS.
Да. Это онлайн режим A-GPS. Снижает нагрузку на вычислительные мощности мобильного устройства и как следствие на батарею. LBS здесь тоже не участвует.
С чего мне об этом забывать? К контексту не относится, я и не упоминал ))
>> Даже если я не прав насчет использования данных LBS, это никак не утвержает, что человек начавший тред прав — так как он не прав в корне.
Именно. Он просто плохо знает, как работает навигация. И именно для этого человека ваш ответ вообще никакой полезной информации не нес. Просто набор слабосвязанных между собой фраз.
Это уже позже в треде вы что-то объяснили, продолжая кстати по сей момент упираться и утверждать, что LBS хоть как-то относится к A-GPS )
Попробуйте глазами плохо знающего о GPS человека прочитать вот эту часть вашего сообщения(собственно весь смысл-то в ней): «телефон определяет координаты через соты и уже знает какие спутники ему искать».
У меня на его месте сразу возникнет вопрос — с какого это перепугу, узнав свои координаты, телефон вдруг сразу будет знать какие спутники ему искать?
Собственно это мотив первого моего ответа на ваш комментарий — я и рассказал про альманах. А иначе с того вашего ответа человек ничего бы не понял.
Это может быть вам понятно, что вы написали и что имели в виду под каждым словом.
Обычный человек видит так: «A-GPS это не определение координат через соты. Но чтоб не жрать батарею, он сначала определяет координаты через соты.»
То есть во-первых это может быть понято как «Определяет не через соты, но таки определяет через соты.» Это что за парадокс?
Предположим, что вы хотели сказать об использовании LBS. Мол LBS используется для ускорения холодного старта. Собственно вы и сейчас это утверждаете(двумя сообщениями выше). Это тоже в корне не верно.
LBS — отдельная технология. Она действительно например в той же iOS показывает юзеру приблизительные координаты еще до того, как A-GPS раздуплится. Но это — исключительно для удобства юзера. К A-GPS эта технология не имеет никакого отношения, хотя в большинстве случаев и используется параллельно(это действительно удобно).
Холодный старт в A-GPS ускоряется только за счет быстрого получения альманаха по сотовым или WiFi сетям.
То, что я упоминал о возможной оптимизации обработки альманаха с помощью LBS — забудьте. Это я просто предположил. Во-первых, это не даст значимого прироста скорости определения первичных координат, во-вторых, если где и используется, то уже в софтовой, относительно высокоуровневой, части самого девайса(коммуникатора или навигатора). Да и польза от этого сомнительна. Сейчас объясню почему(это кроме того, что эти системы пока еще нечасто находятся в одном чипе, LBS в большинстве случаев имеет вообще софтовую реализацию):
Технически еще до получения полного альманаха, при наличии достаточного количества памяти(нужно не так уж много), девайс может параллельно заранее начать прием PRN кодов от спутников. До получения альманаха он может ничего не знать о самих спутниках, но уже будет знать их ID(PRN номера), временные метки и разницу во времени приема.
Соответственно как только он примет альманах, ему ничего не стоит сразу же из накопленных пакетов сопоставить спутники с альманахом и моментально рассчитать текущие координаты. Данные LBS ему здесь не нужны вообще. Они могут помочь уже высокоуровневому софту более стабильно определить координаты при нахождении в городских условиях или вообще в зданиях. Там, где прием сигналов спутников затруднен либо идет с большим «шумом» погрешностей из-за отражения.
В первом каменте написал «определение приблизительных координат по вышкам хотя и входит в технологию A-GPS, но не является главной функцией».
Не в A-GPS оно входит, а в блок навигации девайса. То есть ее чаще всего используют совместно с A-GPS — грех не реализовать, коль уже есть GSM-модуль.
>> «A-GPS это не определение координат через соты. Просто перед тем как начать жрать батарею и искать спутники (холодный старт) телефон определяет координаты через соты»
Вы уж определитесь в этом вопросе, через соты или не через соты )
Определение координат по сотовым и WiFi вышкам — это LBS(Location Based Service). К GPS и A-GPS эта технология отношения не имеет. Используется лишь как вспомогательная в дополнение к ним.
Кроме этого, после получения альманаха он может за счет предварительно определенного по базовым станциям местоположения самостоятельно отсечь из расписания «невидимые» в данный момент спутники и ловить только нужные частоты. Такая небольшая оптимизация. Хотя в большинстве случаев это не столь важно, ибо если на момент получения альманаха видно достаточно спутников, свои координаты девайс определит уже относительно быстро(пара секунд) и опять же — отсечет лишние частоты в соответствии с расписанием.
То есть определение приблизительных координат по вышкам хотя и входит в технологию A-GPS, но не является главной функцией. В первую очередь цель технологии на порядки быстрее получать альманах по альтернативным каналам связи(не с самих спутников). Именно эта функция ускоряет «холодный старт» вплоть до пары секунд. Остальное тоже плюс, но уже второстепенный.
Так что у PHP-то с этим плохо? Кроме того, что большинство библиотек работы с БД блокируют скрипт на время выполнения своих вызовов? Например от отсылки запроса до момента, когда первый fetch можно будет делать. Дальше fetch'ить можно вроде как вперемежку с чем-то еще, но опять же — каждый fetch будет блокироваться.
Я имею в виду, что нельзя реализовать что-то вроде try_fetch с предварительной проверкой, есть ли уже чего fetch'ить в локальном буффере.
БД вообще самое узкое место получается — это та часть, работу которой контролировать изнутри нельзя. И если база затупила в ответе на любой вызов — придется ждать.
У меня как раз это частично решено выносом работы с БД в отдельный демон — он тупит вместе с базой, если что, а основной продолжает работать. Тут получается такая шняга: пока с асинхронного сокета связи с демоном БД не соберется полноценный ответ, основной демон не блокирован и ничем не ограничен делать любую другую работу.
Получается именно тот случай, когда вышеописанный в соседних ветках метод ввода отдельного демона(демона связи с БД в данном случае) не столько добавляет задержки в работу скрипта, сколько наоборот, спасает от залипаний и тупняков при обращениях к БД.
Ровно так же конечный скрипт может отправлять к демону серию запросов, ответы на которые за счет асинхронности могут возвращаться вовсе не в том порядке, в каком были отправлены, а в соответствии с требуемым временем на обработку. То есть ответы на более тяжелые запросы придут позже или типа того.
Так же никто не мешает скрипту работать в синхронном режиме — он просто не будет отправлять следующий запрос, пока не дождется ответа на предыдущий.
Вот как-то так.
По хорошему, у меня с этими асинхронно-ПХПшными экспериментами накопилось материалов на целую статью, а то и на несколько. Все времени нет заняться этим, заодно и задокументировать свои библиотечки…
Мож я чего не знаю…
У меня есть пара демонов, целиком написанных на PHP и использующих только либы из штатной поставки. Работают в одном потоке(один процесс, один тред), запросы асинхронны — сокеты (и серверный слушающий и акцептированные клиенты) полноценные(не локальные), толпой опрашиваются select'ами без блокировки. Работают и жрать не просят.
Там правда не сотня запросов в секунду, на большие нагрузки оно и не расчитывалось, но при паре-тройке сотен запросов в минуту даже не вспотеют(бывают такие пики во время СМС-рассылок по клиентам).
Логика внутри не сказать чтоб сложная, но посложнее предложенного варианта для кеширования данных.
И как-то на веб-морде никаких видимых задержек не наблюдается.
P.S. Я конечно понимаю, что далеко не все PHP-программисты вообще понимают, как на PHP можно написать асинхронный демон(штука нестандартная для PHP, да). Да и писать я его в свое время начал по приколу, сам думал бред на выходе получится. Просто время было, а за Си лень было приниматься. Ан нет. Работает зараза )
Я наконец доехал до инета. Про нефтяную вышку я немного запамятовал — это было исследовательское судно, трансформирующееся в поплавок для нечувствительности к волнам на поверхности: www-mpl.ucsd.edu/resources/flip.intro.html
Тут видео трансформации: www.youtube.com/watch?v=QL8gMwNLW9g
Ну и еще по ходу дела нарыл вот такую ветро-платформу: gisee.ru/articles/windenergy/2905/
Совместить все это дело с якорными системами, и думаю проблемы решаемы )
Я не сомневаюсь, что реализаторы так или иначе решат и проблему размещения ветряков, и проблему ограждения зоны мешков )))
При хорошем запасе глубины ветрякам фундамент не особо нужен — я видел в сети проекты плавучих нефтяных вышек, которые «на месте» в рабочий режим поворачиваются вертикальной «свечкой» и за счет ухода этого «поплавка» корпусом в глубину стоят достаточно стабильно, не реагируя на волнения на поверхности. Это просто как вариант реализации, я не настаиваю )))
К сожалению сейчас привести пруф-ссылки могу, я в разъездах и пишу с автомобиля в мобильном режиме, не до поисков. Но если вам интересно, как доберусь до стационарного инета, могу вам найти и показать.
Но только частично )))
Никто не мешает снять с демона функцию расшифровки, оставив ее в скрипте логина. В таком случае демон может работать кешем чего угодно статичного. Он становится более универсальным. Учитывая, что он хранит все в своей области ОЗУ, это довольно безопасно.
При разнесении нагрузки демонов по экземплярам(по серверам), например по принципу CRC идентификатора сессии, чтоб по возможности скрипт сразу сам вычислял без доп.запросов, к какому именно демону ему обращаться за данными конкретного юзера, это тоже может добавить плюс к производительности.
В общем при желании рулить можно многими вещами.
И опять же — все зависит от конкретики проекта, я не настаиваю на единственности и правильности решения. Где-то это вполне себе неплохое решение, а где-то оно явно лишнее и не нужное.
3. Вы под вызовом подразумеваете время коннекта или отдельного запроса в ту же БД?
Ок. Конкретный пример. Демон не имеет связи с БД. Скрипт, обрабатывающий страницу логина пользователя, берет данные из БД, пихает их демону на расшифровку и хранение. Остальные скрипты пользовательские данные из БД не берут, запрашивают их только у демона и уже в расшифрованном виде. Ну кроме скриптов, которые меняют эти данные(установить новый пароль, поменять имя и т.п.). Демон работает только со своей оперативкой. БД работает что с файлами, что с кешем, что с кучей скриптов(даже с теми, кому user data не нужны). Проблемы с временем коннектов частично решаемы персистент-коннектами. Тут все весьма неоднозначно и зависит опять же от конкретики проекта.
4. Опять упираемся в конкретику. Вот все стремится к одному и тому же )))
5. >> (кроме расчетов, они и так делаются, в том или другом месте)
То есть мое предложение заниматься расшифровыванием только во время логина пользователя или изменении его данных вы как бы пропустили, да? ))))