Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Dima TЭто просто частный случай, демонстрирующий что нет идеального решения проблем работы с числами с фиксированной разрядностью. BINARY FIXED(n,m) DECIMAL FIXED(n,m) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2016, 21:54 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
ИзопропилBINARY FIXED(n,m) DECIMAL FIXED(n,m) Краткость - сестра таланта, но тут непонятно из какой оперы эти понятия. Ссылку бы дал, или еще как-то намекнул о чем речь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2016, 22:01 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Dima T, это PL/1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2016, 22:08 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Челы. Толи от воскресенья... толи от количества выпитого пива туплю. Глянте плиз пред ваши ясны очи. На каждой нечетной итерации мантисса удваивает свое значение. На четной - добавляет единицу. DoubleFormat после некой итерации перестает изменять свое raw-значение. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. Отчотик Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2016, 23:06 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
mayton, это так и задумано? dslow((uint32_t)(du2.iv && 0xFFFFFFFF)); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2016, 05:13 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Блин... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2016, 08:52 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Выводи в hex, в нем смотреть удобнее Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Результат Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2016, 09:37 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Не совсем удобно. Группы битов sign-exponent-mantissa не кратны 4. Граница пересекает 1-hex символ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2016, 10:20 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Сдвигами лечится. PS у тебя еще в double с мантиссой косяк, не 53, а 52 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2016, 10:28 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Dima T Выводи в hex, в нем смотреть удобнее Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Результат Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. Давно для этого изобрели формат %a http://www.cplusplus.com/reference/cstdio/printf/?kw=printf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2016, 10:38 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Dima TСдвигами лечится. PS у тебя еще в double с мантиссой косяк, не 53, а 52 Ааа точно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2016, 11:06 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Хм... последний бит мантиссы немогу задействовать... Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2016, 11:24 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Появилась мысль как сделать сравнимым double - округлять по окончанию расчета до необходимого количества знаков, но не более 15-ти, т.е. 14 после запятой. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. Результат Код: plaintext 1. 2. 3. т.е. надо сделать тип, который кроме значения содержит точность, например при умножении точности складываются, при делении устанавливается максимально возможная для результата и т.д. Тогда можно проверять на равенство, т.е. это будет полноценный числовой тип. Да и NULL там есть, в смысле NaN. Или как минимальный вариант: просто сделать функцию округления до заданного количества десятичных знаков и функцию сравнения, которая при проверке равенства округлит очень близкие значения. Другой вопрос как затестить, 10^15 уже многовато для перебора, а тут еще варианты с разным количеством знаков после точки 14.1, 13.2, 12.3 и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 14:25 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Dima T, ну скажи пожалуйста зачем нужен такой тип данных который нужно округлять после каждой операции с ним? А как просядет нагрузка? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 14:29 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
maytonDima T, ну скажи пожалуйста зачем нужен такой тип данных который нужно округлять после каждой операции с ним? А как просядет нагрузка? Тоже об этом думаю. Надо округления сводить к минимуму, т.е. в конце расчета например. Фиг с ним с округлением, тормоза при сравнении важнее, а они тоже есть. Тема не философская, мне надо для C# определиться в чем деньги хранить. Есть быстрый и компактный double и есть тормозной и неудобный decimal (хитрая 128 битная структура) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 14:47 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Dima TТоже об этом думаю. Надо округления сводить к минимуму, т.е. в конце расчета например. Фиг с ним с округлением, тормоза при сравнении важнее, а они тоже есть. Я-бы не занимался округлением. А просто очертил-бы безопасные операции (присвоение целого). И проверил-бы какие еще можно назвать такими. Тема не философская, мне надо для C# определиться в чем деньги хранить. Есть быстрый и компактный double и есть тормозной и неудобный decimal (хитрая 128 битная структура) Да и нечего думать. Ясен пень храни все в decimal. Деньги важны и копейку терять нельзя. А вот если тебе надо создать OLAP-кубики и быстро гонять по ним аналитику то здесь double подходит идеально. Может даже и float -бы подошел. Датамайнинг там... принятие решений. Туда-же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 15:24 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Dima T(хитрая 128 битная структура) что там хитрого? The binary representation of a Decimal number consists of a 1-bit sign, a 96-bit integer number, and a scaling factor used to divide the integer number and specify what portion of it is a decimal fraction. The scaling factor is implicitly the number 10, raised to an exponent ranging from 0 to 28. The return value is a four-element array of 32-bit signed integers. The first, second, and third elements of the returned array contain the low, middle, and high 32 bits of the 96-bit integer number. The fourth element of the returned array contains the scale factor and sign. It consists of the following parts: Bits 0 to 15, the lower word, are unused and must be zero. Bits 16 to 23 must contain an exponent between 0 and 28, which indicates the power of 10 to divide the integer number. Bits 24 to 30 are unused and must be zero. Bit 31 contains the sign: 0 mean positive, and 1 means negative. Note that the bit representation differentiates between negative and positive zero. These values are treated as being equal in all operations. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 15:32 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Dima TПоявилась мысль как сделать сравнимым double - округлять по окончанию расчета до необходимого количества знаков, но не более 15-ти, т.е. 14 после запятой. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. Результат Код: plaintext 1. 2. 3. т.е. надо сделать тип, который кроме значения содержит точность, например при умножении точности складываются, при делении устанавливается максимально возможная для результата и т.д. Тогда можно проверять на равенство, т.е. это будет полноценный числовой тип. Да и NULL там есть, в смысле NaN. Или как минимальный вариант: просто сделать функцию округления до заданного количества десятичных знаков и функцию сравнения, которая при проверке равенства округлит очень близкие значения. Другой вопрос как затестить, 10^15 уже многовато для перебора, а тут еще варианты с разным количеством знаков после точки 14.1, 13.2, 12.3 и т.д. :) у меня на Delphi еще в 99-м году была написана библиотека, с чудными функциями round2(), round100() фактически да, так и было, любые попытки вычислить sum := round2(price * amount); причем round2 был написан очень хитро, с замглавбуха делали отдельное регрессионное тестирование, перебрав практически все числа. просто чтоб копейки сходились. и все равно пришлось прикручивать еще и финальную коррекцию на сумму счета. в общем трах был незабываемый. что-то вроде этого Код: pascal 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 16:05 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
maytonДа и нечего думать. Ясен пень храни все в decimal. Деньги важны и копейку терять нельзя. Копейки все равно теряются - как ни крути. Округления никто не отменял т.к. учет идет с точностью до копейки. Есть дробные количества, разные методики расчета НДС и т.д. и т.п. Недавно прочитал что оказывается есть даже специальное банковское округление : округление происходит к ближайшему чётному, то есть 2,5 => 2, 3,5 => 4. Наверно в банках при регулярном начислении процентов эти копейки выливаются в круглую сумму. C double проблемы видятся именно в сравнении, т.к. даже при больше/меньше есть проблемы. Например "цена < 100", а она записана с погрешностью как 99.99999999999 и все, попадет в выборку. Хотя можно написать "цена < 99.9999" но это ж помнить постоянно надо. ХЗ почему MS похоронил тип money (64-битное целое со сдвигом на 4 разряда при выводе) и придумал этот decimal в C#. Int64 гораздо быстрее чем структура обрабатывается, т.к. нативный он для процов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 16:27 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Dima TХЗ почему MS похоронил тип money (64-битное целое со сдвигом на 4 разряда при выводе) и придумал этот decimal в C#. чтоб NUMERIC(n,m) от SQL сервера получить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 16:46 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Dima TmaytonДа и нечего думать. Ясен пень храни все в decimal. Деньги важны и копейку терять нельзя. Копейки все равно теряются - как ни крути. вопрос не в том, что они теряются. вопрос в том, что они должны теряться правильно. что еще больше усугубляется тем, что калькуляторы используют именно decimal float ну и базы данных - тоже все числа считают как decimal соответственно, во избежание расхождений на эти самые копейки - нужно везде использовать тот-же decimal а money выпилили из-за невместительности, плюс он не бросает исключение на переполнении. плюс у него есть существенный косяк - он операцию умножения дробных до округления делает не совсем верно. плюс цены и количества могут иметь более 4-х знаков после запятой. короче тип не годный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 16:51 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Dima T, банковское округление - почти случайный термин, оно настолько же банковское, насколько голландское, Гауссово или статистическое. К счету денег именно как денег - непосредственного отношения не имеет . Просто в IEEE 754 именно оно оказалось рекомендованным способом округления по умолчанию. Потому библиотечные коды от Microsoft предпочитают его. И да, в силу своих статистических свойств (оно дает несмещенную оценку среднего) удобнее при вычислении баланса в тысячах . Про деньги - другая история. И округление у денег - с приседом. (Fixed point ариметика обладает "хорошими" свойствами по сложению, но на умножении приезжают почти все те же истории.) Пусть некий процесс счетом суммы по левой стороне дает 12.345, а по правой - 12.34499999999999999999999999 Это - одно и то же число. Только обычный "честный" Round(,2) для одного из них даст 12.35, а для другого - 12.34 При округлении в деньгах важно, чтобы в позиции, используемой для решения о том, куда округлять ( в данном случае в третьей) стояла точная цифра. Этого можно добиться, только если предварительно провести округление до позиции дальше третьей. + исторически существовали (может и сейчас есть) деньги с тремя знаками после запятой. Поэтому в денежном типе у Microsoft заявлено 4 знака. Процедура приведения к этому типу гарантирует Round(,5) и все получившиеся 4 знака - точные. Теперь, наконец, уже в рамках этого типа, Round(,2) правомерен и дает правильный результат. Т.е. если ты хочешь писать свой денежный тип, ты, так или иначе, должен повторить для него технику двойного округления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 17:24 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
Склоняюсь к мысли вести учет в копейках. int32 для цен, int64 для сумм. Как вариант может не экономить и int64 для цен тоже. Есть нагрузка из-за форматирования на входе-выходе, но тут надо потестить. У меня самодельные ToString()/FromString(). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 19:50 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
42 949 672 рублей 95 копеек в int? Хватит-ли. Кроме того ограничения могут стрельнуть в другом месте например если будет расчет арифметического среднего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 20:33 |
|
||
|
inline extern из библиотеки, как правильно декларировать-имплементировать?
|
|||
|---|---|---|---|
|
#18+
mayton42 949 672 рублей 95 копеек в int? Хватит-ли. Кроме того ограничения могут стрельнуть в другом месте например если будет расчет арифметического среднего. В моем случае хватит, для цен сейчас хватает smallmoney в MSSQL т.е. максимум 214'748,3648 р., другое дело посчитать sum(price * kol) по большому количеству документов. Переход на копейки даст предел 21'474'836,48 что тоже немного, а int64 даст предел 92'233'720'368'547'758.08 что есть дофига. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 20:59 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=39285374&tid=2018218]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
166ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 282ms |

| 0 / 0 |
