Ассемблерные вставки и переносимость кода

← →
Rouse_ © (2012-06-15 21:35) [160]

Хотя правда ты говорил что вариант кастомной реализации строки тоже рассматривается, если это учитывать и эта кастомная строка будет брать данные из кэша - то тогда у тебя все правильно.

← →
KSergey © (2012-06-15 21:37) [161]

> Rouse_ © (15.06.12 21:34) [159]
> Во, все правильно пишешь, именно про это я и вел речь, но
> нюанс, все целиком разложенное число не влезет в виртуальную
> память и если по твоему варианту я захочу получить уже не
> двумиллионный знак а двутриллионный - то будет отлуп, ибо
> либо мы держим данное число на пределе точности, ограниченной
> размерами виртуалки, либо его вообще не возможно держать
> в строке и придется держать во внешнем кэше, а это уже не строка...

Еще раз.
Внутри строка содержит строго 2 символа: PI
Ничего другого (ну помимо алгоритма получения цифры на нужном знакоместе) - не нужно.

> в строке и придется держать во внешнем кэше, а это уже не строка...

А когда операционка перекидывает содержимое переменной String в виртуальную память на диск из-за израсходования физического ОЗУ - это тоже перестает быть строкой?

← →
Rouse_ © (2012-06-15 21:39) [162]

> Ничего другого (ну помимо алгоритма получения цифры на нужном
> знакоместе) - не нужно.

Ну т.е. рассматривается вариант [160]?
Если да - то тут никаких возражений, все правильно...

← →
KSergey © (2012-06-15 21:40) [163]

> Rouse_ © (15.06.12 21:35) [160]
> если это учитывать и эта кастомная строка будет брать данные из кэша - то тогда у тебя все правильно.

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

← →
Rouse_ © (2012-06-15 21:41) [164]

> KSergey © (15.06.12 21:40) [163]

Ну в принципе логика понятна, тут целиком согласен.

← →
KSergey © (2012-06-15 21:42) [165]

> Rouse_ © (15.06.12 21:39) [162]
> Ну т.е. рассматривается вариант [160]?

Нет.
Рассматривается вариант "данные + алгоритм получения нужных (производных) данных".

← →
Inovet © (2012-06-15 21:44) [166]

> [162] Rouse_ © (15.06.12 21:39)
> Если да - то тут никаких возражений, все правильно...

А если для получения более точного значения нужно предыдущее.

← →
Rouse_ © (2012-06-15 21:46) [167]

Удалено модератором
Примечание: 170

← →
KSergey © (2012-06-15 21:48) [168]

> Inovet © (15.06.12 21:44) [166]
> А если для получения более точного значения нужно предыдущее.

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

← →
Rouse_ © (2012-06-15 21:48) [169]

> Inovet © (15.06.12 21:44) [166]
> А если для получения более точного значения нужно предыдущее.

В случае кэша это бессмысленно (ну за исключением разве что сам кэш записан в виде разницы значения от предыдущего байта).

← →
Rouse_ © (2012-06-15 21:51) [170]

> KSergey © (15.06.12 21:42) [165]
> Нет.
> Рассматривается вариант "данные + алгоритм получения нужных
> (производных) данных".

Блин, я уже сам запутался...
так я в [160] это и имел ввиду, данных (кэш) и алго для получения (кастомный вариант строки получения оных)

← →
Inovet © (2012-06-15 21:52) [171]

> [168] KSergey © (15.06.12 21:48)
> Это вопрос лишь ресурсоемкости.

Но хранить нам его негде, значит и получить произвольный после предельного не сможем. Допустим, что это единственный алгоритм.

← →
Дмитрий С © (2012-06-15 21:53) [172]

> Rouse_ ©

Неужели точности Extended, например, недостаточно для каких либо некосмических вычислений?

← →
Inovet © (2012-06-15 21:54) [173]

> [172] Дмитрий С © (15.06.12 21:53)
> Неужели точности Extended, например, недостаточно для каких
> либо некосмических вычислений?

Её и для космических достаточно, речь не о достаточности.

