Яндекс.Метрика

Программирование

Программирование

Нарекания к юзабилити QiP 2012

Первого дня опробовал клиент QiP 2012 Версия: 4.0 Build 7102 от 13.01.2012
Он меня несколько разочаровал. Я думал, лучше будет это всё.

  1. Я пишу сообщение из нескольких строк, зажимаю/нажимаю несколько раз вверх и... Нет, я не попадаю на верхнюю строку как должен бы был, У МЕНЯ МЕНЯЕТСЯ СООБЩЕНИЕ НА ПРЕДЫДУЩЕЕ. Вы с дубу рухнули что ли?! Я потерял сообщение, которое писал! Изменение сообщений действительно удобно, но оно должно работать через Ctrl+Arrow, а не просто стрелками. Один из ваших разработчиков сказал, что это как в Скайпе. Хуй-то там, я проверил, в Скайпе такого говна нет. И не смейте мне говорить, что я просто должен быть осторожен. Я не должен быть осторожен, я должен делать нужные мне вещи максимально быстро и удобно. Представьте, что вы держите в руках перфоратор, на боку у которого тумблер с семью степенями свободы. Первая степень — дерево, последняя — бетон. Вы переключаете с бетона на дерево. Вы действительно будете считать сколько раз вы повернули тумблер или вы просто резко рубанёте его до упора? Вот именно, рубанёте до упора. И ТУТ ВАШ ПЕРФОРАТОР НА ХУЙ ВЗРЫВАЕТСЯ, ПОТОМУ ЧТО ПРИ ВЫХОДЕ ЗА ВАЛИДНЫЕ ПРЕДЕЛЫ В НЁМ СРАБАТЫВАЕТ ДЕТОНАТОР, ПРИКРЕПЛЁННЫЙ К ЛИТРУ НИТРОГЛИЦЕРИНА. КРОВЬ, КИШКИ, СТЕНУ РАЗОРВАЛО, ПЛАЧУЩИЕ ДЕТИ, ОСТАВШИЕСЯ БЕЗ ОТЦА. Так вот, ваш клиент выглядит именно так.
  2. Вы не хотите сделать в опциях галочку "разделять контакты по аккаунтам"? Меня несколько нервирует тот факт, что я не знаю с какого из трёх жаббер-аккаунтов я пишу
  3. via #1744630 Лично желаю рака яиц тому, из-за кого я хистори с полученными файлами проебал. Такого я не ожидал даже от анального Apple. Это как если бы установленный официальный ICQ удалял ваши клиенты.

    Программирование

    Скрипт для PlanetLab. Удаление и добаление Nodes

    Так как недавно пришлось вникать в тонкости пользования PlanetLab, я решила поделиться примером скрипта на автоматическое добавление-удаление нодов. Возможно, это в будущем сократит кому-нибудь время.

    image

    Опишу вкратце, о чем идет речь. PlanetLab – это сеть, широко используемая для тестирования новых сетевых сервисов или модификации уже существующих. Узлы PlanetLab (их около 1024-х) распределены в различных странах и доступ к ним получают только сотрудники тех учреждений, которые содержат у себя узлы PlanetLab. Более подробная статья о PlanetLab есть здесь.

    Если вы занимаетесь разработкой распределенных приложений, без PlanetLab обойтись будет сложно. При тестировании распределенного приложения, Вам скорее всего придется иметь дело с большим количеством узлов (Nodes). Проблема состоит в том, что в PlanetLab ноды часто уходят в оффлайн. Соответственно, эти ноды нужно удалить из своего аккаунта (slice) и подключить взамен них новые. Это, безусловно, возможно сделать и через веб-интерфейс руками. Однако, процесс это муторный, поэтому луче всего использовать скрипт. Таким скриптом я и хочу в Вами поделиться. Написан он на питоне.

    Описение всех методов API PlanetLab можно найти по адресу www.planet-lab.eu/doc/api. Сам скрипт постаралась снабдить достаточным колчеством комментариев, чтобы было понятно что происходит.

    #!/usr/bin/env python

    import xmlrpclib
    import sys
    plc_host = 'www.planet-lab.eu'
    auth =
    { 'AuthMethod': 'gpg',
    'name': 'your user name',
    'signature': 'GnuPG signature',


    slice_name = 'tudresdenple_backup'

    api_url = «%s:443/PLCAPI/»%plc_host
    #api_url = «%s/PLCAPI/»%plc_host

    plc_api = xmlrpclib.ServerProxy(api_url,allow_none=True)

    #get list of all nodes
    print «Getting list of all attached to your slice nodes:»
    nodes = plc_api.GetNodes(auth, {}, ['node_id', 'hostname', 'boot_state'])

    #get ids of the nodes that already are added to you slice
    attached_nodes_ids = plc_api.GetSlices(auth, [ slice_name ], ['node_ids'])[0]['node_ids']
    #obtain nodes hostnames, which will look like {'hostname': ''}
    attached_nodes = plc_api.GetNodes(auth, attached_nodes_ids, ['hostname', 'boot_state'])

    #extract hostname only
    have_nodes = []

    for node in attached_nodes:
    have_nodes.append(node['hostname'])

    for node in have_nodes:
    print node

    #Filter all your nodes that are not in the boot state and therefor have to be deleted
    print «Searching for non-boot nodes attached to you slice:»
    to_delete = []

    for node_record in attached_nodes:
    if node_record['boot_state'] != 'boot':
    to_delete.append(node_record['hostname'])

    for node_record in to_delete:
    print node_record
    #delete those nodes

    num_of_deleted = len(to_delete)

    if num_of_deleted > 0:
    success = plc_api.DeleteSliceFromNodes(auth, slice_name, to_delete)
    if success == 1:
    print «Successfullly detached non-booted nodes»
    else:
    print «Deleting of the non-booted nodes has failed!»
    sys.exit()
    else:
    print «Nothing to delete or add»
    sys.exit()

    #add exactly the same number of new now, as the number of deleted ones
    print «Adding new booted nodes»
    to_add = []

    for node_record in nodes:
    if num_of_deleted > 0:
    num_of_deleted -= num_of_deleted
    else:
    break
    if (node_record['hostname'] not in have_nodes) and node_record['boot_state'] == 'boot':
    to_add.append( node_record['hostname'] )

    if len(to_add) > 0:
    success = plc_api.AddSliceToNodes(auth, slice_name, to_add)
    if success == 1:
    print «Successfullly attached new nbooted nodes»
    else:
    print «Addint of the booted nodes has failed!»
    sys.exit()

    print «The following nodes were added:»
    for node_record in to_add:
    print node_record

    Программирование

    Ошибки вычислений в окрестностях машинного нуля

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

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

    Если отбросить физическую суть, то задача состоит в необходимости решения системы семи уравнений в частных производных. Сказано-сделано, сложности в этом особой нет — пишем явную конечно-разностную схему, распараллеливаем на OpenMP и после окончательной синтаксической отладки и оптимизации скорости «машинка начинает шуршать».

    Вычислительная конфигурация: видавший виды HP 550 с Core 2 Duo 1.8 ГГц на борту, под управлением Ubuntu 11.04.

    Компиляторы: gfortran 4.5.2 и Intel Fortran Compiler 12.1.0.

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

    Итак, воды в области нет. Что же хочется написать в начальном условии? Естественно, сразу же было написано 0.0D+00 (программа написана с двойной точностью вещественных чисел). Счёт на первоначальных этапах идёт в непосредственной окрестности машинного нуля. Каковы результаты? Посмотрим на график:

    Ноль

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

    Нужное отступление о подписях в легенде графика: всего было опробовано 18 различных комбинаций ключей (6 для gfortran и 12 для ifort), однако многие из них давали абсолютно одинаковые результаты, и потому объединены. Квадратные скобки в легенде означают, что могла быть написана любая из заключённых в них опций. Например, «шифровка» -O[1,2,3] [-fp-model [strict] [precise]] говорит о том, что компилятор использовался с оптимизацией всех возможных уровней, и дополнительно могла быть включена одна моделей вычислений с плавающей точкой (а могла быть и не включена). Три варианта (два от -fp-model и один без неё) умножить на три уровня оптимизации — итого девять комбинаций. Все они оказались эквивалентны.

    А теперь результат. Нечто реалистичное и физически возможное удалось получить только на gfortran без включения соответствия стандарту IEEE 754 (ключ -ffloat-store). Весь остальной хаос линий не содержит ни капельки физического смысла, потому что даже математически уравнения этого не допускают. Изначально подозревавшаяся неустойчивость разностной схемы была оправдана, поскольку никакие методы борьбы с ней к успеху не привели.

    Было замечено, что при наличии воды в начальный момент счёт остаётся устойчивым и различия между опциями и компиляторами скрываются в окрестности шестой значащей цифры. И т.к. характерные порядки величины, судя по полученным графикам, должны быть в районе 1.0e-2, то в начальное условие было вписано некоторое ненулевое значение, но очень маленькое. Подбором удалось установить, что для 8-байтового real оно должно быть не менее 1.0e-21. И тогда:

    Почти ноль

    Да, здесь, как и написано в легенде, на самом деле пять графиков. Просто мы получаем то самое различие в пределах шестой значащей цифры.

    Причины? Вполне очевидны. Они лежат в тонкостях одновременной обработки больших и малых чисел. И тот факт, что явление настолько существенно по своим масштабам, был, в общем-то, ожидаемым. Но, прежде всего, интерес вызывает нестабильность работы действительно отличного инструмента от Intel на фоне относительного успеха gfortran 4.5.2. Стоит отметить, что подобные проблемы были также найдены при расчётах на старой версии gfortran 4.1.2 с включённой оптимизацией и без других опций, установленной на доступном кластере (под управлением Slamd64), однако им тогда не было уделено должного внимания.

    Соответствие IEEE 754, как ни странно, сыграло критическую роль для gfortran. Без него счёт достаточно стабильный и точный. Для детища Intel это оказалось не столь существенно, ибо оно и так не работало корректно.

    Итак, выводы и мысли о причинах увиденного.

    • Наиболее вероятным кандидатом на роль причины наблюдаемого поведения расчётов представляются тонкости округления чисел. Т.к. в начальном распределении величины задано нулевое значение, то на первых шагах счёт производится практически на границе машинной точности. Соответственно, это приводит к накоплению заметных погрешностей, которые и проявляются в конечном результате.
    • Потери точности в алгоритме вызываются, очевидно, и тем фактом, что решается размерная система семи дифференциальных уравнений в частных производных, переменные в каждом из которых имеют собственные характерные значения, существенно отличающиеся от остальных. При правильном выборе масштабных множителей, в безразмерной системе уравнений получить близкие хотя бы по порядку величины значения всех переменных, хотя при первоначальных попытках провести обезразмеривание в системе возникали малые коэффициенты перед производными, что и стало поводом для отказа от данной процедуры.
    • Вопрос же о том, почему gfortran, не соответствующий стандарту вычислений с плавающей точкой, способен выдавать приемлемый результат, остаётся открытым. Разумно предполагать наличие каких-то собственных, отличных от стандарта, правил округления, которые и обеспечивают сохранение стабильного счёта, а также их корректировку и уточнение в процессе развития компилятора. «Хрупкий баланс ошибок» либо продуманное исправление подхода? Увы, на моём уровне знаний об инструментарии, нацеленном в первую очередь именно на применение компиляторов, а не их тестирование и изучение свойств, это неизвестно. Но заставляет задуматься и вспомнить предостережения о возможных потерях точности в тех или иных местах программ, данные ещё на первых этапах обучения численным методам в вузе.


    Тестирование компиляторов на соответствие IEEE 754 проводилось с помощью FORTRAN-версии «Floating point paranoia» Уильяма Кэхэна.

    Программирование

    Занимались ли Вы олимпиадным программированием? Пригодился ли Вам опыт?

    Проголосовало 365 человек. Воздержалось 74 человека.

    Программирование

    Я считаю, что графический интерфейс IDE должен быть …

    10.08%
    (73)
    с туевой хучей полностью настраиваемых/перемещаемых окошек, панелей + расширяемый миллионом плагинов, способных изменить интерфейс до неузнаваемости (a la Eclipse etc.)
    18.65%
    (135)
    чуть более строгим, нежели предыдущий вариант: главная область с редактором + панели по бокам (IntelliJ IDEA и иже с ней)
    9.94%
    (72)
    в меру минималистисткий (в духе Qt Creator, например, или… кхм… Small Basic :))
    8.43%
    (61)
    ээээ… IDE не нужна — хватит мощного текстового редактора (Emacs, vim, Notepad++, TextMate)
    7.18%
    (52)
    строгим и консервативным (минимум графических элементов — концентрация на тексте)
    5.52%
    (40)
    с красивостями (иконки, анимация действий и т.п.)
    7.6%
    (55)
    ориентирован на управление мышью
    23.34%
    (169)
    управляемым с помощью горячих клавиш
    9.25%
    (67)
    управляемым с помощью ввода команд (встроенная консолька)

    Проголосовало 283 человека. Воздержался 41 человек.