А как же оно тикает?
11,299,746 15,067
 

  slavae ( Слушатель )
09 авг 2015 12:59:11

Тред №981101

новая дискуссия Дискуссия  715

На военной ветке дали ссылку на новый тип суперкомпьютеров, которые сделаны на ПЛИС.
http://sdelanounas.ru/blogs/65962/

Для сравнения: суперкомпьютер «Ломоносов» (использует процессоры Xeon X5570/X5670/E5630 2.93/2.53 GHz и в качестве спецвычислителей Nvidia 2070 GPU, PowerXCell 8i) потребляет около 3 мегаВатт электроэнергии, занимает 250 кв.метров площади. Эта же система — одностоечная, занимает чуть больше 1 кв.метра площадь и потребляет всего 50 кВт электроэнергии, а по производительности они практически эквивалентны, если не считать, что здесь используется фиксированная запятая.



Цитата: ЦитатаПолный расчёт с оптимизацией двигателя самолёта на суперкомпьютере Ломоносов, который построен на процессорах Intel и использует графические ускорители NVidia, занимает 7 лет (что обошлось бы в 800 миллионов рублей). Аналогичная по энергетической мощности отечественная система Плеяда потратит на эту задачу в 60 раз меньше времени, т. е. 43 дня! И обойдётся это в 14 миллионов рублей. А аналогичная по потребляемой энергии вычислительная система Скат-8, которую планируют построить в 2016 году, могла бы выполнить эту задачу за 3,5 дня!!! И обошлось бы это в 1 миллион рублей.
Отредактировано: slavae - 09 авг 2015 13:04:06
  • +0.06 / 5
  • АУ
ОТВЕТЫ (38)
 
 
  Longspig ( Слушатель )
09 авг 2015 22:37:20

Вот это уже сильно "напрягает". Сравнивать  производительность во Флопс'ах вообще некорректно - они от конкретных  Float Point  должны считаться.  Круг задач со скромным динамическим дапазоном для, пусть, многоразрядных Fixed Point все же куда уже, чем для Float. А уж в моделировании тех же газотурбинных "девайсов" на фиксированой точке дуже быстро погрешность набегать начнет и что там в результат попадет...
  • -0.01 / 1
  • АУ
 
 
  slavae ( Слушатель )
09 авг 2015 23:43:50

Сначала прочитайте статью и комменты.
Это специализированные компьютеры, заточенные под решение одной задачи.
Поскольку задача известна, то и порядки величин примерно известны.
Думаю, там не самые дурни с 2002 года впахивают.
  • +0.02 / 2
  • АУ
 
 
 
  l-mik ( Слушатель )
10 авг 2015 14:51:20

Статья не оставляет впечатления какого-то прорыва, а скорее надежды на прорыв. 
Для выч средств до 10тфлоп, их решение однозначно хуже классических - по энергопотреблению и стоимости на порядок.
Для суперкомпьютеров в районе петафлопса они лучше по энергии, но по производительности - их производительность 'виртуальная' - они сравнивают свое железо при 60% нагрузки с конкурентами при загрузке 5%. Аргументируют это тем, что среднестатистическая домохозяйка не выжмет из обычного суперкомпьютера больше 5%
  • -0.02 / 2
  • АУ
 
 
 
 
  stranger1234 ( Слушатель )
12 авг 2015 02:52:58

Ускорители на fpga для пакетов с псевдоразряженными матрицами мною были видены еще 8 лет назад, пото пошли вычисления на карточках графических....прорывом и близко не пахнет- вариант аналогвых компов- быстро, но не универсально...да еще и людей нужно учить работать на реконфигурируемом железе
  • 0.00 / 2
  • АУ
 
 
 
  Longspig ( Слушатель )
10 авг 2015 22:23:12

Думается к упомянутым по ссылке Оук-Риджской национальной лаборатории и Ливерморской лаборатории это равно относится.

