SSRS 2008 Negative Currency Values - ssrs-2008

I have a column with negative currency values. I have changed the text box properties to display negative currency values as '-$##.##' but when I run the report the negative values still show up as (##.##). Any ideas on what is causing this or if there is a format string to fix the issue?
My code is:
Format(Sum(Fields!Column1.Value, "DataSet1"),"C2")
EDIT: I SOLVED IT The code below should work for anyone else with the issue.
Format(Sum(Fields!Column1.Value, "DataSet1"),"$#.00;-$#.00")

What is your Locale? For the U.S., the parenthesis seems to be the expected result for negative numbers for the C format.
123.456 ("C", en-US) -> $123.46
123.456 ("C", fr-FR) -> 123,46 €
123.456 ("C", ja-JP) -> ¥123
-123.456 ("C3", en-US) -> ($123.456)
-123.456 ("C3", fr-FR) -> -123,456 €
-123.456 ("C3", ja-JP) -> -¥123.456
https://msdn.microsoft.com/en-us/library/dwhawy9k(v=vs.110).aspx

Related

lubridate assigns unrealistic date

I have a vector of dates in either dmY formats and Ymd format.
These are all dates in the last century.
From each, I need to extract just the year (Y).
I use the following code
library(lubridate)
sampleDates <- c(20100517,17052010)
result <- year(parse_date_time(x, guess_formats(as.character(x), c("Ymd","dmY"))))
result
517 2010
However, I expect something like
result
2010 2010
Here is a base R solution to your problem that takes a particular difficulty into account with your date format. Let's say you have the date 20112020, i.e. November 20th in the year 2020. For your function, it is not easy to distinguish which part of the string is the year - is it 2011 or 2020? The following code takes this difficulty into account, though let me mention that there surely must be simpler solutions.
Code
NonID <- grepl("^2", sampleDates) & (substr(sampleDates, 5, 5) == "2")
ID <- !NonID
dates_normal <- sampleDates[!NonID]
dates_special <- sampleDates[NonID]
normal_years <- as.numeric(c(substr(dates_normal, nchar(dates_normal) - 3, nchar(dates_normal)), substr(dates_normal, 1, 4)))
normal_years <- normal_years[normal_years > 1999]
special_years <- as.numeric(substr(dates_special, nchar(dates_special) - 3, nchar(dates_special)))
all_years <- c(normal_years, special_years)
all_years
> all_years
[1] 2010 2010
Explanation
First, we divide the date vector into those dates which exhibit the indistinguishability (dates_normal) and those which do not (dates_special). Then, for the normal dates, we use the substr() function to extract the first four and last four digits of the string and keep only those values which exceed 2000. For the special dates, we only keep the last four digits because the year can't be possibly included in the first four digits for this date format.

How to convert datetime to day name and month name in erlang?

How to get following DateTime in Erlang?
Fri Jul 13 19:12:59 IST 2018
TL; DR
Use the exceptional qdate for all your date/time formatting, converting, and timezone handling. Look at the Demonstration section in particular to get the gist, and adjust to your needs.
Erlang's date handling, in my opinion, is convoluted and lacking in the major functionality that's needed for proper date handling. It's getting better, but not quite there. Moreover, timezone handling is primitive at best.
qdate's functions will take (almost) any date format and convert to any date format, while using either an implicit timezone (setting the timezone on a per-process basis), or by setting a specific timezone.
In any case, if you go custom, you will end up with something similar to this:
1> {{Year, Month, Day}, {Hour, Minute, Second}} = calendar:now_to_datetime(erlang:now()).
{{2018,7,13},{14,39,45}}
2> lists:flatten(io_lib:format("~4..0w-~2..0w-~2..0wT~2..0w:~2..0w:~2..0w",[Year,Month,Day,Hour,Minute,Second])).
"2018-07-13T14:39:45"
...not good ;)
Those are my two cents. Cheers!
I found the solution.
A = calendar:universal_time().
qdate:to_string(<<"D M j G:i:s T Y">> , <<"IST">>, A).
You can use http://uk3.php.net/manual/en/function.date.php for different formatting. Advisable to use only if you have to support legacy system because this function call use seems expensive.
date_time() ->
{{Year, Month, Day},{ Hour, Minute, Second}} = calendar:local_time(),
DayOfWeek = calendar:day_of_the_week({Year, Month, Day}),
DayName = day_check(DayOfWeek),
MonthName = month_check(Month),
lists:flatten(io_lib:format("~3..0s ~3..0s ~2..0w ~2..0w:~2..0w:~2..0w IST ~4..0w", [DayName, MonthName, Day, Hour, Minute, Second, Year])).
day_check(1) -> 'Mon';
day_check(2) -> 'Tue';
day_check(3) -> 'Wed';
day_check(4) -> 'Thu';
day_check(5) -> 'Fri';
day_check(6) -> 'Sat';
day_check(7) -> 'Sun'.
month_check(1) -> 'Jan';
month_check(2) -> 'Feb';
month_check(3) -> 'Mar';
month_check(4) -> 'Apr';
month_check(5) -> 'May';
month_check(6) -> 'Jun';
month_check(7) -> 'Jul';
month_check(8) -> 'Aug';
month_check(9) -> 'Sep';
month_check(10) -> 'Oct';
month_check(11) -> 'Nov';
month_check(12) -> 'Dec'.

