-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mergesort output is not uniformly articulated #19
Comments
I've looked at the code a little. After first looking at I decided to study
As we can see, the output is articulated in (nearly) the same uniform manner as the input. The only difference is that the list begins with a What does this mean for Since I've confirmed that this simpler composition works, I suggest that something is going wrong in the |
…s (minor). The new version seems much faster than the prior version: Staffs-MacBook-Air% ./_build/Source/test/experiments.native --experiment Rope_mergesort_name You requested experiment: Rope_mergesort_name ---------------------------------------------------------------------------------- 0:Rope_mergesort_name: Initial run:time:0.4014s (unit cost 77894) 0:Rope_mergesort_name: Initial run:{dirty:0; clean:0; eval:35051; create:35051; tables:5001} -------------------- 0:Rope_mergesort_name: Interacting.. 0:Rope_mergesort_name: Iteraction time: 6.345172 (sec) Staffs-MacBook-Air% ./_build/Source/test/experiments.native --experiment Rope_mergesort_improved_name You requested experiment: Rope_mergesort_improved_name ---------------------------------------------------------------------------------- 0:Rope_mergesort_improved_name: Initial run:time:0.4287s (unit cost 77894) 0:Rope_mergesort_improved_name: Initial run:{dirty:0; clean:0; eval:44280; create:44280; tables:2} -------------------- 0:Rope_mergesort_improved_name: Interacting.. 0:Rope_mergesort_improved_name: Iteraction time: 0.372463 (sec)
Last commit seems to fix the problem for
In particular, I recommend writing a debugging check that automatically checks that the maximum gap between Once we confirm (by testing) that this always gives a uniformly articulated output, I think we can close this issue and move on to more experiments that go deeper. |
Plan: After adding the check proposed above, let's close this issue and move on to these issues, in this order: |
The improved merge sort doesn't seem to maintain granularity. For example: |
Rope_mergesort_name
Improved versionI see output that is consistent with your characterization "extremely fine-grained":
Updated variation of "improved"I just tried a change to the This looks closer to what seems desirable (fine at the start, coarser later in the list):
|
Really, I think we just need to keep the names with their corresponding data items. Since list_merge is going to rearrange things, merge_sort would need to pass the name in the Name case rather than create a nart(this is what list_merge does). I think merge_sort can get by without any narts because list_merge is going to have one for every name. |
To update my previous comment: complex functions returning articulated data can't 'get by' without narts, because narts return an articulation point that suspends computation. Without it, even if there's an inner lazy function, the outer function will be fully computed. The inner function doesn't suspend everything, it returns a suspension of it's own computation. |
commit de68251 and some later ones solved most of our issues with merge sort uniformity. There has not been a debug check, but composing merge sort with rope_length to get 'median' has the trend we expect to see with uniform articulation. The problem was that we needed names in the rope's tree structure for it to remain lazy, and we needed names in the output list to be uniformly distributed for composability. Since the rope's data and tree structure are independent, it seemed like we needed more deterministic names for computation than the input or output had. The solution presented is the realization that it is not I'm closing this issue soon and continuing any conversation in issue #20 which deals with optimizing the median experiment. |
We'd like it if mergesort, when given uniformly named and articulated input, will produce uniformly named and articulated output. Further, we'd like it if it roughly preserved whatever distribution of naming and articulation is found in the input.
As it stands, it doesn't work for uniform (fine-grained) names and articulation points. Instead, the initial output of the sort is articulated, and the later parts are not.
To reproduce this behavior, do this:
You'll see this (notice the two really long lines, and how they look different):
Kyle says: "You'll notice that the order changes from Cons-Name-Art to Name-Cons-Art. That's because of what I wrote in list_merge. I have no idea why I did it, and should probably change it back."
It's not yet clear to me if this discrepancy is related to this issue, or just some other (more minor) one.
The text was updated successfully, but these errors were encountered: