Category: компьютеры

Category was added automatically. Read all entries about "компьютеры".

линейка

Таненбаум о фон Неймане: трудности перевода

Таненбаум Э., Остин Т. Архитектура компьютера. 6-е изд. Глава 1, стр. 38 — СПб.: Питер, 2013.

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

Трудности перевода? Ок, перевод конкретно этого предложения пожалуй действительно настолько неудачный (выразимся интеллигентно), насколько это возможно. Вот смотрите оригинал.

Tanenbaum, Andrew S., Structured computer organization / Andrew S. Tanenbaum, Todd Austin. — 6th ed. Chap. 1, p. 19. Pearson, 2012.

The machine did not have floating-point arithmetic because von Neumann felt that any competent mathematician ought to be able to keep track of the decimal point (actually the binary point) in his or her head.


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

  2. Я бы сказал «предполагал», а не «считал». В русском языке, когда кто-то что-то считает, иногда имеется в виду, что он ещё об этом и заявляет, да не просто, а выставив ногу вперёд.



В итоге в русском переводе всё выглядит так, как будто Таненбаум над фон Неймaном издевается. А в оригинале естественно нет. Хотя теперь у меня и насчёт английского варианта сомнения зародились =). А у вас?

UPD: Вообще вопрос обсуждался довольно обильно, уже не применительно к Таненбауму. Таки да, фон Нейман не считал целесообразным с плавающей запятой париться: https://people.eecs.berkeley.edu/~wkahan/SIAMjvnl.pdf, спасибо товарищу с Бнвача.

Также здесь / also here.
большой брат, система, IBM

1200 для CIS-сканнера

Немного раньше, чем полгода назад, я вопрошал про анизотропную плотность у сканеров и принтеров: https://dluciv.dreamwidth.org/193940.html. По результату получил пачку знаний про CIS-сканеры: https://dluciv.livejournal.com/199662.html?thread=808174#t808174.

