powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Java [игнор отключен] [закрыт для гостей] / int ->double->int - потеря точности.
21 сообщений из 46, страница 2 из 2
int ->double->int - потеря точности.
    #39200617
Фотография Usman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevПерегрузка операторов проблем с "убожестью" языка не решает, а только усугубляет.Перегрузка операторов - это одна из необходимых фич, которые нужно добавить в Java.
На пару с implicit - выглядит очень даже красиво и намного читабельно.Leonid Kudryavtsevnew BigDecimal( new BigDecimal( new BigDecimal( 5 ) + new BigDecimal( new BigDecimal( 10 ) * new BigDecimal( 4 ) ) ) - new BigDecimal( 3 ) ) decimal имхо !Консерватизм Javы породил C#, Groovy, Scala...
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200629
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton, да не новичка. Просто "универсальные языки" стали везде использовать (пихать!) для решения задач, которые всю жизнь решались специализированными языками.

Как следствие - дофига корявого кода, не эффективность и детские ошибки (типа float для денег).

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

Мигрировал БД из PostgreSQL в Oracle. Там ID-шники (!) были float. Почему так, не знаю. Но для меня выглядело диковато. И это не студенческая поделка. А достаточно успешная учетная система, эксплуатирующаяся у одного из наших гигантов и столпов экономики.

ORM. Создатели ООП решили "свое видение" привнести в БД. При этом, очень похоже, что знание СУБД (которым уже не один десяток лет) у них были около нуля.

В результате скрещивания ужа и кактуса получается "10 метров колючей проволоки". При том, что изначально, оба животных вполне себе безобидные и, в чем-то, даже полезные. Куда в IT не посмотришь - везде примерно так.

Вроде идеи по отдельности здравые, хорошие и полезные - но их бездумное объединение (чаще по историческим причинам) такой бардак и помойка....
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200640
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Зло в перегрузке, а тем более в implicit, что оно скрывает от программиста как же реально его код будет выполняться. Да, возможно, в 90% случаев, это приводит к "выглядит очень даже красиво и намного читабельно". Но в 10%, может привести к полной помойке и бардаку. Т.к. где, что и во что "неявно преобразовалось" - фиг найдешь.

В общем "при использование в меру" вещь хорошая и полезная.

Но примеров бездумного использования новомодных фич - как грязи. Я бы даже сказал, Java-программисты страдает от этого намного больше, чем любые другие программисты )))
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200666
lor2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
нененене, и чо и чо? и чо делать то в бухсофте? "вставки на другом языке" это простите, эээээ. а накой тогда ява нужна? давайте на руби и пхп бух софт писать а?
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200667
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
JavaScript AFAIK использует вещественное представление вообще для всех
счетных типов. Но это упрощение заложеное еще на этапе создания
самой машины. И оно работает только внутри JavaScript.
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200672
lor2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
maytonJavaScript AFAIK использует вещественное представление вообще для всех
счетных типов. Но это упрощение заложеное еще на этапе создания
самой машины. И оно работает только внутри JavaScript.
я не думаю, что это хорошая идея делать вычисления в бухе на клиенте.
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200677
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lor2нененене, и чо и чо? и чо делать то в бухсофте? "вставки на другом языке" это простите, эээээ. а накой тогда ява нужна? давайте на руби и пхп бух софт писать а?
1C )))

При всем богатстве выбора....

p.s. Сам на 1С не писал и писать не буду. Язык где операторы по русски - извините, но мне "пошел на" и в реальной жизни хватает. Можно хоть в компьютере будет англоязычное "goto" ?
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200688
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lor2maytonJavaScript AFAIK использует вещественное представление вообще для всех
счетных типов. Но это упрощение заложеное еще на этапе создания
самой машины. И оно работает только внутри JavaScript.
я не думаю, что это хорошая идея делать вычисления в бухе на клиенте.
Клиент эволюционирует. Я лет 10 назад тоже считал JS недо-языком годным
лишь для проверки формочек перед постом. Но сегодня на нем делают игры
и медиаконтент и сам по себе вопрос "ахах дескыть хто разрешил и как
это мона" уже не звучит. Все привыкли. Надежность устраивает.
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200689
lor2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Leonid Kudryavtsev,

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

