A bag contains 16 balls of following colors: 8 red, 4 blue, 2 green, 1 black and 1 white. Anisha picks a ball randomly from the bag and messages Babu its color using a string of zeros and ones. She replaces the ball in the bag and repeats this experiment many times. What is the minimum expected length of the message she has to convey to Babu per experiment?
(a)3/2
(b)log 5
(c)15/8
(d)31/16
(e)2
According to me, since the ball is taken out with replacement. At any time, there are 16 balls of 5 different colors in the bag. To encode 5 colors, ceiling of log5 (base 2) i.e. 3 bits should be needed but the answer given is (15/8). Can someone point out my mistake and provide some hint for the correct solution?
using static huffman compression you can encode the more common colours in fewer bits than the rare colours, that being the case on can expect that common colours will usually be chosen.
eg:
red 1
blue 01
green 001
white 0001
black 0000
on average from 16 draws there will be
8 reds = 8 bits
4 blues = 8 bits
2 greens = 6 bits
1 white = 4 bits
1 black = 4 bits
for a total of 30/16 bits on average
Your answer is right as the maximum value needed for encoding. But consider the following coding scheme 1 - red (1/2 prob), 01 - blue (1/4 prob), 00 - green (1/8 prob), 001 - black (1/16 prob), 000 - white (1/16 prob) multiply message length by probability and you should have 1 + 5/8 ( not 15/8 ... though)
Related
this is my code ...please correct so that label will show correct count.
tool tip is showing correct count.
bars =alt.Chart(r).transform_fold(
['Reservation_count', 'ON_ACCOUNT'],
as_=['column', 'value']
).mark_bar().encode(
x='month:N',
y='value:Q',
color=alt.Color('column:N', scale=alt.Scale(range=["#f50520", "#bab6b7"])),
tooltip=alt.Tooltip(['ON_ACCOUNT','Reservation_count']),
)
text = bars.mark_text(
align='left',
color='black',
baseline='middle',
dx=0,dy=-8 # Nudges text to right so it doesn't appear on top of the bar
).encode(
text=alt.Text('ON_ACCOUNT:Q', format='.0f')
)
rule = alt.Chart(r).mark_rule(color='red').encode(
y='mean(Reservation_count):Q'
)
(bars+text+rule).properties(width=490,height=310)
below is my data:
month ON_ACCOUNT Reservation_count
0 1 22 134
1 2 32 137
2 3 22 135
3 4 21 113
4 5 18 120
5 6 17 90
6 7 26 83
7 8 11 86
8 9 11 102
9 10 2 68
please help me with this altair bar chart..two columns are there Reservation_count and ON_ACCOUNT LABEL IS showing the same number for both ...
Thanks
for example last bar showing 2,2 both labels it should be top 2 and bottom 68
The short version answer to your question is to use text=alt.Text('value:Q', format='.0f').
But there are a few more issues with your code:
You are expanding your text layer from the bar plot, which already has the color parameter set. This will ignore the color setting of the text layer.
You can use a data encoding free from any color specification. You can then use this encoding to build your bar and text layers with their color settings.
I encountered the text ordering issue discussed here, and none of the given solutions worked out. However, changing the plot from vertical bar to horizontal bars seem to resolve the issue. This is potentially a bug.
Since you are plotting the mean of Reservation_count parameter on a stacked plot, the information might be misleading. I would suggest a layered bar instead of a stacked one. Surprisingly, this seems to solve the issue of text order.
Here is the code:
base =alt.Chart(r).transform_fold(
['Reservation_count', 'ON_ACCOUNT'],
as_=['column', 'value']
)
bars = base.mark_bar().encode(
x='month:N',
y=alt.X('value:Q', stack=None), # stack =None enables layered bar
color=alt.Color('column:N', scale=alt.Scale(range=["#f50520", "#bab6b7"])),
tooltip=alt.Tooltip(['ON_ACCOUNT','Reservation_count']),
#order=alt.Order('color_Category_sort_index:Q'),
)
text = base.mark_text(
align='center',
color='black',
baseline='middle',
dx=0,dy=-8, # Nudges text to right so it doesn't appear on top of the bar
#order=alt.Order('color_Category_sort_index:Q'),
).encode(
x='month:N',
y='value:Q',
text=alt.Text('value:Q', format='.0f')
)
rule = alt.Chart(r).mark_rule(color='red').encode(
y='mean(Reservation_count):Q'
)
(bars+text+rule).properties(width=490,height=310)
I can't figure out the difference between the "Color Resolution" field and the "Size of Global Color Table" field in the gif89a spec https://www.w3.org/Graphics/GIF/spec-gif89a.txt (page 9-10):
Color Resolution - Number of bits per primary color [...], minus 1. This value represents the size of the entire palette [...]
Size of Global Color Table - [...] To determine that actual size of the color table, raise 2 to [the value of the field + 1].
...
[The Global Color Table] is a sequence of bytes representing red-green-blue color triplets [...] and contains a number of bytes equal to 3 x 2^(Size of Global Color Table+1).
Let's say we want to create an image with 3 colors, red, green and blue. In this case we need at least ceil(log2(3)) = 2 bits per color (00 = red, 01 = green, 10 = blue). Then, according to the spec, the Color Resolution (CR) field must be set to ceil(log2(3)) - 1 = 2 - 1 = 1:
packed fields = X001XXXX
---
CR field
More generally, if N is the number of colors, then CR = ceil(log2(N)) - 1.
Regarding the size of the Global Color Table (GCT), 1 color requires 3 RGB bytes, therefore the number of entries = the number of bytes / 3 = 2^(Size of GCT + 1). Since we want to store 3 colors, I would go for the power of 2 that comes immediately after 3, which is 2 raised to ceil(log2(3)) = 2^2 = 4. Then, 2^(Size of GCT + 1) = 2^ceil(log2(3)), Size of GCT + 1 = ceil(log2(3)) and Size of GCT = ceil(log2(3)) - 1 = 2 - 1 = 1:
packed fields = XXXXX001
---
Size of GCT field
Again, if N is the number of colors, then Size of GCT = ceil(log2(N)) - 1.
As you can see, CR = Size of GCT = ceil(log2(N)) - 1. It seems like the CR field and the Size of GCT field always hold the same value. I suppose I'm wrong because if I was right one of these two fields would be useless, but I didn't find any clarification in the spec so far.
I'm not alone being confused: http://giflib.sourceforge.net/whatsinagif/bits_and_bytes.html. This article applies the definition of the Size of GCT field to the CR field, and the Size of GCT field is simply not defined at all:
[...] the color resolution [...] allow you to compute [the] size [of the GCT]. If the value of this filed is N, the number of entries in the global color table will be 2 ^ (N+1) [...]. Thus, the 001 in the sample image represents 2 bits/pixel; 111 would represent 8 bits/pixel.
Anybody knows a situation where these two fields differ?
From the spec:
iv) Color Resolution - Number of bits per primary color available
to the original image, minus 1. This value represents the size of
the entire palette from which the colors in the graphic were
selected, not the number of colors actually used in the graphic.
For example, if the value in this field is 3, then the palette of
the original image had 4 bits per primary color available to create
the image. This value should be set to indicate the richness of
the original palette, even if not every color from the whole
palette is available on the source machine.
So to be clear, color resolution is supposed to be the number of bits per color (less 1) in the original image the GIF was made from.
Ok, deep breath.
Suppose one is using a monospace font and has three requirements. This may or may not be wise; that's not what I'm asking.
Show two spaces at the end of each sentence in a web page, provided the sentence ends in midline.
But if the sentence ends in mid-paragraph but happens to approach the right margin, the final character (typically ".") should be able to nestle as close to that right margin as any other character in any other line. That is, carefully tweaking the window width while viewing the test results ought to be able to squeeze out any space following the pre-gap text.
Similarly, no extraneous space must be introduced after the line break.
To be able to justify the text is not a requirement.
A similar question has already been asked here. But that thread has two problems (for me):
It was rightly closed, because the discussion bogged down in whether the requirement was wise in the first place. I do not assert the wisdom of the above requirements; I simply ask the question.
The initiator did not seem to worry about requirement 2 above, so the discussion did not fully address it.
I have tried placing each of the following between two sentences. Each of them either did not fulfill one of the requirements, or completely failed to allow a line break between the two sentences. As you read this list, add semicolons where they seem appropriate; when I added them to the actual list, I got real spaces and stuff, not the names of the entities.
(space)(space)
&emsp&emsp
(space)&emsp
&emsp(space)
&ensp&ensp
(space)&ensp
&ensp(space)
  
