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

I>Что значит удобно, кому удобно, тебе мне или тому, кто кроме циклов и ветвлений ничего в глаза не видел ?

Я к тому, что должен быть предусмотреть способ в одну строчку превратить обычную коллекцию в push-коллекцию и отправить её в парсер. Если такое есть (я надеюсь Rx не идиоты писали?), то всё отлично и можно спокойно один и тот же код использовать разными способами.

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

О да, по тому примеру для парсинга всего лишь числа с плавающей точкой оно и видно. )))

I>Нет, не так. В твоей модельке и скорость и ускорение меняются в зависимости от частоты опросов. Вот изменился уровень сигнала за одну минуту с 0 до 60, скорость изменения — 1 ед/c
I>С твоей "формулой" ты получишь 60 значений и например вполне возможно, последнее будет отрицательным. Опаньки — скорость отрицательная, а сигнал растёт.

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

I>Моя модель гарантирует отображение скорости, а твоя при росте уровня сигнала может показывать отрицательную скорость.

Мдаааа. )))

I>Ты снова частный случай выдал Что мне делать, если теги будут b ? А если в них будет какой то контент, который тоже надо скипнуть ?

Тоже без проблем делается.

I>Итого — ты в очередной раз попытался натянуть регулярную грамматику на контекстно свободный язык.

Ну так она в реальности частенько и натягивается. Естественно не всегда (я сам могу кучу антипримеров привести), но ты вот что-то натыкаешься именно на такие. )))

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

I>Конечно же нет, я ведь погулять вышел.

Ты что-то путаешь. ))) У меня к тебе никогда никаких претензий не было, ну разве что кроме повышенной упёртости. А вот к C#...

Как я понимаю ты согласился, что у C++ гораздо больше возможностей для реализации функциональных фишек в стиле Хаскеля, чем у C#? )


_>>Ну давай набор тестовых данных (входные строки и ожидаемый текст на выходе) — посмотрим. )))
I>То есть, ты решил забрать свои слова на счет того, что не знаешь что такое optional, second и тд ?

Нет, я же говорю, давай входные данные и выходные (вот по ним и пойму ТЗ полностью). Кстати, ты этого так и не дал пока.

I>Мне чисто любопытно, прежде чем перейдем к тестовым данным, ты и вправду считаешь, что готов хотя бы это покрыть регулярными выражениями ?

Так не одним же сразу всё, а императивный код использующий регвыры просто для поиска/замены — с помощью этого вообще любая задачка решается. )))

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

I>Частота зависит от программиста. Скажем если работа с асинхронщиной, то совершенно не ясно, почему это должно возникать редко Наоборот, очень часто — есть коллекция А, есть коллекция Б, их надо смержить. Но вот фокус, они приходят в промисах.
I>и получается вот такое
I>var result = merge(getA(),getB());

I>парадокс — по этому коду нельзя сказать, какой он, синхронный или асинхронный, если не смотреть использование или не глянуть внутрь. Есть один большой минус — брейкпоинты некуда статить.

I>P.S. Я уже знаю, что это называется "лифтинг".

Кстати говоря лифтинг — это как бы совсем функциональный стиль. Т.е. мы преобразуем функцию в функцию (например складывающую числа в складывающую числа в списках). Но есть и промежуточный вариант — использовать что-то типа fmap (а для коллекций будет просто map). Т.е. можно спокойно использовать обычные функции на списках (или на промисах) и при этом обходиться без монад. Просто код будет выглядеть как apply(A, B, merge).

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

I>Не получается. Я наколбасил две небольшие библиотечки, вроде тех что в примерах кода видны, но шота пока не вижу ни одного примера, где бы это было более-менее удобоваримо.

I>На самом деле у тебя возражение про Rx совершенно справедливое, только ты проблему не там ищешь. Посмотри внимательно на Rx или Rxx и тебе станет понятно, что не может быть нормальных монад в обычном ООП языке, если они не встроены сразу в язык.

Так это на каком языке то? ) На C# наверное? ) Ну так а он же далеко не сильнейший среди нормальных ООП языков. Лучше бы C++ или ocaml глянул бы. Кстати у них прямо противоположные подходы для реализации подобного, но оба хотя бы могут.

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

_>А насчёт нетипизированности... Обычно под этим подразумевают, что компилятор может пропустить ошибку и она всплывёт только где-нибудь во время исполнения. В данном случае, если в качестве M передать тип не имеющий определённого оператора >>=, то компилятор выдаст соответствующую ошибку — какую ещё типизацию то можно требовать?

