I am in the process of outputting some results I get from some arrays in C in a nice table format, but I want to cut the value down to 2 digits past the decimal point.
Part of my table code looks something like this (some fake arguments just to get the point across).
printf("%15d %15f %15f\n", arr[i], arr2[i], arr3[i])
I want to trim some of my double variables down so a 55.583159 will just return 55.58 without having to get rid of the double data type. So essentially I'm looking for a way to keep "%15f" and also add into it a "%.2f" in a nice clean manor.
Any suggestions?
you can combine the output format, so if you want 15 digit width (%15f) and 2 places after the decimal (%.2f) you can use (%15.2f)
printf("%15d %15.2f %15.2f\n", arr[i], arr2[i], arr3[i])
this explains different formatting well
Related
I am currently making a small MariaDB database and ran into the following problem:
I want to save a floatingpoint number with only 2 poistions after the decimal point but everything before the decimal point should be unaffected.
For example: 1.11; 56789.12; 9999.00; 999999999999.01 etc.
I have done some research and this is what I am using right now:
CREATE TABLE mytable (
mynumber DOUBLE(10, 2)
)
The problem with this solution is that I also have to limit the number of positions before the decimal point, what I don't want to do.
So is there a possibility to limit the number of positions after the decimal point without affecting the positions before the decimal point or is there a "default number" I can use for the positions before the decimal point?
Don't use (m,n) with FLOAT or DOUBLE. It does nothing useful; it does cause an extra round.
DECIMAL(10,2) is possible; that will store numbers precisely (to 2 decimal places).
See also ROUND() and FORMAT() for controlling the rounding for specific values.
You had a mistake -- 999999999999.01 won't fit in DOUBLE(10,2), nor DECIMAL(10,2). It can handle only 8 (=10-2) digits to the left of the decimal point.
You can create a trigger that intercepts INSERT and UPDATE statements and truncates their value to 2 decimal places. Note, however, that due to how floating point numbers work at machine level, the actual number may be different.
Double precision numbers are accurate up to 14 significant figures, not a certain number of decimal points. Realistically, you need to detemine what is the biggest value you might ever want to store. Once you have done that, the DECIMAL type may be more appropriate for what you are trying to do.
See here for more details:
https://dev.mysql.com/doc/refman/8.0/en/precision-math-decimal-characteristics.html
I have a weird problem if you can call it a problem that is.
Sorry in advance, the database is in french.
I have a table which hold the time a user passed on a specific task
I want to sum the time passed for every task
I'm able to get a sum from the database but the data is kind of wierd
The field is a real number to start with
Example, if I sum 0,35 + 0,63 + 1 I should get 1,98 Data without a sum:
But instead Access give me 1,97999998927116 Data with sum:
If I was to sum only integer the number would be correct
I know I could simply use a round function to get rid of it.
But I would like to know why it does this.
This is because Sum uses floating-point arithmetic if you execute it on a column that is defined as a Single or a Double
Floating-point arithmetic is often inaccurate.
You can avoid these kinds of errors by defining your column as a Decimal or as Currency
I have a SQL Server database that has a table that contains a field of type varbinary(256).
When I view this binary field via a query in MMS, the value looks like this:
0x004BC878B0CB9A4F86D0F52C9DEB689401000000D4D68D98C8975425264979CFB92D146582C38D74597B495F87FEA09B68A8440A
When I view this same field (and same record) using CFDUMP, the value looks like this:
075-56120-80-53-10279-122-48-1144-99-21104-1081000-44-42-115-104-56-10584373873121-49-714520101-126-61-115116891237395-121-2-96-101104-886810
(For the example below, the original binary value will be #A, and the CFDUMP value above will be #B)
I have tried using CAST(#B as varbinary(256)) but didn't get the same value as #A.
What must I do to convert the value retrieved from CFDUMP into the correct binary representation?
Note: I no longer have the applicable records in the database. I need to convert #B into the correct value that can re-INSERT into a varbinary(256) field.
(Expanded from comments)
I do not mean this sarcastically, but what difference does it make how they display binary? It is simply a difference in how the data is presented. It does not mean the actual binary values differ.
It is similar to how dates are handled. Internally, they are a big numbers. But since most people do not know which date 1234567890 represents, applications chose to display the number in a more human friendly format. So SSMS might present the date as 2009-02-13 23:31:30.000, while CF might present it as {ts '2009-02-13 23:31:30'}. Even though the presentations differ, it still the same value internally.
As far as binary goes, SSMS displays it as hexadecimal. If you use binaryEncode() on your query column, and convert the binary to hex, you can see it is the same value. Just without the leading 0x:
writeDump( binaryEncode(yourQuery.binaryColumn, "hex") )
If you are having some other issue with binary, could you please elaborate?
Update:
Unfortunately, I do not think you can easily convert the cfdump representation back into binary. Unlike Railo's implementation, Adobe's cfdump just concatenates the numeric representation of the individual bytes into one big string, with no delimiter. (The dashes are simply negative numbers). You can reproduce this by looping through the bytes of your sample string. The code below produces the same string of numbers you posted.
bytes = binaryDecode("004BC878B0CB9A4F...", "hex");
for (i=1; i<=arrayLen(bytes); i++) {
WriteOutput( bytes[i] );
}
I suppose it is theoretically possible to convert that string into binary, but it would be very difficult. AFAIK, there is no way to accurately determine where one number (or byte) begins and the other ends. There are some clues, but ultimately it would come down to guesswork.
Railo's implementation, displays the byte values separated by a dash "-". Two consecutive dashes indicates a negative number. ie "0", "75", "-56", ...
0-75--56-120--80--53--102-79--122--48--11-44--99--21-104--108-1-0-0-0--44--42--115--104--56--105-84-37-38-73-121--49--71-45-20-101--126--61--115-116-89-123-73-95--121--2--96--101-104--88-68-10
So you could probably parse that string back into an array of bytes. Then insert the binary into your database using <cfqueryparam cfsqltype="CF_SQL_BINARY" ..>. Unfortunately that does not help you, but the explanation might help the next guy.
At this point, I think your best bet is to just restore the data from a database backup.
I'm trying to use this expression to round money type to two decimal point.
=Format(Fields!ClosingBalance.Value,"#,##0.##")
The problem is I'm getting comma(,) in between, comma I do not want.
Also, 100.00 is showing 100. Here I want 100.00.
Please help
Try changing the format string to #.0,00. That will give you two fixed decimal digits. Your 'comma' is in the language settings. You can create your own culture though and assign it to the renderer.
If you don't want a comma, don't place one in the format string:
=Format(Fields!ClosingBalance.Value,"#.##")
If you want 100.00 instead of 100 the correct Format() is
=Format(Fields!ClosingBalance.Value,"0.00")
In format strings # means show character if non-zero and 0 means show character, zero included
I need to multiply a number which is like these 00000000001099 with 0.01 and then convert into two decimal places for e.g., 10.99 after multiplication in a derived column in SSIS package.
Right now I am using these expression (dt_numeric,2,2)((DT_CY)((dt_wstr,14)PRICE) * 0.01) but it is failing.
I get the column price with value 00000000001099 from a flat file after conversion I need to place the value back to a flat file again.
Since your string is 14 long you cannot use DT_I4 - it'll just figure out that this is very wrong and give you the error about potential loss of data. You could edit the error and ignore possible truncations, but a better way is to use a datatype that can hold your number
Your Derivation should look like this:
(DT_NUMERIC,X,2)((DT_NUMERIC,X+2,2)([InputColumn]))*0.01)
In your example
(DT_NUMERIC,14,2)(((DT_NUMERIC,16,2)([PRICE]))*0.01)
By using the extra step with x+2,2 makes you able to hold 99999999999999 into the numeric, then divide by 100 (or multiply with 0.01) and cast back to the minimum possible numeric (x,2) - you might want to use a bigger standardized numeric type - look at MSDN/BOL to see the storage requirements for each of them, and just pick the biggest type taking the same amount of bytes as your requirement.
This should work...
(DT_DECIMAL, 2 )(DT_WSTR, 20 )((DT_I4)#[User::Cost] * 0.01)
While the value 00000000001099 is a number, it cannot be represented this way in a numeric datatype. The leading zeros will be stripped. Because you are showing this number this way, I must presume the number is stored in a string datatype. In the dataflow before your derived column I would recommend the use of the "Data Conversion" component. Convert the string to a numeric type. In the downstream derived column component perform the mathematical multiplcation operation to get the decimal point in the correct place.