Впрочем, прикинул на пальцах... действительно эффект от  ухода на "конечный автомат" с фиксированой точкой вполне может быть. Если брать стандартную мантиссу FPU386 64 разряда, то доведя фиксированую разрядность к слову до 256, получим избыточность 192 старших разряда на которые ставим контроль "все по нулям/все еденицы" (что на ПЛИС нетрудно) и пускаем тестовую задачу. Если контроль не дает "ухода за край диапазона",  то задача обсчитана в пределах точности не уступающей FPU. А те же Xeon с их 130 Ватт на кристалл штука во многом для этих целей дурная, бо всякие набитые туда Интелом для развлекухи MMX/SSE* жрущими площадь кристалла и энергию там нужны как  зайцу...(легкая венерическая болезнь).
Вот, правда, с умножением (а наипаче делением) на 256 разрядов... в ПЛИС кажется будет похуже,  т.е.. сделать-то можно..., но 64-битному FPU386 проиграем очевидно.

Только вот нафига телескопу атмосферные искажения корректировать в реалтайме, так и не понял. Записал массив, а потом обсчитал тихой сапой на каком-нибудь "обычном Пентиуме-*", главное не под Виндой, а в системе и с софтом так же "персонально" подготовлеными под конкретную задачу (тогда окажется можно и на "обычном" нехило выиграть). В Винде/Линуксах одно только страничное преобразование ополовинивает скорость работы с некешированой памятью, а она там и так хуже некуда. (делал замеры когда-то. На SDRAM133 получалось всего 3МГц.... давно было...).

Гы. Конец 90-х. Сотрудник попросил как-то помочь. Понадобилось ему BMP картинку повернуть на 90град, а "фотожопов" тогда еще не знали. Писал он бухгалтерские программы на FoxPro. Ну, да, взял описание формата. Написал. Картинка не особо-то большая "поворачивалась"... 6 часов. Я, ради забавы, то же на Ассемблере... ну да нажатие Enter и результат практически совпадали... Было бы весело, если бы не было так грустно - современная довольно дорогая программа, которой я зарабатываю на кусок хлеба повторяет сейчас этот же эффект до мелочей. Т.е. я результат жду 8 часов. Но, то же самое делаю в ДОС за секунды дремучим бинарным редактором (с неблагозвучным названием). Увы, некоторые моменты, из-за закрытого формата, им не сделать. Приходится тупо ждать... 
  • +0.03 / 3
  • АУ
 
 
 
 
  Superwad ( Слушатель )
17 авг 2015 13:07:39

Ну проблема с накапливающейся погрешностью не такая уж простая на первый взгляд. да и может серьезно влиять в повседневной жизни. Вот один из примеров - промахи ракет "Пэтриот". Оказалось из-з постоянного преобразования одних цифирь с плавающей точной в другие набегали такие потери, что ракета прото напросто промахивалась.
а второй пример был - лондонская биржа вынуждена была по той же причине переписать софт и перейти на рассчеты в целочисленных величинах (правда как они обрабатывают дробную часть х/з - но очень интересно было бы).
Да большая часть современных проем - это отсутствие желания оптимизировать время работы программ и нежелание "крутых" программеров признать ущербность с/с++ и выкинуть его на свалку истории. написав более приемлемые и качественный инструментарий. Всё это из-за пресловутого потреблятства, пришедшего с Запада.
Пример качественной оптимизации при недостатке ресурсов и высоким уровнем решения поставленных задач - это проект бортовой системы "Буран".
  • -0.01 / 3
  • АУ
 
 
 
 
 
  Alexxey ( Слушатель )
17 авг 2015 15:18:24

Как правило - проблема убер-крутых программистов, не умеющих округлять например. "Вась, представь, что у тебя есть тыща рублей... Ну, или для круглого счёта 1024." Веселый
А так-то оно да-а-а, мировая закулиса ущербный с/с++ всему виной: копит погрешности втихаря, а власти скрывают.
  • +0.02 / 2
  • АУ
 
 
 
 
 
  stranger1234 ( Слушатель )
19 авг 2015 02:30:08

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

