quotable6

query

‘O(n)’

result-#moarvm.md

Cute. I hadn't thought of that and was figuring it would be an O(n) search...
The algorithms we're using aren't all O(n)
Plus it matches the general principle that to ask the length in something other than the current level you're working in requires O(n) work (like asking the number of bytes means doing the encoding)
in the backlog jnthn is speculating a bit about Str with different normalization to behave the same as NFG, but work at O(n) complexity rather than O(1)
well, in this case O(n) is bounded by the length of the string, but in an actual use case you only know n after you've iterated to find it
minor efficiency choice: do we maintain it as a heap while adding retired live ranges (complexity, O(n log n)), or do we heapify it afterwards (complexity: O(n))
suffix trees have long been a favorite of mine. they make some string-searching problems that "feel" O(n**2) actually be O(n)
O(1)? i thought this was O(n) now?
The O(n) was doing a linear search in the SC to find the index
the O(n) for the setting seems most useful first
but my gut feeling is start with "the simplest thing that could possibly work" to get down to O(n)

result-#p6dev.md

Found nothing!

result-#perl6-dev.md

I only glanced SmokeMachine's proposal (didn't have time/brane to ponder it more yet), though I note that the additions lets you do something in O(1) space that'd need O(n) space otherwise
or O(n) maybe
So you could more easily spot O(n) vs O(1) memory use
so we could bypass the whole O(n) discussion
To me this looks like a case of premature optimization (including the speed improvements commits I pushed). The methods aren't that slow to begin with and they're not commonly used. It's O(n), but so what?
I would never expect .succ to be O(n)
AlexDaniel: I don't get where "the reasoning for keeping O(n) kinda contradicts itself."
I dunno, I just think that .succ being O(n) is exceptional (and is unexpected), while I guess most people know that combinations/permutations can blow up with high n's
native str looks O(n)
"NEW version is 51497.76x faster"... k looks like O(n) changed. /me plugs that change in and strestests
.oO( In today's episode of "accidentally O(n)..." )
Just because you've got an NFC/Uni/whatever doesn't mean we have to forget what graphemes are, just that you're going to pay O(n) instead of O(1)
It may be unorthodox, but it's O(n) :P
md5sum *.jpg | cut -d ' ' -f 1 | sort | uniq -c | sort # O(n) + smallcoeff * O(n log n)
(e.g. it should be O(1) memory, not O(n))
If I understood jnthn++ correctly, we store strings in NFG, because it makes accesses O(1) instead of O(n). Something that will matter to many users.
"Turns O(1) things into O(n) things" hurts.
.chars on a Uni is O(n), not O(1) like on Str

result-#perl6.md

checking for presence of a single item in a set is amortized O(1), but if you have an equality function, you have to check against every entry of the set, which is O(n)
Still, $elem ∈ @array is O(n) either way
O(1) or O(n)?
if we use a bit to store it, it is O(1); if we count it, then may be O(n)
wander: as far as I can see, it is O(n) on js backend
so according to that description, it's definitely O(n)
some algorithms are O(n) in memory usage--I believe file duplicate checking falls into that category
that's stil O(n), just a smaller n
It's still O(n), even if there are 3-4 passes over the input data
jnthn: did you think about randomizing our hashes (so that the hash lookup can't be O(n)'ed by malicious) data, or is that waiting for a volunteer? ;)
That's O(n) I guess... :)
Thing is, I know the ones involving set and unique are O(n). I've no clue what the junction one might be :)
lucasb: and if you do it with arbitrary sized integers, they nearly double in size at each iteration, making each operation quadratic in time, so you have an O(n^3) algorithm for something that looks to be O(n)
I wish I could explain why a bit better. to a first approximation, you want your parse time to be O(n) on the length of the parsed text, not O(2**n)
skids: so, the insertion's complexity is O(n), not O(1)?
i guess it should be O(1) - best case , or O(n) worst case?
is 1 ∈ ^6 a O(n) operation?
Converting a list to a hash takes at least O(n) time, regardless of whether you do it manually or use, for example, the .set method on the list.
Probably does not matter. As you said, both are probably O(n)
its O(n) in every case
can someone confirm that this is O(n)
and you can't do better than O(n) here
For large enough scale, the sort *should* dominate, because O(n log n) > O(n) ... but that depends on e.g. 'xx' being O(n).
Int has unlimited bits. Thus my bitvector LCS::BV has half the code now, is the shortest and fastest (written in P6;-). And O(n). A::Diff crashed in second benchmark.
Otherwise, (a) we could not actually do the type check in O(1), but it'd be O(n) to examine everything, where n might be infinite on a lazy array, and (b) the constraint might become untrue during the execution of the thing you passed it to if you manage to mutate the array in that time
pippo: Well, opting into an O(n**2) algorithm rather than an O(n) one probably should be enough to make you take notice. :)
2 Oct 2015 22:54Z <lizmat> jnthn: possibly even O(n) :-(
that's what giving me a O(n) feeling
.tell jnthn possibly even O(n) :-(
Yes, but if they weren't then set membership testing would be O(n) instead of being O(1) :)
but the <!before> solution is not exponential, it just has a larger constant on the O(n)
I'm not sure "let's quietly do this O(n) operation on a potentially infinite thing BEHIND THE SCENES" is a great idea. ;)
Well, it's algorithm design in some sense. Adding/removing from a SetHash is O(1). If you have a set and want to union in another value, getting a new set, then it's O(n) to do so.
japhb: In any other units, O(n)
TimToady: is "foo".codes desired as an O(1) or an O(n) operation?
Yeah, that should be O(n), I would think.
^^ that is a good analysis of abstract O(n) notation and practical performance
I don't think that it will make sense to publish lots of small incremental language specs, as any (good) compiler needs to implement each and every spec, and even if code is mostly re-used, there's O(n) testing per compiler release and O(n²) cumulative
on the face of it, it might incur an O(n) slowdown for n allocated objects.
ab5tract: pfft, O(n) algorithm
raydiak: it's not so much a bug as an O(n) problem
it's significant, because it's O(n) if you don't do something clever (and your internal encoding is fixed width)
TimToady: when you say linked lists are a terrible way to approach to parallelism, which ways? Obviously the O(n) access is slow, or is there some other aspect to consider
timotimo: Depends on the size of the list. It's all O(n) afaict, so we're discussing constant factor...
TimToady: S06 has it as, "In the abstract, this cache is just a hash where incoming argument Captures are mapped to return values." Object hashes use WHICH. eqv doesn't produce a hash value, afaik, so a lookup would be O(n) instead of O(1) if we go that way?
"Beware that, unlike in most collections, this method is NOT a constant-time operation. Because of the asynchronous nature of these queues, determining the current number of elements requires an O(n) traversal. Additionally, if elements are added or removed during execution of this method, the returned result may be inaccurate. Thus, this method is typically not very useful in concurrent applications."
Perl 6 will do Unicode better than Perl 5. Stuff that is hard in perl 5 will be easy. Stuff that is O(n) in Perl 5 will be O(1) [and consequently O(n**2) will be O(n)]
for a comparison sort, you need O(n*log(n)) work to sort everything, but you can get the first element with O(n) work
there are several sorting algorithms that can be lazy in the sense of returning the first element in O(n) time
quicksort has the further interesting property that you can retrieve the kth result in O(n) time
the only sort running in O(n)
you won't get good threading, and your Unicode will be O(n)
My personal feeling, on unexpected bad performance grounds, is no -- seeing an O(n) algorithm become O(n**2) because of hidden scan semantics kinda sucks.
he wrote his email on the 24th. I replied on the same day with "I will read your explanation carefully and ponder whether it actually proves that the algorithm runs faster than I thought. If it does I will definitely revisit my review. Before looking closely at it though, I kinda doubt it'd be O(n), since even Gaussian elimination is O(n**3)."
more generally, I don't think an algorithm which has to correlate info across n things *can* be O(n)
hm, I think I can easily show that the algorithm isn't O(n).
quietly wonders if QC could generate a uniformly random balanced-brackets string in O(n) time
Perl 5 (the current implementation) is never going to have better than O(n) Unicode [for code points] and O(n**2) Unicode [for graphemes]
I mean, with Boyer-Moore, you can sometimes do good guesses and beat O(n), but...
you now have an O(n �squared�) encoding, not just O(n)
it's commonly believed that SSL would fall apart if there was an O(n) way to factorise huge numbers
It's not that ~ is quadratic, it's that you're doing an O(n)-y thing n times
I remember reading some stuff on SO that some O(n) things in Turing machine had to be O(n log n) or summat like that
Ropes basically do that, but in a tree structure so that access is O(log N) instead of O(n)
and, of course, it gets even better performance as N gets bigger, since qrpa is O(n) for that test while rpa is O(n**2)
I don't know why it didn't hit me before today that having a O(n) shift_pmc operation on RPA would be detrimental to our list model
anyway, the new shift code replaces the O(n) memmove function with a couple of integer ops
ah, we had a link to a very cool page that had an O(n) setup / O(1) per-step algorithm
yes, for a first stab I'm implementing the straightforward O(n) setup / O(n) per-step version
Oh, for sure. I was more meaning that ?@array vs +@array is potentially the difference between O(1) and O(n), whereas ?%hash and +%hash are both O(1), just varying in constant factor.
niecza: my %h = 'A'..'Z' Z=> 1..*; say %h.perl # niecza's Hash.perl explicitly sorts the result :p O(n), O(log n), close enough
3. jumping around in the input should not be O(n)
cedric: .*? <at($n)> has to do an O(n) amount of backtracking
wonders whether in the short term it would be better to have an O(n) Str.chars that respects surrogates or an O(1) Str.chars that doesn't
wild guess: it has an O(n) lookup?
not sure about O(n), but it's pretty slow
Item, Add, Remove, Contains are all O(n). It's supposed to have "fasted keyed retrieval"
got it, yes it's O(n)
Woodi: hash lookup is still O(1) rather than O(n) ... did you order your conditionals such that the most likely string is tested for first?
niecza: Avoid O(n) GetField and GetMethod in thaw procedure
moritz: Still, it would be slightly LTA. The real poll() watches n sockets over t time. Our poll watches only one socket in the given time, so if we wanted to check n sockets, our time either grows in O(n), or we have to reduce the time spent on an individual socket
sjohnson: it talks about what O(n) is, yes
O(n) means you have to move in 1 dimension
and I can likely make it so that it's O(n) for most hits with some smart caching
it depends. Rewriting line by line is probably around O(n), now rethinking the module and writing it The Perl 6 Way can be more interesting sometimes
and then I'll be able to use it to avoid a ton of other O(n) operations that we currently do :)
even at O(n^2), I'm wondering if we'll still do better than O(n)
sorry, O(n) where "n" is really 300x
It's O(n) and better than the inferior runloops :)
no, it's O(n) filtering behavior, which requires rerolls sometimes
it feels wrong to me for "is rw" to turn O(n) code into O(1) code
also note: both Perl 5 and Niecza use an O(n) algorithm for goto
sorear: I'm curious: why is the algorithm for goto O(n) in Niecza and Perl 5?
.oO( both lolpush and lolpop are O(n)... )
an O(n) operation that makes fine sense currently
that's makes string comparisons in O(n) possible again (i hope)
Parrot-land doesn't understand the fact that nulling registers after their lifetime ends is the difference between O(n) and O(1) memory usage
does this hold a reference to the beginning of the iterator chain and thereby force the evaluation to take O(n) space?
as we shift items off that list, it remains O(n) space
he and I discussed that we could take the current O(n**2) algorithm and make it O(n) if we just checked the vtable for matches.
and that would convert what is currently O(n**2) to O(n)
mberends: yes. I guess it's still O(n) rather than O(1). :/
while if you use a list, deletes require O(n) (because you have to scan the list)
actually, delets are worse than O(n), because you first have to scan the list to find the element, and then delete, which also adds complexity.
deleting is also O(n)
and O(n) + O(n) = O(n)
O(n) vs. O(1)
It sounds very fast - O(n)
DanielC: indeed, only hashes can beat O(n) afaik
mberends: Though I guess the good thing about tries is that they're O(n) on the key length rather than the number of times, so I guess on times they're O(log(n)) too?
so we're taking an O(n) operation and turning it into O(n^2)
pmichaud: php doesn't have hashes but rather key-value pair arrays, array_key_exists() is O(n) because of that
that new technique, once it's working (it syntax-checks in perl now! :), should give O(n) parsing once I add a zillion trace lines and actually get it working. you might call that last commit a stub.
I forgot to say, O(n) parsing, even when the grammar is filled with left recursive rules (both direct and indirect).
still O(n)
O(n) vs O(N*log(N))
O(n)
O(2) often beats O(n) for large values of n
my concern is that substr could turn an O(n) scanning algorithm into O(n**2), e.g. my implementation of Str.graphs
I found http://spyced.blogspot.com/2005/06/why-php-sucks.html ... O(1) vs. O(lg n) -> O(n)
that paragraph I quoted continues: "Therefore, using this module for pattern matching currently takes an O(n) performance hit for every call to the patternmatching function. n is the number of branches, sets of conditions."
this suggests that FP magically gets you better than O(n)
Hm right, but it might be important if some kind of string lookup is O(1) or O(n).
only O(n), we hope
which should bring this impl closer to the haskell version in terms of O(n) complexity
and though I think bulat's library does array resizing, it does so by a O(n) memcpy into another memchunk
so it's basically O(n)
so need to do a O(n) prescan
our VStr's .length is O(n), right?
splice() is O(1), not O(n)
Of course, finding the splice point may have become O(n) instead of O(1), so there's a tradeoff. :-)
mostly O(n) problems
CALLER is O(n) of course
it's O(n) even if you look up just one frame
all of them? that's like, O(n)
I know it's possible to compile the methods into O(n) (n is the number of methods) type check
but more importantly, it's now O(n) instead of O(n**2).
does !! end up getting optimized somehow, or is it really O(n) as the prelude specifies it?
TreyHarris: I think it's O(n) in the general case
except operations go from O(n log n) to O(n)
the problem is that most of these "detections" are O(n)