Перевод из любой системы счисления в любую с++

[Absurd]

Кстати, что такое пессимизированный алгоритма, я не понял. Что ты подразумеваешь под этим словом?

Иногда это слово используют в продолжении цитаты Кнута "Корень всех зол - ранняя оптимизация" - "Поздняя пессимизация тоже ничего хорошего не принесет". Автор некто Лен Лантацци, никогда о таком не слышал.

[Сионист]

и достаточно оптимален.

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

и переменные в нём имеют неосмысленные имена,

Имена как раз в порядке, проблема в смене назначения одной и той же переменной без применения union. Если бы было

Код: Выделить всё

union
{
 int i; // позиция текущей цифры в числе
 int next; // позиция справа от текущей цифры в числе
};
...
for(i=0;x[i];i++);
    //А потом с последнего символа начинаем переводить
    for(;next;next--){
        //значение цифры
        for(k=0;abc[k]!=x[next-1] && k<36;k++);

, то путаницы бы не было, у него же одно и то же имя используется в двух значениях. И ссылка проблему не решит, так как объявление ссылки означает, что новое имя - синоним старого, union же объявляет несколько разных переменных в одном месте в памяти, то есть такой код будет значить: i больше не нужна и теперь на её месте у нас находится next, имеющая уже другой смысл в данной программе.

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

То есть что такое оптимизированный алгоритм, ему известно. All complete. Пессимизация же противоположна оптимизации.

И про недообфускированный тоже поясни.

Слегка запутанный, но не зашифрованный.

[Romeo]

Нет. Взять ту же -1 на каждом шаге.

На счёт -1 - согласен, но одна целочисленная команда не так уж и страшна, чтобы сразу ставить на алгоритме крест и говорить о его не оптимальности. Ну не подумал просто человек. Это же мелочь. А вот предложенное тобой вычисление длины через логарифм реально бы просадило perfomance.

Код: Выделить всё

union
{
 int i; // позиция текущей цифры в числе
 int next; // позиция справа от текущей цифры в числе
};

Скажу честно, если бы кто-то такое залил вот такой uniuon в код, за который я ответственен, я бы просто убил этого человека Это совсем не тот случай, когда нужно использовать union.

Пессимизация же противоположна оптимизации.

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

Слегка запутанный, но не зашифрованный.

Ну а это точно изобретение слова.

Ты скажешь, что я придираюсь. Может и так. Просто терпеть не могу когда люди намеренно используют заумные слова, щеголяя ими перед молодыми, которым эти слова скорее всего ещё не понятны. Именно намеренно и без нужды. Ведь всё это можно было сказать более простым языком. А если ещё и придумывают слова, чтобы казаться умными, это вообще фуууу.

[Absurd]

Просто это не общепринятый термин.

Александреску в "Modern C++ Design" использует несколько раз в смысле "Если уж мы будем использовать очень крутые приемы программирования, давайте предварительно снизим их цену чтобы быть смелее. Это не преждевременная оптимизация, это избегание пессимизации, то есть написания кода который заведомо медленнее оптимизированного варианта".

[Romeo]

Тем не менее гугл молчит. Пессимизацию он знает только сайтов.

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

[Сионист]

Тем не менее гугл молчит. Пессимизацию он знает только сайтов.

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

А где здесь усложнение?

На счёт -1 - согласен, но одна целочисленная команда не так уж и страшна, чтобы сразу ставить на алгоритме крест и говорить о его не оптимальности.

По одной на шаг цикла. Хорошо, что числа короткие, пара десятков вычитаний и та не наберётся. А если не на встроенном типе для промежуточного представления числа, а на длинной арифметике? Тогда одна -1 в тексте может вылиться в тысячи операций вычитания и каждая будет требовать тысяч элементарных операций и возможно десятков-сотен тысяч тактов. И того миллионы тактов из-за одной замены декремента вычитанием и внесения его в цикл. А при длине числа в миллион цифр уже сотни триллионов тактов. Оптимально же только то, что вообще нельзя улучшить, даже незначительно. Единственный такт и то нельзя выиграть, изменив семантику операций, а можно только лишь оптимизацией на уровне кода. Только тогда алгоритм оптимален. Замена постфиксных декрементов/инкрементов на префиксные, или замена

Код: Выделить всё

i=i+1[/cpde] на [code]i++

и

Код: Выделить всё

i=i-1[/cpde] на [code]i--

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

Код: Выделить всё

x<<=2

на

Код: Выделить всё

x*=4

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

Ну а это точно изобретение слова.

Есть такое слово, "словотворчество".

Скажу честно, если бы кто-то такое залил вот такой uniuon в код, за который я ответственен, я бы просто убил этого человека Это совсем не тот случай, когда нужно использовать union.

Когда же ещё нужен union, кроме как при использовании одной и той же области памяти для разных целей? А разнотипные, или однотипные переменные туда сложить, это уже мелочь. Даже приведение через union оправдано в том лишь случае, когда разные представления одной и той же информации предназначены для разных целей и одновременно типы таковы, что для приведения достаточно иначе прочитать те же байты. В остальных случаях приводите явно операторами.

[Absurd]

Замена постфиксных декрементов/инкрементов на префиксные, или замена

Код: Выделить всё

i=i+1[/cpde] на
Код :
i++
и [code]i=i-1

на
Код :
i--
в тех местах программы, где нужно лишь значение самой переменной, а значение оператора некуда возвращать, не меняет алгоритм даже на эквивалентный, это как раз оптимизация на уровне кода.

Для любого современного компилятора утверждения i=i+1 и ++i, а также x<<=2 и x*=4 абсолютно эквивалентны. Кроме того, я однажды видел в сети постинг человека из группы разработки микрочипов который писал что уже давно на современных процессорах инструкции сдвига реализуются через умножение, ибо держать на кристалле сразу две схемы - сдвига бит и умножения - совершенно излишне, поскольку умножение это более общая операция и поддерку команд сдвига можно реализовать через нее. Ничего сложного в умножении нет, это просто каскад сумматоров. При этом в современных процессорах вычислительное ядро включая плавающую точку и поддержку SIMD инструкций занимает менее 20% площади. Все остальное это кеши L0 и L1. Так что вся оптимизация кода сводится к оптимизации использования кешей и написание высокопроизводительного кода превращается в искусство кеширования. Все остальное не имеет никакого значения. Так что перестаньте, пожалуйста, засорять этот форум своим упоротым бредом.

[Сионист]

Для любого современного компилятора утверждения i=i+1 и ++i, а также x<<=2 и x*=4 абсолютно эквивалентны.

Всякая оптимизация делается для определённых условий и исходя из них, пессимизация часто тоже, тем более пессимизация на уровне кода. Компиляторы ведь были и достаточно древние, а настоящий пессимизатор ну просто обязан отключить всю автоматическую оптимизацию, до которой сможет добраться. <<=2 и *=4 различаются тем, что в первом случае гарантированно происходит умножение лишь на один взвешенный бит правого множителя и не выполняется сложение, а во втором случае возможна компиляция в более общую инструкцию, по которой переменная будет умножена на все биты правого множителя, в том числе, нулевые, а потом полученные произведения ещё и будут сложены.

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

Сумматоров и сдвигателей, иначе умножение может занимать многие годы. А раз в самом умножении уже есть сдвиг, то действительно зачем дублировать?

x*7 как будете считать? x+x+x+x+x+x+x? На самом деле x+(x<<1)+(x<<2). А если x*1028768317896558? Прогоните цикл на 1028768317896558 шагов? 1028768317896558=11101001111010100011001010001001001111011101101110 двоичное, а x*1028768317896558=(x<<1)+(x<<2)+(x<<3)+(x<<5)+(x<<6)+(x<<8)+(x<<9)+(x<<10)+(x<<12)+(x<<13)+(x<<14)+(x<<15)+(x<<18)+(x<<21)+(x<<25)+(x<<27)+(x<<30)+(x<<31)+(x<<35)+(x<<37)+(x<<39)+(x<<40)+(x<<41)+(x<<42)+(x<<45)+(x<<47)+(x<<48)+(x<<49), всего 64 шага цикла вместо квадриллиона, доли микросекунды вместо четырёх суток. А ведь это далеко не самый большой множитель. Как на 9223372036854775807 будете умножать? Если просто складывать левый множитель, то процесс займёт 105 лет, а если сначала сдвинуть и сложить уже промежуточные результаты, то опять доли микросекунды. Ядро то всё равно RISC и умножает не оно, а микрокод, используя один сумматор, один сдвигатель и менее пяти квазирегистров. И повторно использовать тот же сдвигатель уже для сдвига для такого камня не проблема. Но целиком то весь код умножителя для сдвига не используется, когда нужен именно сдвиг, то даже это слишком долго, так как альтернатива - завернуть в инструкцию кода ровно одну инструкцию микрокода, которая выполнит только сдвиг и ровно один раз. Другой вопрос, делать ли сдвиг сдвигом, или x<<1=x+x, x<<2=(x<<1)+(x<<1), x<<3=(x<<2)+(x<<2) и т.д., то есть последовательным удвоением через сложение. В RISC то ядре. Если это даст экономию площади, то в зависимости от требований может и можно пойти на некоторое замедление инструкции собственно сдвига и реализовать её тоже циклом, для умножения же сдвиг так и так нужен последовательный на 1 за шаг. Мало того, инструкция сложения тоже делается на том сумматоре, который использован в умножителе.

[Romeo]

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

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

А повесть про умножения на большие числа, для одного из которых ты даже не поленился расписать суммы и сдвиги битов, чтобы даже дурак понял твою глубокую идею, вложенную в каждое из этих 64-ёх слагаемых, вообще достойна поклонения. Вот только в кульминации этой повести мне чуть-чуть не хватило накала. Почему число 9223372036854775807 осталось не разложенным???

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

Хочешь совета? Не насилуй организм. Бросай ты это гиблое дело. Как программирование, так и вообще точные науки. Не твоё это. Ты тратишь столько времени и сил на то, чтобы состояться на поприще, которые просто не для тебя. Есть ведь иные роды занятий, где все перечисленные минусы либо не важны, либо даже станут плюсами. Знаешь чем займись? Начни писать книги! Из тебя выйдет потрясающий писатель абсурдной фантастики, типа Станислава Лема. Обожаю его "Звёздные дневники Ийона Тихого" и культовый "Солярис". И очень часто, читая твои посты наподобие предыдущего, раз за разом прихожу к выводу, что ты мог бы и забористее нафантазировать - дай только волю. Послушайся моего совета. Ты потом будешь мне благодарен. Ты не смотри на то, что я начинал свой пост с сарказма: сейчас я говорю на полном серьёзе.

[Сионист]

Интересно, ты долго фантазировал, чтобы извергнуть такое, или просто под кайфом пишешь все свои посты?

По себе меришь. К Жириновскому не ходить.

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

А переходы не больше времени займут?

Почему число 9223372036854775807 осталось не разложенным???

Потому что домашнее задание.

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

Absurd пишет именно за этим. Я - не за этим.

По факту же, ты - весьма посредственный программист

Ога. Чтоб написать модель гидромагнитоэлектродинамики в аппарате внепечной комплексной обработки стали и в установке электрошлакового литья, надо быть ну очень посредственным и не уметь работать самостоятельно.

искать информацию,

и именно поэтому моей задачей при оформлении четырёх патентов был именно поиск информации.

обладающий не систематизированными знаниями,

О c++ да. Но не о сдвигах и арифметике. И не об автоматизации технологических процессов.

а ещё снабжённый неуёмной жаждой фантазировать,

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

Знаешь чем займись? Начни писать книги!

Не моё.