(space) 
 (space)
(space)(space-within-span)
(space-within-span)(space)
(space-within-span)(space-within-span)
In addition, I tried the white-space: pre-wrap idea, which failed requirement 2.
What do you suggest? In my tests, the stylesheet is this:
P.intro
{
font-family: Courier, monospace;
}
P.prewrap
{
font-family: Courier, monospace;
white-space: pre-wrap;
}
... and the web page is this:
<HTML><HEAD>
<link rel="stylesheet" href="style.css">
</HEAD><BODY>
<P class=intro>
01 alpha spacespace omega spacespace<BR>
<BR>
02 alpha    omega   <BR>
03 alpha space  omega space <BR>
04 alpha  space omega  space<BR>
<BR>
05 alpha    omega   <BR>
06 alpha space  omega space <BR>
07 alpha  space omega  space<BR>
<BR>
08 alpha omega <BR>
09 alpha space omega space <BR>
10 alpha space omega space<BR>
<BR>
11 alpha space-spanspace <SPAN> </SPAN>omega space-spanspace<BR>
12 alpha spanspace-space<SPAN> </SPAN> omega spanspace-space<BR>
13 alpha spanspace-spanspace<SPAN> </SPAN><SPAN> </SPAN>omega spanspace-spanspace<BR>
<BR>
0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2
<BR>
01 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3
</P>
<P class=prewrap>Lorem ipsum. Dolor sit amet.</P>
</BODY></HTML>
Include this in your css file:
SPAN.eos
{
word-spacing: 0.625em
}
Do this at the end of each midparagraph sentence:
finalword<SPAN class=eos>. B</SPAN>eginning
how can I divide a binary number (in 2 complement) by 2 .
I've tried bit shifting but I have a problem with negative odd numbers, how can I solve it?
for example :
(-7/2) 11001/2 => (shifts the number one place to the right) => 11100 (-4)
Can you use after the . ? Like this?
1 0011 . 1000
Part 1 2 3 4
Part 1: Negative number
Part 2: Makes 3
Part 3: Separate by .
part 4: Makes 0.5
The negative part works like:
.1000 = 0.5
.0100 = 0.25
.1100 = 0.75
.0010 = 0.125
So instead of multiply by 2 to shift to left. You can do a divide by 2 to the right. So after the dot /2 and before the dot x2.
Hope you can use this information.
I am parsing colour codes that I get from a Flex(Flash ActionScript) application, then creating HTML div elements with that same colour.
My Problem: The colours are all only 8 digits long. So they cant be RGB colour values can they? What color value format are they in? If I can figure the format they are in I can convert them to RGB. Maybe the last/first digit signifies its 0. alpha value?
PS: Should I convert the colours to RGB or something else?
This is an example of the colour code values I getting from the flash application:
16777215
4803910
84545883
16777215
RGB colours are represented by hexadecimal digits (base 16).
Base 16 means that each place in the number can represent numbers 0-15 in this order:
0 1 2 3 4 5 6 7 8 9 A B C D E F
Using 0x in AS3 represents a hex number. As an example, run this:
trace(0xF); // 15
The output as you can see is represented in decimal (base 10). What you're seeing above in your question is the decimal representation of your colours.
If you want to see the hex version, use toString() and parse 16 as the radix parameter. You'll notice that the default is 10 (for base 10 / decimal numbers that we all know and love).
var num:int = 15;
trace(num.toString(16)); // f
Hope this makes sense.