Языки программирования

[GlitchMob]

А Win3.11 с дискет слабо?

 

 

Ита шта таке?)))))000

 

Я никогда с дискетами не работал так, так что не умею я-)

[4upaKabra]

Я умею переустанавливать любой Windows

Вот и вскрылась правда

[active69]

А Win3.11 с дискет слабо?

В 90-х я ставил с дискет 95 ...

[ОСОБО НЕОПАСЕН]

А я могу так поставить Windows так, что он потом hal.dll просит. И я действительно этим горжусь.

[STSOFT]

Загадка.

 

На каком языке это написано и приблизительно оцените время счета на гениальной конструкции Института Кибернетики АН УССР.

 

"НАЧ"; "РАЗР" 1000; PI:=ARCCOS(-1); "ВЫВ" PI; "КОН"

 

P.S. Могут быть незначительные ошибки. Восстановлено по памяти.

[ОСОБО НЕОПАСЕН]

Загадка.

 

На каком языке это написано и приблизительно оцените время счета на гениальной конструкции Института Кибернетики АН УССР.

 

"НАЧ"; "РАЗР" 1000; PI:=ARCCOS(-1); "ВЫВ" PI; "КОН"

 

P.S. Могут быть незначительные ошибки. Восстановлено по памяти.

 

Выглядит как обыкновенное описание алгоритма программы (=.

[STSOFT]

Выглядит как обыкновенное описание алгоритма программы (=.

 

Не совсем. Это входной язык ЭВМ "Мир-1" Алмир. Проект МИР-3 в начале перестройки был фактически скуплен на корню американцами, т.к. не нашел поддержки. Аналогичная судьба постигла и гигантский проект супер-ЭВМ "Эльбрус", который не уступал американским Cray и даже превосходил по многим параметрам. Самое интересное, что все оригинальные идеи 0-адресной ЭВМ МИР затем частично проявились в гигантских ЭВМ Tandem, но вскоре ушли в подполье, в Пентагон.

 

Уникальность Алмира была в том, что в любой момент работы программы можно было поменять разрядность чисел с плавающей точкой оператором "РАЗР". Это было началом эры прецизионных вычислений.

Кроме того, среди операторов Алмира были суммы, произведения, интегралы и операторы дифференцирования - как численные, так и аналитические (!!!).

[4upaKabra]

Задолго до появления телефонов с редакторами рингтонов я такой редактор на турбо паскале написал. Вводишь последовательность нот с указанием октавы и длительности, жмёшь О.К., музыка пиликает.

[Ustas.SSR]

Аналогичная судьба постигла и гигантский проект супер-ЭВМ "Эльбрус", который не уступал американским Cray и даже превосходил по многим параметрам.

 

Ведь сейчас производят какие-то процессоры "Эльбрус".

[STSOFT]

Ведь сейчас производят какие-то процессоры "Эльбрус".

 

Из их производства нам (т.е. России) принадлежит не известно какая доля т.к. выпускают его на Тайване, взамен Зеленограда, как планировали. Похоже, остатки проекта распроданы ряду инвесторов. Сильно попортилась изначальная архитектура - упор на микропроцессоры, совместимые с Intel-процессорами гасит мощность. По плавающей точке сделан крен в стандарт IEEE, что ставит "крест" на серьезности соответствующих расчетов. Изначально планировался DECIMAL FLOAT(33) как базовый (он использовался в IBM 370 и выше). Это гораздо серьезнее, но в микропроцессорном варианте практически неосуществим.

[Ustas.SSR]

Ну так заказ разместили на тайване, вот и выпускают. Потому что у нас негде.

И вероятно все принадлежит, никому он больше не нужен.) К тому же они используются в оборонке, и никого чужого к ним не допустят.

 

упор на микропроцессоры, совместимые с Intel-процессорами гасит мощность.

 

Не понял. Ведь наоборот позиционируют как довольно мощный процессор для вычислений. Например последняя их модель.

[STSOFT]

Не понял. Ведь наоборот позиционируют как довольно мощный процессор для вычислений. Например последняя их модель.

 

Арифметика с плавающей точкой у них так же, как и в Intel'овских 32, 64 и 80 - битная. Какие могут быть серьезные вычисления на 80-ти битах? 18 десятичных разрядов хватит разве что для инженерных расчетов. Ну для простеньких задач, да. Нету аппаратной поддержки 128-битной арифметики с плавающей точкой.

 

По крайней мере так или я что-то недопонял - не так уж много сведений об этом процессоре.

[Ustas.SSR]

Я сильно не вчитывался, и судил по обещанной скорости вычислений.

Нужную разрядность должно быть можно реализовать программно. Может для его применения этого и не требуется.

[STSOFT]

Я сильно не вчитывался, и судил по обещанной скорости вычислений.

Нужную разрядность должно быть можно реализовать программно. Может для его применения этого и не требуется.

 

Программно можно реализовать, конечно, все, но сколько это будет считаться по времени. Вот, например, пакет Paris на Си++, финский пакет apfloat и др. - все более-менее, но попробуй вычислять в цикле, например, sin(x) - это труба и пассатижи, время взлетает кубически. По идее ожидалось прорыва в микропроцессорной технике. Остаются еще сопроцессоры с плавающей точкой. В военных делах они используются до сих пор, т.к. точности 16 знаков мантиссы во многих случаях расчета всякого рода траекторий не хватает. А уж про космос и говорить нечего...

[Scud-IIEPBblu]

Кстати. Вот сугубо для любителей шевельнуть (хоть один-единственный раз в жизни) собственными мозгами. Чисто такой демонстрационный пример. Допустим, вам надо точно посчитать, сколько подряд нулей справа будет иметь факториал от 1000 000 000...

А что? Слабо, что ли? Да врёте - ни в жизнь не поверю!

[STSOFT]

Кстати. Вот сугубо для любителей шевельнуть (хоть один-единственный раз в жизни) собственными мозгами. Чисто такой демонстрационный пример. Допустим, вам надо точно посчитать, сколько подряд нулей справа будет иметь факториал от 1000 000 000...

 

Число нулей справа в n! равно показателю, с которым 5 входит в разложение n! на простые множители.

 

Гораздо более актуальная задача - оценить кол-во памяти в байтах для хранения n!. Приняв за основу, например, двоичный код.

[Scud-IIEPBblu]

Число нулей справа в n! равно показателю, с которым 5 входит в разложение n! на простые множители.

 

Гораздо более актуальная задача - оценить кол-во памяти в байтах для хранения n!. Приняв за основу, например, двоичный код.

 

Ну, да. Ваша мысль, разумеется, в верном направлении движется. Вот только ответом это я, в преподскую свою бытность, вряд ли счел бы.

[ATTACH]407313[/ATTACH]

 

Вот это ответ на твердую троечку. Или, если то же самое, но в виде алгоритма на каком-нибудь паскакале.

На четыре пришлось бы добавить, что речь идет исключительно о случае представления числа n! в форме позиционной записи по основанию 10. Это важно. Ибо от этого напрямую зависит ответ задачи. К примеру, если б речь шла про позиционную же запись, но по основанию 11 (а почему бы и нет?) – ответ был бы совершенно иной, ибо 11 число простое, и поэтому ноль справа в этой системе записи никак не может появляться в результате умножения не на ноль.

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

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

 

Что же касается Вашего вопроса, то мне не совсем понятно, что Вы имели в виду. Для записи любого целого числа m (без знака, ибо факториал определен только для положительных целых чисел), достаточно int(ld(m))+1 бит памяти (если нам учебники не врут). И m=n! – тут не исключение. Или же Вы имели в виду, как это вычислить на практике? Ну, для точного вычисления я, пожалуй, так навскидку и не найду ничего лучшего, чем брутфорс. Но ведь точное значение Вам, судя по всему, и вовсе без надобности. Не так ли? Особенно – учитывая то, что в двоичной записи n! будет иметь довольно много (Вы это тоже легко можете посчитать) нулевых бит справа. Причем ни для одного n, кроме 0! и 1!, как Вы легко можете убедиться, n! никогда не будет даже полностью использовать все значащие разряды тоже. Поэтому Вам, возможно, достаточно иметь приблизительное значение размерности необходимой памяти. Для этого можно воспользоваться тем, что любое произведение требует не больше цифр для его записи, чем было суммарно в обоих сомножителях. То есть, если умножать максимальное число на минимальное (1), мы получим произведение, длина которого не превышает ld(n)+1+1. Соответственно, в середине последовательности длина произведения не превысит 2*ld(n/2)+1. А самих таких пар будет n/2, то есть на самом паршивом компе быстро прикинуть по максимуму оценочное значение длины n! не должно представлять ни малейшей сложности.

Впрочем, тут есть ещё, конечно, над чем подумать…

Изменено 23.05.2014 01:16 пользователем Scud-IIEPBblu

[4upaKabra]

Ждём ответ от STSOFTa и запасаемся попкорном.

[Scud-IIEPBblu]

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

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

Так что, господа разочарованные, уж не взыщите...

[STSOFT]

10! = 3628800

 

ln(10) = 2,3025850929940456840179914546844

ln(5) = 1,6094379124341003746007593332262

 

ln(10) / ln(5) = 1,430676558073393050670106568764

 

Если предположить, что в формуле ln(n) \ ln(5) (кстати, неясно, почему используется ln, а не lg), то

 

ln(10) \ ln(5) = 1.

 

В итоге верхний предел в сумме равен 1, j=1..1, По формуле получается

 

10 / 5 (или с учетом ранее сделанного предположения 10 \ 5) = 2.

 

Ответ правильный - 2 нуля.

 

Берем другое n = 20

 

n! = 2432902008176640000

 

Кол-во нулей = сумма(j=1..1, n \ 5^j) = 4.

 

Похоже формула работает правильно. Более детальную проверку сделаю чуть позже, но Паскаль в данном случае отвергается, мои библиотеки высокоточных вычислений - на С++, потребуется класс HInt сверхбольших (huge) целых чисел.

[Scud-IIEPBblu]

Там, вообще-то, имелся в виду логорифм по основанию 5. ln(n)/ln(5) - это просто автоматом выскочило, по привычке. Дело в том, что в изначальной формуле верхний предел указан не был вообще, что с точки зрения математики совершенно корректно (ибо суммирование любого числа нулей на результат никак не влияет). А вот с точки зрения алгоритма вычислений такой прокол явился бы явным говнокодингом.

Ну, проверять формулу вряд ли целесообразно - она ещё у Эйлера 300 лет назад исправно работала...

О, кстати. Очень существенно отметить разницу между "/" и "\". Если использовать обычное (дробное) деление, то вся формула, как это нетрудно видеть, просто превращается в n/4, и только целочисленное деление (с отбрасыванием остатка) даст правильный результат:

249 999 998 правых нулей для 1 000 000 000!

249 999 989 --"--"-- для 999 999 999!

и т.п.

 

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

[STSOFT]

Для меня больший интерес представлял вопрос о рациональном ДРП (дин. размещении памяти) для хранения результатов умножения/деления гигантских чисел. Позже я вернусь к этому вопросу.

[Scud-IIEPBblu]

Для меня больший интерес представлял вопрос о рациональном ДРП (дин. размещении памяти) для хранения результатов умножения/деления гигантских чисел. Позже я вернусь к этому вопросу.

 

O'o!!!

Не скрою - заинтриговали. С чем-то серьёзным, видать, дело имеете, да?

Нет, я вовсе не провидец. Просто любому понятно без слов, что на ублюдочном писюке, да под (CENSORED!) Вонью, запросто способной свопнуть на винт хоть терабайт любого дерьма, - никаких таких проблем быть просто не может. Тут (это даже такому лоху, как я, понятно) речь может идти лишь о двух вариантах: либо микроконтроллер - либо комп под полностью верифицируемой осью.

К сожалению (и с огромным сожалением!), тут я должен сразу предупредить, что, если чем-то и смогу быть полезным, то, увы, - лишь на уровне самой-самой общеизвестной банальщины...

Изменено 30.05.2014 03:02 пользователем Scud-IIEPBblu

[STSOFT]

O'o!!!

Не скрою - заинтриговали.

Проблема есть, на самом-то деле. Дело в том, что n! находится в знаменателе почти всех рядов, т.е. речь идет о вычислении функций, раскладываемых в ряд Тейлора. Самый быстро сходящийся ряд exp(x), самый медленно сходящийся ln(x). А теперь представим, что нам надо спроектировать векторный процессор, решающий задачу в кратчайший срок с минимальным объемом ОЗУ. И все это в условиях регулируемой точности. На этапе имитационного моделирования. Цель - проектное решение в виде СП-модели (СП - сеть Петри, слава этой мнемонике).

Решение - тоже СП-образ. Далее за дело берутся электронщики, слойщики (от слова слой (процессора)) и пр.

[Scud-IIEPBblu]

Проблема есть, на самом-то деле. Дело в том, что n! находится в знаменателе почти всех рядов, т.е. речь идет о вычислении функций, раскладываемых в ряд Тейлора. Самый быстро сходящийся ряд exp(x), самый медленно сходящийся ln(x). А теперь представим, что нам надо спроектировать векторный процессор, решающий задачу в кратчайший срок с минимальным объемом ОЗУ. И все это в условиях регулируемой точности. На этапе имитационного моделирования. Цель - проектное решение в виде СП-модели (СП - сеть Петри, слава этой мнемонике).

Решение - тоже СП-образ. Далее за дело берутся электронщики, слойщики (от слова слой (процессора)) и пр.

 

STSOFT, элементарные вещи мне объяснять не обязательно. (Хотя это, разумеется, могло бы быть небесполезным для "телезрителей", но я не настолько оглтелый оптимист, чтоб на это надеяться).

Методика, основанная на рядах Тейлора, имеет, видите ли, одно преимущество - она универсальна. Но, увы, "одно" часто оказывается "одним-единственным". Я имею в виду, что на практике всегда (практически, всегда ) приходится иметь дело с вычислениями ограниченной точности. А для них гораздо удобней полиноминальные разложения. Да, они всегда приблизительны (почти ни одно из них (за исключением, разве что формулы Стирлинга) никогда не дает точного результата). Но зато они быстры и не особо требовательны к ресурсам (к памяти, главным образом). К примеру, ряд:

24 arctg(1/8) + 8 arctg(1/57) + 4 arctg (1/239)

- пригодный для вычисления числа "пи" с точностью до 100 000 знаков (и немного больше, вообще-то), работает (при такой разрядности) раз в триста быстрее классического ряда Лейбница (того же Тейлора, в принципе).

Да, не спорю, полиноминальное разложение не является строго алгоритмизируемым. Да, тут без применения интеллекта - никуда. Не спорю.

Но...

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

Изменено 29.05.2014 23:23 пользователем Scud-IIEPBblu