Decode(false,
ivar>10,'variable is greater than 10',
ivar<25, ' variable is less than 25 ',
'No match found ')
where ivar=25
What will be the answer as tha options are
..Greater than 10
..Less than 25
..No match found
..Error : expression is invalid
I think that the right answer is: variable is less than 25
because of:
Case Statements/Decode Function in Informatica
DECODE
Try to explain
First param is false - that means that we are waiting for the first false
first_search than first_result in params and last - default value that's why i check about the syntax and param numbers and it's ok. Than i'm watch on a value ivar=25
25 < 10 - true, but we need a false. 25 < 25 NO - that's what we are waiting for
If i'm mistaken tell me.
Why do certain random strings produce colors when entered as background colors in HTML?
For example, bgcolor="chucknorris" produces a red background:
<body bgcolor="chucknorris"> test </body>
Conversely, bgcolor="chucknorr" produces a yellow background:
<body bgcolor="chucknorr"> test </body>
This holds true across various browsers and platforms. What’s going on here?
It’s a holdover from the Netscape days:
Missing digits are treated as 0[...]. An incorrect digit is simply interpreted as 0. For example the values #F0F0F0, F0F0F0, F0F0F, #FxFxFx and FxFxFx are all the same.
It is from the blog post A little rant about Microsoft Internet Explorer's color parsing which covers it in great detail, including varying lengths of color values, etc.
If we apply the rules in turn from the blog post, we get the following:
Replace all nonvalid hexadecimal characters with 0’s:
chucknorris becomes c00c0000000
Pad out to the next total number of characters divisible by 3 (11 → 12):
c00c 0000 0000
Split into three equal groups, with each component representing the corresponding colour component of an RGB colour:
RGB (c00c, 0000, 0000)
Truncate each of the arguments from the right down to two characters.
Which, finally, gives the following result:
RGB (c0, 00, 00) = #C00000 or RGB(192, 0, 0)
Here’s an example demonstrating the bgcolor attribute in action, to produce this “amazing” colour swatch:
<table>
<tr>
<td bgcolor="chucknorris" cellpadding="8" width="100" align="center">chuck norris</td>
<td bgcolor="mrt" cellpadding="8" width="100" align="center" style="color:#ffffff">Mr T</td>
<td bgcolor="ninjaturtle" cellpadding="8" width="100" align="center" style="color:#ffffff">ninjaturtle</td>
</tr>
<tr>
<td bgcolor="sick" cellpadding="8" width="100" align="center">sick</td>
<td bgcolor="crap" cellpadding="8" width="100" align="center">crap</td>
<td bgcolor="grass" cellpadding="8" width="100" align="center">grass</td>
</tr>
</table>
This also answers the other part of the question: Why does bgcolor="chucknorr" produce a yellow colour? Well, if we apply the rules, the string is:
c00c00000 => c00 c00 000 => c0 c0 00 [RGB(192, 192, 0)]
Which gives a light yellow gold colour. As the string starts off as 9 characters, we keep the second ‘C’ this time around, hence it ends up in the final colour value.
I originally encountered this when someone pointed out that you could do color="crap" and, well, it comes out brown.
I'm sorry to disagree, but according to the rules for parsing a legacy color value posted by Yuhong Bao, chucknorris does not equate to #CC0000, but rather to #C00000, a very similar but slightly different hue of red. I used the Firefox ColorZilla add-on to verify this.
The rules state:
make the string a length that is a multiple of 3 by adding 0s: chucknorris0
separate the string into three equal length strings: chuc knor ris0
truncate each string to two characters: ch kn ri
keep the hex values, and add 0's where necessary: C0 00 00
I was able to use these rules to correctly interpret the following strings:
LuckyCharms
Luck
LuckBeALady
LuckBeALadyTonight
GangnamStyle
The original answerers who said the color was #CC0000 have since edited their answers to include the correction.
The reason is the browser can not understand it and try to somehow translate it to what it can understand and in this case into a hexadecimal value!...
chucknorris starts with c which is recognised character in hexadecimal, also it's converting all unrecognised characters into 0!
So chucknorris in hexadecimal format becomes: c00c00000000, all other characters become 0 and c remains where they are...
Now they get divided by 3 for RGB(red, green, blue)... R: c00c, G: 0000, B:0000...
But we know valid hexadecimal for RGB is just 2 characters, means R: c0, G: 00, B:00
So the real result is:
bgcolor="#c00000";
I also added the steps in the image as a quick reference for you:
Most browsers will simply ignore any non-hexadecimal values in your color string, substituting non-hexadecimal digits with zeros.
ChuCknorris translates to c00c0000000. At this point, the browser will divide the string into three equal sections, indicating Red, Green and Blue values: c00c 0000 0000. Extra bits in each section will be ignored, which makes the final result #c00000 which is a reddish color.
Note, this does not apply to CSS color parsing, which follow the CSS standard.
<p><font color='chucknorris'>Redish</font></p>
<p><font color='#c00000'>Same as above</font></p>
<p><span style="color: chucknorris">Black</span></p>
The browser is trying to convert chucknorris into a hexadecimal color code because it’s not a valid value.
In chucknorris, everything except c is not a valid hexadecimal value.
So it gets converted to c00c00000000.
This is split into groups of 3, R G B (pad 0's at the end if not multiple of 3)
Of each group only two characters are picked as that is what's allowed.
It finally becomes #c00000, a shade of red.
This seems to be an issue primarily with Internet Explorer and Opera (12) as both Chrome (31) and Firefox (26) just ignore this.
P.S. The numbers in brackets are the browser versions I tested on.
Similarly, Rajnikanth (Indian Chuck Noris) converse to a shade of black:
0a00 00a0 0000 => #0a0000
On a lighter note
Chuck Norris doesn’t conform to web standards. Web standards conform
to him. #BADA55
The WHATWG HTML specification has the exact algorithm for parsing a legacy color value.
The code Netscape Classic used for parsing color strings is open source: netscape/lib/layout/layimage.c.
For example, notice that each character is parsed as a hex digit and then is shifted into a 32-bit integer without checking for overflow. Only eight hex digits fit into a 32-bit integer, which is why only the last 8 characters are considered. After parsing the hex digits into 32-bit integers, they are then truncated into 8-bit integers by dividing them by 16 until they fit into 8-bit, which is why leading zeros are ignored.
This code does not exactly match what is defined in the spec, but the only difference there is a few lines of code. I think it is these lines that were added (in Netscape 4):
if (bytes_per_val > 4)
{
bytes_per_val = 4;
}
The browser will try to convert chucknorris into a hexadecimal value.
Since c is the only valid hex character in chucknorris, the value turns into: c00c00000000(0 for all values that were invalid).
The browser then divides the result into three groupds: Red = c00c, Green = 0000, Blue = 0000.
Since valid hex values for HTML backgrounds only contain two digits for each color type (r, g, b), the last two digits are truncated from each group, leaving an RGB value of c00000 which is a brick-reddish toned color.
chucknorris starts with c, and the browser reads it into a hexadecimal value.
Because A, B, C, D, E, and F are characters in hexadecimal.
The browser converts chucknorris to a hexadecimal value, C00C00000000.
Then the C00C00000000 hexadecimal value is converted to RGB format (divided by 3):
C00C00000000 ⇒ R:C00C, G:0000, B:0000
The browser needs only two digits to indicate the colour:
R:C00C, G:0000, B:0000 ⇒ R:C0, G:00, B:00 ⇒ C00000
Finally, show bgcolor = C00000 in the web browser.
Here's an example demonstrating it:
<table>
<tr>
<td bgcolor="chucknorris" cellpadding="10" width="150" align="center">chucknorris</td>
<td bgcolor="c00c00000000" cellpadding="10" width="150" align="center">c00c00000000</td>
<td bgcolor="c00000" cellpadding="10" width="150" align="center">c00000</td>
</tr>
</table>
The rules for parsing colors on legacy attributes involves additional steps than those mentioned in existing answers. The truncate component to 2 digits part is described as:
Discard all characters except the last 8
Discard leading zeros one by one as long as all components have a leading zero
Discard all characters except the first 2
Some examples:
oooFoooFoooF
000F 000F 000F <- replace, pad and chunk
0F 0F 0F <- leading zeros truncated
0F 0F 0F <- truncated to 2 characters from right
oooFooFFoFFF
000F 00FF 0FFF <- replace, pad and chunk
00F 0FF FFF <- leading zeros truncated
00 0F FF <- truncated to 2 characters from right
ABCooooooABCooooooABCoooooo
ABC000000 ABC000000 ABC000000 <- replace, pad and chunk
BC000000 BC000000 BC000000 <- truncated to 8 characters from left
BC BC BC <- truncated to 2 characters from right
AoCooooooAoCooooooAoCoooooo
A0C000000 A0C000000 A0C000000 <- replace, pad and chunk
0C000000 0C000000 0C000000 <- truncated to 8 characters from left
C000000 C000000 C000000 <- leading zeros truncated
C0 C0 C0 <- truncated to 2 characters from right
Below is a partial implementation of the algorithm. It does not handle errors or cases where the user enters a valid color.
function parseColor(input) {
// todo: return error if input is ""
input = input.trim();
// todo: return error if input is "transparent"
// todo: return corresponding #rrggbb if input is a named color
// todo: return #rrggbb if input matches #rgb
// todo: replace unicode code points greater than U+FFFF with 00
if (input.length > 128) {
input = input.slice(0, 128);
}
if (input.charAt(0) === "#") {
input = input.slice(1);
}
input = input.replace(/[^0-9A-Fa-f]/g, "0");
while (input.length === 0 || input.length % 3 > 0) {
input += "0";
}
var r = input.slice(0, input.length / 3);
var g = input.slice(input.length / 3, input.length * 2 / 3);
var b = input.slice(input.length * 2 / 3);
if (r.length > 8) {
r = r.slice(-8);
g = g.slice(-8);
b = b.slice(-8);
}
while (r.length > 2 && r.charAt(0) === "0" && g.charAt(0) === "0" && b.charAt(0) === "0") {
r = r.slice(1);
g = g.slice(1);
b = b.slice(1);
}
if (r.length > 2) {
r = r.slice(0, 2);
g = g.slice(0, 2);
b = b.slice(0, 2);
}
return "#" + r.padStart(2, "0") + g.padStart(2, "0") + b.padStart(2, "0");
}
$(function() {
$("#input").on("change", function() {
var input = $(this).val();
var color = parseColor(input);
var $cells = $("#result tbody td");
$cells.eq(0).attr("bgcolor", input);
$cells.eq(1).attr("bgcolor", color);
var color1 = $cells.eq(0).css("background-color");
var color2 = $cells.eq(1).css("background-color");
$cells.eq(2).empty().append("bgcolor: " + input, "<br>", "getComputedStyle: " + color1);
$cells.eq(3).empty().append("bgcolor: " + color, "<br>", "getComputedStyle: " + color2);
});
});
body { font: medium monospace; }
input { width: 20em; }
table { table-layout: fixed; width: 100%; }
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"></script>
<p><input id="input" placeholder="Enter color e.g. chucknorris"></p>
<table id="result">
<thead>
<tr>
<th>Left Color</th>
<th>Right Color</th>
</tr>
</thead>
<tbody>
<tr>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
</tr>
</tbody>
</table>
I'm working with php client getting data from Google analytics api. There are a lot of request working ok, but for some google analyticis account i'm getting a null value at [Rows] result even if i have totalResults bigger than 0
As an example:
Rows result is null
[Rows] =>
but in the total data set it says that there are 67 records.
[totalResults] => 67
These are the dimensions i'm asking for
'ga:fullReferrer', 'ga:browser', 'ga:deviceCategory', 'ga:operatingSystem', 'ga:dateHour', 'ga:country','ga:pagePath'
I have a dataset I am working with that is very similar to the one created below. I want to graph the yearly trend in score by state, on the same graph. Additionally, I want to shade a portion of the graph where something happened (in this case a drop in score). Let's say I expected this event to be between 2011 and 2013. I want to shade a light gray rectangle over those years. I think my code is close, but cannot quite get the syntax correct.
Any help accomplishing this would be greatly appreciated. Also, any recommendations on cleaning up the proc template statements (are both needed? or can I combine into one?). Thanks.
Edit: the main issue, I think, is the syntax of the annorec data step.
data statescores;
input state $ year score;
cards;
NC 2010 75
NC 2011 77
NC 2012 72
NC 2013 85
NC 2014 87
SC 2010 72
SC 2011 73
SC 2012 60
SC 2013 79
SC 2014 76
VA 2010 80
VA 2011 80
VA 2012 79
VA 2013 81
VA 2014 83
;
run;
data drop;
input startdate enddate;
datalines;
2011 2013
;
data annorec;
/* length function style color $8; */
retain xsys '2' ysys '1' when 'b';
set drop;
function='rectangle';
height=.4;
width=2;
x=startdate;
y=60;
display="all";
FILLCOLOR='LTGRAY';
output;
/* function='bar'; */
/* x=enddate; */
/* y=90; */
/* color='ltgray'; */
/* style='solid'; */
/* output; */
run;
proc template;
define style styles.stocks;
parent=styles.listing;
style GraphData1 from GraphData1 /
ContrastColor=blue
Color=red
MarkerSymbol="CircleFilled"
Linestyle=1;
style GraphData2 from GraphData2 /
ContrastColor=brown
Color=blue
MarkerSymbol="none"
Linestyle=2;
style GraphData3 from GraphData3 /
ContrastColor=orange
Color=orange
MarkerSymbol="none"
Linestyle=2;
end;
run;
proc template;
define statgraph trend;
begingraph;
entrytitle "Scores for NC, SC, and VA";
discreteattrmap name="stockname" / ignorecase=true;
value 'NC' /
markerattrs=GraphData1(color=red symbol=circlefilled)
lineattrs=GraphData1(color=red pattern=solid);
value 'SC' /
markerattrs=GraphData2(color=orange)
lineattrs=GraphData2(color=green pattern=dot);
value 'VA' /
markerattrs=GraphData3(color=blue)
lineattrs=GraphData3(color=blue pattern=dot);
enddiscreteattrmap;
discreteattrvar attrvar=stockmarkers var=stock
attrmap="stockname";
layout overlay;
seriesplot x=year y=score /
group=state
display=(markers)
name="scores";
discretelegend "scores" / title="State Scores";
endlayout;
endgraph;
end;
run;
/* Plot the score trends */
ods pdf file="/sasdata/username/testgraph.pdf";
ods pdf style=styles.stocks;
proc sgrender data=statescores template=trend sganno=annorec;
run;
quit;
ods pdf close;
I would try to avoid using a discrete attribute map in GTL if you can avoid it. If you have only a few states, you really don't need it; even in your code above it does little other than to override some things you set in the earlier template step. Attribute maps are nice for SGPLOT, but are a pain in GTL in my experience.
In this case, you should try to use the BAND plot to make your gray band. Play with it some, but this should basically give you what you want:
proc sgplot data=statescores;
series x=year y=score/ group=state;
band y=score upper=2013 lower=2011 /transparency=0.8 ;
run;
That makes a pretty nice looking plot with four lines of code, plus if you want to add the colors you can fairly easily (either in an attribute map dataset, or in template code). In general, annotate datasets are often unnecessary in the SGPlot/GTL world, as you can layer plots easily and a lot of annotation can be done via layered plots instead.
If you want more detailed code review, I suggest posting in communities.sas.com, where some of the graph developers who work at SAS will often give suggestions on improvements to code.
I need to generate a GUID and save it via a string representation. The string representation should be as short as possible as it will be used as part of an already-long URL string.
Right now, instead of using the normal abcd-efgh-... representation, I use the raw bytes generated and base64-encode them instead, which results in a somewhat shorter string.
But is it possible to make it even shorter?
I'm OK with losing some degree of uniqueness and keeping a counter, but scanning all existing keys is not an option. Suggestions?
I used an Ascii85 encoding for writing a Guid to a database column in 20 ASCII characters. I've posted the C# code in case it is useful. The specific character set may be different for a URL encoding, but you can pick whichever characters suit your application. It's available here: What is the most efficient way to encode an arbitrary GUID into readable ASCII (33-127)?
Sure, just use a base larger than 64. You'll have to encode them using a custom alphabet, but you should be able to find a few more "url-safe" printable ASCII characters.
Base64 encodes 6 bits using 8, so a 16 byte GUID value becomes 22 bytes encoded. You may be able to reduce that by a character or two, but not much more.
I found this discussion interesting: https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/
Basically you take the 36 characters and turn them into 16 bytes of binary but first sort the three temporal pieces using a stored procedure:
set #uuid:= uuid();
select #uuid;
+--------------------------------------+
| #uuid |
+--------------------------------------+
| 59f3ac1e-06fe-11e6-ac3c-9b18a7fcf9ed |
+--------------------------------------+
CREATE DEFINER=`root`#`localhost`
FUNCTION `ordered_uuid`(uuid BINARY(36))
RETURNS binary(16) DETERMINISTIC
RETURN UNHEX(CONCAT(SUBSTR(uuid, 15, 4),SUBSTR(uuid, 10, 4),SUBSTR(uuid, 1, 8),SUBSTR(uuid, 20, 4),SUBSTR(uuid, 25)));
select hex(ordered_uuid(#uuid));
+----------------------------------+
| hex(ordered_uuid(#uuid)) |
+----------------------------------+
| 11e606fe59f3ac1eac3c9b18a7fcf9ed |
+----------------------------------+
I'm not sure if this is feasible, but you could put all the generated GUIDs in a table and use in the URL only the index of the GUID in the table.
You could also reduce the length of the guid - for example use 2 bytes to indicate the number of days since 2010 for example and 4 bytes for the number of miliseconds since the start of the current day. You will have collisions only for 2 GUIDs generated in the same milisecond. You could also add 2 more random bytes which will make this even better.
(long time, but just came into the same need today)
UUIDs are 128bits long, represented by 32 hex plus 4 hyphens.
If we use a dictionary of 64 (2^6) printable ascii`s, it is just a matter of converting from 32 groups of 4 bits (length of a hex) to 22 groups of 6 bits.
Here is a UUID shortner. Instead 36 chars you get 22, without losing the original bits.
https://gist.github.com/tomlobato/e932818fa7eb989e645f2e64645cf7a5
class UUIDShortner
IGNORE = '-'
BASE6_SLAB = ' ' * 22
# 64 (6 bits) items dictionary
DICT = 'a'.upto('z').to_a +
'A'.upto('Z').to_a +
'0'.upto('9').to_a +
['_', '-']
def self.uuid_to_base6 uuid
uuid_bits = 0
uuid.each_char do |c|
next if c == IGNORE
uuid_bits = (uuid_bits << 4) | c.hex
end
base6 = BASE6_SLAB.dup
base6.size.times { |i|
base6[i] = DICT[uuid_bits & 0b111111]
uuid_bits >>= 6
}
base6
end
end
# Examples:
require 'securerandom'
uuid = ARGV[0] || SecureRandom.uuid
short = UUIDShortner.uuid_to_base6 uuid
puts "#{uuid}\n#{short}"
# ruby uuid_to_base6.rb
# c7e6a9e5-1fc6-4d5a-b889-4734e42b9ecc
# m75kKtZrjIRwnz8hLNQ5hd
You could approach this from the other direction. Produce the shortest possible string representation and map it into a Guid.
Generate the key using a defined alphabet as below:
In psuedocode:
string RandomString(char[] alphabet, int length)
{
StringBuilder result = new StringBuilder();
for (int i = 0; i < length; i++)
result.Append(alphabet[RandomInt(0, alphabet.Length)]);
return result;
}
If you keep the string length < 16, you can simply hex encode the result and pass it to the Guid constructor to parse.
not for exact same problem, but very very close - I have used CRC64, Base64 that and you get 11 bytes, CRC64 has been tested (not proven) to NOT produce duplicates on a wide range of strings.
And since it is 64 bit long by definition - you get the key that is half the size.
To directly answer the original question - you can CRC64 encode any representation of your GUIDs.
Or just run CRC64 on the business key and you will have a 64 bit unique thing that you can then base64.