|
|
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
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... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 14:09 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
mayton, да не новичка. Просто "универсальные языки" стали везде использовать (пихать!) для решения задач, которые всю жизнь решались специализированными языками. Как следствие - дофига корявого кода, не эффективность и детские ошибки (типа float для денег). Плюс. Что, возможно, много хуже. Создатели данных "универсальных решений" стали считать себя гуру и свое корявое решение с упорством и с успехом пропихивать туда, где до них было все хорошо Мигрировал БД из PostgreSQL в Oracle. Там ID-шники (!) были float. Почему так, не знаю. Но для меня выглядело диковато. И это не студенческая поделка. А достаточно успешная учетная система, эксплуатирующаяся у одного из наших гигантов и столпов экономики. ORM. Создатели ООП решили "свое видение" привнести в БД. При этом, очень похоже, что знание СУБД (которым уже не один десяток лет) у них были около нуля. В результате скрещивания ужа и кактуса получается "10 метров колючей проволоки". При том, что изначально, оба животных вполне себе безобидные и, в чем-то, даже полезные. Куда в IT не посмотришь - везде примерно так. Вроде идеи по отдельности здравые, хорошие и полезные - но их бездумное объединение (чаще по историческим причинам) такой бардак и помойка.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 14:17 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
Зло в перегрузке, а тем более в implicit, что оно скрывает от программиста как же реально его код будет выполняться. Да, возможно, в 90% случаев, это приводит к "выглядит очень даже красиво и намного читабельно". Но в 10%, может привести к полной помойке и бардаку. Т.к. где, что и во что "неявно преобразовалось" - фиг найдешь. В общем "при использование в меру" вещь хорошая и полезная. Но примеров бездумного использования новомодных фич - как грязи. Я бы даже сказал, Java-программисты страдает от этого намного больше, чем любые другие программисты ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 14:25 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
нененене, и чо и чо? и чо делать то в бухсофте? "вставки на другом языке" это простите, эээээ. а накой тогда ява нужна? давайте на руби и пхп бух софт писать а? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 14:44 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
JavaScript AFAIK использует вещественное представление вообще для всех счетных типов. Но это упрощение заложеное еще на этапе создания самой машины. И оно работает только внутри JavaScript. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 14:44 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
maytonJavaScript AFAIK использует вещественное представление вообще для всех счетных типов. Но это упрощение заложеное еще на этапе создания самой машины. И оно работает только внутри JavaScript. я не думаю, что это хорошая идея делать вычисления в бухе на клиенте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 14:47 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
lor2нененене, и чо и чо? и чо делать то в бухсофте? "вставки на другом языке" это простите, эээээ. а накой тогда ява нужна? давайте на руби и пхп бух софт писать а? 1C ))) При всем богатстве выбора.... p.s. Сам на 1С не писал и писать не буду. Язык где операторы по русски - извините, но мне "пошел на" и в реальной жизни хватает. Можно хоть в компьютере будет англоязычное "goto" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 14:49 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
lor2maytonJavaScript AFAIK использует вещественное представление вообще для всех счетных типов. Но это упрощение заложеное еще на этапе создания самой машины. И оно работает только внутри JavaScript. я не думаю, что это хорошая идея делать вычисления в бухе на клиенте. Клиент эволюционирует. Я лет 10 назад тоже считал JS недо-языком годным лишь для проверки формочек перед постом. Но сегодня на нем делают игры и медиаконтент и сам по себе вопрос "ахах дескыть хто разрешил и как это мона" уже не звучит. Все привыкли. Надежность устраивает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 14:55 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, по бухе я долго ковырял эту тему. вариантов не много: или бигдецимал и его угребищные выражения на птичьем языке, или же целочисленные копейки (центы, тугрики, куруши и т.п.) (он же инт) с последующим переводом во что-нибудь что два знака после запятой показывать умеет. оба варианта на мой взгляд уродские костыли. ну либо третий вариант - мас.раунд и теоретически куда-нибудь девающиеся копейки в случае объемных вычислений. я всё же не понимаю как там в больших корп. проектах это всё считается? неужели бигдецимал? или вообще тупо арифметику в скуль перетаскивают? )) тогда зачем хибер и эти неясные скрещивания ужей с ежами (из соседней темы)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 14:56 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
maytonlor2пропущено... я не думаю, что это хорошая идея делать вычисления в бухе на клиенте. Клиент эволюционирует. Я лет 10 назад тоже считал JS недо-языком годным лишь для проверки формочек перед постом. Но сегодня на нем делают игры и медиаконтент и сам по себе вопрос "ахах дескыть хто разрешил и как это мона" уже не звучит. Все привыкли. Надежность устраивает. я нисколько не сомневаюсь в возможностях жса кроме того я полагаю что по сложности и объемности знаний жс ничем яве не уступает. тут вопрос именно безопасности )) типа чел возьмет и в клиенте сам себе расчет зп подкрутит. помню раньше игра такая была ил2 штурмовик, забытые сражения по сети в нее резались (кстати, на яве сделанная, уже тогда - 2004-й год емнип) так вот, там попадания вычислялись на КЛИЕНТЕ. т.е. ты стреляешь в чувака, а попал-не попал считается не у него или на серваке, а у тебя. так вот, я просто залез в базу моделей повреждения и у всех вражеских самолетов поставил броню ноль. одна пуля рвала самолет врага как тузик грелку. крылья там отваливались и т.п. это я к чему - думаю ясно к чему. :) нехорошая это идея в общем. я понимаю если какие-то там отчеты индикативные готовить, а если критические вычисления - то нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 15:00 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
lor2я всё же не понимаю как там в больших корп. проектах это всё считается? неужели бигдецимал? или вообще тупо арифметику в скуль перетаскивают? )) тогда зачем хибер и эти неясные скрещивания ужей с ежами (из соседней темы)? Ты щас всё спутал и смешал в одну кучу. При чем тут хибер вообще? Ты что с хибером что без него видишь один и тот-же ResultSet. По поводу как считают. Один чел который писал логику для фондовых бирж (hiload) говорил (и я гарантирую это ибо знакомый) что они для денег используют long (64bit) и в целых числах (копейках или центах) в зависимости от валюты. Код валюты тут-же кладётся рядом в class (record, datarow). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 15:04 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
lor2я всё же не понимаю как там в больших корп. проектах это всё считается? Oracle Customer Care & Billing - Big Decimal. Пред. версия и часть вычислений на Cobol'е. ГИС ГМП - AFAIK копейки (какой язык не знаю) Google Flight - копейки, центы (какой язык не знаю) lor2или вообще тупо арифметику в скуль перетаскивают? Oracle OeBS - Вся логика на PL/SQL, на Java только часть морды. Через что отображают деньги - не помню. Но у них OAF/ADF, скорее всего BigDecimal. lor2тогда зачем хибер и эти неясные скрещивания ужей с ежами (из соседней темы)? Модно, весело и молодежно ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 15:06 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
maytonlor2я всё же не понимаю как там в больших корп. проектах это всё считается? неужели бигдецимал? или вообще тупо арифметику в скуль перетаскивают? )) тогда зачем хибер и эти неясные скрещивания ужей с ежами (из соседней темы)? Ты щас всё спутал и смешал в одну кучу. При чем тут хибер вообще? Ты что с хибером что без него видишь один и тот-же ResultSet. По поводу как считают. Один чел который писал логику для фондовых бирж (hiload) говорил (и я гарантирую это ибо знакомый) что они для денег используют long (64bit) и в целых числах (копейках или центах) в зависимости от валюты. Код валюты тут-же кладётся рядом в class (record, datarow). может я костноязычен но суть следующая: щас я допиливаю уже (слава Всевышнему!) проект где используется хибер и скуля нет вообще практически только мелкие вкрапления хкуля да и те особо не нужны. вот у меня встанет задача избавиться от дабла и бигдецимала и претащить всю арифметику в скуль - эээ я даже близко не представляю какой же это будет костылище, а так всё "быстро, красиво, молодежно" и по ооп )) ну.. в принципе исходя из сообщения предыдущего оратора, да и то что я сам говорил: или считаем в копейках, или ужасный бигдец. просто с даблами всё так красиво выходит, структурированно и по оопшному - ты и из формы циферки вынимаешь и если надо обсчеты, относящиеся ко вьюшке делаешь как положено во вьюшке жсп-ой и т.п., в коде так же а+б/ц и т.п. а если пользовать бдц или копейки то появляются долбаные костыли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 15:20 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
mayton...что они для денег используют long (64bit) и в целых числах (копейках или центах) в зависимости от валюты. Код валюты тут-же кладётся рядом в class (record, datarow) Оно конечно хорошо, но подозреваю, для целого ряда применений может быть не достаточно. Т.к. например курсы валют считаются с большей точностью, чем 2-а знака после запятой. Да и с точки зрения эстетики, это выглядит донельзя корявым. Рубль изначально и возник как "счетная единица". Такой монеты еще не было, а понятие рубль для феодальной отчетности ))) /поскольку бухгалтерию еще тоже не придумали/ уже было. А тут прогресс... копейками считаем. Кроме того, нужно привязывать точно знаков вывода после запятой к валюте. Не хилое усложнение форматирования. Не все валюты основаны по основанию 100, википедия уверяет: "...1 тунисский динар — 1000 миллимов... Мавритания, где угия делится на 5 хумсов, и Мадагаскар, чья национальная валюта ариари состоит из 5 ираймбиланья." Т.ч. форматирования для вывода и/или отладка - будет еще та себе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 15:25 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
Возможно в тех биржевых операциях важнее была компактность хранения и базовая ариметика типа там сложить или сравнить на больше или меньше. Не возражаю против перевода валют но очевидно что оптимизация шла в сторону наболее частых операций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 15:39 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev P.S. в apache commons либе увидел код, в котором double приводят к int 1) Показывай код и место, где его применили. класс Fraction имеет билдер(не тот, что в GoF), который принимает только double Код: java 1. Мне надо сравнить мою дробь с целым числом. приводить цело число к дроби, со знаменателем 1 ну как-то не очень красиво. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 16:04 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
есть Код: java 1. который принимает double и внутри они дабл кастят к инту. а для просто инта - нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 16:06 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
questionerесть Код: java 1. который принимает double и внутри они дабл кастят к инту. вижу следующий код: Код: java 1. 2. 3. 4. 5. Что и зачем делают - вроде все понятно. Будет ли эквиваленты вызовы: getFraction( (double)1.0 ) и getFraction( "1" ) - на мой взгляд да Преобразование int -> double -> int при отсутствие арифметических операций и одном и том же основании счисления (2) должно быть безопасно. IMHO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 16:30 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsevquestionerесть Код: java 1. который принимает double и внутри они дабл кастят к инту. вижу следующий код: Код: java 1. 2. 3. 4. 5. Что и зачем делают - вроде все понятно. Будет ли эквиваленты вызовы: getFraction( (double)1.0 ) и getFraction( "1" ) - на мой взгляд да Преобразование int -> double -> int при отсутствие арифметических операций и одном и том же основании счисления (2) должно быть безопасно. IMHO ИМХО тоже, только меня смутило, что какого-то 100 пудового доказательства в глубине души я не смог придумать. ну и + 1 может же стать 0.99999999999999999999 или нет таки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 20:13 |
|
||
|
int ->double->int - потеря точности.
|
|||
|---|---|---|---|
|
#18+
делать было нечего и я проверил: спринг просто прекрасно принимает с текстовго поля формы значение цифровое и автоматом его переводит в бигдец. кроме того если этот бигдец отправлять обратно во вьюшку то там с ним можно вполне свободно стандартыми способами крутить-вертеть в жспшках как хочешь, типа ((бигдец1+бигдец2)/бигдец3) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2016, 23:22 |
|
||
|
|

start [/forum/topic.php?fid=59&gotonew=1&tid=2124227]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
50ms |
get topic data: |
12ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
77ms |
get tp. blocked users: |
2ms |
| others: | 254ms |
| total: | 445ms |

| 0 / 0 |
