Просто реал
Модератор: Дед Пахом
Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
-
- Ветеран
- Сообщения: 390
- Зарегистрирован: 26 Август 2009, 12:41
- Откуда: Moscow
- Контактная информация:
Просто реал
Добрый день!
Немного поплакаться! )))
Кларион 10, Windows 7 (не играет роли)
Задача отбросить третий знак после точки. Переменная Real.
Все время делал это умножая переменную на 100, присвоением Long , ну и делением на 100.
Знаю прекрасно как хранится real в памяти, но все же......
Есть:
X real
Y Long
Z real
X=531.51
Y=X*100
Возмутило вот что:
STOP(Y&'='&X*100)
Дает результат : 53150=53151
Вероятнее всего мишень умножения - real, отсюда и результат.
Cпасает только через присвоение Real:
X=531.51
Z=X*100
Y=Z
Алексей
Немного поплакаться! )))
Кларион 10, Windows 7 (не играет роли)
Задача отбросить третий знак после точки. Переменная Real.
Все время делал это умножая переменную на 100, присвоением Long , ну и делением на 100.
Знаю прекрасно как хранится real в памяти, но все же......
Есть:
X real
Y Long
Z real
X=531.51
Y=X*100
Возмутило вот что:
STOP(Y&'='&X*100)
Дает результат : 53150=53151
Вероятнее всего мишень умножения - real, отсюда и результат.
Cпасает только через присвоение Real:
X=531.51
Z=X*100
Y=Z
Алексей
Просто реал
Я бы вывел поле через format, а потом вырезал нужный кусок. Ну и функция Round может пригодиться.
round( x-0.005, 2) - примерно так...
round( x-0.005, 2) - примерно так...
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4629
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 7 раз
- Поблагодарили: 37 раз
Просто реал
Я на автомате в таких случаях делаю round или int, в зависимости от того, округлить или отбросить надо. И когда работаю с real, то обычно все в real.
y=round(int(x*100)/100,0.01)
x real
y real
Ну и в виде функции оформить, чтобы в проекте не отсвечивать. Что-то типа
y=getCost(x,1)
y=round(int(x*100)/100,0.01)
x real
y real
Ну и в виде функции оформить, чтобы в проекте не отсвечивать. Что-то типа
y=getCost(x,1)
C6/C11, ШВС, tps/btrieve.
-
- Ветеран
- Сообщения: 390
- Зарегистрирован: 26 Август 2009, 12:41
- Откуда: Moscow
- Контактная информация:
Просто реал
Добрый день!
Алексей
Да, такая конструкция читабельней, да и работает)y=round(int(x*100)/100,0.01)
Алексей
-
- ✯ Ветеран ✯
- Сообщения: 4990
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 21 раз
Просто реал
Тут срабатывает, видимо, "правило получателя". Раз нужно целое значение, значит вот так. Вопрос как обойти, если привыкли к не совсем корректным выражениям. Вот лайфхак от меня:Алексей- Софт-Центр писал(а): ↑29 Март 2019, 12:14 X=531.51
Y=X*100
Возмутило вот что:
STOP(Y&'='&X*100)
Дает результат : 53150=53151
Код: Выделить всё
Y = round(X * 100, 1)
We are hard at work… for you.
- Игорь Столяров
- Ветеран движения
- Сообщения: 7385
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 14 раз
- Поблагодарили: 49 раз
Просто реал
Подозреваю, что именно вот в таких обсуждениях и появился лет 30 назад тип данных DECIMAL.
И вроде бы тема была закрыта. Но не везде и не для всех.
И вроде бы тема была закрыта. Но не везде и не для всех.
За теми кто отстал - не возвращаться. (С) Кодекс
-
- Ветеран
- Сообщения: 390
- Зарегистрирован: 26 Август 2009, 12:41
- Откуда: Moscow
- Контактная информация:
Просто реал
Ну, не 30, а по более ))))
Decimal хорош, но он является самым медленным из всех типов.
Так что пока тема не совсем закрыта
Алексей
Decimal хорош, но он является самым медленным из всех типов.
Так что пока тема не совсем закрыта
Алексей
- Игорь Столяров
- Ветеран движения
- Сообщения: 7385
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 14 раз
- Поблагодарили: 49 раз
Просто реал
Биткоины майните ? Ничего, что я по фене ?
За теми кто отстал - не возвращаться. (С) Кодекс
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4629
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 7 раз
- Поблагодарили: 37 раз
Просто реал
Лучше базы еще никто ничего не придумал, как говорят культуристы. Кстати, Игорь, а как Вы храните количество или цену в decimal? Они могут быть с разным количеством знаков после запятой.Игорь Столяров писал(а): ↑29 Март 2019, 15:42Подозреваю, что именно вот в таких обсуждениях и появился лет 30 назад тип данных DECIMAL.
И вроде бы тема была закрыта. Но не везде и не для всех.
C6/C11, ШВС, tps/btrieve.
- Игорь Столяров
- Ветеран движения
- Сообщения: 7385
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 14 раз
- Поблагодарили: 49 раз
Просто реал
Оно как бы да, но всё время париться с контролем округления тоже тяжко …
Берём по максимуму. Например для цены DECIMAL(13,4), для кол-ва DECIMAL(13,3), для коэффициентов DECIMAL(15,6) и т.д.
А реальная используемая точность определяется настройкой - для всего ассортимента (если мы говорим о торговых программах).
Т.е. если есть весовой товар, то кол-во будет 1.000 шт., 2.340 метра, 5.678 кг. и т.д.
Была программа, где точность кол-ва была привязана к его единице измерения - но это на любителя, не красиво в отчётах.
Сразу хочу сказать, что я не антагонист REAL. Этот тип данных используется, но по назначению - там где требуется "беспредельная"
точность вычислений.
За теми кто отстал - не возвращаться. (С) Кодекс
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4629
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 7 раз
- Поблагодарили: 37 раз
Просто реал
Ну, я так и думал. Тогда Вам без round все равно не обойтись. Кроме того, есть еще проблема неявных промежуточных округлений в расчетах. Добавим сюда разницу в скорости работы и специфичность реализации формата decimal в разных субд (помните про историю с btrieve?) - получается, что целесообразность использования decimal вместо real совсем не очевидна. У real есть единственный вопрос с округлениями, которые надо делать явно. Где-то сразу, где-то в конце цепочки расчетов. Не нравится явно писать round с указанием точности, можно подтянуть функции-надстройки для округления суммы, количества и т.п. (iPrice, iSum, iQuantity). У меня все это есть, хотя по привычке на автомате чаще пишу просто round.
C6/C11, ШВС, tps/btrieve.
- Игорь Столяров
- Ветеран движения
- Сообщения: 7385
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 14 раз
- Поблагодарили: 49 раз
Просто реал
Да, конечно - Round() юзается … но такого беспредела как в первом посте этой темы - с DECIMAL в принципе быть не может.
Нет никаких проблем. Btrieve прекрасно работает с DECIMAL, но если это поле используется в ключах и индексах
(что в общем-то экзотика), то надо использовать родной тип PDECIMAL. И всё.
Я придерживаюсь академической точки зрения. Тип данных DECIMAL - создан и предназначен для финансовых расчётов.
REAL - конечно более универсален и совместим в различных системах данных (говорят ещё и быстрее) - но у него своё назначение.
Я знаю одну банковскую систему, где вообще для скорости и точности расчётов используются только целочисленные операции.
С эквайрингом Сбера работали ?
За теми кто отстал - не возвращаться. (С) Кодекс
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4629
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 7 раз
- Поблагодарили: 37 раз
Просто реал
Ну так, в клиппере, если не ошибаюсь, использовались только целочисленные вычисления. А sqlite вообще все в строках хранит. В общем, возможны разные варианты...
C6/C11, ШВС, tps/btrieve.
Просто реал
Как только наступите на REAL-ные грабли, так сразу начнете использовать DECIMAL вместо REAL.
Рассказываю, как можно легко на них наступить.
При различных вычислениях можно получить разницу миллиардные доли или даже меньше.
При попытке записать число в виде строки можете получить число, которое будет выглядеть, например как 1.65.
А число на самом деле 1.65 умноженное на 10 в степени -9.
Рассказываю, как можно легко на них наступить.
При различных вычислениях можно получить разницу миллиардные доли или даже меньше.
При попытке записать число в виде строки можете получить число, которое будет выглядеть, например как 1.65.
А число на самом деле 1.65 умноженное на 10 в степени -9.