я всё же не понимаю как там в больших корп. проектах это всё считается? неужели бигдецимал? или вообще тупо арифметику в скуль перетаскивают? )) тогда зачем хибер и эти неясные скрещивания ужей с ежами (из соседней темы)?
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200700
lor2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
maytonlor2пропущено...

я не думаю, что это хорошая идея делать вычисления в бухе на клиенте.
Клиент эволюционирует. Я лет 10 назад тоже считал JS недо-языком годным
лишь для проверки формочек перед постом. Но сегодня на нем делают игры
и медиаконтент и сам по себе вопрос "ахах дескыть хто разрешил и как
это мона" уже не звучит. Все привыкли. Надежность устраивает.
я нисколько не сомневаюсь в возможностях жса кроме того я полагаю что по сложности и объемности знаний жс ничем яве не уступает. тут вопрос именно безопасности )) типа чел возьмет и в клиенте сам себе расчет зп подкрутит. помню раньше игра такая была ил2 штурмовик, забытые сражения по сети в нее резались (кстати, на яве сделанная, уже тогда - 2004-й год емнип) так вот, там попадания вычислялись на КЛИЕНТЕ. т.е. ты стреляешь в чувака, а попал-не попал считается не у него или на серваке, а у тебя. так вот, я просто залез в базу моделей повреждения и у всех вражеских самолетов поставил броню ноль. одна пуля рвала самолет врага как тузик грелку. крылья там отваливались и т.п.

это я к чему - думаю ясно к чему. :) нехорошая это идея в общем. я понимаю если какие-то там отчеты индикативные готовить, а если критические вычисления - то нет.
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200706
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lor2я всё же не понимаю как там в больших корп. проектах это всё считается? неужели бигдецимал? или вообще тупо арифметику в скуль перетаскивают? )) тогда зачем хибер и эти неясные скрещивания ужей с ежами (из соседней темы)?
Ты щас всё спутал и смешал в одну кучу. При чем тут хибер вообще? Ты что с хибером
что без него видишь один и тот-же ResultSet.

По поводу как считают. Один чел который писал логику для фондовых бирж (hiload) говорил
(и я гарантирую это ибо знакомый) что они для денег используют long (64bit) и в целых
числах (копейках или центах) в зависимости от валюты. Код валюты тут-же кладётся рядом
в class (record, datarow).
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200709
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lor2я всё же не понимаю как там в больших корп. проектах это всё считается?

Oracle Customer Care & Billing - Big Decimal. Пред. версия и часть вычислений на Cobol'е.
ГИС ГМП - AFAIK копейки (какой язык не знаю)
Google Flight - копейки, центы (какой язык не знаю)

lor2или вообще тупо арифметику в скуль перетаскивают?

Oracle OeBS - Вся логика на PL/SQL, на Java только часть морды. Через что отображают деньги - не помню. Но у них OAF/ADF, скорее всего BigDecimal.

lor2тогда зачем хибер и эти неясные скрещивания ужей с ежами (из соседней темы)?
Модно, весело и молодежно )))
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200739
lor2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
maytonlor2я всё же не понимаю как там в больших корп. проектах это всё считается? неужели бигдецимал? или вообще тупо арифметику в скуль перетаскивают? )) тогда зачем хибер и эти неясные скрещивания ужей с ежами (из соседней темы)?
Ты щас всё спутал и смешал в одну кучу. При чем тут хибер вообще? Ты что с хибером
что без него видишь один и тот-же ResultSet.

По поводу как считают. Один чел который писал логику для фондовых бирж (hiload) говорил
(и я гарантирую это ибо знакомый) что они для денег используют long (64bit) и в целых
числах (копейках или центах) в зависимости от валюты. Код валюты тут-же кладётся рядом
в class (record, datarow).
может я костноязычен но суть следующая: щас я допиливаю уже (слава Всевышнему!) проект где используется хибер и скуля нет вообще практически только мелкие вкрапления хкуля да и те особо не нужны. вот у меня встанет задача избавиться от дабла и бигдецимала и претащить всю арифметику в скуль - эээ я даже близко не представляю какой же это будет костылище, а так всё "быстро, красиво, молодежно" и по ооп )) ну.. в принципе исходя из сообщения предыдущего оратора, да и то что я сам говорил: или считаем в копейках, или ужасный бигдец.