Да большая часть современных проем - это отсутствие желания оптимизировать время работы программ и нежелание "крутых" программеров признать ущербность с/с++ и выкинуть его на свалку истории. написав более приемлемые и качественный инструментарий. Всё это из-за пресловутого потреблятства, пришедшего с Запада.
Пример качественной оптимизации при недостатке ресурсов и высоким уровнем решения поставленных задач - это проект бортовой системы "Буран".
  • +0.01 / 1
  • АУ
 
 
 
 
 
 
  Superwad ( Слушатель )
19 авг 2015 08:51:47

Транзакции идут и в дробной части. Когда контора маленькая и транзакций немного - это не проблема. А когда транзакций становится очень много - накопленная ошибка очень неприятная штука. Да и скорость обработки меньше, чем у целочисленных. Вот потому и Лондонскую систему переделали (она периодически падала). Как сейчас не знаю.Думающий
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
  Alexxey ( Слушатель )
19 авг 2015 17:10:39

Откуда берётся накопленная ошибка?
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
  rommel.lst ( Слушатель )
19 авг 2015 17:47:55

Нет там никакой накопленной  ошибки. Усреднения бывают как в плюс, так и в минус, потому при большом количестве транзакций баланс будет сходиться всегда к точной величине плюс хвост порядка порога округления. Т.е. считанные копейки там будут все время болтаться. 
  • +0.01 / 1
  • АУ
 
 
 
 
 
 
 
 
 
  Alexxey ( Слушатель )
19 авг 2015 17:55:44

Superwad утверждает, что есть. Аж целую биржу вон переделали. Вот мне и интересно - откуда?
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
  Удаленный пользователь
19 авг 2015 21:09:26

Видимо, пользовались не теми правилами округления. "Округлением к большему", к примеру.
Второй источник ошибки - округление половинного промежутка.
Вообще, если я правильно помню, нулевое математическое ожидание погрешности округления даёт метод случайного округления - вероятность округления к большему по модулю равна отбрасываемой дробной части, приведённой к 1... Или же метод "округление к ближайшему целому + округление 0,5 к ближайшему чётному (банковское)". Остальные методы дают ненулевое математическое ожидание погрешности.
  • +0.01 / 1
  • АУ
 
 
 
 
 
 
 
 
 
 
 
  rommel.lst ( Слушатель )
19 авг 2015 21:31:00

Дык, это просто кривое программирование, которое не завист от того на чем пишешь. А то начали тут Си - говно, Си - говноУлыбающийся
  • +0.01 / 1
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
  Longspig ( Слушатель )
19 авг 2015 22:19:45

"С"-шником, увы,  я так и не стал, хоть и пытался. Но вот не помню я там возможностей менять тип "округления" для чисел с плавающей точкой. У собствено FPU386 там 4 типа округления. К максимальному целому, к минимальному целому, к нулю, и к "ближайшему".
На Ассемблере же я очень "вкусно" работал с 64-битной целочисленой арифметикой на FPU, даром что там готовые команды преобразования 64-битных целых в "плавающие" и наоборот. Кстати, манипуляции с типом округления, помнится, были очень актуальны. Было это примерно в 2000-м и о 64-битных целочисленых процессорах "для домохозяек" тогда даже не заикались. Тогда от безысходности получить 32-битную реалтаймовую  машину с монополизацией всех ресурсов под пользовательскую задачу (что под Виндой невозможно по определению) даже начал писать собственый 32-битный ДОС (проект автоматически "сдох" когда пришло понимание отчего Микрософт монополист - "закрытая" картельным сговором  аппаратная часть для графики, звука и многого другого). Впрочем свои дисковые драйвера написать таки удалось. Кажется это единственая в истории (хоть и незавершеная) ОС у которой отладчик был встроен в ядро системы. Причем дизассемблирующий "на лету". Даже выкладывал ее тогда в Инет, но вскоре у моего провайдера "сдох" сервер с "клиентскими" сайтами, а восстанавливать было уже малоактуально.
Ее  тогда я таки смог "пристроить" к одному полезному делу. Нужно было сделать захват видеосигнала с прогрессивной разверткой. А единственый доступный чип видеозахвата Connexant Bt848/878 был аппаратно завязан на чресстрочный телевизионный сигнал. Я даже драйвера не стал писать. Прямо воткнул в тело программы работу с регистрами контроллера. И он прекрасно "сожрал" прогрессивный сигнал. Получилось "дешево и сердито".
  • +0.01 / 1
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
  Alexxey ( Слушатель )