Такую, чтоб ошибки возникали не при "передавании типа", а при написании обобщенного кода. Обобщенный код на плюсах практически нетипизированный, хотя нетипизированность в данном случае обычно называют "permissiveness", но сути это не меняет.
Об этом я и писал: "На самом деле понятно, как это предполагается использовать обобщенно, но проблема тут будет в том, что это обобщение не типизировано. Родственная проблема — семантическая неопределенность. Про (=<<) можно много чего сказать не зная ничего о конкретной имплементации, про ваш перегруженный сдвиг ничего сказать нельзя."

_>Да, цепочки вида m a->m b->m c возникают весьма редко.

У меня противоположный опыт на этот счет.

_>Мы же вроде как это уже обсудили один раз.

Даже больше одного. Я несколько раз объяснял, что контроль за эффектами и монады это темы слабосвязанные. Никакой необходимости использовать монады для такого контроля в чистом языке нет. Вы либо не понимаете, либо просто игнорируете мои объяснения и как ни в чем не бывало снова это повторяете. Скорее всего игнорируете, потому, что если бы не понимали — вы бы какие-то вопросы по этой теме задали.

_>Это особенности реализации IO/ST в Хаскеле.

Нет, IO и ST реализуются с помощью инкапсуляции (неэкспорта конструктора) и Rank-2 полиморфизма во втором случае. Монады особенностями реализации не являются. Монады используются для создания разделяемой кодовой базы для обобщенной работы с эффектами, функциями, списками, итераторами, генераторами значений для тестов, парсерами, сериализаторами/десериализаторами и еще зиллионом разных вещей. Будут среди них IO и ST или не буду — ничего принципиально не поменяет.

_>Правда вы указали, что эти особенности привносят некие плюсы по сравнению с другими языками.

Это совершенно отдельный разговор не про полезность монад, а про полезность контроля эффектов.

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

У меня перед глазами красноречивый пример — ваш диалог с Ikemefula, который вам приводит примеры без всякого толку. Так что я не буду торопиться с примерами, а сначала провентилирую вопрос с "ужасами подобного кода". Т.е. раньше чем вы покажете тут эти ужасы и мы их предметно обсудим, разговор дальше не пойдет и никаких примеров не будет.

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

_>Вообще то я ещё в самом первом сообщение на данную тему (про wxHaskell) точно указал что и где надо сравнивать. Если вы так до сих пор этого не увидели, то мне если честно надоело повторяться.

Это, разумеется, неправда. "Я видел некие примеры к wxWidgets которые на C++ выглядят лучше, чем на Haskell" точным указанием не являются. Вам, чтоб подкрепить свои слова нужно дать ссылки по которым можно пройти сразу, а сюда скопипастить обозримые примеры, которые можно было предметно обсудить. Никто за вас это не сделает, искать подтверждения и иллюстрации для ваших тезисов я не собираюсь. Конкретный хаскель-код вы предметно обсуждать отказались, а кода на плюсах, который бы мне понравился я никогда не видел, так что ничем вам тут помочь не могу.

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

_>Соответственно дальше действия простые — другая сторона получив p1, m, s и имея у себя r путём простейшей проверки может гарантированно убедиться, что p1 честно соответствует m (а это обычно что-то вроде текста "ООО Рога и Копыта").

А есть способы убедиться, что "ООО" это именно то что нам нужно? Например, я скачиваю программу, а она подписана "Microsoft Corporation". Как понять, что это именно M$? Ведь написать можно и "Microsoft Inc", да и просто "Microsoft"...


P.S. Большое спасибо за объяснения, очень доходчиво. Книжку выпустить не планируете?

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

_>Так это на каком языке то? ) На C# наверное? ) Ну так а он же далеко не сильнейший среди нормальных ООП языков. Лучше бы C++ или ocaml глянул бы. Кстати у них прямо противоположные подходы для реализации подобного, но оба хотя бы могут.

Я бы сказал, что из ООП С++ наихудший. В ём тащут возможности, которые к ООП не имеют никакого отношения — шаблоны, макросы и указатели.
Окамл прежде всего это функциональный язык, а уже потом ОО.

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

I>>P.S. Я уже знаю, что это называется "лифтинг".

_>Кстати говоря лифтинг — это как бы совсем функциональный стиль. Т.е. мы преобразуем функцию в функцию (например складывающую числа в складывающую числа в списках). Но есть и промежуточный вариант — использовать что-то типа fmap (а для коллекций будет просто map). Т.е. можно спокойно использовать обычные функции на списках (или на промисах) и при этом обходиться без монад. Просто код будет выглядеть как apply(A, B, merge).

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

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

