> как определять грамматические конструкции и правила?
Если писать код самому, нужно, разумеется, знать все эти правила и запрогать их (алгоритм указал). Т. е. Вы должны знать всю грамматику японского.
Если же нужно готовое решение, то готовых я не знаю, я могу только потеоретизировать на тему алгоритмов для разбора.
> были бы в предложении пробелы!!! вопроса бы не было
Расстановка пробелов — не очень сложная операция (алгоритм тоже указал). А вот грамматический разбор предложения и установление зависимости слов — очень трудная (алгоритм указал).
> сам пока собираю переводы слов, значение кандзи и т. д. с интернета.
Можно скачать весь словарь JMDict в машиночитаемом формате. Он для этого и создавался, чтобы его можно было скачать.
О, спасибо за лайк, я если честно, даже не ожидал, что Вы прочитаете мой ответ =) У меня такое чувство, что реально интересоваться этой темой и размышлять на эту тему может только маньяк)
PS. У Вас может возникнуть вопрос, как в частице は мы определили, что глагол является концом части сложного предложения, а не началом причастного оборота. Легко: если поюзаны частицы けど、のに、から、ので или условные формы глагола, либо же предложение тупо кончилось, то это конец части. Если же у нас, допустим, глагол + существительное, то эту связку лучше рассматривать не как сложное предложение, а как причастный оборот, а значит は продолжает своё действие даже несмотря на наличие глагола.
Тогда тут может возникуть другой вопрос: а что, если сам автор решил не распространять действие так далеко, может ли оно закончиться раньше? Ответ: я не знаю, и как определить — тоже не знаю, т. к. по смыслу оба варианта, вероятно, будут абсолютно идентичны, а значит определить как оно на самом деле, вероятно нельзя (либо тут нужен опытный лингвист, чтобы он сказал, может ли は распространять действие меньше).
Кстати, если взглянуть на зависимости в этом предложении:
(趣味を仕事にしたら)(趣味は(((無くなる)ことに)なるだろう))
… то может показаться, что японский сложный для понимания человеком. На самом деле это не так, т. к. основной принцип прост: определение обычно стоит сразу перед определяемым. Благодаря этому в реальности всё невероятно просто. Из этого правила 4 исключения (которые я перечислил выше), но они все легки — は вводит тему, сложное предложение можно тупо рассматривать как 2 простых, а перечисления сразу идентифицируют себя как перечисления (в русском же у Вас не возникает проблем с перечислениями). Поэтому не надо смотреть на сложность скобок — в реальности всё было бы легко даже при отсутствии интуиции, а ведь на самом деле интуиция присутствует, а значит в реальности всё до невероятности просто.
Пример 2 (разбор с начала):
趣味を仕事にしたら趣味は無くなることになるだろう — исходная фраза
[趣味を 仕事にしたら趣味は無くなることになるだろう — находим определение, кладём в стек "["
[趣味を 仕事に したら趣味は無くなることになるだろう — находим ещё одно определение
[趣味を 仕事に したら] <趣味は無くなることになるだろう — находим определяемое, убираем из стека "[", закрываем квадратную скобку. Также したら указывает на то, что текущая группа является определением последующей части предложения, поэтому добавляем в стек "<". Так произошло, потому что условная форма говорит нам о том, что это сложное предложение.
[趣味を 仕事に したら] <趣味は <無くなることになるだろう — находим определение 趣味は. は говорит о том, что текущее определение определяет последующее предложение, а значит кладём в стек "<".
[趣味を 仕事に したら] <趣味は <[無く なることになるだろう — находим определение 無く. Мы знаем, что это определение, а не определяемое, т. к. это наречие. Раз мы нашли "висящее" определение, добавляем скобку "[" и кладём её в стек. Когда мы найдёт первое определяемое, мы сможем убрать "[" из стека.
[趣味を 仕事に したら] <趣味は <[無く なる] ことになるだろう — находим определяемое なる, убираем "[" из стека.
[趣味を 仕事に したら] <趣味は <([無く なる] ことに) なるだろう — находим определяемое ことに. Раз мы нашли определяемое без "висячего" определения, это значит, что текущая группа теперь является определением для этого определяемого. Выражаем это круглыми скобками. При этом работа со стеком для круглых скобок нам не требуется (но тут мог использоваться другой стек для того, чтобы понять, где начинается наша текущая группа).
[趣味を 仕事に したら] <趣味は <(([無く なる] ことに) なるだろう) — находим определяемое なるだろう. Аналогично добавляем круглые скобки. Определением этого слова будем являться текущая группа, а из предыдущего пункта мы знаем, что текущая группа — ([無くなる]ことに).
[趣味を 仕事に したら] <趣味は <(([無く なる] ことに) なるだろう)>> — мы нашли конец части сложного предложения, что позволяет нам убрать две скобки "<" из стека. Разбор окончен.
(趣味を 仕事に したら) (趣味は ((((無く なる) ことに) なるだろう))) — заменяем квадратные и треугольные скобки на круглые.
(趣味を 仕事に したら) (趣味は (((無く なる) ことに) なるだろう)) — упрощаем выражение, убирая "лишние" скобки. Как это ни удивительно, но у нас вышел абсолютно тот же результат, как при разборе с конца.
(趣味を仕事にしたら)(趣味は(((無くなる)ことに)なるだろう)) — тоже самое без пробелов. Компьютер теперь может понимать японскую речь, ну а мы прокачали своё знание японского =)
С каким проблемами мы будем сталкиваться:
1. Нарушение порядка слов (в японском на самом деле определения могут стоять после определяемого)
2. Проблемы с частицей が
3. Проблемы с опусканием сказуемого (думаю, лёгкая проблема).
4. И др., например, синонимы
PS. Из-за нарушение порядка слов вместо скобок придётся использовать что-то другое, например, стрелочки + скобки. Чаще всего нарушение порядка идёт темой (пример: "好きだよ、私は"), но может быть вызвано и другими определениями (пример: "やっと出来た、宿題を"). Теоретически вынести за конец предложения можно даже несколько определений, хотя на практике такое почти не встречается. Кстати, интересно подметить, что это говорит о том, что в японском по факту любой порядок слов — можно поставить слова в каком угодно порядке. Конечно, это немного преувеличено, т. к. при изменении порядка изменяется оттенок, а также мы не можем так просто разрубать или перемешивать слова в сложных конструкциях, а также в японском есть стандартный порядок, но тем не менее забавная вещь. Куда хочешь, туда и ставь слово.
PS. Возможно, в реальной жизни разбор нужно делать с начала, а не с конца, чтобы упростить разбор на слова.
PS. Задача разбора предложения — очень сложная задача для реализации, а также очень трудоёмкая для написания по разным причинам, а также требует высококвалифицированного программиста, а также имеет очень много серьёзных подводных камней, которые я здесь не перечислил. Кроме того, непонятно, зачем это нужно. Ну вот попытались Вы понять смысл предложения. А дальше что с ним делать? Для перевода на другие языки я не уверен, что это годится. А кроме перевода где ещё это может быть нужно? Для написания бота? Хотя может где-то нужно, не знаю… Лично я написал этот ответ с теоретической точки зрения, т. к. люблю японский и программирование.
Где можно почитать правила платформы? Или разрешено продавать всё, что не противоречит законодательству? Если да, то в рамках законодательства какой страны они работают?
rPman, Зачем мне единая площадка? Мне она не нужна, я даже рад, что её нет. Тем более, что в мире столько стран, у меня есть ну очень большие сомнения, что все страны могли бы объединиться и сделать единый сервис.
Я говорил о сервисе-базе данных, где будут ссылки на площадки для каждого произведения. Такой сервис может просто скриптом парсить площадки и выдавать ссылки. Было бы очень удобно.
Впрочем, за уже оставленные рекомендации спасибо, я протестирую их.
Зачем мне на русском языке? Мне надо с русскими субтитрами, если их нет, то с английскими или японскими, если их нет, то с субтитрами языка оригинала, если и их нет, то пусть будет хотя бы без субтитров.
А по поводу Google Play — я сильно сомневаюсь, что там можно что-то найти. Разве что очень маленький процент самых популярных вещей, снятых в США. Полагаться на удачу не вариант, нужно чтобы ты ввёл и 100% получил список всех сервисов.
По поводу поисковика Google у меня тоже есть сомнения, хотя я попробую. Но как минимум Google не сможет распарсить название. Ведь чаще всего произведения имеют много разных вариантов написания названия, и сервис должен понимать их все. Это исключая неофициальные переводы названия, т. к. понятно, что их может быть бесконечное множество, но они и не нужны, т. к. человек в здравом уме не будет гуглить, к примеру, по русскому названию.
Сергей Горностаев, спасибо, если так подумать, у нас есть команда взятия значения по адресу, значение которого находится по другому адресу. И в цикле мы вначале выполняем эту команду допустим, для (внешнего) адреса 1000, потом для 1001, потом для 1002, и логично, что мы выполним эту команду также и для 1003, 1004 и т. д. Ну или как-нибудь аналогично по последовательности команд, как Вы сказали.
Получается, теоретически процессор может предсказать такие рандомные обращения к памяти, потому что их вызывает явно не рандомный код.
Сергей Горностаев, упреждающее чтение возможно только при последовательном доступе. Если у нас есть 1 ГБ данных, к которым мы обращаемся рандомно, то я сомневаюсь, что процессор сможет это оптимизировать… (хотя не факт).
Фишка в том, что мы не совсем рандомно обращаемся, по факту следующий рандомный элемент известен заранее. Вот и интересно, насколько хорошо такие вещи оптимизируются или в случае чего лучше самому соптимизировать.
Ну и можно дополнить, что при этом само Node-приложение не зависло, а продолжает выполняет требуемые вычисления, просто часть задач приостановились, а другая часть успешно работает.
mayorovp, а что Вам мешает ответить на вопрос, вместо того, чтобы задавать встречные вопросы, не относящиеся к делу. Думаю, автор итак знает про такой подход, и сейчас задаёт вопрос не про это.
Все вместо ответа отвечают как перестать использовать длинные ссылки. А вопрос был не в этом. У меня тот редкий случай, когда длинные ссылки на 99% подходят лучше всех.
Пользователь вводит поисковый запрос, к примеру, на 2000 символов. И хочет сохранить ссылку на этот запрос.
Нет, кто-то скажет "сохраните тогда ссылку на сервере". Но ссылка обновляется после каждого ввода символа, а ответы показываются мгновенно. Это ж сколько ссылок пришлось бы сохранить.
Браузеры вроде поддерживают 32 или 64 КБ в GET. Если поддерживают, почему бы этим не воспользоваться? Я конечно не надеялся на ответ, но…
Ладно, сам потом попытаюсь по логам посмотреть, может там чё-то будет.
