Нужна или не нужна программистам математика, по-моему, напрямую зависит от задач, которые решаются. Некоторые из приведенных в статье разделов математики, по-моему, больше нужны тем, кто занимается разработкой каких-нибудь трансляторов, компиляторов и что-то близкое к этому. Алгоритмы они в каждой области абсолютно разные, у каждого свои. Может это к огромному сожалению, а может к большому счастью, но на современном этапе уже нет большой необходимости разбираться в алгоритмах. Если и кому-то и нужен какой-то алгоритм, он просто подключает соответствующую библиотеку и не разбирается, что в ней делается и как она работает. Да, и подавляющая масса задач вообще не требует каких-то серьезных знаний.
На современном этапе бухгалтера уже мало используют калькуляторы. Если какая-нибудь процедура очень часто используется и достаточно распространена, то роль чаще всего роль бухгалтера или какого-нибудь другого оператора сводится к простому и правильному вводу определенных данных. Все остальное делает программа. Если процедура не очень распространена, то ее также пытаются автоматизировать. Основная масса бухгалтеров, на нормальных предприятиях, уже давно превратилась в операторов, которые просто правильно вводят данные. А вот организовать, создать, наладить весь этот процесс ввода данных и дальнейшей обработки вот для этого нужны соответствующие люди, умеющие не только программировать, но и знающие все тонкости того, что пытаешься запрограммировать.
Рыночная экономика и конкуренция - это лебедь, рак и щука. Лебедь рвется в облака, рак пятится назад, а щука тянет в воду. Кто виноват из них, кто прав - судить не нам, но только воз и ныне там. Но только воз и ныне там, как результат всего действия. А вот, если лебедя, рака и щука заставить тянут в одну сторону, то и воз, глядишь, сдвинется. Но это и есть административный ресурс. Другой, и самый главный и основной, вопрос - куда и на что направлен административный ресурс.
В этот же перечень можно добавить COBOL, Fortran, которым далеко за 60, и которые до сих пор являются основополагающими во многих областях. COBOL никак не могут заменить в банковской сфере, а на FORTRAN-е написано огромное количество научных программ, переписать которые тоже проблематично. И вот эти пенсионеры не используют ни классы, ни паттерны, ни SOLID и никакие другие аналогичные вещи. И разобраться в коде COBOL-а, Fortran-а ой как проблематично. То, что выдается за хороший код и называется хорошим, это больше вопрос привычки. Если человек привык работать с определенными операторами и они у него хорошо отложились в голове, то для него и код хороший. И попробуйте в этот код добавить, всеволишь, несколько незнакомых операторов. Крику, возгласов, эмоций будет выше нормы, мягко говоря. И, пожалуйста, не надо привычку - работать с определенными операторами и по определенным правилам - выдавать за хороший код. Все эти новомодные тенденции, такие как классы, паттерны и прочее, так сильно нагружают систему, что говорить о качестве кода не приходиться. Хороший код не может быть простым.
Тут проблема не только в алгоритмах. Проблема гораздо глубже. Очень давненько правда это было. Но, когда писал и считал на ЕС-ках, мне удавалось получать ошибку на уровне последнего знака (для одинарной точности это 8-ой знак после запятой). Если же я запускал эту же самую программу на персоналках, при тех же самых условиях, максимально, что удавалось добиться, - это 5 знаков после запятой, реально это 3, 4 знака точности. При этом евклидова норма погрешности для вектора значений, в первом случае была на уровне 7 знака, а во втором случае погрешность была уже во втором знаке после запятой. И что бы я не делал, добиться другого результат я не смог. Много позже понял почему такая ситуация: поскольку современные процессоры - это наследники каких-нибудь процессоров серии 8080, то соответственно все ограничения тех процессоров, автоматом перекочевали в современные. Не думаю, что ситуация как-то поменялась в лучшую сторону. Если что-то и получается лучше, то это чистая математика. Что не есть хорошо.
Всем большое спасибо за интерес, проявленный к данной статье.
А как Вы отнесетесь, если я сообщу следующую информацию.
Я разработал алгоритм деления длинных чисел и написал программу на C++ в Visual Studio 2017. Также были проверены эти данные на MathLab, Java и других программах и языках.
Получил следующие результаты:
Разделил 100-значное десятичное число на 35-значное десятичное число в цикле 100 000 раз.
Время расчета на тестах (MathLab, Java и другие программы и языки) составляет — от 1/2 минуты и выше.
На моей программе рассчитывается на одном процессоре — 0,1 секунды.
Затем я разделил 225-значное десятичное число на 53-значное десятичное число в цикле 1 000 000 раз. На моей программе рассчитывается на одном процессоре – около 3 секунд.
Я специально написал, что сложность 2*N. Я нигде не понимал это как O(2*N). Прекрасно знаю, что означает O(N). Это может быть и 2*N, и 10*N, и 1000*N. Вообще запись O(N) означает k*N, где k много меньше N (k<<N). Почему я написал, что сложность 2*N. Алгоритм линейный, в нем нет сравнений элементов друг с другом. С каждым элементом выполняются определенные действия. Это одно N. Второе N – это накладные расходы. В реальности они много меньше N, но я поднял границу до N. Вот почему я написал, что сложность алгоритма 2*N. Если бы накладные расходы были сравнимы с N или кратны N, тогда я бы написал, что сложность алгоритма O(N). Но накладные расходы много меньше N.
Если Вы работаете в кодировке ANSI и сортируете по возрастанию, то так и останется. Кода в кодировке ANSI: i-105, l-108, o-111. Первая буква «l» — у всех общая, поэтому сортироваться будет по 2-ой букве. Другие кодировки также работают.
И что подразумевается под «Любую?»?
К тому, что ваше утверждение, что ваша сортировка универсальна — некорректно. Почему? Я написал, что я могу сортировать текстовую информацию, целые и десятичные числа, положительные и отрицательные. Программа сортирует. После сортировки полностью, один в один, совпадает сортировкой, получаемой функцией std::sort.
К чему вопрос? Как можно сортировать без сравнений? Разработан новый алгоритм, работающий по другим правилам. Можно сортировать текстовую информацию, целые и десятичные числа, положительные и отрицательные.
По равномерному, согласен. Но равномерное распределение не дает какой-то закономерности, которую можно использовать и применить какие-то специальные методы.
15% — это реальные значения для текстовой информации, без всякого подгона, мухлежа. Для плавающей запятой сортировка также работает, но я не тестировал настолько, чтобы дать такую же информацию, как по текстовой.
По сравнению с функцией std::sort, используемой в Visual Studio 2017. По-моему, как в таблицах, так и в текстах об этом не единожды об этом упоминается.
Нет, я не пишу про сортировку Таноса, с ней ничего общего нет и в помине. Это сначала. Во-вторых, не трогайте Valemak. В-третьих, для того, чтобы о чем-то рассуждать, надо знать, о чем рассуждаешь. В статье, самое главное, это результаты тестирования, приведенные в таблицах. Все остальное — это общие рассуждения, помогающие что-то понять, чтобы меньше задавать вопросов. Самый главный результат — это то, что по новому алгоритму, выигрыш по быстродействию более 15%, а по затратам на память — практически двукратный. И чем больше объем сортируемой информации, тем более стремительный выигрыш мы будем иметь.
И, наконец, если очень хочется ругаться, то пришли e-mail. Поругаемся. А хамить здесь, не надо!!!
Нужна или не нужна программистам математика, по-моему, напрямую зависит от задач, которые решаются. Некоторые из приведенных в статье разделов математики, по-моему, больше нужны тем, кто занимается разработкой каких-нибудь трансляторов, компиляторов и что-то близкое к этому. Алгоритмы они в каждой области абсолютно разные, у каждого свои. Может это к огромному сожалению, а может к большому счастью, но на современном этапе уже нет большой необходимости разбираться в алгоритмах. Если и кому-то и нужен какой-то алгоритм, он просто подключает соответствующую библиотеку и не разбирается, что в ней делается и как она работает. Да, и подавляющая масса задач вообще не требует каких-то серьезных знаний.
На современном этапе бухгалтера уже мало используют калькуляторы. Если какая-нибудь процедура очень часто используется и достаточно распространена, то роль чаще всего роль бухгалтера или какого-нибудь другого оператора сводится к простому и правильному вводу определенных данных. Все остальное делает программа. Если процедура не очень распространена, то ее также пытаются автоматизировать. Основная масса бухгалтеров, на нормальных предприятиях, уже давно превратилась в операторов, которые просто правильно вводят данные. А вот организовать, создать, наладить весь этот процесс ввода данных и дальнейшей обработки вот для этого нужны соответствующие люди, умеющие не только программировать, но и знающие все тонкости того, что пытаешься запрограммировать.
Рыночная экономика и конкуренция - это лебедь, рак и щука. Лебедь рвется в облака, рак пятится назад, а щука тянет в воду. Кто виноват из них, кто прав - судить не нам, но только воз и ныне там. Но только воз и ныне там, как результат всего действия. А вот, если лебедя, рака и щука заставить тянут в одну сторону, то и воз, глядишь, сдвинется. Но это и есть административный ресурс. Другой, и самый главный и основной, вопрос - куда и на что направлен административный ресурс.
В этот же перечень можно добавить COBOL, Fortran, которым далеко за 60, и которые до сих пор являются основополагающими во многих областях. COBOL никак не могут заменить в банковской сфере, а на FORTRAN-е написано огромное количество научных программ, переписать которые тоже проблематично. И вот эти пенсионеры не используют ни классы, ни паттерны, ни SOLID и никакие другие аналогичные вещи. И разобраться в коде COBOL-а, Fortran-а ой как проблематично. То, что выдается за хороший код и называется хорошим, это больше вопрос привычки. Если человек привык работать с определенными операторами и они у него хорошо отложились в голове, то для него и код хороший. И попробуйте в этот код добавить, всеволишь, несколько незнакомых операторов. Крику, возгласов, эмоций будет выше нормы, мягко говоря. И, пожалуйста, не надо привычку - работать с определенными операторами и по определенным правилам - выдавать за хороший код. Все эти новомодные тенденции, такие как классы, паттерны и прочее, так сильно нагружают систему, что говорить о качестве кода не приходиться. Хороший код не может быть простым.
Тут проблема не только в алгоритмах. Проблема гораздо глубже. Очень давненько правда это было. Но, когда писал и считал на ЕС-ках, мне удавалось получать ошибку на уровне последнего знака (для одинарной точности это 8-ой знак после запятой). Если же я запускал эту же самую программу на персоналках, при тех же самых условиях, максимально, что удавалось добиться, - это 5 знаков после запятой, реально это 3, 4 знака точности. При этом евклидова норма погрешности для вектора значений, в первом случае была на уровне 7 знака, а во втором случае погрешность была уже во втором знаке после запятой. И что бы я не делал, добиться другого результат я не смог. Много позже понял почему такая ситуация: поскольку современные процессоры - это наследники каких-нибудь процессоров серии 8080, то соответственно все ограничения тех процессоров, автоматом перекочевали в современные. Не думаю, что ситуация как-то поменялась в лучшую сторону. Если что-то и получается лучше, то это чистая математика. Что не есть хорошо.
А как Вы отнесетесь, если я сообщу следующую информацию.
Я разработал алгоритм деления длинных чисел и написал программу на C++ в Visual Studio 2017. Также были проверены эти данные на MathLab, Java и других программах и языках.
Получил следующие результаты:
Разделил 100-значное десятичное число на 35-значное десятичное число в цикле 100 000 раз.
Время расчета на тестах (MathLab, Java и другие программы и языки) составляет — от 1/2 минуты и выше.
На моей программе рассчитывается на одном процессоре — 0,1 секунды.
Затем я разделил 225-значное десятичное число на 53-значное десятичное число в цикле 1 000 000 раз. На моей программе рассчитывается на одном процессоре – около 3 секунд.
И что подразумевается под «Любую?»?
К тому, что ваше утверждение, что ваша сортировка универсальна — некорректно. Почему? Я написал, что я могу сортировать текстовую информацию, целые и десятичные числа, положительные и отрицательные. Программа сортирует. После сортировки полностью, один в один, совпадает сортировкой, получаемой функцией std::sort.
И, наконец, если очень хочется ругаться, то пришли e-mail. Поругаемся. А хамить здесь, не надо!!!