просто с даблами всё так красиво выходит, структурированно и по оопшному - ты и из формы циферки вынимаешь и если надо обсчеты, относящиеся ко вьюшке делаешь как положено во вьюшке жсп-ой и т.п., в коде так же а+б/ц и т.п. а если пользовать бдц или копейки то появляются долбаные костыли.
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200745
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton...что они для денег используют long (64bit) и в целых
числах (копейках или центах) в зависимости от валюты. Код валюты тут-же кладётся рядом
в class (record, datarow)
Оно конечно хорошо, но подозреваю, для целого ряда применений может быть не достаточно. Т.к. например курсы валют считаются с большей точностью, чем 2-а знака после запятой.

Да и с точки зрения эстетики, это выглядит донельзя корявым. Рубль изначально и возник как "счетная единица". Такой монеты еще не было, а понятие рубль для феодальной отчетности ))) /поскольку бухгалтерию еще тоже не придумали/ уже было.

А тут прогресс... копейками считаем.

Кроме того, нужно привязывать точно знаков вывода после запятой к валюте. Не хилое усложнение форматирования. Не все валюты основаны по основанию 100, википедия уверяет:

"...1 тунисский динар — 1000 миллимов... Мавритания, где угия делится на 5 хумсов, и Мадагаскар, чья национальная валюта ариари состоит из 5 ираймбиланья."

Т.ч. форматирования для вывода и/или отладка - будет еще та себе.
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200754
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Возможно в тех биржевых операциях важнее была компактность хранения и базовая ариметика
типа там сложить или сравнить на больше или меньше. Не возражаю против перевода валют
но очевидно что оптимизация шла в сторону наболее частых операций.
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200777
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Leonid Kudryavtsev
P.S. в apache commons либе увидел код, в котором double приводят к int
1) Показывай код и место, где его применили.

класс Fraction имеет билдер(не тот, что в GoF), который принимает только double
Код: java
1.
getFraction



Мне надо сравнить мою дробь с целым числом.

приводить цело число к дроби, со знаменателем 1 ну как-то не очень красиво.
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200778
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
есть
Код: java
1.
public static Fraction getFraction(double value) {


который принимает double и внутри они дабл кастят к инту.

а для просто инта - нет
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200797
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
questionerесть
Код: java
1.
public static Fraction getFraction(double value) {


который принимает double и внутри они дабл кастят к инту.


вижу следующий код:
Код: java
1.
2.
3.
4.
5.
public static Fraction getFraction(double value) {
...
252        final int wholeNumber = (int) value;
253        value -= wholeNumber;
...


Что и зачем делают - вроде все понятно.

Будет ли эквиваленты вызовы:

getFraction( (double)1.0 ) и getFraction( "1" ) - на мой взгляд да

Преобразование int -> double -> int при отсутствие арифметических операций и одном и том же основании счисления (2) должно быть безопасно. IMHO
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39200958
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Leonid Kudryavtsevquestionerесть
Код: java
1.
public static Fraction getFraction(double value) {


который принимает double и внутри они дабл кастят к инту.


вижу следующий код:
Код: java
1.
2.
3.
4.
5.
public static Fraction getFraction(double value) {
...
252        final int wholeNumber = (int) value;
253        value -= wholeNumber;
...


Что и зачем делают - вроде все понятно.

Будет ли эквиваленты вызовы:

getFraction( (double)1.0 ) и getFraction( "1" ) - на мой взгляд да

Преобразование int -> double -> int при отсутствие арифметических операций и одном и том же основании счисления (2) должно быть безопасно. IMHO

ИМХО тоже, только меня смутило, что какого-то 100 пудового доказательства в глубине души я не смог придумать.

ну и + 1 может же стать 0.99999999999999999999

или нет таки?
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39201009
lor2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
делать было нечего и я проверил:
спринг просто прекрасно принимает с текстовго поля формы значение цифровое и автоматом его переводит в бигдец. кроме того если этот бигдец отправлять обратно во вьюшку то там с ним можно вполне свободно стандартыми способами крутить-вертеть в жспшках как хочешь, типа ((бигдец1+бигдец2)/бигдец3)
...
Рейтинг: 0 / 0
int ->double->int - потеря точности.
    #39201731
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ребята а что будет, когда вы узнаете чему равен синус
?
...
Рейтинг: 0 / 0
21 сообщений из 46, страница 2 из 2
Форумы / Java [игнор отключен] [закрыт для гостей] / int ->double->int - потеря точности.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]