So, my assignment is to get the centered average of a list, much like a few of the other posts on here like this one (https://codereview.stackexchange.com/questions/108404/how-to-get-a-centered-mean-excluding-max-and-min-value-of-a-list-in-python) and a few others. However, my professor has told us we are not allowed to use min, max, or sort to solve this. So what I have right now is this, it is still a work in progress:
def centered_average(nums):
high=0
low=0
a=0
b=0
for i in range(len(nums)):
if nums[i]>a:
a=nums[i]
high=a
for i in range(len(nums)):
if nums[i]<b:
b=nums[i]
low=b
total=sum(nums)
average=(total-high-low)/(len(nums)-2)
print(average)
My problem is that I can't get low to be recognized as the lowest number in the list. For example, if I input [1,2,3,4,5] as the list, my function should return 5 as the high, 1 as the low, and 3 as the centered average since 2+3+4 is 9/3=3. However, what I have right there returns the low as 0. I think it is because of the (lens(nums) since it would think the first number is a 0. I'm not sure how I should fix this.
Note: I am still a beginner at this stuff so I know what I have might not be the best or that the error could be simple to fix, but I am still in the process of learning so any help and advice would be much appreciated.
The problem is your starting the running minimum (and running maximum) as 0.
Start the running minimum as float("inf") (as everything is guaranteed to be less than that). Start the running maximum as float("-inf") (as everything is guaranteed to be greater than that).
Or, start both as the first element of the list (which is either a true minimum/maximum, or there's another element that is lower/higher than it).
Related
RE: Apache OpenOffice 4.1.7, AOO417m1(Build:9800) - Rev. 46059c9192, 2019-09-03 12:04.
I need to sum non-integer entries across a range of cells, but without including the decimal values (complicated by some cells being text). I started with ROUNDDOWN, then TRUNC, then FLOOR. I'm driving myself nuts trying to find a clean code (or even an arbitrarily extensible ugly code) for what would be the following:
=SUMIF(ISTEXT(R7:CL7);0;TRUNC(R7:CL7))
The above doesn't work, of course, since TRUNC() doesn't apply to ranges, but it conveys what I'm trying to do in a nutshell -- some of the cells contain text, which SUM() ignores (luckily), but they flummox TRUNC, so I needed to handle the text problem.
I started with ISNUMBER, just to get the ball rolling; ISTEXT has fewer characters, but it's not worth fixing that right now.
FLOOR was equally disappointing for ranges:
=SUM(FLOOR(R7:T7;1))
I tried variations of =SUM(IF(... and searches for ROUNDDOWN range (and variations on that) and such pseudocode as "IFTEXT" and "SUMTRUNC" (and variations on that). I found info on ROUNDDOWN(SUM(... and so forth, but not "SUM(ROUNDDOWN(..." or any equivalent.
In my delirium, I got silly and even tried:
=SUMIF(ISTEXT(S7:U7);0;AND(TRUNC(S7);TRUNC(T7);TRUNC(U7)))
To be clear: {2.9→2 + 2.9→2 + 2.9→2 = 6} ≠ {2.9+2.9+2.9 = 8.7→8}. I'm looking for a 6, not an 8 (I'd joke about sixes and sevens, but I'm way past pumpkin o'clock and 2.428571 takes up too much space).
My current test-kludge is:
=SUM(IF(ISNUMBER(R7);ROUNDDOWN(R7);0);IF(ISNUMBER(S7);ROUNDDOWN(S7);0);IF(ISNUMBER(T7);ROUNDDOWN(T7);0); ... ;IF(ISNUMBER(AX7);ROUNDDOWN(AX7);0))
It ends at AX7 only because of the char count. I hope to SUM the whole row in a single sweep, but that ain't gonna cut it. I could do it in large chunks in multiple cells, and then add those cells up, but oy gevalt.
Since it's already ugly anyway, I could use the following to save a few characters, but this would only mean being able to extend the range maybe 6 further cells (not much point in that):
=IF(ISTEXT(R7);0;TRUNC(R7))+IF(ISTEXT(S7);0;TRUNC(S7))+IF(ISTEXT(S7);0;TRUNC(S7))
I'm seriously considering simply going down a bunch of rows (to below my data cells) and entering the following, then copying the cell and pasting it to a complementary range, and telling the SUM cells to just sum up their respectively shadowed rows (instead of the data rows that they sit in):
=IF(ISTEXT(R7);0;TRUNC(R7))
Sorry for the rambling; I need sleep. This started as a need, then multiple failed attempts became a grudge match of principle and obstinacy, and now I'm just plugging away at it out of blind habit developed over the past 2-3 days (hopefully I won't forget what the purpose was).
In summary...: ++?????++ Out of Cheese Error +++DIVIDE BY CUCUMBER.
I'm comfortable enough with macros, though it's been ~7 years (and that was in Excel). Thanks in advance, even if the answer is that I'm stuck with one of these! 🙂
EDIT: I don't see a way to attach a .csv here (though I could open the .csv with Notepad, and copy-and-paste the contents if that would help anyone), so here's a set of pics:
So in the tag prolog someone wanted to solve the "the giant cat army riddle" by Dan Finkel (see video / Link for description of the puzzle).
Since I want to improve in answer set programming I hereby challenge you to solve the puzzle more efficient than me. You will find my solution as answer. I'll accept the fastest running answer (except if it's using dirty hacks).
Rules:
hardcoding the length of the list (or something similar) counts as dirty hack.
The output has to be in the predicate r/2, where it's first argument is the index of the list and the second its entry.
Time measured is for the first valid answer.
num(0..59).
%valid operation pairs
op(N*N,N):- N=2..7.
% no need to add operations that start with 14
op(Ori,New):- num(Ori), New = Ori+7, num(New), Ori!=14.
op(Ori,New):- num(Ori), New = Ori+5, num(New), Ori!=14.
%iteratively create new numbers from old numbers
l(0,0).
{l(T+1,New) : op(Old,New)} = 1 :- l(T,Old), num(T+1), op(Old,_).
%no number twice
:- 2 #sum {1,T : l(T,Value)}, num(Value).
%2 before 10 before 14
%linear encoding
reached(T,10) :- l(T,10).
reached(T+1,10) :- reached(T,10), num(T+1).
:- reached(T,10), l(T,2).
:- l(T,14), l(T+1,_).
%looks nicer, but quadratic
%:- l(T2,2), l(T10,10), T10<T2.
%:- l(T14,14), l(T10,10), T14<T10.
%we must have these three numbers in the list somewhere
:- not l(_,2).
:- not l(_,10).
:- not l(_,14).
#show r(T,V) : l(T,V).
#show.
Having a slightly more ugly encoding improves grounding a lot (which was your main problem).
I restricted op/2 to not start with 14, as this should be the last element in the list
I do create the list iteratively, this may not be as nice, but at least for the start of the list it already removed impossible to reach values via grounding. So you will never have l(1,33) or l(2,45) etc...
Also list generation stops when reaching the value 14, as no more operation is possible/needed.
I also added a linear scaling version of the "before" section, although it is not really necessary for this short list (but a cool trick in general if you have long lists!) This is called "chaining".
Also note that your show statement is non-trivial and does create some constraints/variables.
I hope this helps, otherwise feel free to ask such questions also on our potassco mailing list ;)
My first attempt is to generate a permutation of numbers and force successor elements to be connected by one of the 3 operations (+5, +7 or sqrt). I predefine the operations to avoid choosing/counting problems. Testing for <60 is not necessary since the output of an operation has to be a number between 0 and 59. The generated List l/2 is forwarded to the output r/2 until the number 14 appears. I guess there is plenty of room to outrun my solution.
num(0..59).
%valid operation pairs
op(N*N,N):- N=2..7.
op(Ori,New):- num(Ori), New = Ori+7, num(New).
op(Ori,New):- num(Ori), New = Ori+5, num(New).
%for each position one number
l(0,0).
{l(T,N):num(N)}==1:-num(T).
{l(T,N):num(T)}==1:-num(N).
% following numbers are connected with an operation until 14
:- l(T,Ori), not op(Ori,New), l(T+1,New), l(End,14), T+1<=End.
% 2 before 10 before 14
:- l(T2,2), l(T10,10), T10<T2.
:- l(T14,14), l(T10,10), T14<T10.
% output
r(T,E):- l(T,E), l(End,14), T<=End.
#show r/2.
first Answer:
r(0,0) r(1,5) r(2,12) r(3,19) r(4,26) r(5,31) r(6,36) r(7,6)
r(8,11) r(9,16) r(10,4) r(11,2) r(12,9) r(13,3) r(14,10) r(15,15)
r(16,20) r(17,25) r(18,30) r(19,37) r(20,42) r(21,49) r(22,7) r(23,14)
There are multiple possible lists with different length.
In the creation of a SsaSpikeEstimator instance by the DetectSpikeBySsa method, there is a parameter called pvalueHistoryLength - could anybody please help me understand, for any given time series with X points, which is the optimal value for this parameter?
I got similar issue, when I try to read the paper, https://arxiv.org/pdf/1206.6910.pdf, I notice one paragraph
Also, simulations and theory (Golyandina, 2010) show that it is
better to choose window length L smaller than half of the time series length
N. One of the recommended values is N/3.
Maybe that's why in the ML.Net Power Anomaly example, the value is chosen to be 30 for the 90 points dataset.
Feel free to cut immediately past the first two paragraphs, they are mostly waffle explaining the situation.
I'm working on a task for my University course, while I don't want any help solving the actual problem (I feel like that's "cheating" as it were) I would like help finding a way to extend the lengths of lists shown in prolog when tracing. For example, in the task you have to make a path finder through a maze with coloured "edges" between nodes which are each assigned a unique letter from the alphabet. The edges are "two way" and there is a "start" node that connects via a red edge to the "m" node also. The goal is to reach the "g" node in the middle while going along edges from the start in a repeating order of [red,brown,yellow].
Anyway, I think my algorithm finds a correct route at the bottom of the recursion, but going through the tracer is possible thousands of steps (I was holding return for about 2 minutes before it finished). Currently it doesn't "return" the generated list of steps (and while I'm sure some of you would be able to tell me how to do so, I'd rather you didn't because it's important I learn the actual prolog myself I feel) so the only time I see what's in the list of route steps is in the trace. SO here is the problem:
path(k, [red, brown, yellow], [[start, red], [m, brown], [e, yellow], [h, red], [r, brown], [p, yellow], [n|...], [...|...]|...], [start, m, e, h, r, p, n, j|...], g)
The final list holds the route I want to know if it's valid, however:
[start, m, e, h, r, p, n, j|...]
Cuts off at j, I want the trace to show FULL lists, otherwise I will have to go back through 100s of lines of trace trying to find the broken up and "correct" nodes in the path, with lots of backtracking mixed in i.e. really hard, and really easy to make a mistake. Also the I'm using program only keeps 30 or so lines prior (no idea if this is normal but I am using a SWI-Prolog(Multi-threaded, version 7.2.3) from the official site). Which means I'd have to go through everything past the first time it reaches the j node which would take a huge amount of time.
So as I say, this could be solved by having the list be unified (or whatever it is called) as a "return" (or whatever it is called) but I don't want an answer like that spoon fed to me and would rather figure it out on my own. So if you know how to do so, please refrain from telling me and just still with the way to increase the maximum displayed list with trace thank you.
I appreciate the help, sorry for the hoops I'm asking people to jump through.
to prevent these kinds of outputs [_|...] adding the code below ;
:- set_prolog_flag(toplevel_print_options,
[quoted(true), portrayed(true), max_depth(0)]).
Im wondering if I can optimize my pathfinding code a bit, lets look at this map:
+ - wall, . - free, S - start, F - finish
.S.............
...............
..........+++..
..........+F+..
..........+++..
...............
The human will look at it and say its impossible, becouse finish is surrounded... But A-star MUST check all fields to ascertain, that there isnt possible road. Well, its not a problem with small maps. But when I have 256x265 map, it takes a lot of time to check all points. I think that i can stop searching while there are closed nodes arround the finish, i mean:
+ - wall, . - free, S - start, F - finish, X - closed node
.S.............
.........XXXXX.
.........X+++X.
.........X+F+X.
.........X+++X.
.........XXXXX.
And I want to finish in this situation (There is no entrance to "room" with finish). I thought to check h, and while none of open nodes is getting closer, then to finish... But im not sure if its ok, maybe there is any better way?
Thanx for any replies.
First of all this problem is better solved with breadth-first search, but I will assume you have a good reason to use a-star instead. However I still recommend you first check the connectivity between S and F with some kind of search(Breadth-first or depth-first search). This will solve our issue.
Assuming the map doesn't change, you can preprocess it by dividing it to connected components. It can be done with a fast disjoint set data structure. Then before launching A* you check in constant time that the source and destination belong to the same component. If not—no path exists, otherwie you run A* to find the path.
The downside is that you will need additional n-bits per cell where n = ceil(log C) for C being the number of connected components. If you have enough memory and can afford it then it's OK.
Edit: in case you fix n being small (e.g. one byte) and have more than that number of components (e.g. more than 256 for 8-bit n) then you can assign the same number to multiple components. To achieve best results make sure each component-id has nearly the same number of cells assigned to it.