Здравствуйте, olegkr, Вы писали:

I>>Ты предложил вариант который дает слишком много кода и я тебя даже предупредил об этом.
O>О да! Для начала наворотить тонну кода для своего языка, что бы потом вместо двух килограмм написать один.

Я так и думал, религия запрещает перечитать написаное.

Может хватит додумывать и выдумывать ? Я же сказал — решение на C# заняло слишком много кода, который надо было постоянно править.

В нашем случае написание языка было далеко не самой сложной задачей, но тебе, безусловно, виднее.

Здравствуйте, olegkr, Вы писали:

O>Замечательный теоретический пример
Я как-то его делал для одной довольно популярной в РФ программы...

Здравствуйте, Pzz, Вы писали:

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

IMHO внутренние тормоза должны быть очень надёжны и многоплановы. Если ты что-то не можешь описать регэкспом за час (этот таймаут с большим пребольшим запасом взят), то точно надо тормознуть и подумать почему не получается...

Здравствуйте, olegkr, Вы писали:

O>Да нет там никаких особых тонкостей

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

Здравствуйте, AndrewVK, Вы писали:

E>>Проблема только в том, что с глубокими знаниями производительность не коррелирует...
AVK>У тебя есть данные статистики? Или тебе так кажется?
Ну статистика в рамках конторы за историю её существования, так скажем.
Немного, но что есть.


AVK>Не могу согласиться. Формальные грамматики были придуманы как раз для описания грамматик естественных языков в формальном виде. Это первыше шажки на этапе компьютерного анализа текстов на естественных языках. Впрочем, я никого ни в чем убеждать не намерен. Есть желание начинать изготовление космического корабля с каменного молотка — ради бога, как я уже говорил, ряд факторов в современном софтостроении это позволяют.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Если наложить ограничение на длинну строки, это точно совершенно описывается конечным автоматом. А значит, и регулярное выражение можно подобрать

Если наложить ограничение на длину, то будет просто конечный словарь вариантов. Правда при длинне скажем в 100 символов оо-о-о-о-о-о-о-о-о-о-о-о-о-о-о-о-о-о-о-о-о-очень большой. И регэксп такой же будет и автомат. Таки лучше стековым...

Здравствуйте, SE, Вы писали:

SE>По поводу рисования в восьми направлениях, интересная идея, я наверно тоже тупой кодер , но зачем оптимизировать зарание, разве простота кода не важней?

Возможно ты и прав, я на всяк случай прикинул, как оно было бы.
В целом сложнее. Хотя может тоже не работает, так как я тоже "из головы"...

//    рисует линию
void drawLine( int xFrom, int yFrom, int xTo, int yTo );    

//    Рисует 2 элементарных "дуги" окружности симметричных относительно линии 
//        ( x - xCenter ) = ( y - yCenter )
void drawTwoPiecesOfCircle( int xCenter, int yCenter, int dxStart, int dyStart, int dxEnd, int dyEnd )
{
    drawLine( xCenter+dxStart, yCenter+dyStart, xCenter+dxEnd, yCenter+dyEnd );
    drawLine( xCenter+dyStart, yCenter+dxStart, xCenter+dyEnd, yCenter+dxEnd );
}

//    рисует четыре элементарные "дуги" окружности, симметричные относительно линий
//        ( x = xCenter ), ( y = yCenter )
void drawFourPiecesOfCircle( int xCenter, int yCenter, int dxStart, int dyStart, int dxEnd, int dyEnd )
{
    drawLine( xCenter+dxStart, yCenter+dyStart, xCenter+dxEnd, yCenter+dyEnd );
    drawLine( xCenter+dxStart, yCenter-dyStart, xCenter+dxEnd, yCenter-dyEnd );
    drawLine( xCenter-dxStart, yCenter+dyStart, xCenter-dxEnd, yCenter+dyEnd );
    drawLine( xCenter-dxStart, yCenter-dyStart, xCenter-dxEnd, yCenter-dyEnd );
}