String formatting in SyncFusion?

String formatting:
"#0.##%;(#0.##%); "
The above will format a double into a percentage string with two decimal points, put it into parenthesis if it’s negative and leave it a blank string if it’s zero.
The problem is, if the double value has no decimal points, eg if the value is 2, then for some reason the resulting string is “2%” and not “2.00%”.
My question is: how do I make it go to “2.00%”?
p.s. the formatting is happening on a Syncfusion grid cell object and requires a string mask.
p.s.s. the existing functionality described above in italics must be maintained.
Hashes denote an optional character. Use “#0.00%” (etc.).
You can use the string format #0.00% for 2 digital places.
"#" means optional to show the digital while "0" means mandatory to show. In this case (#0.00%) stands for the 2 digital places are mandatory and the digital right before the "." is mandatory as well. If there is any digital before the "0", it will show up. Otherwise, it won't as this digital is optional.
e.g.
2 -> 2.00%
12 -> 12.00%
120 -> 120.00%
11.234 -> 11.23%
And using "P" or "P2" also works fine in this case. "P" stands for percent, "2" is the amount of digital places.
e.g.
double number = .2468013;
Console.WriteLine(number.ToString("P", CultureInfo.InvariantCulture));
// Displays 24.68 %
Console.WriteLine(number.ToString("P",CultureInfo.CreateSpecificCulture("hr-HR")));
// Displays 24,68%
Console.WriteLine(number.ToString("P1", CultureInfo.InvariantCulture));
// Displays 24.7 %
You can refer to the MSDN for more details.

Coercing float into unsigned char on ARM vs. Intel

When I run the following C code on an Intel machine...
float f = -512;
unsigned char c;
while ( f < 513 )
{
c = f;
printf( "%f -> %d\n", f, c );
f += 64;
}
...the output is as follows:
-512.000000 -> 0
-448.000000 -> 64
-384.000000 -> 128
-320.000000 -> 192
-256.000000 -> 0
-192.000000 -> 64
-128.000000 -> 128
-64.000000 -> 192
0.000000 -> 0
64.000000 -> 64
128.000000 -> 128
192.000000 -> 192
256.000000 -> 0
320.000000 -> 64
384.000000 -> 128
448.000000 -> 192
512.000000 -> 0
However, when I run the same code on an ARM device (in my case an iPad), the results are quite different:
-512.000000 -> 0
-448.000000 -> 0
-384.000000 -> 0
-320.000000 -> 0
-256.000000 -> 0
-192.000000 -> 0
-128.000000 -> 0
-64.000000 -> 0
0.000000 -> 0
64.000000 -> 64
128.000000 -> 128
192.000000 -> 192
256.000000 -> 0
320.000000 -> 64
384.000000 -> 128
448.000000 -> 192
512.000000 -> 0
As you can imagine, this sort of difference can introduce horrible bugs in cross-platform projects. My questions are:
Was I wrong to assume that coercing a float into an unsigned char would yield the same results on all platforms?
Could his be a compiler issue?
Is there an elegant workaround?
The C standard doesn't have very hard rules for what you're trying to do. Here's the paragraph in question, from Section 6.3.1 Arithmetic operands (specifically Section 6.3.1.4 Real floating and integer):
When a finite value of real floating type is converted to an integer type other than _Bool, the fractional part is discarded (i.e., the value is truncated toward zero). If the value of the integral part cannot be represented by the integer type, the behavior is undefined.
There's even a more specific footnote about the exact case you're asking about:
The remaindering operation performed when a value of integer type is converted to unsigned type need not be performed when a value of real floating type is converted to unsigned type. Thus, the range of portable real floating values is (−1, Utype_MAX+1).
UtypeMAX+1 for your case is 256. Your mismatched cases are all negative numbers. After the truncation, they're still negative and are outside the range (-1, 256), so they're firmly in the 'undefined behaviour' zone. Even some of the matching cases you've shown, where the floating point number is greater than or equal to 256, aren't guaranteed to work - you're just getting lucky.
The answers to your numbered questions, therefore:
Yes, you were wrong.
It's a compiler issue in the sense that your different compilers give different results, but since they're allowed to by the spec, I wouldn't really call that the compiler's fault.
It depends on what you want to do - if you can explain that better, someone on SO community is almost certain to be able to help you out.
I'm going to answer to 3 in my own question but will not flag that as the accepted answer. The trick seems to be a simple cast in the coercion:
c = (char) f;
Using (int) or (short) works too. I'm still interested to find out where the cause of this problem lies: compiler or processor.
The specific issue you're dealing with looks like endianness to me. Try replacing one or the other implementation with c = *((char *)&f + sizeof(float) - 1); or something similar to get the last byte of the float, and see if it matches the result for the other platform.
In general, the behavior will depend on endianness, word length and floating point capabilities of the processor, and how the compiler targets that. ARM is bi-endian, so it might or might not match IA byte ordering. It seems there's also no general guarantee that one C implementation supports the same floating point format as another: Fixed-size floating point types .
Are you using this in production code? I'd look very hard at why this needs to be done. One or the other type is probably not being used as intended. Workarounds are not going to be elegant.

NSNumberFormatter to display custom labels for 10^n (10000 -> 10k)

I need to display numbers on a plot axis. The values could change but I want to avoid too long numbers that will ruin the readability of the graph.
My thought was to group every 3 characters and substitute them with K, M and so on (or a custom character).
So:
1 -> 1,
999 -> 999,
1.000 -> 1k,
1.200 -> 1.2k,
1.280 -> 1.2k,
12.800 -> 12.8k,
999.999 -> 999.9k,
1.000.000 -> 1M,
...
Note that probably I'll only need to format round numbers (1, 10, 1000, 1500, 2000, 10000, 20000, 30000, 100000, ...).
Is that possibile with NSNumberFormatter? I saw that it has a setFormat method but I don't know how much customizable it is.
I'm using NSNumberFormatter cause the graph object I use wants it to set label format and I want to avoid changing my data to set the label.
You can use this code:
let formatter = NSNumberFormatter()
formatter.multiplier = 0.001
formatter.positiveFormat = "#,###k"
formatter.zeroSymbol = "0"
return formatter
It helped me to convert the currency values:
2000 -> 2k
10000 -> 10k
No. The closest you can get is Scientific Notation. Have a look here for how to create a format for that. You could obviously quite easily do the k, M etc substitution yourself though.