_>Ты что-то путаешь. ))) У меня к тебе никогда никаких претензий не было, ну разве что кроме повышенной упёртости. А вот к C#...

Будет тоже самое, только вместо >>= будет функция

_>Как я понимаю ты согласился, что у C++ гораздо больше возможностей для реализации функциональных фишек в стиле Хаскеля, чем у C#? )

На бумажке больше, а на практике без внятного GC для лямбд толку никакого, чемодан без ручки.

_>>>Ну давай набор тестовых данных (входные строки и ожидаемый текст на выходе) — посмотрим. )))
I>>То есть, ты решил забрать свои слова на счет того, что не знаешь что такое optional, second и тд ?

_>Нет, я же говорю, давай входные данные и выходные (вот по ним и пойму ТЗ полностью). Кстати, ты этого так и не дал пока.

Ога, ты читать пробовал то самое сообщение, где пример кода был ?

I>>Мне чисто любопытно, прежде чем перейдем к тестовым данным, ты и вправду считаешь, что готов хотя бы это покрыть регулярными выражениями ?

_>Так не одним же сразу всё, а императивный код использующий регвыры просто для поиска/замены — с помощью этого вообще любая задачка решается. )))

просто поиск мне не нужен, мне нужно обработать язык, который в принципе не может быть описан регулярной грамматикой

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

I>>Что значит удобно, кому удобно, тебе мне или тому, кто кроме циклов и ветвлений ничего в глаза не видел ?

_>Я к тому, что должен быть предусмотреть способ в одну строчку превратить обычную коллекцию в push-коллекцию и отправить её в парсер. Если такое есть (я надеюсь Rx не идиоты писали?), то всё отлично и можно спокойно один и тот же код использовать разными способами.

Есть конечно.

_>О да, по тому примеру для парсинга всего лишь числа с плавающей точкой оно и видно. )))

Тот пример он как раз плохой, потому что в джаваскрипте никакой поддержки монад нет.
Но он гораздо лучше, чем в C#, потому что за счет динамики можно уменьшить количество текстового мусора.
В Хаскеле и других ФЯ можно сделать намного лучше и чище, практически БНФ

I>>С твоей "формулой" ты получишь 60 значений и например вполне возможно, последнее будет отрицательным. Опаньки — скорость отрицательная, а сигнал растёт.

_>Ты похоже путаешь понятие "скорости" (мгновенной, в точке) и "средней скорости по заданному интервалу". ) Это вообще то по физике ещё наверное в классе 7-ом проходят. )))

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

I>>Моя модель гарантирует отображение скорости, а твоя при росте уровня сигнала может показывать отрицательную скорость.

_>Мдаааа. )))

Именно так.

I>>Ты снова частный случай выдал Что мне делать, если теги будут b ? А если в них будет какой то контент, который тоже надо скипнуть ?

_>Тоже без проблем делается.

Ну да, переписывая код, и в какой то момент тебе понадобится автомат с магазином

I>>Итого — ты в очередной раз попытался натянуть регулярную грамматику на контекстно свободный язык.

_>Ну так она в реальности частенько и натягивается. Естественно не всегда (я сам могу кучу антипримеров привести), но ты вот что-то натыкаешься именно на такие. )))

Ты просто хочешь свести всё подряд к регэкспам и простым автоматам.

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

_>Я к тому, что запись грамматики через linq — это не твоё изобретение, а как раз авторов библиотеки. Т.е. это не твой неудачный пример, а подразумеваемая стандартная практика.

В который раз объясняю — в C# нет паттерн-матчинга. Потому 100% библиотек берут на себя эти обязнности, в сложных случаях громоздко, неэфективно и некачественно.

Ровно то же в С++ — там нет паттерн матчинга, потому 100% библиотек содержан вагоны строчек кода, которые собтсвенно этот ПМ и делают, в сложных случаях громоздко, неэфективно и некачественно.

I>>Снова феерическая чушь — я показал пример _реактивного_ парсинга ! буст.спирит такой парсинг не умеет, как все твои yacc и lexx.

_>Так речь шла о задание грамматики, а не об этом.

Речь шла про реактивный парсинг.

>Можно же без проблем написать парсер работающий реактивно и при этом с заданием грамматики в стиле boost.sprit. Вот для этой задачи такое и было бы оптимальным.

