Что вы имеете в виду под «почему вы не считаете треугольник Паскаля»?
Я написал в статье функцию bcr, поторая считает по треугольнику паскаля. И написал, что элемент из 34 строки считался около минуты. Также в конце статьи написал, что при расчете коэффициентов с длинной арифметикой использовал рекурсию (т.е. треугольник паскаля) с запоминанием посчитанных коэффициентов.
А хочу понять логику высказывания «С++ непричем». Первый отзыв и сразу «непричем»… Если мне нужно найти некий алгоримХ на языке С++, я пишу в поисковике «алгоритмХ С++» и если поисковик возвращает мне алгоритмХ на PHP, то вот этот РНР — «непричем». А если он возвращает алгоритм на С++ или С, то это то, что надо. Я его беру и использую.
12 человек добавили в избранное, но только 2 плюсанули. Итог — минус 2. Пожалуй, не стоит писать подобные статьи (это был пробный камень. так сказать).
«Простая задача часто имеет простое и понятное решение. Увы, неправильное...» Как увидеть эту неправильность и довести до ума — вот в чем вопрос. Способы могут быть разными. У меня работает и при n=67 и не тратит время на вычисление НОДов.
Я все примеры компилировал на С++. Заголовком я хотел сказать «можно брать функции расчета, вставлять их в программы на языках С, С++ и все будет работать». На Бейсике или Паскале это не получится. Что Вас не устраивает?
Интересное замечание, но хочу заметить:
1. Возможно, при каких-то k и n<=33 все же возникнет переполнение
2. Граница отодвинулась, но для n=34 все же осталось переполнение.
3. Переход на 64 бита кардинально отодвигает эту границу
Можно, конечно, в числителе и знаменмтеле поискать общие множители и посокращать их, но я не стал двигаиться в этом напралении.
Я специально сделал сравнение по ключу, который есть число/10 и отметил это в статье, чтобы у 30,31,32 был одинаковый ключ. А сделал для того, чтобы увидеть, как сортировки поступают со значениями, имеющими одинаковый ключ (т.е. устойчивые они или нет), И это тоже в статье написано. Выходит, Вы пробежались по ней не читая и сразу стали высказывать свое «фи». Печально.
Если над моими статьями будут смеяться те, кто сам ничего написать не может, то пусть смеются. Я считаю, что поставленную задачу — дать новичкам практическое понимание сортировки и руководство к действию выполнил. Показал, почему пузырьковая сортировка работает медленно, на каких данных. Показал, как пользоваться стандартной qsort (с этим у новичков бывают проблемы).
Посмотреть на видео с сортировками, конечно, интересно, но для новичков практической пользы немного, имхо. Он пишет «помогите сделать/исправить сортировку, она не работает», а я ему ссылку на видео дам? В общем, осталось дождаться мнений начинающих программистов и, исходя из них, решать — стоит ли заниматься этим дальше или нет.
Насчет сортировки выбором соглашусь. Хотя у меня почему-то такое название ассоциируется с другим алгоритмом. Если статья Вам не интересна, это не значит, что она не интересна или бесполезна другим. Я писал для начинающих, для тех, кто в 1001 раз задает на форумах вопросы «сортировка не работает», «надо сделать сортировкау пузырьком, как?» и т.п.
Что касается быстрой сортировки. Задачи реализовывать самому этот алгоритм не стояло. В статье показано, что можно использовать стандартный (если он доступен) и он дает весьма хороший результат (обгоняя пузырек и шейкер в 1000 раз на массиве в 100тыс элементов).
Минусов наставили, желание писать дальше для новичков отбили. Пишите тогда сами, а я посмотрю, что у Вас получится и найду недостатки (это гораздо проще, чем заметить достоинства).
Листинги смотрятся коряво, пришлось вручную перенести в html-файл.
Станно, что мой haswell 4590 просчитал 100тыс за 9.7сек, а 1млн за 123.5 сек, что примерно в 400 раз хуже, чем у автора. Что у него за компьютер?
Телетайп с 5-дорожечной перфолентой помню, а вот как называлась используемая им кодировка — забыл (но кажется, не КОИ-5...)
Кстати, хотя телетайп печатал медленней электрической машинки «Консул», зато он в отличии от нее никогда не сбивался. А у «Консула» рычажки заклинивались и печать прерывалась.
Это статья (в паре со статьей о кодировках) написана, чтобы программистам было понятнее, что такое UTF-16BE/LE, UTF-8, что такое и зачем нужен BOM, как символы хранятся в памяти и в файлах. Чтобы им было легче понять, почему у них в программе читаются/пишутся «кракозябры».
Извиняюсь, если вместо понимания я невольно ввел в заблуждение. Но ведь по Unicodee есть масса других статей, где-то более правильных и интересных. Я написал такую, какую сам бы хотел прочитать лет 5 назад… Кстати, первый вариант опубликован пару лет назад, но ЖЖ не дает поисковикам индексировавать начинающих авторов. А если статьи нет в поисковике — ее, считай, нет в интернете.
Спасибо за комментарий.
Вопрос не вполне однозначный, давайте попробуем разобраться. Я предложил простую схему:
UCS-2 для старого unicode, когда использовалась только одна плоскость;
UTF-16 для нового, когда их стало 17 и потребовались суррогатные пары;
Почему-то UTF-16 в применении к UCS-2 мне не попадалась.
Может, мое описание не совсем точно, зато просто и понятно и при описании языков программирования (Java, например) UCS-2 чаще трактуется как урезанный UTF-16 (без суррогатных пар), а не как абстактная точка кодовая пространства.
Вы предлагаете UCS-2 как идею точки в кодовам пространстве. Хорошо, тогда ответьте на вопрос: как хранились символы Unicode в файлах, когда была только одна плоскость? Был ли это фиксированный порядок или он мог быть разным? Как назывался этот разный порядок? Наберите в Google UCS-2 Little Endian (хотя это некорректно) и получите десятки тысяч ссылок
Впрочем, не хочется уподобляться остро и тупо-конечникам. Чем больше значений (даже не вполне точных/корректных) мы знаем — тем лучше (если, конечно, хотим понимать друг-друга, а не бороться за чистоту языка).
Давайте еще раз расставим точки над i.
1. По поводу кодировки и кодовой страницы вам уже написали, что англоязычная Википедия отражает суть лучше, потому что это не синонимы (хотя и употребляются в синонимичном значении многими).
Я не спорил ни с этим высказыванием ни с английской википедией, речь шла о вашей русскоязычной формулировке. Если Вам понятнее — мне не нравится ваш перевод (или толкование): «Кодовая страница — это таблица соответствия набора символов, их кодов и способа хранения этих кодов. А кодировка — это, строго говоря, способ хранения этих кодов сам по себе»
2. Не надо превращать популярную (не требующую от читателя глубоких специлизированных знаний) статью в занудство.
3. Я отмечал, что понятия кодовой страницы и кодировки близки, но не абсолютные синонимы, но выяснять различия выходит за рамки статьи. Прочитайте первое предложение статьи и название раздела.
4. Сами это понятия менялись с течением времени и понятие кодовой страницы в момент ее первого появления отличается от сегодняшнего. Тогда не было мультибайтовых кодировок (еще раз — статья опубликована в разделе история ИТ).
Вы делаете упор на железо — Ваше право. Я делаю упор на экономику. Почему железо было сделано таким? Потому, что память была очень дорогая и для англоязычных потребителей смысла удорожать железо не было (дешевле было использовать фокусы). Если у вас есть ссылки на более авторитетные источники — поделитесь ими, иначе спорить бесполезно.
Что касается переключения кодовых страниц, то на практике переключать их туда-сюда в процессе работы особой нужды не было: просто при запуске ДОС вместо зашитой в адаптер загружалась альтернативная (чаще всего) и все — дальше работа шла только с ней. С СGA я не работал, а вот с VGA работал довольно активно на уровне железа.
Я написал в статье функцию bcr, поторая считает по треугольнику паскаля. И написал, что элемент из 34 строки считался около минуты. Также в конце статьи написал, что при расчете коэффициентов с длинной арифметикой использовал рекурсию (т.е. треугольник паскаля) с запоминанием посчитанных коэффициентов.
1. Возможно, при каких-то k и n<=33 все же возникнет переполнение
2. Граница отодвинулась, но для n=34 все же осталось переполнение.
3. Переход на 64 бита кардинально отодвигает эту границу
Можно, конечно, в числителе и знаменмтеле поискать общие множители и посокращать их, но я не стал двигаиться в этом напралении.
Посмотреть на видео с сортировками, конечно, интересно, но для новичков практической пользы немного, имхо. Он пишет «помогите сделать/исправить сортировку, она не работает», а я ему ссылку на видео дам? В общем, осталось дождаться мнений начинающих программистов и, исходя из них, решать — стоит ли заниматься этим дальше или нет.
Что касается быстрой сортировки. Задачи реализовывать самому этот алгоритм не стояло. В статье показано, что можно использовать стандартный (если он доступен) и он дает весьма хороший результат (обгоняя пузырек и шейкер в 1000 раз на массиве в 100тыс элементов).
Минусов наставили, желание писать дальше для новичков отбили. Пишите тогда сами, а я посмотрю, что у Вас получится и найду недостатки (это гораздо проще, чем заметить достоинства).
Станно, что мой haswell 4590 просчитал 100тыс за 9.7сек, а 1млн за 123.5 сек, что примерно в 400 раз хуже, чем у автора. Что у него за компьютер?
Кстати, хотя телетайп печатал медленней электрической машинки «Консул», зато он в отличии от нее никогда не сбивался. А у «Консула» рычажки заклинивались и печать прерывалась.
Извиняюсь, если вместо понимания я невольно ввел в заблуждение. Но ведь по Unicodee есть масса других статей, где-то более правильных и интересных. Я написал такую, какую сам бы хотел прочитать лет 5 назад… Кстати, первый вариант опубликован пару лет назад, но ЖЖ не дает поисковикам индексировавать начинающих авторов. А если статьи нет в поисковике — ее, считай, нет в интернете.
Вопрос не вполне однозначный, давайте попробуем разобраться. Я предложил простую схему:
UCS-2 для старого unicode, когда использовалась только одна плоскость;
UTF-16 для нового, когда их стало 17 и потребовались суррогатные пары;
Почему-то UTF-16 в применении к UCS-2 мне не попадалась.
Может, мое описание не совсем точно, зато просто и понятно и при описании языков программирования (Java, например) UCS-2 чаще трактуется как урезанный UTF-16 (без суррогатных пар), а не как абстактная точка кодовая пространства.
Вы предлагаете UCS-2 как идею точки в кодовам пространстве. Хорошо, тогда ответьте на вопрос: как хранились символы Unicode в файлах, когда была только одна плоскость? Был ли это фиксированный порядок или он мог быть разным? Как назывался этот разный порядок? Наберите в Google UCS-2 Little Endian (хотя это некорректно) и получите десятки тысяч ссылок
Впрочем, не хочется уподобляться остро и тупо-конечникам. Чем больше значений (даже не вполне точных/корректных) мы знаем — тем лучше (если, конечно, хотим понимать друг-друга, а не бороться за чистоту языка).
1. По поводу кодировки и кодовой страницы вам уже написали, что англоязычная Википедия отражает суть лучше, потому что это не синонимы (хотя и употребляются в синонимичном значении многими).
Я не спорил ни с этим высказыванием ни с английской википедией, речь шла о вашей русскоязычной формулировке. Если Вам понятнее — мне не нравится ваш перевод (или толкование): «Кодовая страница — это таблица соответствия набора символов, их кодов и способа хранения этих кодов. А кодировка — это, строго говоря, способ хранения этих кодов сам по себе»
2. Не надо превращать популярную (не требующую от читателя глубоких специлизированных знаний) статью в занудство.
3. Я отмечал, что понятия кодовой страницы и кодировки близки, но не абсолютные синонимы, но выяснять различия выходит за рамки статьи. Прочитайте первое предложение статьи и название раздела.
4. Сами это понятия менялись с течением времени и понятие кодовой страницы в момент ее первого появления отличается от сегодняшнего. Тогда не было мультибайтовых кодировок (еще раз — статья опубликована в разделе история ИТ).
Вы делаете упор на железо — Ваше право. Я делаю упор на экономику. Почему железо было сделано таким? Потому, что память была очень дорогая и для англоязычных потребителей смысла удорожать железо не было (дешевле было использовать фокусы). Если у вас есть ссылки на более авторитетные источники — поделитесь ими, иначе спорить бесполезно.
Что касается переключения кодовых страниц, то на практике переключать их туда-сюда в процессе работы особой нужды не было: просто при запуске ДОС вместо зашитой в адаптер загружалась альтернативная (чаще всего) и все — дальше работа шла только с ней. С СGA я не работал, а вот с VGA работал довольно активно на уровне железа.