Можно ли, чтобы при конвертации в тип string, он не обрезал число.  

Это сообщение отредактировал(а) Dino99rus - 25.10.2007, 20:45

почитай Standard Numeric Format Strings 

Спасибо. поставил бы + да постов маловато

Мдя или округляет на один знак, как в первом посте. Или при использование Round-Trip на число больше. Про Round-Trip сказано что при выч. Math.PI=3.141592653589793, а на примере получаю 3.1415926535897931, что очень мешает. Вот среднего размера у них нет.

Уже 2-й касяк в C#... или мне так везет их находить.


Это сообщение отредактировал(а) Dino99rus - 27.10.2007, 15:17

если очень хочешь, то после пятнатцатого знака можешь дописать любое количество цифр, но все они будут бессмысленными.
Тебе везет их выдумывать. Если бы попробовал пользоваться справкой, то прочитал бы про double: Its range is +/–1.7E308 with at least 15 digits of precision. 

double d=0.70710678118654757;
он спокойно это хавает, притом это число он сам записывает и возвращает типом double посчитай 
d=Math.Sqrt(2)/2; //d=0.70710678118654757 вот это он число запишет

Я бы такие глупые вопросы не зодовал если не проверял. И ничего он не обрезает.

Результат : 0.70710678118654746

Ты удивлён? = Я - нет  

Дело в том, что вещественные типы слегка шумят в хвосте, это факт. Но физики, математики и программисты, кропевшие над железом и микропрограммами сопроцессора не такие уж прям идиоты, чтобы считать их труд полным,  как ты пишешь, косяков. Это не так просто, там имеются некоторые тонкости, в частности, статистические. Язык C# (и .NET) здесь вообще ни при чём, а на работу процессоров есть стандарты и спецификации в несколько тысяч страниц. Вот несколько простых наблюдений :

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

Если так критично, попробуй воспользоваться типом decimal. Он в два раза больше : 128 бит. Подозреваю, что он - "сконструированный" (раз работает на 32-битных машинках), но точность всё-равно могла бы и повыситься :



Это сообщение отредактировал(а) marcusmae - 31.10.2007, 22:45