Under RDS-TMC, we have the values RDS_DIRECTION and DIRECTION that can either have the value '+' or '-'. What do these values represent?
I read the developer's guide and went through additional documentation, but did not find any explanation of these parameters. Could maybe someone clarify this for me? Thanks in advance!
When traffic becomes congested, a queue of vehicles begins to build up in the opposite direction to the driving direction. The value can be "+" or "-".
The value "-" indicates that the traffic is queued in the opposite
direction to the driving direction.
Related
I am using the following expression in my R-script and getting an incorrect value. I was wondering whether it is a bug or I am doing something wrong. Any help will be appreciated.
as.integer(10.7275*1e7)
it is returning 107274999. I was expecting it to return 107275000. How can I fix that?
This is due to computer inaccuracy with decimals (as mentioned in comments by #Suren). You can get around it by:
as.integer(ceiling(10.7275*1e7))
Note:
ceiling(as.integer(10.7275*1e7))
will not work (it will return the value you are getting now).
Its a floating point issue. One quick fix would be to use double precision floating point for better accuracy:
as.double(10.7275*1e7) # alternatively as.numeric()
# [1] 107275000
Also refer to this floating point post to get more information and resolutions for floating point math as commented by #Wai Ha Lee
could anyone tell me that
is it right way if i calculate the crc by the method given below:
i did this because dataword length is large.
is it right?
The bottom set of divisions are what you want for a CRC, and arrive at the correct remainders. Your quotients each need one more bit, but they are not used anyway.
The top division was not completed, but it is not relevant, since you need to append the four zeros first as you did in the bottom left, or the four-bit CRC as you did in the bottom right.
Ultimately, You are doing the same thing what a division does. Refer https://www.wikihow.com/Divide-Binary-Numbers binary division for more. However, the data word to be sent to the receiver should not be altered.
I am trying to simply enter the character "i" into SageMathCloud so that I can construct imaginary numbers, this is my syntax:
ran40 = matrix(QQ,2,2,[[2*i,-2],[3,4]])
show(ran40)
I am constructing a matrix so that I can compute the reduced-row echelon form. The first element that is 2*i just needs to be 2i but I keeping getting syntax errors, how do I enter i for an imaginary number into SageMathCloud? I cannot find an example anywhere on the internet, if anyone knows this syntax please do inform me.
Your problem is that you decided what the ring is, and that ring doesn't have any imaginaries.
matrix(QQ,2,2,[[2*i,-2],[3,4]])
QQ is the rationals (the fraction field of ZZ, if you like).
Is this what you want? It will make things in the "symbolic ring" which can be slow...
M = matrix(2,2,[[2*i,-2],[3,4]])
show(M)
show(M.echelon_form())
show(M.rref())
This is a Vigenere cipher-text
EORLL TQFDI HOEZF CHBQN IFGGQ MBVXM SIMGK NCCSV
WSXYD VTLQS BVBMJ YRTXO JCNXH THWOD FTDCC RMHEH
SNXVY FLSXT ICNXM GUMET HMTUR PENSU TZHMV LODGN
MINKA DTLOG HEVNI DXQUG AZGRM YDEXR TUYRM LYXNZ
ZGJ
The index of coincidence gave a shift of six (6): I know this is right (I used an online Java applet to decrypt the whole thing using the key 'QUARTZ').
However, in this question we are only told the first and last two letters of the Key - 'Q' and 'TZ.'
So far I have split the ciphertext into slices using this awesome applet. So the first slice is 0, k, 2k, 3k, 4k; the second is 1, k + 1, 2k + 1, 3k + 1; et cetera.
KeyPos=0: EQEQQSCXQJJHDEYIUTSVMTVUMTYJ
KeyPos=1: OFZNMICYSYCWCHFCMUULILNGYUX
KeyPos=2: RDFIBMSDBRNOCSLNERTONOIADYN
KeyPos=3: LICFVGVVVTXDRNSXTPZDKGDZERZ
KeyPos=4: LHHGXKWTBXHFMXXMHEHGAHXGXMZ
KeyPos=5: TOBGMNSLMOTTHVTGMNMNDEQRRLG
My idea was to calculate the highest-frequency letter in each block, hoping that the most frequent letter would give me some clue as to how to find 'U,' 'A' and 'R.' However, the most frequent letters in these blocks are:
KeyPos=0: Q,4 T,3 E,3, J,3
KeyPos=1: C,4 U,3 Y,3
KeyPos=2: N,4 O,3 R,3 D,3 B,2
KeyPos=3: V,4 D,3 Z,3
KeyPos=4: H,6 X,6 M,3 G,3
KeyPos=5: M,4 T,4 N,3 G,3
Which yields QCNVHM, or QUNVHM (being generous), neither of which are that close to QUARTZ. There are online applets that can crack this no problem, so it mustn't be too short a text to yield decent frequency counts from the blocks.
I guess I must be approaching this the wrong way. I just hoped one of you might be able to offer some clue as to where I am going wrong.
p.s. This is for a digital crypto class.
Interesting question...
I don't have a programmatic solution for cracking the original ciphertext, but I was able to solve it with a little mind power and some helpful JavaScript.
I started by using this page and the information you supplied. Provide the ciphertext, a key length of 6 and hit initialize. What's nice about the approach here is that unknowns in either the plaintext or key are left as hyphens.
Update the key, adding only what you know Q---TZ and click 'update plaintext'. At this point we know:
o---sua---opo---oca---nha---enc---rom---dth---ama---int---ept---our---mun---tio---ewi---eus---the---ond---loc---onf---now---hed---off---ere---nsw---esd---tmi---ght
Here's where I applied a bit of brain power. You start recognizing bits of the plaintext. the, now and off make an appearance. At the end, there's ght - this made me think the prior letter is likely a vowel. For example light or thought. I replaced the corresponding hyphen with u and clicked update keyword to find what letter would have produced that combination. The matching letter turns out to be F. I think updated the plaintext to see the results. They didn't look promising. So I tried i instead which resulted in:
o--usua--ropo--loca--onha--eenc--prom--edth--eama--eint--cept--gour--mmun--atio--wewi--beus--gthe--cond--yloc--ionf--mnow--thed--poff--mere--insw--nesd--atmi--ight
Now we're getting somewhere. At the start I see something that might be usual, and further in I see int--cept and near the end w--nesd-- at mi--ight. Voila. Filling in the letters for wednesday and updating the keyword yielded QUARTZ.
... So, how to port this approach to code? Not sure about the best way to do that just yet. The idea of using the known characters in the key, partially decrypting the ciphertext and brute forcing the rest is appealing. But without a dictionary handy, I'm not sure what the best brute-forcing method would be...
To be continued (maybe)...
An algorithm wouldn't just consider the most frequent letters but the frequency pattern of the whole alphabet. Technically you compute the index of coincidence for each possible shift and consider the maximal ones.
It is quite easy to find palindrome replacing letters on both ends with (Φ).
ΦabaΦ
ΦΦbaΦ
ΦΦbaΦ
ΦΦbaΦ
ΦΦbaΦ
ΦΦbaΦ
ΦΦbΦΦ
ΦΦbΦΦ
ΦΦbΦΦ
ΦΦΦΦΦ
ΦΦΦΦΦ
ΦΦΦΦΦ YES
It is possible with changing a to A , and changing A to a at the end of task. But does anybody have an idea ,how to achieve this without using additional signs?
Moving of end characters can help:
ΦΦabaΦΦ
ΦaΦbaΦΦ
ΦaΦbΦaΦ YES
or
ΦΦabbaΦΦ
ΦaΦbbaΦΦ
ΦaΦbbΦaΦ
ΦabΦbΦaΦ
ΦabΦΦbaΦ YES
You can change a to A, and b to B, and ur end character would be a capital letter. (take the ascia value, and if it falls in the uppercase range, you know the end)
This assume your input is entirely lower case.
For each possible symbol on the tape (which I assume are drawn from a finite set), you need a state, which I'll call "$X_LOOKING". Start at the left end and set the state to "$X_LOOKING" for the symbol $X that you find there. Move right until you hit the end and see if it matches $X.
When you move back left, you'll have to stop at the 2nd letter instead of the first. For this maybe you can keep track of how many letters you've looked at on another area of the tape.