From a balanced AVL tree, if a Node is removed and insert it back, is it possible to get the original tree again?
I think, No. Here's an example.
root: 10
child_left: 5
child_right: 15
------------
15 as root
child_left: 12
child_right: 18
remove 10, you'll get something like
root: 12
child_left: 5
child_right: 15
------------
15 as root
child_right: 18
Add 10, you'll get something like
root: 12
child_left: 5
child_right: 15
------------
15 as root
child_left: 10
child_right: 18
------------
The last and first can be told same, but they're not exactly same, i suppose! If they can be told exactly same, then it is possible to get the original tree again.
Related
This is my problem:
Brownout detector was triggered
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5008
ho 0 tail 12 room 4
load:0x40078000,len:10600
ho 0 tail 12 room 4
load:0x40080400,len:5684
entry 0x400806bc
I want to make some web server on my ESP32
I was trying to add a few system calls to the xv6 source code developed at MIT, and upon reading this resource (https://pdos.csail.mit.edu/6.S081/2020/xv6/book-riscv-rev1.pdf), on page 26, they consider the maximum possible virtual address that XV6RISC-V supports.
When I tried to look at the source code for the definition of MAXVA (MAXimum Virtual Address), I came across the following code snippet.
// one beyond the highest possible virtual address.
// MAXVA is actually one bit less than the max allowed by
// Sv39, to avoid having to sign-extend virtual addresses
// that have the high bit set.
#define MAXVA (1L << (9 + 9 + 9 + 12 - 1))
I was intrigued by the expression '9 + 9 + 9 + 12 - 1' instead of simply writing '38'. I tried to look up the underlying reasoning for this but did not find anything related. Is this some kind of optimization? If so, at what level is this relevant and where else could this be relevant?
I have some experience in assembly language programming and understand the basics of how the C code written is being translated to the assembly structure and how the final assembly code corresponding to bit shifting might look like, (using x86 salq and sarq or RISC-V slli). Any hints/ thoughts would be appreciated as well.
The answer could be guessed from vm.c
// The risc-v Sv39 scheme has three levels of page-table
// pages. A page-table page contains 512 64-bit PTEs.
// A 64-bit virtual address is split into five fields:
// 39..63 -- must be zero.
// 30..38 -- 9 bits of level-2 index.
// 21..29 -- 9 bits of level-1 index.
// 12..20 -- 9 bits of level-0 index.
// 0..11 -- 12 bits of byte offset within the page.
9+9+9 correspond to each 9 bits index to address the page
12 correspond to the offset in the page
For the compiler, write 9+9+9+12-1 is the same than 38, but for the human -aware of bits fields- reading this, the first is more clear.
I am trying to figure out how to get the number of DNS queries/second for each domain controller using PowerShell Get-DnsServerStatistics. I copied some of the relevant outputs below.
I try to figure out what is the time period of getting 11793847 "TotalQueries" ?
Under section "TimeStatistics," does the field "TimeElapsedSinceLastClearStatisticsBetweenRestart" with value 00:00:28 means 28 seconds? There is another field "TimeElapsedSinceServerStart" has value 34.01:35:21 and I don't understand what it means? maybe 34 days 1 hour 35 min 21 second?
But if there are 28 seconds with total 11793847 DNS queries. i.e. 421208 queries/second is seems not true in our environment. Could you please help me out?
TimeStatistics:
==============
**TimeElapsedSinceLastClearedStatisticsBetweenRestart 00:00:28**
LastClearTime 9/7/2021 9:33:20 PM
ServerStartTime 9/7/2021 9:33:20 PM
TimeElapsedSinceLastClearedStatistics 34.01:35:21
TimeElapsedSinceServerStartBetweenRestart 00:00:28
**TimeElapsedSinceServerStart 34.01:35:21**
Query2Statistics:
================
TypeAll 1917
TKeyNego 0
TypeOther 897431
**TotalQueries 11793847**
Your assumptions about the time formats are correct. The *BetweenRestart times are the offline times of your DNS service. The time you are looking for is
TimeElapsedSinceLastClearedStatistics - TimeElapsedSinceLastClearedStatisticsBetweenRestart
This is the timespan in which your DNS service was actually answering queries (34.01:34:53). I recommend to parse the timespans into TimeSpan objects using [System.TimeSpan]::Parse("34.01:35:21"), for example. Then you can easily subtract the timespans like shown above.
The resulting timespan object offers you the TotalSeconds member attribute, which you can use for your ratio calculation (your ratio is about 4 queries/s).
I have run into a behavior of Scala Observables that has surprised me. Consider my example below:
object ObservablesDemo extends App {
val oFast = Observable.interval(3.seconds).map(n => s"[FAST] ${n*3}")
val oSlow = Observable.interval(7.seconds).map(n => s"[SLOW] ${n*7}")
val oBoth = (oFast merge oSlow).take(8)
oBoth.subscribe(println(_))
oBoth.toBlocking.toIterable.last
}
The code demonstrates emitting elements from two observables. One of them emits its elements in a "slow" way (every 7 seconds), the other in a "fast" way (every 3 seconds). For the sake of the question assume we want to define those observables with the use of the map function and map the numbers from the interval appropriately as seen above (as opposed to another possible approach which would be emitting items at the same rate from both observables and then filtering out as needed).
The output of the code seems counterintuitive to me:
[FAST] 0
[FAST] 3
[SLOW] 0
[FAST] 6
[FAST] 9 <-- HERE
[SLOW] 7 <-- HERE
[FAST] 12
[FAST] 15
The problematic part is when the [FAST] observable emits 9 before the [SLOW] observable emits 7. I would expect 7 to be emitted before 9 as whatever is emitted on the seventh second should come before what is emitted on the ninth second.
How should I modify the code to achieve the intended behavior? I have looked into the RxScala documentation and have started my search with topics such as the different interval functions and the Scheduler classes but I'm not sure if it's the right place to search for the answer.
That looks like the way it should work. Here it is listing out the seconds and the events. You can verify with TestObserver and TestScheduler if that is available in RXScala. RXScala was EOL in 2019, so keep that in mind too.
Secs Event
-----------------
1
2
3 [Fast] 0
4
5
6 [Fast] 3
7 [Slow] 0
8
9 [Fast] 6
10
11
12 [Fast] 9
13
14 [Slow] 7
15 [Fast] 12
16
17
18 [Fast] 15
19
20
21 [Fast] 18
everyone, who read this.
I found an issue that latitude or longitude of geocoordinate with, for example, 2 minutes and 59 seconds, after converting to decimal format, has value "0.049722", but
2 minutes and 60 seconds has value "0.35", but I thought it must be equal to equal to
3 minutes and 00 seconds, that has value "0.05"
3 minutes and 00 seconds, that has value "0.05"
But again
2 minutes and 61 seconds, that has expected value "0.050278"
Is it global geocoordinate issue or online converter issue?
I use http://the-mostly.ru/konverter_geograficheskikh_koordinat.html
When looking at the source of the respective website, you notice the following line:
if (LAsec==60) {LAsec = 0;LAminutes = LAminutes+1;}
Since LAminutes is still a string, this represents a string concatenation, so 2 is converted to 21 instead of 3.
See: javascript (+) sign concatenates instead of giving sum?
In short, the website is very wrong!
Maybe you should use WolframAlpha for this:
https://www.wolframalpha.com/input/?i=0+deg+2%27+60%22+N,+0+deg+E