Обновить
36
0
Лев@exaide

Пользователь

Отправить сообщение
Обращаю внимание на то, что Вы ещё не приводили «чётких примеров и дефиниций», равно как и ссылок на публикации по брейнетике.

Тем не менее, приведу несколько ссылок про семиотику. Их более чем достаточно для понимания концепции представления знаний. Сенсформика и индефинитика представляют меньший интерес для данной темы.
Вы вырываете тезис из контекста.

Если отвечая на мой первый вопрос выше, Вы скажете «да», это означает, что знания, содержащиеся в сообщении «Петя сказал, что завтра он не пойдёт в школу» могут быть сохранены в любой современной БД. Если же ответ «нет», то рассуждать нужно не о «матрёшечной» структуре, а хотя бы о базовой реализации БЗ на самом примитивном уровне (раз уж он, на Ваш взгляд, качественно отличается).

В целом, не конструктивно предлагать дискуссию о знаниях столь туманно описывая проблематику и не ссылаясь ни на какие публикации. Спекулировать на фундаментальных проблемах не предлагая новых теорий или методов, критикуя всех и вся — удел псевдонаук.

Для меня такае науки, как семиотика, сенсформика и индефинитика дают достаточное понимание о том, как можно представлять и обрабатывать знания. А такие стандарты (RDF, OWL, micro*) или онтологии (такие, как SIOC, SKOS, DC, FOAF) являются отличными инструментами для того, чтобы воплощать это в жизнь.
Т.е. Ваша точка зрения заключается в том, что для перехода от данных к знаниям необходимо увеличить детализацию самих данных, их контекста и учесть некоторый набор типовых поведенческих, мыслительных алгоритмов человека?

О какой вложенности идёт речь, можно больше конкретики? Описанная вложенность — алгоритмическая, она не отражается на представлении знаний.

Перечисленные типы БД не обладают качественными различиями в контексте обсуждения. Вложенность можно реализовать используя любой из обозначенных подходов, равно как перевод данных из однго представления в другое не представляет сложностей (это лишь дело удобства и быстродействия обработки данных).
Благодаря сообществам, сделанное одиночками приобретает значимость, обретает поддержку/финансирование/и т.п. Но сам факт того, что фундаментальные проекты в области ИТ сделаны теми самыми одиночками, от этого не меняется.
Не забывайте, что вероятность получения worst case для массива уже из 100 чисел составляет менее 10^-200 при более-менее нормальной реализации алгоритма. Поэтому для быстрой сортировки используется оценка средней сложности, которая как раз составляет O(n log n).
и желательно ставить символ доллара перед суммой или, хотя бы, отделять пробелом, если он указан после.
Не поверите, но можно делать выборку только новых записей из RSS.
Аналогии были про накладные расходы для обеспечения изменения поля в зависимости от его значения и без этой зависимости. Апдейтом можно изменить счётчик на 10%, а INCR — нет. За счёт такого ограничения удаётся избежать создания блокировок на уровне строк в БД. Как это реализовано на уровне ядра СУБД, думаю, можно узнать у хабраюзера kadishmal. Мне кажется, это вариация на тему атомиков.
Для вознокновения дедлока необходимо как минимум наличие блокировок.

Попробую объяснить на примере, хотя и не претендую на полноту знаний о CUBRID. Рассмотрим выдачу номеров новым абонентам телефонной сети…

Первый вариант — апдейт. Предположим, что последний выданный номер написан на доске мелом и чтобы выдать новый, ответственный человек должен подойти к доске (начало блокировки), запомнить написанное число, стереть его и записать увеличенное на 1 (конец блокировки).

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

В обоих случаях есть блокировки на уровне алгоритма реализации, но это не то же самое что блокировки СУБД (которые значительно более ресурсоёмки): первый случай требует знания того что было на доске и вычислений, второй лишь бездумного сбрасывания карты. В первом случае несколько человек у доски устроят хаос, во втором будет лишь тяжело уследить какой номер был только что сверху (грязное чтение).

Думаю детали реализации можно подсмотреть — проект же открытый :)
Соглашусь про нелогичность операции «чтения» которая меняет данные, это сродни геттеру, который меняет поле класса при каждом вызове. UPDATE RETURNING всё же не является эквивалентом именно из-за создания блокировки. Тем не менее, рост производительности пытается всё это оправдать :)

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

С параллельным изменением возможны 2 сценария — INCR и INCR в селектах, либо INCR и операция DML. В первом случае (который и предполагается использовать) всё просто — счётчик дважды увеличится, т.к. это не апдейты которые читают данные перед изменением и грязных чтений не будет. Со вторым сценарием я не экспериментировал… надеюсь лишь что селект при этом не ждёт снятия блокировки :)
github и maven транслитерированы, java, velocity и html — нет. Походит на дискриминацию. Осталось найти признак по которому она происходит.

P.S.: сама статья понравилась.
Люди читающие заметку хотят знать чем она может быть полезна им, а не Вам, при всём уважении. Я не отрицаю актуальность решённой проблемы, а лишь хочу чтобы она была ясна до прочтения стены комментариев.
Обратите внимание на количество сделанных вами оговорок: «требуется именно имитировать ajax-клиента», «кросс-доменный запрос», «все лагает, памяти на всех не напасешься», кроссплатформенность и т.д.

Стоило написать всё это в статье. Без этих оговорок велосипед не нужен, а все вопросы решаются общеиспользуемыми инструментами.
и, в завершение ликбеза по man'у
-H "content-type: application/soap+xml"
-b "some cookies"

В любом случае, предположение об отсутствии «приличного инструмента для отладки json» сомнительно.
curl -d @request_file.xml "url string here"
Тогда всё сходится. Хотя, всё же, общепринято не учитывать размер входных данных при оценке требований к памяти.
Интересно для чего 6. По-моему 4 хватает:
public class Main {
    static private long NOD(long n1, long n2) {
        if (n2 == 0)
            return n1;
        return NOD(n2, n1 % n2);
    }
    
    static private void shr(char[] arr, int N) {
        for (int i = 0; i < NOD(arr.length, N); i++) {
            int j = i;
            char saved = arr[j];
            do {
                j = (j + N) % arr.length;
                char nextVal = arr[j];
                arr[j] = saved;
                saved = nextVal;
            } while (i != j);
        }
    }
    
    public static void main(String[] args) {
        char[] test = {'e', '2', 'i', '/', 'o', 'e', 'u', 'i', '/', 'o'};
        shr(test, 2);
        System.out.println(test);
    }
}


в android market тоже пока что недоступно
Остаётся только посочувствовать тем, кому такой код останется на сопровождение.

не иначе как для Франкенштейна

Информация

В рейтинге
Не участвует
Откуда
Уфа, Башкортостан(Башкирия), Россия
Зарегистрирован
Активность