//    Рисует 8 элементарных "дуг" окружности симметричных относительно линий 
//        ( x = xCenter ), ( y = yCenter ) и ( x - xCenter ) = ( y - yCenter )
void drawEightPiecesOfCircle( int xCenter, int yCenter, int dxStart, int dyStart, int dxEnd, int dyEnd )
{
    drawFourPiecesOfCircle( xCenter, yCenter, dxStart, dyStart, dxEnd, dyEnd );
    drawFourPiecesOfCircle( xCenter, yCenter, dyStart, dxStart, dyEnd, dxEnd );
}


//    Рисует окружность
void drawCircle( int xCenter, int yCenter, int r )
{
    assert( r > 0 );
    const double drawDistance = M_PI_4; //    будем рисовать 1/8 окружности, попутно рисуя 8 отражений этой дуги
    const double directLineSegmentLen = 5;
    
    //    будем рисовать отрезками примерно по maxDirectLineLen пикселей, но не менее, чем 16-тиугольник
    const double angleStep = drawDistance  / max( 1, int( 0.5 + r * drawDistance / directLineSegmentLen ) );
    const double angleTo = drawDistance - angleStep;
    double angle = angleStep / 2;
    int dxStart = int( 0.5 + r * sin( angle ) );
    int dyStart = int( 0.5 + r * cos( angle ) );

    //    отрезки, соединяющие начала осьмушек
    drawTwoPiecesOfCircle( xCenter, yCenter, -dxStart, dyStart, dxStart, dyStart );
    drawTwoPiecesOfCircle( xCenter, yCenter, -dxStart, -dyStart, dxStart, -dyStart );
    
    for( angle += angleStep; angle < angleTo; angle += angleStep )
    {
        int dxEnd = int( 0.5 + r * sin( angle ) );
        int dyEnd = int( 0.5 + r * cos( angle ) );
        drawEightPiecesOfCircle( xCenter, yCenter, dxStart, dyStart, dxEnd, dyEnd );
        dxStart = dxEnd;
        dyStart = dyEnd;
    }
    
    //    отрезки, соединяющие концы осьмушек
    drawFourPiecesOfCircle( xCenter, yCenter, dxStart, dyStart, dyStart, dxStart );
}

Хотя, наверное, если есть возможность писать на С++, то стоило бы оформить как класс

class CircleDrawer {
public:
    CircleDrawer( int xCenter, int yCenter );
    
    void Draw( int r ) const;

private:
    int xCenter;
    int yCenter;
    
    void drawTwoPiecesOfCircle( int dxStart, int dyStart, int dxEnd, int dyEnd ) const;
    void drawFourPiecesOfCircle( int dxStart, int dyStart, int dxEnd, int dyEnd ) const;
    void drawEightPiecesOfCircle( int dxStart, int dyStart, int dxEnd, int dyEnd ) const;
};

Но эта вечная проблема всяких дурацких вопросов на интерьвю -- совершенно не понятна предполагаемая подробность проработки требуемого решения...

Здравствуйте, Erop, Вы писали:

E>приведи, пожалуйста, пример запроса который гарантированно не делается на регэкспах...
Я где-то оспаривал эту теорию? Ну а так сходу, не думая, попробую. Изначально было в бинарнике, но попробую перевести в строки. Есть набор строк, типа
AABBBCCC
где
AA — номер транзакции
BBB — тип данных
ССС — данные

Строки идут вперемешку, т.е. они не сгруппированы по номерам транзакций. Нужно вернуть все данные по транзакции. Т.е. что бы regexp возвращал А1 B11 C11 B12 C12 B13 C13, ну и т.д. для каждого уникального AAA
Тестовые данные:
A1B11C11
A5B51C51
A1B12C12
A5B52C52
A1B13C13

Здравствуйте, Erop, Вы писали:

E>Да нет, с ним бодались, в принципе, он что-то там доказывал, что-то показывал, какие-то трудности изобретал, якобы объективные.

Не, я с вас фигею. Ну прям куча беспомощных начальников перед лицом коварного работника. Самому не смешно?

