To get a %age divide the number by the number of decimal places defined on the column
-
I came across this nugget today. Some values were being stored that were "out" by a factor of 100. Someone claimed it was because the field definition was "7,4 instead of 7,2". I queried this and received this response ...
Quote:
It’s because the system is assuming that the value is to 4 decimal places so 50 become 0.0050 whereas if you assume to decimal places it becomes 0.50 which is correct.
Which was further explained as
Quote:
We have told [redacted] that a field which is a number with no decimal places has an implied DP
Yes really. So the company concerned has taken the "implied DP" and decided that the number should be divided by 10 to the power of the number of decimal places defined. :omg: Who does that? Why would you? Oh - and this is a Financial Services application :doh:
-
I came across this nugget today. Some values were being stored that were "out" by a factor of 100. Someone claimed it was because the field definition was "7,4 instead of 7,2". I queried this and received this response ...
Quote:
It’s because the system is assuming that the value is to 4 decimal places so 50 become 0.0050 whereas if you assume to decimal places it becomes 0.50 which is correct.
Which was further explained as
Quote:
We have told [redacted] that a field which is a number with no decimal places has an implied DP
Yes really. So the company concerned has taken the "implied DP" and decided that the number should be divided by 10 to the power of the number of decimal places defined. :omg: Who does that? Why would you? Oh - and this is a Financial Services application :doh:
-
CHill60 wrote:
Why would you?
Obfuscated API, maybe?
"Five fruits and vegetables a day? What a joke! Personally, after the third watermelon, I'm full."
-
I came across this nugget today. Some values were being stored that were "out" by a factor of 100. Someone claimed it was because the field definition was "7,4 instead of 7,2". I queried this and received this response ...
Quote:
It’s because the system is assuming that the value is to 4 decimal places so 50 become 0.0050 whereas if you assume to decimal places it becomes 0.50 which is correct.
Which was further explained as
Quote:
We have told [redacted] that a field which is a number with no decimal places has an implied DP
Yes really. So the company concerned has taken the "implied DP" and decided that the number should be divided by 10 to the power of the number of decimal places defined. :omg: Who does that? Why would you? Oh - and this is a Financial Services application :doh:
CHill60 wrote:
and decided that the number should be divided by 10 to the power of the number of decimal places defined.
That actually makes sense. With some of the credit card processors I deal with, all amounts are integers with an implied number of decimal places, usually 2, so 1234 is 12.34. So yeah, if I had a spec that said the number of implied decimal places was 4, then 1234 would be .1234 And yes, only in Financial Services. :rolleyes: What I would be more concerned with is, when they divide by 10^n, what's the data type that's holding the result? Hopefully not a float or a double!
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX Calls -
CHill60 wrote:
and decided that the number should be divided by 10 to the power of the number of decimal places defined.
That actually makes sense. With some of the credit card processors I deal with, all amounts are integers with an implied number of decimal places, usually 2, so 1234 is 12.34. So yeah, if I had a spec that said the number of implied decimal places was 4, then 1234 would be .1234 And yes, only in Financial Services. :rolleyes: What I would be more concerned with is, when they divide by 10^n, what's the data type that's holding the result? Hopefully not a float or a double!
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX CallsMarc Clifton wrote:
And yes, only in Financial Services. :rolleyes:
I disagree... In the Automation world, this is used pretty often. I.E. you get analog inputs i.e. [0, 10](V) transformed into decimal (depending on manufacturer or configurations 0 to 27658 or 0 to 32768) to save data transferred into de bus (i.E. for the SCADA Visualization) is usual to send the int16 or Word and say in the panel, this variable contains 2 decimals (1234 = 12.34) or 4 decimals (1234 = 0.1234) This is because the float / double would be 32 bits long, which means you save 2 bytes per variable using this method. And this is still actual because (one of the reasons) the standard "Profi-Bus" speed is 1.5 mbit/s, saving that much bytes still helps.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
I came across this nugget today. Some values were being stored that were "out" by a factor of 100. Someone claimed it was because the field definition was "7,4 instead of 7,2". I queried this and received this response ...
Quote:
It’s because the system is assuming that the value is to 4 decimal places so 50 become 0.0050 whereas if you assume to decimal places it becomes 0.50 which is correct.
Which was further explained as
Quote:
We have told [redacted] that a field which is a number with no decimal places has an implied DP
Yes really. So the company concerned has taken the "implied DP" and decided that the number should be divided by 10 to the power of the number of decimal places defined. :omg: Who does that? Why would you? Oh - and this is a Financial Services application :doh:
About this concrete case, I can't say much. But I have used it a lot in automation. For more details see my answer to Marc.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Marc Clifton wrote:
And yes, only in Financial Services. :rolleyes:
I disagree... In the Automation world, this is used pretty often. I.E. you get analog inputs i.e. [0, 10](V) transformed into decimal (depending on manufacturer or configurations 0 to 27658 or 0 to 32768) to save data transferred into de bus (i.E. for the SCADA Visualization) is usual to send the int16 or Word and say in the panel, this variable contains 2 decimals (1234 = 12.34) or 4 decimals (1234 = 0.1234) This is because the float / double would be 32 bits long, which means you save 2 bytes per variable using this method. And this is still actual because (one of the reasons) the standard "Profi-Bus" speed is 1.5 mbit/s, saving that much bytes still helps.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
Nelek wrote:
In the Automation world, this is used pretty often.
Ah, very true -- I remember doing exactly that sort of thing in the good 'ol days of assembly language programming and interfacing to a variety of hardware.
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX Calls -
Nelek wrote:
In the Automation world, this is used pretty often.
Ah, very true -- I remember doing exactly that sort of thing in the good 'ol days of assembly language programming and interfacing to a variety of hardware.
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX CallsPLC LAD is kind of similar to assembler ;) And still in use almost overall.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
CHill60 wrote:
and decided that the number should be divided by 10 to the power of the number of decimal places defined.
That actually makes sense. With some of the credit card processors I deal with, all amounts are integers with an implied number of decimal places, usually 2, so 1234 is 12.34. So yeah, if I had a spec that said the number of implied decimal places was 4, then 1234 would be .1234 And yes, only in Financial Services. :rolleyes: What I would be more concerned with is, when they divide by 10^n, what's the data type that's holding the result? Hopefully not a float or a double!
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX Calls -
I came across this nugget today. Some values were being stored that were "out" by a factor of 100. Someone claimed it was because the field definition was "7,4 instead of 7,2". I queried this and received this response ...
Quote:
It’s because the system is assuming that the value is to 4 decimal places so 50 become 0.0050 whereas if you assume to decimal places it becomes 0.50 which is correct.
Which was further explained as
Quote:
We have told [redacted] that a field which is a number with no decimal places has an implied DP
Yes really. So the company concerned has taken the "implied DP" and decided that the number should be divided by 10 to the power of the number of decimal places defined. :omg: Who does that? Why would you? Oh - and this is a Financial Services application :doh:
This is a really old programming problem. How would you store a running total of a bank account? Since it has dollars and cents, how about a float? Ok, so then you run into the "floating-point rounding error" problem.
>>> 0.1+0.1+0.1
0.30000000000000004Well... that's pretty bad to be adding/dropping pennies every trillion transactions or so because of cumulative binary representation of decimal digit errors. What else can we do? One of the commonly chosen ways is to used fixed decimal. i.e. Assume a fixed number of decimals and represent everything as integers. One no longer has to worry about fractions of a penny creeping up on you over time if you work in discrete units of pennies. i.e. 100-97 = 3, never 0.30000000000000004 Well... then your manager comes in and says, we need to be able to track hundredths of a penny because the state tax paid even including fractions of a penny. So it is deemed that 4-digits is enough precision to satisfy the need. Now 10000 - 9700 = 300 is still okay, is never gonna be 300.00000000000004 and the same situation applies as before. But your front-end buddies didn't update the website to account for the fact that the database now assumes 4 digits of precision. And thus the problem is born. Fun trivia: "Office Space" movie characters took advantage of this to siphon off millions of dollars back when this was a thing in the 80s-90s-00s.
-
This is a really old programming problem. How would you store a running total of a bank account? Since it has dollars and cents, how about a float? Ok, so then you run into the "floating-point rounding error" problem.
>>> 0.1+0.1+0.1
0.30000000000000004Well... that's pretty bad to be adding/dropping pennies every trillion transactions or so because of cumulative binary representation of decimal digit errors. What else can we do? One of the commonly chosen ways is to used fixed decimal. i.e. Assume a fixed number of decimals and represent everything as integers. One no longer has to worry about fractions of a penny creeping up on you over time if you work in discrete units of pennies. i.e. 100-97 = 3, never 0.30000000000000004 Well... then your manager comes in and says, we need to be able to track hundredths of a penny because the state tax paid even including fractions of a penny. So it is deemed that 4-digits is enough precision to satisfy the need. Now 10000 - 9700 = 300 is still okay, is never gonna be 300.00000000000004 and the same situation applies as before. But your front-end buddies didn't update the website to account for the fact that the database now assumes 4 digits of precision. And thus the problem is born. Fun trivia: "Office Space" movie characters took advantage of this to siphon off millions of dollars back when this was a thing in the 80s-90s-00s.
Yeah - I get that it makes sense. It also saves space in automation etc. TBH we used to do it back in the day (but that was sooo long ago I'd forgotten). My main gripe with this was that this is the only feed (of many) that was defined like this, and it's not the case for all the fields :confused: It looks like the whole shebang was designed by committee! To make things worse the BA involved shares specifications a page at a time, only the bits that she thinks are necessary to do a job (that she is not qualified to do nor has any experience of). This was not on the pages she chose to share with me :|