19 авг 2015 22:31:32

И что? Из-за того, что нет встроенной функции для того или иного типа округления, оно становится невозможным что ли? Шокированный
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
  rommel.lst ( Слушатель )
19 авг 2015 22:57:53




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

Вы на чем свою "ось" писали? Прямо на асме?
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  Longspig ( Слушатель )
21 авг 2015 12:55:00

Да. В основном на переделаном под ДОС (неким доброжелателем) TASM_5.3 от Винды. Но сборка под Flat модель памяти вышла редким извращением (с задействованием линкеров от Watcom C, а затем PharLap). Вся "система" получилась одним файлом 41кб!!! (включая удаляемый из памяти загрузчик-инициализатор и встроеный отладчик с дизассемблером). Стартовала из под ДОС и в него же возвращалась (закидывая его в последний мегабайт памяти).
Глянуть под ДОС бы легко, но одна засада. ДОС перехватывает прерывания на себя, а ОС они нужны "нетронутые" как их формирует BIOS. Потому нужны пляски с бубном флоппом, для формирования файла области прерываний той, которая до старта ДОС. Ну кого сейчас флопп рабочий сохранился, и живые дискеты.... (у меня - Да!).
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  rommel.lst ( Слушатель )
21 авг 2015 13:36:47

Сейчас загрузку можно запросто организовать и с флешки или СD - БИОСы пошли умные.  
Кстати, а как насчет линуксов? Там же вроде можно любую модель памяти выстроить, скомпилив под любое железо. И средства разработки есть любые.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  Longspig ( Слушатель )
22 авг 2015 00:49:31

Проблема не в загрузке. Старт с любого носителя - легко. Только смысла нет, поддержки файловых систем там еще небыло и загрузить пользовательскую задачу было - никак. Потому старт с ДОС и возврат в него же. Работа с файлами примитивна. В любой ФС создаем файл нужного размера (желательно нефрагментированый) и берем его физический адрес на диске. По этому адресу и работаем. Для редких задач достаточно и... невероятно быстро (никакой обработки структур ФС). А флопп был нужен для другого. В него вписывался загрузчик. Комп стартовал с флоппа и зависал. Загрузчик на этот же флопп вписывал в 3 сектора первые 1536 байт памяти с прерываниями и параметрами BIOS. Потом эти сектора извлекались в файл. Он брался при старте задачи и подменял начало памяти на доДОСовское. Сделать это можно и на HDD, но его дергать из компа на другой (для считывания) хлопотней чем флопп. С флешкой вроде должно тоже сработать.

Линукса... Конечно рассматривал. Но! Начал я вообще-то с Watcom C. (тогда и пытался его освоить). Но меня ждало разочарование. Его DOS-Extender закидывал пользовательскую задачу в низшее 3-е кольцо привелегий, со всем его ограничениями. Спрашивается - нафига! Мне надо было получить доступ ко всей адресуемой памяти (включая видео буфер LFB) и напрямую работать с портами ВВ. Возможно это как-то и делалось, но документации по этим функциям не нашел.

Разобрать Линукс под компиляцию своего ядра, "начинающему С-шнику" как то светило мало (Паскалист я по жизни, ну да Ассемблер с микроконтроллеров неплохо знал). Да и не уверен, что смог бы перестроить ядро Линукса под работу в нулевом кольце. А тут попался самопальный DOS-Extender 93-года от Tom Pytel  (он еще писал потом движки для игр) в исходниках, вот с него и начал. Потом выяснилось, что без отладки ничего не сделать. ну и пошло-поехало. Пока не "уперся" в графику. Акселерация была наглухо закрыта даже примитивная (надо-то было всего фукнции переноса прямоугольных областей, типа BitBLT и рисование линий). Стандарт VBE AF так и не был воплощен в жизнь. Добили меня тогда исходники Linux с которых пытался хоть что-то накопать. Помню, как сейчас. OpenSUSE 10.2 читаю исходник драйвера под видеоадаптеры ATI.  Там коммент - "Драйвер написан на основании документации 1998 года на ATI Rage 128, единственой  которую удалось найти". И это в 2006 году! Да! Потом, IBM выкупив ATI открыла документацию аппаратного уровня. Но к тому времени это уже было не нужно. Мавр сделал свое дело...
  • +0.01 / 1
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  Superwad ( Слушатель )
24 авг 2015 11:56:23

