The poster is basically proposing something like always doing:
def all(lis: List[T], mapf: Callable [[T], bool]) -> bool:
for e in (mapf(l) for l in lis):
if e is False: return False
return True
At least that's my take on avoiding Truthy and Falsy via a mapping closure (or function?). But I don't see it solving OPs issue here when lis is empty... So maybe I'm missing something too.
I'm totally with you for processes should probably use glibc/platform API calls, but procfs is nothing short of brilliant and a great validation of the power of the "everything is a file".
I'm not sure that's the case. I don't think people are responding to the "redneck in a pick-up" stereotypes as much as that "pavement princess" owner trying to "cosplay" truck culture stereotypes.
Sidenote - I'm finding my vocabulary pretty lacking now that so much stereotyping is done in images and memes.
https://mathworld.wolfram.com/RootedTree.html: “A rooted tree is a tree in which a special ("labeled") node is singled out. This node is called the "root" or (less commonly) "eve" of the tree. Rooted trees are equivalent to oriented trees (Knuth 1997, pp. 385-399). A tree which is not rooted is sometimes called a free tree, although the unqualified term "tree" generally refers to a free tree.”
> A tree which is not rooted is sometimes called a free tree, although the unqualified term "tree" generally refers to a free tree.
I wonder if that was once the case but no longer is. I'm learning I think of trees mostly through the lens of data structures and not graph theory and I imagine more people do than not.
You gotta be careful -- a path does not exist between two leaf nodes, unless your edges are non-directional, in which case you're right. Oh and restrict it to 'only visit each node once' given undirected.
Visiting a node twice implies a loop, which implies two paths between your original nodes.
Let’s say we want to get from A to B, but we visit Y twice. That means there’s a segment of A~B that is Y~Y (a loop). However, since we’re talking about undirected edges, we can reverse that segment. Then both our original A~B and the A~B with Y~Y reversed are paths from A to B.
So if there’s a single path from A to B, there cannot be a Y we visit twice along that path.
(Please don’t take this as criticism; my pedantic nature got the better of me.)
Yes, but in an UndirectedGraph you can do loops easy peasy. A->b->a->b etc. if you have a tree with a parent node, then the tree (A{children:[b], parent: null}, B{children:[], parent: A}) still may allow for this behavior (graph representation unions parent and children since a parent in tree parlence is basically 'incoming-edges' in graph parlence while children is 'outgoing-edges')
I was trying to find terminology for something
Like 'all possible paths between these two nodes contain exactly one Hamiltonian sub-path' but I think that's a bit of a circular definition
All that said I'm running off 3 hours of sleep and about to recoup so that probably explains my non constructive comments here
I think that I shall never see; A graph more lovely than a tree. A tree whose crucial property; Is loop-free connectivity. - Radia Perlman, inventor of spanning tree
Not OP but between Java and C# it's hard to not to lean Java for the absolutely massive lead in high quality libraries and ecosystem support. C# still feels like the new kid in open source circles though the languages are 90% the same.
This kind of response is a common issue .NET has to deal with. C# is not Java, I wish it was tongue in cheek but I keep having to seriously respond to these, as unfortunate as it is.
First OSS version of .NET was released 8 years ago.
Java is much higher level and much more OOP focused language than C# of today, which is multi-paradigm and exposes a lot of low-level features when needed, and is implemented under the hood way closer to the likes of C++ and Rust.
The difference in quality is dependent on the context. If a company is a pure Java shop that lives and breathes Apache projects - sure. Not so much or opposite otherwise.
We can say most positive integers are greater than 5. Or most real numbers are irrational. Half of all integers are even — even though there's just as many of both!
A ton of comments are missing the point of this complaining about list/map syntax etc. I'm not sure if the kotlin lazy addresses this.
The point is that static final variables interact especially well with the JIT's constant folding machinery. But lazy loading a constant necessitates that it can't be final: it's initially null until it's effectively final after the first lazy load. This finality is clear to the developer but not to the JVM.
This is introduces a way to implement lazy constants via a blessed class that solves this.
The article is pretty clear about what the point is — but does require some careful reading and context.
The example used is the venerable Logger class from the log4j package. It seem implausible that imprecise constant folding would cause a measurable performance decrease when using that class. So to me the point is not clear. A more convincing argument would be before and after stats of a benchmark showing x% performance increase.
