Сообщение Re[13]: вопрос hi_octane про c# от 30.08.2020 4:28
Изменено 30.08.2020 4:35 Sinclair
Re[13]: вопрос hi_octane про c#
Здравствуйте, alex_public, Вы писали:
_>Ну так а тогда у тебя именно так и было: была написана не плохая числодробильная функция, зачем-то "прилепленная" к linq. С тех пор что-то принципиально изменилось? Я тебе тогда ещё сказал, что подобный аргумент абсолютно равносилен написанию функции для решения диффуров, вызовом её по нажатию кнопки на WPF форме, и заявлению после этого, что WPF очень удобный инструмент для решения диффуров.
Нет, так не работает.
S>>Как впоследствии оказалось, даже это не совсем так. К примеру, бинаризацию по Sauvola переписать на "обычные методы" будет крайне громоздко — конструкция let сильно сокращает "процедурный" код.
S>>А без неё сделать нельзя — expression trees не позволяют заводить временные переменные и делать присваивания. Это ограничение было бы дефектом, если бы оно не упрощало компилятор и не гарантировало отсутствие побочных эффектов, в отличие от настоящих присваиваний.
_>Эммм, мне кажется или ты это сейчас пытаешься недостаток linq выдать за такое себе своеобразное преимущество linq?
Этот "недостаток" быстро перестаёт казаться недостатком, как только сам садишься писать компилятор для деревьев выражений.
_>Уууу какая отборная демагогия и наглые передёргивания. Сравнивать для разных "сторон" разный уровень гарантий и разный уровень требований по производительности. Причём сравнивать естественно по "обратному" реализации критерию. Не уж, тут такое не пройдёт. Ты давай определись, какой конкретно случай мы рассматриваем (естественно любой приличный инструмент должен отлично отрабатывать оба случая, т.к. они оба встречаются в работе). Или мы говорим про случай с непринципиальной производительностью, но важной параноидальной защитой инвариантов или же у нас случай с принципиальным быстродействием. Для каждого из них код пишется по разному.
Это у вас в C++ надо выбирать между производительностью и инвариантами. Лично я хочу больше.
_>Вот напиши классическую реализацию и на linq (ха ха) для каждого из них и потом сравни. А то сравнил ориентированную на производительность классическую версию с ориентированной на сохранение инвариантов любой ценой версию linq, причём сравнил по критерию сохранения инвариантов. Ты считаешь тут всех на форуме дебилами, что никто не заметит такого очевидного передёргивания?
Вот есть i4o — там опять всё быстро и гарантированно корректно. Не нужно выбирать между производительностью и безопасностью.
Для 2d массивов я написал Linq-версию. Она одновременно быстрая и безопасная. Т.е. попытка выхода за границы массива приводит к OutOfBoundsException, но при этом сами проверки устраняются в рантайм. Ничего близкого "классический" случай предложить не может.
Ну, и кто тут передёргивает?
_>Ну так а тогда у тебя именно так и было: была написана не плохая числодробильная функция, зачем-то "прилепленная" к linq. С тех пор что-то принципиально изменилось? Я тебе тогда ещё сказал, что подобный аргумент абсолютно равносилен написанию функции для решения диффуров, вызовом её по нажатию кнопки на WPF форме, и заявлению после этого, что WPF очень удобный инструмент для решения диффуров.
Нет, так не работает.
S>>Как впоследствии оказалось, даже это не совсем так. К примеру, бинаризацию по Sauvola переписать на "обычные методы" будет крайне громоздко — конструкция let сильно сокращает "процедурный" код.
S>>А без неё сделать нельзя — expression trees не позволяют заводить временные переменные и делать присваивания. Это ограничение было бы дефектом, если бы оно не упрощало компилятор и не гарантировало отсутствие побочных эффектов, в отличие от настоящих присваиваний.
_>Эммм, мне кажется или ты это сейчас пытаешься недостаток linq выдать за такое себе своеобразное преимущество linq?
Этот "недостаток" быстро перестаёт казаться недостатком, как только сам садишься писать компилятор для деревьев выражений.
_>Уууу какая отборная демагогия и наглые передёргивания. Сравнивать для разных "сторон" разный уровень гарантий и разный уровень требований по производительности. Причём сравнивать естественно по "обратному" реализации критерию. Не уж, тут такое не пройдёт. Ты давай определись, какой конкретно случай мы рассматриваем (естественно любой приличный инструмент должен отлично отрабатывать оба случая, т.к. они оба встречаются в работе). Или мы говорим про случай с непринципиальной производительностью, но важной параноидальной защитой инвариантов или же у нас случай с принципиальным быстродействием. Для каждого из них код пишется по разному.
Это у вас в C++ надо выбирать между производительностью и инвариантами. Лично я хочу больше.
_>Вот напиши классическую реализацию и на linq (ха ха) для каждого из них и потом сравни. А то сравнил ориентированную на производительность классическую версию с ориентированной на сохранение инвариантов любой ценой версию linq, причём сравнил по критерию сохранения инвариантов. Ты считаешь тут всех на форуме дебилами, что никто не заметит такого очевидного передёргивания?
Вот есть i4o — там опять всё быстро и гарантированно корректно. Не нужно выбирать между производительностью и безопасностью.
Для 2d массивов я написал Linq-версию. Она одновременно быстрая и безопасная. Т.е. попытка выхода за границы массива приводит к OutOfBoundsException, но при этом сами проверки устраняются в рантайм. Ничего близкого "классический" случай предложить не может.
Ну, и кто тут передёргивает?
Re[13]: вопрос hi_octane про c#
Здравствуйте, alex_public, Вы писали:
_>Ну так а тогда у тебя именно так и было: была написана не плохая числодробильная функция, зачем-то "прилепленная" к linq. С тех пор что-то принципиально изменилось? Я тебе тогда ещё сказал, что подобный аргумент абсолютно равносилен написанию функции для решения диффуров, вызовом её по нажатию кнопки на WPF форме, и заявлению после этого, что WPF очень удобный инструмент для решения диффуров.
Нет, так не работает. Вы можете попробовать переписать решение для sauvola (ссылку тут уже дважды привели) на цепочку методов и убедиться, что ничего не получится.
Точнее, получится — но код будет громоздким и плохочитаемым. А весь смысл — как раз в том, чтобы дать пользователю писать короткий и понятный код, не теряя ни в безопасности, ни в производительности.
Я, пока отлаживал linq2d, нашёл у себя штук пять ошибок в изначальном процедурном коде sauvola. Причём эти ошибки без linq я мог бы вовсе и не заметить — картинку-то код давал похожую на нужную. Где-то плюс с минусом перепутаны, где-то x с y. Слишком много boilerplate.
В простых случаях типа a[i,j]+b[i,j] разница невелика, но как только начинается более-менее интересная математика — типа того же Саволы, — так сразу видно, какой вариант лучше.
S>>Как впоследствии оказалось, даже это не совсем так. К примеру, бинаризацию по Sauvola переписать на "обычные методы" будет крайне громоздко — конструкция let сильно сокращает "процедурный" код.
S>>А без неё сделать нельзя — expression trees не позволяют заводить временные переменные и делать присваивания. Это ограничение было бы дефектом, если бы оно не упрощало компилятор и не гарантировало отсутствие побочных эффектов, в отличие от настоящих присваиваний.
_>Эммм, мне кажется или ты это сейчас пытаешься недостаток linq выдать за такое себе своеобразное преимущество linq?
Этот "недостаток" быстро перестаёт казаться недостатком, как только сам садишься писать компилятор для деревьев выражений.
_>Уууу какая отборная демагогия и наглые передёргивания. Сравнивать для разных "сторон" разный уровень гарантий и разный уровень требований по производительности. Причём сравнивать естественно по "обратному" реализации критерию. Не уж, тут такое не пройдёт. Ты давай определись, какой конкретно случай мы рассматриваем (естественно любой приличный инструмент должен отлично отрабатывать оба случая, т.к. они оба встречаются в работе). Или мы говорим про случай с непринципиальной производительностью, но важной параноидальной защитой инвариантов или же у нас случай с принципиальным быстродействием. Для каждого из них код пишется по разному.
Это у вас в C++ надо выбирать между производительностью и инвариантами. Лично я хочу больше.
_>Вот напиши классическую реализацию и на linq (ха ха) для каждого из них и потом сравни. А то сравнил ориентированную на производительность классическую версию с ориентированной на сохранение инвариантов любой ценой версию linq, причём сравнил по критерию сохранения инвариантов. Ты считаешь тут всех на форуме дебилами, что никто не заметит такого очевидного передёргивания?
Вот есть i4o — там опять всё быстро и гарантированно корректно. Не нужно выбирать между производительностью и безопасностью.
Для 2d массивов я написал Linq-версию. Она одновременно быстрая и безопасная. Т.е. попытка выхода за границы массива приводит к OutOfBoundsException, но при этом сами проверки устраняются в рантайм. Ничего близкого "классический" случай предложить не может.
Ну, и кто тут передёргивает?
_>Ну так а тогда у тебя именно так и было: была написана не плохая числодробильная функция, зачем-то "прилепленная" к linq. С тех пор что-то принципиально изменилось? Я тебе тогда ещё сказал, что подобный аргумент абсолютно равносилен написанию функции для решения диффуров, вызовом её по нажатию кнопки на WPF форме, и заявлению после этого, что WPF очень удобный инструмент для решения диффуров.
Нет, так не работает. Вы можете попробовать переписать решение для sauvola (ссылку тут уже дважды привели) на цепочку методов и убедиться, что ничего не получится.
Точнее, получится — но код будет громоздким и плохочитаемым. А весь смысл — как раз в том, чтобы дать пользователю писать короткий и понятный код, не теряя ни в безопасности, ни в производительности.
Я, пока отлаживал linq2d, нашёл у себя штук пять ошибок в изначальном процедурном коде sauvola. Причём эти ошибки без linq я мог бы вовсе и не заметить — картинку-то код давал похожую на нужную. Где-то плюс с минусом перепутаны, где-то x с y. Слишком много boilerplate.
В простых случаях типа a[i,j]+b[i,j] разница невелика, но как только начинается более-менее интересная математика — типа того же Саволы, — так сразу видно, какой вариант лучше.
S>>Как впоследствии оказалось, даже это не совсем так. К примеру, бинаризацию по Sauvola переписать на "обычные методы" будет крайне громоздко — конструкция let сильно сокращает "процедурный" код.
S>>А без неё сделать нельзя — expression trees не позволяют заводить временные переменные и делать присваивания. Это ограничение было бы дефектом, если бы оно не упрощало компилятор и не гарантировало отсутствие побочных эффектов, в отличие от настоящих присваиваний.
_>Эммм, мне кажется или ты это сейчас пытаешься недостаток linq выдать за такое себе своеобразное преимущество linq?
Этот "недостаток" быстро перестаёт казаться недостатком, как только сам садишься писать компилятор для деревьев выражений.
_>Уууу какая отборная демагогия и наглые передёргивания. Сравнивать для разных "сторон" разный уровень гарантий и разный уровень требований по производительности. Причём сравнивать естественно по "обратному" реализации критерию. Не уж, тут такое не пройдёт. Ты давай определись, какой конкретно случай мы рассматриваем (естественно любой приличный инструмент должен отлично отрабатывать оба случая, т.к. они оба встречаются в работе). Или мы говорим про случай с непринципиальной производительностью, но важной параноидальной защитой инвариантов или же у нас случай с принципиальным быстродействием. Для каждого из них код пишется по разному.
Это у вас в C++ надо выбирать между производительностью и инвариантами. Лично я хочу больше.
_>Вот напиши классическую реализацию и на linq (ха ха) для каждого из них и потом сравни. А то сравнил ориентированную на производительность классическую версию с ориентированной на сохранение инвариантов любой ценой версию linq, причём сравнил по критерию сохранения инвариантов. Ты считаешь тут всех на форуме дебилами, что никто не заметит такого очевидного передёргивания?
Вот есть i4o — там опять всё быстро и гарантированно корректно. Не нужно выбирать между производительностью и безопасностью.
Для 2d массивов я написал Linq-версию. Она одновременно быстрая и безопасная. Т.е. попытка выхода за границы массива приводит к OutOfBoundsException, но при этом сами проверки устраняются в рантайм. Ничего близкого "классический" случай предложить не может.
Ну, и кто тут передёргивает?