Сильно не копал. Но. Раньше были отдельные дистрибутивы с Real-time ядром на Линуксе. Сейчас вроде это встроено в ядро как один из режимов. У нас даже станок на Линуксе работает (Сименсовская спец.сборка) - на нее заведено все, т.е. не управляющая - а управляюще-исполнительная.
Но в Линуксе реализовано т.н. "мягкая" Real-Time.
ЗЫ. C и C++ - это зло. которое надо выкорчевывать - медленно и выжигать, так как нормально отлаживать в нем - ещё тот гемор, а разбираться в чужом С коде (а если ещё и без комментов) - лучше сразу застрелиться. Посему Паскаль и Ко (языки высокого уровня) рулят. А если еще добавить в связку язык Дракон - вообще цены нет.
  • +0.01 / 1
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
  Yura_L ( Слушатель )
20 авг 2015 15:43:46

Легко. В стандартных библиотеках  есть функции ceil() и floor(). Округление вверх и вниз. Этого вполне достаточно для всех типов округлений.
Собственно чего так грешить на округление? 64 бита - это 18  значащих десятичных разрядов !!! Это сколько же надо округлять, чтобы набралась более или менее приличная ошибка?  Особенно на бирже, где все в рублях и копейках, на крайний случай в фунтах шиллингах и пенсах. Т.е. все цифры точные с фиксированной точкой.

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

Но это - кривое программирование. 
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  Longspig ( Слушатель )
21 авг 2015 13:07:15

В "обычном" программировании Float как правило с сокращеной до 53 разряда мантиссой (80-битные Float считаются внутреним форматом и не все языки позволяют работать в них). Но при том, аппаратная связка 64-битное целое  - 64-битная мантисса Float теряется (вместе с аппаратным округлением). А все остальное - программно реализованые "суррогаты".  Дык, я на 8-битном мироконтроллере (51-й Intel) вполне работал с 32-х битной математикой, включая деление. Но это, мягко говоря, как-то - ректально...

А что до накопления погрешностей на бирже. То скорее всего - валютная биржа, где постоянно считается курсовая разница, а там без деления никуда. А это уже часто периодическая дробь в результате. Без округления - никак.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  stranger1234 ( Слушатель )
21 авг 2015 14:04:43

Валютных бирж нет - форекс чисто межбанковский небиржевой рынок...Есть фьючерсы на валюту в чикаго и еще в нескольких местах, но там все тоже стандартизованою Вот к примеру лот по евро http://www.cmegroup.…tions.html - минимальное измерение 3,125 USD...Ошибок округления быть не может...Быстродействие наверное таки да страдать будет при использовании FPU, но не округление
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  Longspig ( Слушатель )
22 авг 2015 00:56:27

Возможно это сейчас! Как следствие. А что было тогда, когда возникли пресловутые проблему округления.

Форекс!... (достали рекламой, млин!...)  Ни разу не финансист... потому слегка озадачился. А ММВБ тогда - это что?
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  Andrew Carlssin ( Слушатель )
26 авг 2015 06:17:17
Сообщение удалено
Andrew Carlssin
12 май 2022 16:27:40
Отредактировано: Andrew Carlssin - 12 май 2022 16:27:40

  • +0.00
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  Longspig ( Слушатель )
26 авг 2015 11:45:29