За десять минут уложишься ?

I>>В принципе хрен с ним, со спиритом, сделай хотя бы императивно, но что бы это был честный реактивный код, условимся, для простоты, что в эвентах инфа приходит по одному символу. Скажем я могу запускать такие парсеры хоть асинхронно в одном потоке, хоть в разных, могу менять, добавлять комбинаторы как угодно. А у тебя чуть что, так надо подкладывать костыли, например из за многопоточности, паралеллизма и тд и тд и тд.

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

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

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

K>Такую, чтоб ошибки возникали не при "передавании типа", а при написании обобщенного кода. Обобщенный код на плюсах практически нетипизированный, хотя нетипизированность в данном случае обычно называют "permissiveness", но сути это не меняет.
K>Об этом я и писал: "На самом деле понятно, как это предполагается использовать обобщенно, но проблема тут будет в том, что это обобщение не типизировано. Родственная проблема — семантическая неопределенность. Про (=<<) можно много чего сказать не зная ничего о конкретной имплементации, про ваш перегруженный сдвиг ничего сказать нельзя."

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

K>Даже больше одного. Я несколько раз объяснял, что контроль за эффектами и монады это темы слабосвязанные. Никакой необходимости использовать монады для такого контроля в чистом языке нет. Вы либо не понимаете, либо просто игнорируете мои объяснения и как ни в чем не бывало снова это повторяете. Скорее всего игнорируете, потому, что если бы не понимали — вы бы какие-то вопросы по этой теме задали.

Вообще то я это давно понял, согласился и т.п. И продолжаю разговор уже именно про эти самые эффекты.

K>Нет, IO и ST реализуются с помощью инкапсуляции (неэкспорта конструктора) и Rank-2 полиморфизма во втором случае. Монады особенностями реализации не являются. Монады используются для создания разделяемой кодовой базы для обобщенной работы с эффектами, функциями, списками, итераторами, генераторами значений для тестов, парсерами, сериализаторами/десериализаторами и еще зиллионом разных вещей. Будут среди них IO и ST или не буду — ничего принципиально не поменяет.

Я это уже давным давно понял. ))) Да, но только не надо совсем отделять монады от этого дела. Во-первых они всё же используются чтобы частично скрыть некие "ужасы" реализации IO/ST Хаскеля. И во-вторых, с учётом важности этого вопроса для любого нормального приложения, на практике получается что в Хаскеле монады мы видим чаще всего именно в этой области.

K>Это совершенно отдельный разговор не про полезность монад, а про полезность контроля эффектов.

Совершенно верно. И как раз про это я спрашиваю уже очень давно и так ни разу и не получил ответа. Естественно про какие-то случаи из реальной практики, а не обобщённую теорию..

Ну а про монады мне вообще то уже давно всё понятно, как в Хаскеле, так и в других языках...

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

K>Это, разумеется, неправда. "Я видел некие примеры к wxWidgets которые на C++ выглядят лучше, чем на Haskell" точным указанием не являются. Вам, чтоб подкрепить свои слова нужно дать ссылки по которым можно пройти сразу, а сюда скопипастить обозримые примеры, которые можно было предметно обсудить. Никто за вас это не сделает, искать подтверждения и иллюстрации для ваших тезисов я не собираюсь. Конкретный хаскель-код вы предметно обсуждать отказались, а кода на плюсах, который бы мне понравился я никогда не видел, так что ничем вам тут помочь не могу.

Я вообще то говорил не про некие отвлечённые, а про вполне конкретные примеры из поставки wxWidgets. Т.е. идём в папку wxWidgets (она у меня уже много лет на компьютере), видим там папку samples и в ней ещё 86 папок с примерами на все случаи. Аналогично с wxHaskell, только там насколько я помню примеров намного меньше. Находим одинаковые и сравниваем код. Я это сделал когда-то, когда смотрел на Haskell вообще и получил вполне однозначные выводы. Сейчас прямо за секунду (а иначе лень) легко повторить это не могу, т.к. уже давно стёр и wxHaskell и сам Haskell у себя с компьютера, как не нужное. Но если кто-то хочет проверить мои слова, то алгоритм очень простой. Причём я указал на эти самые примеры в первом же своём сообщение на эту тему.

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

B>А есть способы убедиться, что "ООО" это именно то что нам нужно? Например, я скачиваю программу, а она подписана "Microsoft Corporation". Как понять, что это именно M$? Ведь написать можно и "Microsoft Inc", да и просто "Microsoft"...

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

