andy_h
Где здесь про Excel ???

Кусок кода в начале ещё добавил.

Сказали бы: "Не, мужик!!! Это делается не так, а вот так!!!".
Нет же ... сразу в библиотеку посылают, или в "любви" признаются.
А по сути - ничего ...

Вот отсюда все начали кипеть: /topic/268869&pg=-1#2421411

andy_hРома, вот ты любишь всякие алегории, особенно про рыбалку.
Вот ты приходишь и говоришь: "Научи меня ловить рыбу".
А тебе отвечают:"Иди-ка поучись бамбук для удочек выращивать".
Так и здесь ....

Гы :-) Если я приду и спрошу "Как ловить рыбу?" - меня пошлют читать многочисленные пособия по рыбалке. И правильно. А вот вопрос в духе "на какого мотыля лучше ловятся карпы в подмосковье?" - это уже более сложный и узкий вопрос, и по нему литературы так просто не найти.

Я всегда пишу свои обработчики округления с заданной мне точностью именно по принципу "умножил-отбросил-разделил", так как проблема округления вещественных чисел мне известна еще со времен C++. Боолее того, это общепринятая практика для численных методов - только так ты можешь гарантировать отсутствие погрешности при округлении.
И я никогда не пользовался BigDecimal до сегодняшнего дня. Тем не менее, мне хватило нескольких минут для того, чтобы заглянуть в исходники класса BigDecimal и увидеть там, откуда растут ноги твоей проблемы. Ты мог сделать те же самые шаги. Но почему-то поленился это сделать, а обратился в форум. Согласись, вопрос явно не из серии узкоспециализированных, и недостоин форума, если для его решения нужно полчаса?

Я собственно к тому, что новое поколение (блин, мне всего 25 лет, а я говорю про другое поколение) зачастую хочет достать готовое решение. Это хорошо с точки зрения "сделал и забыл", но ни разу не правильно с точки зрения профессионального роста.

Мне довелось попрограммировать на ассемблере для ZX Spectrum, в основном методом Научного-Тыка. Это был великолепный опыт, к сожалению, не понадобившийся мне в дальнейшем. Из подобных вещей и складывается умение решать проблемы самостоятельно, а также инженерное мышление и спсобность на нестандартные решения. И то, что новые программисты зачастую не знают ничего, кроме паттернов (да и тех толком не знают) - вот что меня беспокоит по-настоящему. И я так думаю - не одного меня.

andy_hПросто ожидал большего от этого языка. Возьми, например, класс String: сколько методов для работы со строкой. В том же Паскале для тех же целей много приходилось писать ручками. Поэтому, отсутствие roundTo(double d, int digit) - несколько обескуражило, неужели трудно было добавить его в Math?

Ну так и добавили. BigDecimal.ROUND_HALF_UP делает именно то, что тебе надо - если не забывать о косяке округления и делать так, как советуют сами разработчики языка - сначала преобразовать из double в String - это исключит потерю точности.

Вот так надо было написать: new BigDecimal(""+d).setScale(3, BigDecimal.ROUND_HALF_UP));

Да, понимаю, добавили немного не в том месте, где ожидалось... Этому есть свои причины.

Теперь-то можно дискуссию закрывать? Или ты, как и я, не можешь оставить последнее слово за оппонентом? ;-)

ежемуха andy_hПоэтому, отсутствие roundTo(double d, int digit) - несколько обескуражило, неужели трудно было добавить его в Math?

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

Скорее для того, чтобы отделить hardware-dependent значение (double на 32-битных x86, 64-битных AMD и Itanium, маках с прямым порядком байтов etc) от hardware-independent BigDecimal, который по спецификации будет одинаков для всех систем. Например, для меня стало сюрпризом, что int в C++ - это не всегда 32 бита, а в общем-то зависит от разрядности процессора. В таких случаях косяки по переполнению могут полезть в самых неожиданных местах.