The MySQL server I'm using is 5.5.41. I also want to note I did not design this database.
The problem I'm running in to, is when using MySQL's TRUCATE function, I seem to be getting an off by one error. As in it's not accurate. See the attached screen shot for what I mean.
If the option of changing the table structure was limited, is there a way around fixing this bug and returning the correct number?
Floating point numbers are not exact. The actual value of 70.85 is probably something like 70.84999999, but it's being shown rounded off to the nearest 2 decimal places. TRUNCATE takes the actual value and just discards all the decimal places beyond what you requested, so it always rounds down, not to the nearest value, so it becomes 70.84.
If you don't want to lose accuracy like this, use the DECIMAL datatype instead of FLOAT. You could also use ROUND(reserve_amount, 2) instead of TRUNCATE(reserve_amount, 2).
Related
I've only been studying Zabbix for two mere weeks. I've been finding my way around the software pretty well, yet I don't really seem to understand calculated items.
I'm sure you've heard it before. I want to monitor the ink level on one of my printers. I've already obtained the OID's that are bound to the ink levels. The value of 100% would be '8000'. So 50% would be 4000.
I've checked out the Zabbix guide, but that didn't really seem to help me out. I understand the concept it tries to explain, but I don't understand what exact parameters I should be using. This is what I have so far, which is obviously not working.
100*last("cyan")/last("8000")
I've created five seperate items, one for each colour and one that is simply the value '8000'. Could anyone give me a little bit of insight? I'd love to get more familiar with the software due to it's near endless possibilities!
Many thanks,
Thomas.
Item of just "8000" is most likely not needed. You said "obviously not working", but did not say how it fails. In any case, the following should work - assuming you have an item with key "cyan" and that item is getting values.
last(cyan)/80
You haven't specified what is your goal, but the above will return %, assuming 8000 is 100%.
So that's about calculated items. You actually don't need them if all you want is the value in % and the scale is the same for all of them. Instead of adding yet another item (the calculated one), do the calculation right in the original item - set the custom multiplier to 0.0125. This was configured differently in earlier versions of Zabbix, see the corresponding version in the manual if using something older than 3.4.
Hi My Fellow Access user.
I am using Access to do reconciliation, by link two Excel sheets. the number are two decimal.
Linked Table view
However, when i was trying to run subtraction between two numbers both 2 decimals, it return results like this:
Appreciate if anyone know how this could happen, and what steps I need to take to fix it?
Thanks
Tian
Don't use the linked Excel data directly.
Create simple select queries where you can convert and trim your data. Like:
Select SomeField, Description, CCur([TotalAmount]) As Total
From YourLinkedExcelTable
When dealing with amounts, always use Currency as data type.
Now, calculate your Diff using the query.
For a linked Excel sheet, the column type is probably Double, a 64-bit floating point number. This problem you experience is probably due to an inherent limitation of floating point numbers and is not unique to Excel or Access.
This Stack Overflow question asks essentially the same thing: Why does this subtraction not equal zero?
Excel is no exception, only that the default formatting might not show the necessary precision to reveal the behavior. Selecting scientific format or increasing the number of displayed decimal places will reveal the same behavior.
Consider the following:
For monetary amounts, convert values to Currency using the CCur() function. Currency is a fixed-decimal value, but be aware it only has 4 digits to the right of the decimal. (Updated to reflect advice from Gustav)
Convert values to fixed-point Decimal type using CDec() function before performing the math. There is no native VBA Decimal type, so these are variants containing Decimal values. But upon conversion back to floating-point, it is still possible to experience extra digits.
Round the results using the Round() function, but again this is not guaranteed to eliminate floating-point limitations.
Choose an explicit format for displaying the numbers.
I have read the posts about divide by zero, and using functions to overcome it, which I usually do with normal reports.
What I can't find is how to handle the divide by zero issue on calculated fields. You can't use a function because of aggregation (which calculated fields does not allow), so I do not know how to get round it.
I could write some more SQL just for this pie chart I am doing, but it is part of an existing report and ideally I want to use what is already there.
Does anybody know how to handle divide by zero issues for calculated fields?
Example: =Fields!Other.Value/Fields!Total.Value*100
Thanks,
Kevin.
It's been a while since I used reporting services, but can't you validate the Total value before doing the division? Something like this:
=iif(Fields!Total.Value>0,Fields!Other.Value/Fields!Total.Value*100,0)
I need to use a percentage in my Rails app. In any view, including when it is entered by the user, the format will need to be the hundreds format, 100.000. When it's used in calculations, it needs to be represented in the hundredths format, 1.00000.
My migration (I'm adding the column to an existing table) has the following line:
add_column :worker, :cash_split, :decimal, :precision => 6, :scale => 5
So, as of right now, I'm storing it in the hundredths (1.00000) format. My basis for choosing to store it in this format is that i figure it will mean cleaner business logic (i.e. no worker.cash_split / 100.0.to_d code hanging around) when i need to do multiplication.
My only other thought was maybe abusing the composed_of method. I could store the data in the hundreds (100.000) format as cash_split and then make an attribute accessor cash_split_percentage that returns cash_split in its 1.0000 format counterpart.
Your first thought is the right one...don't overthink it.
You should definitely store percentage numbers in the database in hundredths format. And use that format in all of your Ruby calculations.
Percentage figures are a display convention. Eg the number 0.45 is displayed as 45%. As such, use a View helper to convert your percentage figures from their internal format (decimal numbers) to your chosen display format--a string which includes the % sign.
It depends.
First off, I don't think there is a right way or a wrong way. It's your app and your code, so you can do what you want, but you should do what makes the most sense for your circumstances.
As #BishmaStornelli commented in #LarryK's answer,
How would you handle percentages in forms? Users will want to enter it like 45% but it should be stored as 0.45. Nevertheless, if the user inputs another field wrong and the form is re-rendered, the percentage field sould have 45 and not 0.45. With this I want to say that a callback may not be the final solution.
You're damned if you do and you're damned if you don't. You either clutter up your calculation code with divisions by 100, or you clutter up your Model and Views with converting from a decimal to a percentage and back again.
I suppose the answer depends on which is more heavy in your application.
If you are conducting lots of calculations based on this percentage then storing it as a decimal would seem like the best approach that will provide the least amount of code and the clearest, cleanest code to view and maintain.
However, if you are not conducting lots of calculations based on this percentage (maybe only a couple) then it may make more sense to not have to write a bunch of code in the Model and Views to display the decimal as a nice percentage, and just divide by 100 when you need to perform a calculation.
In our particularly case, and the reason I ended up here, we want the User to enter the value as a nice percentage, like 75%, in the form. And we always want to display this value in Views, Reports, etc. as a nice clean percentage, like 75%. And we only need to perform a calculation with this value a couple of times.
So, it makes sense in our case to store the value as a percentage in the database. It makes saving and viewing much easier, and only incurs a "divide by 100" penalty in the couple of spots we perform a calculation on it.
Hopefully, that helps others and provides a different viewpoint to the already well-written and accepted answer.
Thanks #BishmaStornelli for the alternative perspective!
The problem is this, when I add two or more doubles from a table to a view, instead of giving me the right results, it adds a about ten or so more digits. For example 0.5+1.5=1.99999999998 or 5.5+8.5=14.0000000001. Any ideas?
(I know this is sort of n00b question and I remember having to deal with stuff like that in the exams at 9th grade, but I just cannot remember how I did it back then :P)
http://dev.mysql.com/doc/refman/5.0/en/string-functions.html#function_format
You can format numbers this way if thats what your after?
Adding 1 and 1 as floats or doubles should not result in anything but 2.
I find it hard to believe that 0.5 + 1.5 comes out to anything but 2.
All these numbers can be represented correctly in binary floating point.
I hate to say I don't believe your examples, but I don't. :-)
However, I do believe that you might have trouble with a number such as 1.1.
Why? Because 1/10 turns out to be a repeating decimal in binary.
The problem comes when trying to convert floating point numbers between decimal and binary representations. Some numbers make the trip fine, but others are only approximated.
However, if your examples really work like that, I have no idea what is happening, and I'd love to know.
floating point numbers are ALWAYS mere approximations. :-) If precision matters, figure out a way to use integers.
In my experience, when I used decimal datatype instead of float/double, I did always got the precise results.
This article explains the issue pretty well.
In a nutshell, very large, or very small floating point numbers can result in a loss of precision during calculations.
Don't expect integers when you work with floating point types.
Not sure if you're looking for an explanation or a solution, but since you've already gotten pointers to good explanations....
If you need your numbers to behave like integers, use integers. If you need a finite degree of precision (ie, two decimal places, for fields that represent money), store it as an integer anyway, but multiply it by whatever factor of 10 you need to get rid of the decimal when you put it into the database and divide by the same when you pull it back out.
So if you're representing a widget that costs $3.99, you put 399 into the WIDGET.cost field.
Dunno if that applies to your situation or not. But the general rule of thumb is that floating point numbers are ALWAYS mere approximations. :-) If precision matters, figure out a way to use integers.