B>P.S. Большое спасибо за объяснения, очень доходчиво. Книжку выпустить не планируете?

Спасибо отзыв. ) про книжку даже никогда не приходило такое в голову. Я как бы 100% практик и в программирование и в бизнесе, а форум просто для развлечения и разминки ума. ) Хотя образование у меня наоборот максимально академическое — может это и накладывает отпечаток. )))

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

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

Да я не об этом. Вот смотри, допустим есть такая функция:

template<typename T> auto ComplexFunc(T t)->decltype(apply(h, apply(g, apply(f, t)))){ return apply(h, apply(g, apply(f, t))); }

Так вот она всегда вернёт значение y=h(g(f(x))), кем бы у нас не был x. Это могут быть "голые" значения, могут быть какие-то функторы/монады, а могут вообще какие-нибудь stl коллекции. Причём функции f, g, h не перегруженные, а есть только в одном экземпляре, работающем с "голыми" значениями. И естественно имеем тут ноль накладных расходов, в отличие от решения "а сделаем ка всё монадой на будущее, на всякий случай".

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

I>Будет тоже самое, только вместо >>= будет функция

Ну функция вместо оператора это не принципиально... Так покажешь компилируемую реализацию liftM2 на C#? )

I>Ога, ты читать пробовал то самое сообщение, где пример кода был ?

Пример кода (если ты про C#) мне как бы ни к чему, т.к. нет никакого желания лазить по документации Rxx и понимать его смысл. Мне нужен тестовый набор входных и выходных данных и всё. Что бы после реализации никто уже точно не придрался к коду (выдаёт нужное — значит правильный).

I>просто поиск мне не нужен, мне нужно обработать язык, который в принципе не может быть описан регулярной грамматикой

Эммм, так никто и не собирается искать решение в виде "одного мега регулярного выражения". Решение задачи даёт императивный код (который, как ты понимаешь, может в принципе всё, вопрос только какой ценой в смысле размера кода). Просто его размер резко сокращается, если использовать в нём регулярные выражения.

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

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

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

_>Да я не об этом. Вот смотри, допустим есть такая функция:
_>

_>template<typename T> auto ComplexFunc(T t)->decltype(apply(h, apply(g, apply(f, t)))){ return apply(h, apply(g, apply(f, t))); }
_>

_>Так вот она всегда вернёт значение y=h(g(f(x))), кем бы у нас не был x. Это могут быть "голые" значения, могут быть какие-то функторы/монады, а могут вообще какие-нибудь stl коллекции. Причём функции f, g, h не перегруженные, а есть только в одном экземпляре, работающем с "голыми" значениями. И естественно имеем тут ноль накладных расходов, в отличие от решения "а сделаем ка всё монадой на будущее, на всякий случай".

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

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

I>Тот пример он как раз плохой, потому что в джаваскрипте никакой поддержки монад нет.
I>Но он гораздо лучше, чем в C#, потому что за счет динамики можно уменьшить количество текстового мусора.
I>В Хаскеле и других ФЯ можно сделать намного лучше и чище, практически БНФ

А можно сделать практически БНФ без всяких монад и в не функциональных языках.

I>Меня интересует практическая ценность. Попробуй вывести на экран свою скорость и расскажи, как ты сможешь это использовать.

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

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

Касательно конкретно твоей задачки. Определись просто что тебе надо выводить на экран. Скорость или же усреднённую на каком-то интервале скорость. И кстати во втором случае в нормальном софте обычно позволяют регулировать размер интервала и при этом в зависимости от этого параметра значение средней скорости вполне может и знак поменять даже...

А вообще это всё не имеет никакого отношения к данной темке. Но это ты зачем-то увёл разговор сюда. Хотя я не против — мне тема численных вычислений вполне близка. )))

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

I>В который раз объясняю — в C# нет паттерн-матчинга. Потому 100% библиотек берут на себя эти обязнности, в сложных случаях громоздко, неэфективно и некачественно.

В C# есть по крайне мере перегрузка операторов и простенький вариант обобщённых типов. Этого уже достаточно, чтобы сделать приличное задание подобных шаблонов в коде. Но народ похоже просто увлечён той кривой хренью, которая например лично мне даже и для коллекций не нравится. Иного объяснения не нахожу.

I>За десять минут уложишься ?

Не, переписать Spirit под реактивный стиль — это не слабая задачка... ))) Но если сделать такое (в принципе ни единой проблемы там нет, просто существенный объём работы), то думаю что это будет самое идеально решение подобных задач.