Сейчас у меня есть МФУ Epson L3050 (https://www.epson.eu/products/printers/inkjet-printers/for-home/ecotank-l3050#specifications) — за свою цену чудесная штука. Причём при сканировании у него похоже именно заявленные 1200 dpi: если пытаться поднимать разрешение дальше, получается бесполезная размазня, а на 1200 всё ещё более или менее чётко, и явно проявляются детали, которых нет на 600. Я в этом убеждался и на документах, и на фотографиях. Как и многие дешёвые железки, этот CIS-сканер весьма неплохо работает, но только в идеальных условиях.

Кстати, с фотографиями, как ни странно, всё зависит от контента. Если, скажем, карточка 10x15, и на ней одна–три морды, ну, на худой конец, пять, то 600 dpi оказывается вполне уместно. Без фанатизма если. А если на ней человек 15, то уже 1200 dpi надо, а то никак. Причём на это, скорее всего, влияет и факт съёмки одиночных и групповых портретов через разные объективы.

Но есть другая напасть, причём на разных разрешениях. Я кивал на WiFi, но и с USB та же ерунда.



На картинке кусок документа с гильошем. Вы видите «ступеньку»? У меня такое ощущение, что проблема программная (на стороне сканера скорее всего). Или сканер не успевает обдумать данные в какой-то момент, или ещё что. Причём картинка выше вообще не с моего сканера, а с другого дешёвенького МФУ, не Epson, но на моём примерно то же самое. При сканировании по звуку отловить этот момент не получается.

Вопрос, можно ли бороть, и, если можно, то как?

P.S. Да, я нормальными полиграфическими сканерами, подключёнными через SCSI, тоже пользовался, и в курсе, что сканер, который впятеро дороже, такого не делает.

Также здесь / also here.
большой брат, система, IBM

(no subject)

Знаете, в чём я вижу заговор? Серьёзно.

Не один десяток лет выпускаются локализованные клавиатуры, на них появляется куча ненужных кнопок для Винды, но почему, шерсть на носу, на них нет специальной кнопки Рус/Лат? Или Укр/Лат, или Груз/Лат, не важно. Что за бред...

Также здесь / also here.
не для всех, криптопридурок

Exploits of a Mom

Назарбаев подписал указ о переходе Казахстана на латиницу.

Известно, что для Казахов ни кириллица, ни латиница не являются родными. Также ясно и то, что при выборе между латиницей и кириллицей, если обе не родные, сейчас действительно больше технических преимуществ у латиницы. Да хотя бы на клавиатуре ПЕКА латиница расположена отдельно от всего. А кириллица — нет, поскольку её много. А это на самом деле очень неудобно. И нормальной отдельной кнопки для переключения между латинским и национальным наборами нет. Тут я, правда, вообще в недоумении, поскольку это ещё более неудобно, но за много лет все привыкли и не возмущаются. Короче не предназначена клавиатура для кириллицы-то.

Не ясны две вещи. Во-первых, почему им приспичило это сделать сейчас, а не сразу после распада СССР. А в-нулевых — зачем это делать так по-дурацки?

Сейчас объясню, почему мне кажется, что они сделали по-дурацки.

Даже если оставить написанное журналистами слово «апостроф» и посмотреть на указ Назарбаева, можно убедиться в том, что действительно вводятся новые буквы, выглядящие, как буквы с апострофами. В Юникоде, помимо самого апострофа, уже имеются похожие на него дополняющие диакритические знаки U+0315 (Combining Comma Above Right) и U+031B (Combining Horn) — вот как с ними выглядит латинская буква «o», например: «ơ» и «o̕». Возможно одна из них через некоторое время станет казахской. Это в лучшем случае. В худшем там именно апостроф и окажется. Самый настоящий, из ASCII.

Непродолжительное время (в 1930-е) казахи пользовались вот таким алфавитом на базе латиницы. Сейчас пока что кириллицей. Прошу заметить, что ни там, ни там никакой похожей на апостроф диакритики нет. Т.е. сейчас апостроф у казахов в алфавите — определённо новодел. На его месте могло быть что угодно. Циркумфлекс например.

Дальше больше — можете посмотреть расширенную латиницу в Юникоде и убедиться в том, что и похожие на апостроф диакритики почти нигде не используются в формировании символов. И это, ёлки-палки, логично. Апостроф, хоть и встречается на письме, не особо-то предназначен для конструирования алфавита.

Теперь, собственно, вопрос: всё-таки почему и за что я так прикопался именно к апострофу? А вот именно потому, что его легко набирать. Даже если они сделают нормальный набор символов, и даже если оно попадёт в очередной стандарт Unicode, бухгалтера и юристы уже до этого успеют привыкнуть печатать апостроф и продолжат его печатать дальше.



Всё понятно?

Исходный пост тут, комментировать можно при помощи OpenID.
большой брат, система, IBM

Немного неглубокой старины. Задачка для старших школьников и младших студентов

Весна 2000 года. Я заканчиваю второй курс на Матмехе СПбГУ.

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

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

А в 2000-м у меня ни флешек, ни ADSL не было, а была пачка дискет на 1440 КиБ, отформатированных на 1600 КиБ. Вообще дискеты можно было хитроумным форматированием дожать и до 1720 КиБ с копейками, но тогда с ними или Windows NT 4, или FreeBSD 3 (не помню, кто из них, а может обе) отказывались работать.

Поездка в центр города и обратно на метро вместе с преписыванием дискет и параллельным хлебанием чая с синим слоном (в советском, а не доброчановском смысле, хотя второй наверное произошёл от первого), заняли у меня 2 часа. Я всё довольно точно оценил, и решил поступить именно так, потому что у меня был модем, который передавал данные с максимальной скоростью 14400 бит в секунду (да, внутренний USR Sportster на шине ISA).

А теперь внимание, задачка: в предположении, что на 10 дискет по 1600 КиБ скан конспекта влез впритык (это конечно было не так, но предположим):

  1. Какой минимальной должна была быть скорость наших с одногруппником факсмодемов, чтобы я решил не ехать с дискетами на метро, а соединиться по телефонной линии (допустим, одногруппник тоже был согласен надолго занять телефон =)) и хлебать чай у себя дома?

  2. Почему я упорно писал размер дискет в КиБ? В чём подвох? Почему я нестал писать 1,44 и 1,6 с другой единицей?

Комментарии скринятся (надеюсь =)).
линейка

Код. Тайный язык информатики.

Код. Тайный язык информатики.
Чарльз Петцольд. Код. Тайный язык информатики.

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