Т.е. так и запоминать, как отношение двух "нормализованых" Float чисел? (или таки целых)
Тогда придется вместо результата операции, запоминать всю цепочку предшествующих операций и так хранить (ибо результат так или иначе округлять придется, если он лишь бесконечной периодической дробью представляется). Т.е. математика вообще не нужна.
нужна лишь память (да побольше, побольше... (с) Доктор, выпишите мне таблетки от жадности...  ).
  • -0.01 / 1
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  pkdr ( Слушатель )
26 авг 2015 11:51:27

Разве что эмуляцией в специализированных пакетах для математических задач типа matlab, octave и т. п. но и скорость будет соответствующей.
Для обычных же расчётов такой способ будет крайне неудобен, так как и аппаратное и программное устройство современных компьютеров ну никак не приспособлено для эффективной работы с такой логикой. Да и проблемы с таким округлением встречаются крайне редко, поэтому оказалось, что проще и дешевле искать пути обхода в тех крайне редких случаях, когда такие проблемы возникают.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  rommel.lst ( Слушатель )
26 авг 2015 12:07:45

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

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

Вот, только скорость работы - пичалька.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  Alias ( Слушатель )
26 авг 2015 22:39:03

mathematica ведь появилась после maxima, а maxima из лиспа серпает родословную...Поставил себе на ппаншет(андрюху) максиму - теперь приходится для расчетов постоянно float вставлять, ибо максима постоянно норовит перевести в десятичные дроби, корнм м прочие символьные вычисления...,,А вообще занятный продукт - для студиозиоусов при изучении матана самое оно - резульаты символьных вычисления дает на раз-два-три....Правда решения нет
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  Alias ( Слушатель )
26 авг 2015 22:29:41

вопрос какой дроби? Ежели двоичной то оно и так в нем храниться, а если рациональной, то надо переходить к цепным дробям...Кстати на цепных дробях весьма успешно можно решать задачи на fpga, правда вот операции с ними весьма затруднены...
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  Yura_L ( Слушатель )
28 авг 2015 10:14:54

А зачем? Число разрядов будет тем же самым для заданной точности, а арифметические операции - сложнее.
Да и дробная часть - она и так записывается в виде дроби, с постоянным знаменателем. 
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  adolfus ( Слушатель )
04 сен 2015 19:46:16

Если вычисления представляют собой конечную последовательность сложений/умножений/вычитаний/делений, типа как в случае обращения матриц, то можно проводить вычисления в конечном поле очень большого порядка, достаточного для точного представления исходных данных и результатов. При этом вообще ничего округлять не нужно будет, поскольку арифметика модулярная. Встречал статью, где был описаны успехи по обращению плохо обусловленных матриц. Использовалось модулярное представление в базисе Z/p_i и китайская теорема об остатках.
  • +0.01 / 1
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  folk ( Слушатель )
05 сен 2015 13:19:37

Плохо обусловленные матрицы не только и не столько из за ошибок округления дают неверные результат - сколько из за использования итерационных методов.
  • +0.01 / 1
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  adolfus ( Слушатель )
07 сен 2015 14:34:06

Итерационный метод предполагает гладкую сходимость процесса в рабочей области. В случае обращения плохообусловленных матриц это обычно не наблюдается. Вернее, плохообусловленные матрицы обычно появляются в там, где гладкие решения отсутствуют. Там рулят прямые методы, например, Гаусса.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
  Alexxey ( Слушатель )
19 авг 2015 22:07:56

Как-то сомнительно, что авторы ПО Лондонской биржи ничего об этом не знали.Непонимающий
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
  stranger1234 ( Слушатель )
20 авг 2015 23:06:04
Сообщение удалено
stranger1234
20 авг 2015 23:09:42
Отредактировано: stranger1234 - 20 авг 2015 23:09:42

  • +0.00
 
 
 
 
 
 
  Alexxey ( Слушатель )
19 авг 2015 17:09:00

Ну не всегда. Например: телефонный биллинг (тариф - 10 копеек/мин., тарификация посекундная), работа в нескольких валютах одновременно и т.д. и т.п.
  • +0.00 / 0
  • АУ
 
<< Тред №981100
Тред №981102 >>