Допустим докажет Вася, пусть даже технической победой в суде, что он ничего не разглашал. Или что вы не можете доказать его причастность к разглашению. А далее запросит по суду копии писем, отправленных в посольства, и засудит вас за defamation, false statements или еще что-нибудь подобное, в зависимости от опытности своих адвокатов. Ведь письма-то рассылались с очевидным умыслом нанести вред Васиной репутации. Он даже может сказать, что эти письма “сломали ему жизнь”. И что делалось это без постановления суда, установившего (юридически) хотя бы сам факт нарушения контракта,
Для бесплатных редакторов в web такой подход работает. Но… Все алгоритмы, которые добавляют синтетические точки пересечений с рассчитанными в числах координатами (на промежуточных стадиях вычислений) по большому счету ламерские. Если в сложной закрашенной фигуре при таком подходе сделать очень сильный zoom вблизи рассчитанной точки пересечения ребер, то мы сможем увидеть не закрашенные щели или прорисовку узких фрагментов одной фигуры поверх другой. Это происходит из-за того, что многие решения уравнений (особенно с кривыми Безье) нельзя представить числами с фиксированной (и сравнительно небольшой) разрядностью без потери точности. И эта потеря точности вылезает наружу при сильных zoom-ах. Чтобы победить это, нужно откладывать все вычисления точных координат промежуточных точек до самого последнего этапа, когда будет делаться окончательная отрисовка (растеризация в пикселы). Но тогда промежуточные вычисления и анализ становятся намного более сложными — придется применять ряд подходов, которые используются в системах машинной математики. Например — рациональные числа вместо float, операции над векторами или кватернионы, и т.п. Просто решения через вычисления в float уравнений из школьной алгебры и геометрии будут давать артефакты при сильных zoom-ах (видимые даже в браузерах типа IE при загрузке в них SVG полученных через такие промежуточные вычисления).
На счет США можно не переживать — там разрешена продажа оружия, поэтому узурпация власти какой-то хунтой крайне маловероятна. Если власти начнут выключать телефоны на митингах люди возьмут свое оружие и к Белому Дому придут сотни тысяч вооруженных людей. И тогда гипотетическую засевшую там хунту не защитит никакая спецслужба — охранка попросту разбежится или перейдет на сторону народа, как уже бывало в истории в других странах. Поэтому удаленное выключение телефона не представляет собой угрозу для демократии. И как уже сказали выше отключить всю связь можно и через оператора.
Самый главный критерии для сравнения таких сервисов — это среднее время доставки сообщения и надежность доставки. Остальное — как-то решаемо. К сожалению Вы ничего не пишите в сравнении о времени доставки и ее надежности.
Забыли так же про Netmeeting — H.323 коммуникатор Windows 95/98/NT/2000, который с 1996 года входил в комплект ОС (в дистрибутивах до 2001 года как минимум) и имел достаточно много пользователей успешно конкурируя с VocalTec.
Введут таможенные сборы/налог на покупку физических товаров из-за границы. Для примера аналогичные меры предприняты в ряде европейских стран (при покупках товаров из-за пределов ЕС если за них не уплачен НДС). Причем эту меру поддержат и крупные российские интернет-магазины, чтобы избавится от конкуренции с eBay и иностранными магазинами. IMHO.
Отдельным пунктом хочу отметить поиск. Вы не поверите, но первые 3 дня по точному названию приложения его найти было просто невозможно. Оно не входило в те 500 (или около того) приложений, которые находил Google Play.
А можно ли избежать этой проблемы, если начать рекламировать приложение только спустя три дня после размещения в google play? Или если в первые дни не будет закачек это понизит рейтинг?
1.005 это бесконечная периодическая дробь в двоичной системе счисления, примерно равная 1.004999995 при обратном переводе из float. Соответственно после умножения на 1000 получается 1004.999995. По стандарту преобразование к целым отбрасывает дробную часть и мы получаем 1004. Так что ничего удивительного. Скорее уж необычно то, что SSE дает 1005 — но и это можно понять — видимо у GCC счет идет с двойной точностью и срабатывают чуть-чуть другие правила округления при неточном результате, из-за чего получается 1005 — так как при двойной точности округленное значение 1.005 = 1.0049999999999999.
Это смотря у кого – у самых требовательных к быстродействию систем данные лежат в оперативной памяти (и даже не в кэшах, а прямо доступны по указателям). А драйверы сетевой карты так написаны, что берут данные непосредственно с пользовательских страниц без промежуточного буфера. Так вот оказывается, что при формировании буферов с данными для отсылки генерация тысяч вставок содержащих очередные счетчики чего-либо, денежные суммы и т.п. занимает достаточно большое время и есть смысл оптимизировать процедуры конверсии – можно выиграть процентов 5-10 времени. А если бы в машине была бы встроенная BCD-арифметика, то можно было бы не перекодировать эти числа вообще. Потому, что в подавляющем большинстве случаев в реальном времени с этими данными не делается никакой содержательной работы, кроме прибавления/вычитания единицы (или денежной суммы взятой из очередной транзакции) и конверсий туда-сюда.
Безусловно Вы правы если говорить о чистых вычислениях. Но давайте сравним что будет быстрее — прочитать число из текстовой строки (условно — из каких-нибудь XML-данных) перекодируя его в binary, прибавить к нему единицу и перекодировать обратно в текст — или же сделать все тоже самое в BCD, заморачиваясь только (опционально) паковкой и распаковкой.
Это при отображении пользователю. Но на сервере преобразование чисел в тексты, например, перед отправкой HTML или (особенно) XML занимает настолько большое время, что эту процедуру специально оптимизируют, в частности, давно разработаны и используются алгоритмы для преобразования binary -> decimal не содержащие во внутреннем цикле даже команды умножения.
В основном — не связано. Просто новые технологии, как в железе (что всем понятно), так и в софте (что менее очевидно и не всегда это так) сначала, сразу после изобретения, стоят очень дорого. Но постепенно затраты на их изначальную разработку окупаются, а уровень развития технологий в целом делает более дешевым массовое производство или возникает необходимость в массовом использовании (если мы говорим о софте) и технологии находят применение на массовом рынке уже по приемлемой цене. Хотя бывает, конечно, что технология сразу отлично подходит и для массового рынка.
Да, но регистры уже почти 20 лет 32-битные даже под Windows. Поэтому эти команды утеряли актуальность примерно два десятилетия назад. И их выполнение всегда занимало несколько тактов, а данные нужно было грузить в AL, поэтому я не уверен, что даже на 8086 они были выгоднее своей software эмуляции.
Для сравнения на IBM/370 можно было сложить, вычесть, умножить или поделить (!) два десятичных 31-разрядных (16-байтовых, речь идет о десятичных разрядах) числа одной машинной командой.
Это верно только для сложения и вычитания, но так же нужно заметить, что организация цикла по байтам была уже менее эффективной, чем софтверная реализация без процессорных команд.
Правда состоит в том, что они оказались у Вас на столе как раз именно потому, что отдел маркетинга в IBM так решил. :) Уже давно компании типа IBM, MS и т.п. создают новые, а не обслуживают имеющиеся потребности людей. Хотя вторым они тоже занимаются, но уже во вторую очередь или как косвенный результат основной инновационной деятельности. Именно эта магия — умение создавать новые потребности — позволяет компании заработать миллиарды (а не миллионы).
BCD-числа по-прежнему актуальны в SQL (стандартные типы данных CURRENCY и DECIMAL это BCD, INTEGER с заданным числом цифр часто тоже реализуют через BCD, если заданная разрядность превышает разрядность платформы).
Операции над BCD в x86 поддерживали двухзначные числа — поэтому на практике были бесполезными, и работу с нормальными BCD-числами приходилось делать используя длинный (и крайне нетривиальный для понимания другими людьми) код.
Фактически они (двоично-десятичные числа) никогда не поддерживались. Для работы с ними существовали четыре унаследованные и фактически бесполезные команды, применимость которых была ограничена двухзначными (!) числами. Именно поэтому на практике они практически никогда не использовались и их убрали в современной архитектуре. Поддержка BCD актуальна для SQL и для работы с финансовыми данными, но из-за отсутствия поддержки в железе ее реализуют софтверно.
Для сравнения на IBM/370 можно было сложить, вычесть, умножить или поделить (!) два десятичных 31-разрядных (16-байтовых, речь идет о десятичных разрядах) числа одной машинной командой.