Русское издание в бумажном виде сейчас найти - проблема. Как вот это ISBN 5-7502-0159-7 в 2004 выпустили, так и всё. А жалко.
линейка

Бьюсь лбом

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

Тяжелее с другими, которые к компьютеру относятся нормально, но не хотят понимать, что программист должен быть продвинутым пользователем. А ведь это требуется, чтобы быстро врубаться во что-то новое.

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

Никак им не помог семестр, проведённый под Линуксом. Во-первых, Юникс-подобные системы сейчас уже достаточно дружественные, во-вторых даже от тех навыков, которые эти товарищи приобрели, они избавились с максимальной скоростью.

Боюсь, что следующим первокурсникам действительно потребуется выделить целый месяц на «обучение работе с ПК», а не два занятия (а по факту и столько не делают), как предлагается в программе.
линейка

Алгол 68 живее всех живых

Мне захотелось продолжить серию из трёх постов: (1) (2) (3).

Есть такой замечательный язык — Алгол 68. Он немного старше Си и Паскаля по возрасту, но при этом принципиально мощнее и гибче Паскаля, и строже, чем Си. Кстати, он и строже Паскаля, и мощнее Си, но уже не в той степени.

До конца 80-х в СПбГУ пользовались, в т.ч. и для обучения студентов, собственным транслятором Алгола 68 - А68ЛГУ. Сейчас студентов Алголу 68 не учат. Нынешнее обучение на Математико-механическом факультете (правда уже не поголовное, слава Богу) младших студентов программированию на Паскале по сравнению с этим явно сливает. Обучение на Алголе 68 привносило аутентичность, обучение же на Паскале (используя тот самый старый добрый Turbo Pascal 7, и, буквально пару последних лет, Free Pascal) – только отстойность. Практическая же польза в обоих случаях сравнима.

Сначала А68ЛГУ делали под ЕС ЭВМ, потом его портировали под PC, причём сначала на Правец, так что вычислительные аппетиты транслятора пришлось сильно уменьшить. Уже портированный на архитектуру PC он до сих пор используется на нескольких коммерческих предприятиях (ЗАО Ланит-Терком, ГУП Терком, ФГУП НПК «Красная заря» - та, которая до революции называлась Ericsson, кстати), в частности, для реализации функционального программного обеспечения АТС.

Описание Алгола 68 можно прочитать в Пересмотренном сообщении об Алголе 68 (ред. А. ван Вейнгаарден. Пер. с англ. — М., Мир, 1979—533 с.), и отпасть, либо в какой-нибудь более вменяемой для конечного пользователя книге, например, этой: Программирование на языке алгол 68 для начинающих — издательство ЛГУ, 1988 (кстати, полный список авторов — Н.Н. Вояковская, Н.Г. Графеева, М.В. Дмитриева, С.М. Селеджи, Т.А. Шубочкина, под редакцией чл.-кор. АН СССР С.С. Лаврова).
Если же вы допускаете чтение книг, которые не пахнут клопами, то можете либо поискать последнее указанное пособие в электронном виде, либо посмотреть ссылочки из статей Википедии.

Среди не очень примечательных особенностей языка можно отметить возможность задать произвольную точность, по крайней мере, для целых типов. Скажу сразу, что А68ЛГУ на PC такого не тянул. Удвоение точности в два раза (до определённых реализацией пределов) производилось путём приписывания модификатора LONG нужное количество раз.

Поскольку А68ЛГУ в доступной мне ипостаси не умеет считать и хранить данные с произвольной точностью, я пользовался интерпретирующим транслятором языка — Algol68G. Это очень неплохая реализация, кстати, и, в отличие от А68ЛГУ, вполне живая. И позволяет задавать произвольную точность. Для чисел с плавающей запятой, правда, LONG можно писать только два раза, а точность задавать уже из командной строки. В 100 десятичных знаков, например.

Ну, поехали.

(
 
LONG LONG REAL a := 1.0000001, b := a;
 
TO 27 DO
    a
:= a * a; b := b ** 2
  OD;
  print
((a, new line, b, new line, "www.leningrad.su/museum"))
)

Запускаем: a68g --file leningrad.a68 --precision 100

Получаем:

+6.745304707410845593826891780297468128444441434103420317423773278390177617568356469241850369483141171614489467913e +5
+6.7453047074108455938268917802974681284444414341034203174237732783901776175683564692418503694831411716144
94515622e +5
www.leningrad.su/museum

Обратите внимание, подсчёт таки идёт разными способами, но зато с какой точностью!

Кстати, лексические сущности языка, написанные здесь прописными буквами (т.н. индиканты, слабыми подобиями которых являются ключевые слова в других языках) в А68ЛГУ писались в произвольном регистре (обычно в нижнем), но выделялись точкой в начале. Это выглядело намного симпатичнее и эротичнее, с моей точки зрения.

UPD: точность в A68G, кстати, получилась выше 100 цифр. Фактически, длина мантиссы здесь задаётся не с точностью до знака или бита, а с определённым шагом. Точность меняется при прибавлении примерно 6 десятичных знаков. Значит шаг - 6 * log_2(10) ~ 20 битов. Скорее всего, 20.

линейка

Войны покемонов: PDP наносит ответный удар

В продолжение серии постов:
(II)
(I)

Эмулятор ДВК мне так и не удалось найти.

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

И получил на выходе:
Free Image Hosting at www.ImageShack.us
674530.47061203349
674530.47082311274
WWW.LENINGRAD.SU/MUSEUM

M$ QBasic 1.1 при подсчете выдал следующее (пользуясь типом float, насколько я предполагаю):
8850397       8850397      WWW.LENINGRAD.SU/MUSEUM
QBasic, пользуясь float, выдал одинаковую лажу. Раз она одинаковая, то, судя по всему, он оптимизирует возведение в целую степень.

Если QBasic использует double, то выдает всё правильно, так же, как и другие PC-средства. Так, например, программа на C (с функцией pow и типом dlouble) выдает на PC то же самое, что и программа на Питоне, даже если точность у обеих задрать до максимума. Это можно считать идеальным ответом. Уж программа на C - то точно ничего не мудрит и лишнего не делает.

Что сразу бросается в глаза, так это то, что под хранение чисел с плавающей запятой на БК памяти не пожалели.
БК уделала всех, включая даже и PC, если на PC использовать float.
Результат БК был настолько адекватен (8 правильных значащих цифр), что стебаться дальше неинтересно. Поэтому на нём мы и закончим.
линейка

Бейсик ДВК

Будучи не в силах бороться с напавшим на меня игривым настроением, я проверил-таки программку с картинки. По клику большая, встретилась в Статье про ДВК. Симулятор ДВК мне было искать лень, и я воспользовался Python и Haskell на PC.

Код на Python:
a = 1.0000001
b = a
for i in range(0,27): #range is non-inclusive
    a = a*a
    b = b**2
print a, b, "www.leningrad.su/museum"
Машина выдает:
674530.475522 674530.475522 www.leningrad.su/museum

Код на Haskell:
main = let
  ntimes f x n =  if n > 0 then ntimes f (f x)  (n-1) else x
  a = 1.0000001
  b = a
  (a', b') = ntimes (\ (a, b) -> (a*a, b**2)) (a, b) 27
 in do
  putStrLn ((show a') ++ "\t" ++ 
            (show b') ++
            "\twww.leningrad.su/museum")
Машина выдает (HUGS) ещё лучше (форматирование по умолчанию точнее):
674530.475521788    674530.475521789    www.leningrad.su/museum
Ага, в последнем знаке разница на 1, попался!!! :)
А при помощи GHC - разницы нет :) , тоже весело:
674530.4755217875   674530.4755217875   www.leningrad.su/museum

Для тех, кому картинку смотреть лень, ДВК выдала
568044    1202420    www.leningrad.su/museum


Т.е.:
  1. результаты отличаются более, чем в два раза;
  2. это при том, что с точностью до 10^-7 оно таки считает (LET A=1.0000001), а то и точнее;
  3. если они с плавающей запятой, то у первого дробная часть получилась равной 0, вероятность чего - 1/10 - ну это так, просто забавно;
  4. у PC оба результата между результатами ДВК :);
  5. да, и зайдите на http://www.leningrad.su/museum/.
Так-то вот. Это я к тому, что надо всё-таки ценить прогресс, уважаемые программисты. Иногда кажется, что он стоит на месте, ан нет, происходит всё-таки что-то...