E>IMHO просто жалко было его выгонять, так как реально мужчина много знал и умел.

Я где то писал, что его надо выгнать?

E>Ну уволили его по его обоюдному желанию.

Это ничего не меняет. Если человек негодной квалификации — надо было выгнать после испытательного срока. Если годной — значит ваши менеджеры не смогли его эффективно задействовать.

Здравствуйте, Erop, Вы писали:

AVK>>В продемонстрированном тобой примере оказалось в итоге, что квалификация наоборот была недостаточна.
E>Да хрен его знает. Сам по себе он что-то хорошее умеет. Он от чего-то фатально ен вписался в коллектив. Ну типа ему казалось неправильным не использовать буст, дельфи, ещё что-то казалось неправильным.

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

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

Да ради бога. Но для разработки софта это необходимое условние, но не достаточное.

E>IMHO, ПТЦА для этого критична далеко не всегда. Мало того, я заню много примеров, когда знание этой теории не спасает

Я утверждал где то обратное, что таких примеров нет?

E>Ну самые основы, они довольно компактны и их легко изучить на самом деле.

Именно об этих основах здесь и речь. За углубленные познания лично я никогда не агитировал.

E> ВУЗы ежегодно выпускают толпы людей хорошо знающих весь расхваливаемый тобой мат. бэкграунд, но при этом совершенно никаких инженеров.

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

E>попробуй таки поговорить с хорошим инженером из какой-нибудь другой отрасли.

Попробуй таки не поучать собеседников. Еще неизвестно, кто из нас с большим количеством инженеров общался.

Здравствуйте, olegkr, Вы писали:

O>Аналогии они такие... ты с ними поосторожнее

Я то с ними как раз таки осторожно и не использую их в качестве доказательства.

O>, а то ведь и против тебя в споре повернуться могут

Испугал ежа голой попой.

Здравствуйте, Erop, Вы писали:

E>Ну статистика в рамках конторы за историю её существования, так скажем.
E>Немного, но что есть.

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

E>И я тебе так скажу, что все эти "первые шажки" -- это как раз каменный топор и есть, даже не топор, а палка-копалка.

Да! Но без них — нифига не получится.

Здравствуйте, Erop, Вы писали:

Pzz>>Если наложить ограничение на длинну строки, это точно совершенно описывается конечным автоматом. А значит, и регулярное выражение можно подобрать

E>Если наложить ограничение на длину, то будет просто конечный словарь вариантов. Правда при длинне скажем в 100 символов оо-о-о-о-о-о-о-о-о-о-о-о-о-о-о-о-о-о-о-о-о-очень большой. И регэксп такой же будет и автомат. Таки лучше стековым...

Я не это имел ввиду. Чтобы подсчитать плюсики-минусики, не надо больше состояний, чем может быть плюсиков или минусиков. А их не может быть больше, чем длина строки.

Здравствуйте, Erop, Вы писали:

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

E>IMHO внутренние тормоза должны быть очень надёжны и многоплановы. Если ты что-то не можешь описать регэкспом за час (этот таймаут с большим пребольшим запасом взят), то точно надо тормознуть и подумать почему не получается...

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Не, я с вас фигею. Ну прям куча беспомощных начальников перед лицом коварного работника. Самому не смешно?
Дык поинт в том, что чотрудник должен сотрудничать, а иначе он нам не нужен.

E>>IMHO просто жалко было его выгонять, так как реально мужчина много знал и умел.
AVK>Я где то писал, что его надо выгнать?

Зато я писал. Было много разных менеджеров, которые пробовали разные варианты воздействия. IMHO самый компетентный уволил

E>>Ну уволили его по его обоюдному желанию.
AVK>Это ничего не меняет. Если человек негодной квалификации — надо было выгнать после испытательного срока. Если годной — значит ваши менеджеры не смогли его эффективно задействовать.

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Ты путаешься в показаниях. Либо он в коллектив не вписался, тогда не вижу смысла обсуждать это в данном топике, либо таки у него серьезные проблемы с кодом, тогда в лес все эти невписывания, проблема в том числе и в квалификации.