← →
Rouse_ © (2012-06-15 21:54) [174]

> Дмитрий С © (15.06.12 21:53) [172]
> Неужели точности Extended, например, недостаточно для каких
> либо некосмических вычислений?

А ты скомпилируй пример, он же как раз это и показывает :)

← →
KSergey © (2012-06-15 21:54) [175]

> Rouse_ © (15.06.12 21:46) [167]
> 1. данные не хранятся в строке (собственно основной постулат данного спора)

Но почему не хранятся?? Почему там должно храниться непременно десятичное представление?? и почему тогад десятичное? а если я в одинадцатеричном виде захочу результат получать?
Там как раз хранятся данные для алгоритма, то самое PI.
Ну или 1000000^2000000

> 2. для вычисления на современном компьютере даже 1 миллиардного
> знака после запятой у числа PI потребуется пару часов...

Это не делает решение некорректным.

← →
Rouse_ © (2012-06-15 21:55) [176]

> KSergey © (15.06.12 21:54) [175]

угу, пардон, я там запутался, посмотри 170

← →
KSergey © (2012-06-15 21:57) [177]

> Inovet © (15.06.12 21:52) [171]
> Но хранить нам его негде, значит и получить произвольный
> после предельного не сможем. Допустим, что это единственный алгоритм.

Пожалуйста, перечитайте 161, чтоли...
И укажите что жеименно нам негде хранить.

← →
Inovet © (2012-06-15 21:57) [178]

> [175] KSergey © (15.06.12 21:54)
> Почему там должно храниться непременно десятичное представление??

Да неважно, пусть хранится 256-ричное.

← →
Rouse_ © (2012-06-15 21:58) [179]

> Дмитрий С © (15.06.12 21:53) [172]

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

← →
KSergey © (2012-06-15 21:59) [180]

> Rouse_ © (15.06.12 21:55) [176]
> угу, пардон, я там запутался, посмотри 170

Ну на сколько я понимаю - таки консенсус )

А все чертова терминология и толкование каждого термина каждым в строго определенном смысле...

← →
Inovet © (2012-06-15 21:59) [181]

> [177] KSergey © (15.06.12 21:57)
> Пожалуйста, перечитайте 161, чтоли...
> И укажите что жеименно нам негде хранить.

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

← →
Rouse_ © (2012-06-15 22:00) [182]

В данном вопросе кажется да :)

← →
Rouse_ © (2012-06-15 22:01) [183]

ЗЫ: если что ребят пардоньте сегодня больше в споре участия принимать не буду, ибо уже голова не пашет правильно, но если что, то я готов завтра продолжить :)

← →
KSergey © (2012-06-15 22:03) [184]

> Rouse_ © (15.06.12 21:58) [179]
> Блин, опять-же пардон, пример покажет не то что точности
> не хватает, а то, что стандартные функции округления не имеют достаточной точности...

Если я правильно понял, то речь о том, чтобы суметь отличить истинное 1.9999 от неистинного, т.е. реального 2, я верно понял?
Тема сама по себе животрепещущая, мы ее более грубо решаем, хотя артефакты случаются...

← →
Rouse_ © (2012-06-15 22:07) [185]

> KSergey © (15.06.12 22:03) [184]
> Если я правильно понял, то речь о том, чтобы суметь отличить
> истинное 1.9999 от неистинного, т.е. реального 2, я верно
> понял?
> Тема сама по себе животрепещущая, мы ее более грубо решаем,
> хотя артефакты случаются...

Абсолютно верно, у нас просто софт завязан на сметы и там ошибка округления может влиться в очень большие убытки (утрирую конечно, но например представь произошла ошибка на 1 копейку при расчете стоимости 1 кирпича при постройке кирпичного пятиэтажного дома).
Поэтому требуется очень высокоточный алгоритм. На сайте выложен т.н. пользовательский вариант, там у меня точность до 18 знаков, в боевом же алгоритме точности до 35 знаков после запятой (кункуренты не дремлют и сайт мой знают :).

← →
KSergey © (2012-06-15 22:14) [186]

> Rouse_ © (15.06.12 22:07) [185]

По секрету: мы тоже деньги в них считаем )
И тоже округлять до копеек лишь бы как - нельзя, да )

← →
Rouse_ © (2012-06-15 22:15) [187]

> Тема сама по себе животрепещущая, мы ее более грубо решаем,
> хотя артефакты случаются...

Кстати, если у вас конечно не что-то секретное, не мог бы показать ваш вариант?

← →
Rouse_ © (2012-06-15 22:17) [188]

зы: можно в личку rouse79@yandex.ru

> Rouse_ © (15.06.12 22:15) [187]
> Кстати, если у вас конечно не что-то секретное, не мог бы показать ваш вариант?

Только тапками не кидаться )

Хранятся копейки до дробной точки. Из этого исходим.

Идея тупая и очень грубая дальше: делим/умножаем, когда закончили - то прибавляется 0,5+EPS (EPS что-то тпа 0,00001) - и отрубаем дробную часть. Я понимаю, что при этом может получиться все те же 1,9999 вместо истинной двойки, но тут уже вопрос интерпретации в момент печати, просто алгоритмы отображения устроены как-то так, что рисуется 2 в таком случае.

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

Это явно много грубее вашего подхода, но если исходить из того, что это вот копейки и нам надо до копеек округлить - то я не вижу разницы между истинным 1,9999 и истинным 1,9997. Лишь бы единичка наша не попала на 7, нехорошо получится )

Вспомнилось из математики.
Почему 0.9999(9) = 1 ?

нашел
http://ru.wikipedia.org/wiki/0,%289%29

странно, нам это объяснили тем, что 0.9999(9) = 1 по определению равенства, т.к. между ними нельзя вставить какое либо действительное число (0.9999(9) < x < 1)

> то прибавляется 0,5+EPS (EPS что-то тпа 0,00001)

Угу знакомо, мы попадали на такое, собственно исходя из примерно похожего примера и было принято решение писать туеву хучу высокоточных алгоритмов.
А кратце попадалово было в тот момент, когда число (допустим) было 1.99994 (абсолютно нормальный результат без погрешности в последней четверке) и тут мы правим "погрешность" прибавляя этот 0,00001 (в оригинале было 0,00000001), получая на выходе двойку на округлении.
Газпром был очень не доволен (мягко говоря) :)
Пришлось проштудировать много макулатуры по представлению чисел в матсопроцессоре, найти там ошибку (багрепорт ушел в интел), потом сделать то-же самое по процессорам от АМД, вычислить лимит погрешности для обоих железяк, рассчитать сальдо на пике (мы остановились на 96, т.е. 4 процента ошибок при 35 знаках пос запятой, что за глаза) и по минимуму доводить исходный матаппарат под результат, ибо там если немного перекрутить - то сыпятся ошибки но уже с другой стороны (ну что-то типа переполнения, но по другому)

> Пришлось проштудировать много макулатуры по представлению
> чисел в матсопроцессоре, найти там ошибку

А если не сложно можно маленький пример воспроизводящий ошибку?

> А если не сложно можно маленький пример воспроизводящий
> ошибку?

Там ошибка в документации, ес не ошибаюсь один из регистров не инициализировался так как было описано в документации, или наоборот.

> Там ошибка в документации, ес не ошибаюсь один из регистров
> не инициализировался так как было описано в документации,
> или наоборот.

У обоих производителей?

А на практике в чем ошибка выражалась?

А по поводу АМД, из-за него идет ветвление выходящее на "fprem1". Точнее как потом показала практика под i5/i7 тоже туда происходит выход в отличие от предыдущих моделей...

> У обоих производителей?

Нет.

> А на практике в чем ошибка выражалась?

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

Давно не встречалось на дм чего нить интересного почитать. Спасибо.

зы, ну я в смысле что народ давно погряз в оффтопах и даже не ожидал что в споре родится техническая ветка :)

Ассемблерные вставки и переносимость кода Найти похожие ветки