Да ничего я не путаюсь. Просто ты чего-то не понимаешь. Как разработчик ПО он был реально крутой. Он кое-что сам делал и потом в другой конторе тоже делал, правда библиотеку навороченных шаблонов. Вполне успешно вроде. А у нас он хотел решать задачи не как у нас принято, а как он считал верным. А так получалось очень тормозно. Можно считать потому, что с нашим остальным кодом тяжко такому продвинутому стыковаться, а можно считать, что потому, что решение он своё переусложнял сильно...

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

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

E>>IMHO, ПТЦА для этого критична далеко не всегда. Мало того, я заню много примеров, когда знание этой теории не спасает
AVK>Я утверждал где то обратное, что таких примеров нет?
Не знаю. Я имел в виду не примеры задач, а примеры людей.
Короче мой опыт такой: ПТЦА или там булева алгебра или регэкспы или ещё что некритичны, а вот инженерные скилы критичны. Их развить в сотруднике намного сложнее.

E>>Ну самые основы, они довольно компактны и их легко изучить на самом деле.
AVK>Именно об этих основах здесь и речь. За углубленные познания лично я никогда не агитировал.
Ну так это вопрос небольшого ликбеза и отсылке к паре книжек. Всё равно программисто должен уметь учиться, это тоже критичный навык... Так что не о чем тут вообще думать. Ну не знает кто-то формальных грамматик, ну и фиг с ним. Пусть за исп. срок узнает. Не узнает, ну и значит учиться не умеет,а узнает -- значит и проблемы нет, если вдруг ему они нужны на самом деле будут...

E>> ВУЗы ежегодно выпускают толпы людей хорошо знающих весь расхваливаемый тобой мат. бэкграунд, но при этом совершенно никаких инженеров.
AVK>Опять эта странная логика. Если есть машины, у которых кондиционер работает фигово, это же не значит, что кондиционер в машине не нужен, не так ли?
Ну мне не нужен, на самом деле. Правда я вообще машины не любу.
Но логика другая. Если опыт учит нас, что кондиционер легко привинчивается в любую машину (что не так), то пофиг есть ли он при покупке. А вот то что машина не едет -- не пофиг...

E>>попробуй таки поговорить с хорошим инженером из какой-нибудь другой отрасли.
AVK>Попробуй таки не поучать собеседников. Еще неизвестно, кто из нас с большим количеством инженеров общался.
Тогда я не понимаю о чём спор?

Здравствуйте, Pzz, Вы писали:

Pzz>С тормозами, с другой стороны, важно не перестараться. Слишком хорошие тормоза превратят все, что угодно, в недвижимость

Ну да. Тормоза должны быть хорошо настроены, и не только в области регэкспов, а в области вообще всего.

Здравствуйте, AndrewVK, Вы писали:

AVK>У меня есть небольшое хобби, мне интересно изучать, как устроен процесс разработки в разных конторах. Так вот, ваша в этом плане весьма и весьма специфична. Да и продукты у вас тоже весьма специфические.
Ну, дык. Но у нас же много кода пишется. Много и обычного довольно. Стандартного, заурядного...

AVK>Да! Но без них — нифига не получится.
Ну там очень много без чего не получится, IMHO.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Я не это имел ввиду. Чтобы подсчитать плюсики-минусики, не надо больше состояний, чем может быть плюсиков или минусиков. А их не может быть больше, чем длина строки.

Ну ладно, хоя ограничивать строку -- чтерство, пусть будет баланс скобок разных типов

Здравствуйте, olegkr, Вы писали:

Pzz>>Ну например, понимать e-mail адреса клиентов во всем том разнообразии синтаксических оттенков, которое допускает RFC822.
O>Легко!
O>http://www.rsdn.ru/Forum/?mid=2729536

Автор: olegkr
Дата: 14.11.07

А доказать что этот регексп полностью соответствует RFC тоже легко? А написать его было тоже легко? Он получился простой для понимания?