453 karma · joined December 1, 2011
BUT, they have list comprehensions!! One of the main things I miss coming from Python.
Not an index per se but the Canadian Centre for Policy Alternatives publishes living wage reports, here is how they calculated it in the last one (2019): https://www.policyalternatives.ca/sites/default/files/upload...
As a paranoid citizen I don't trust people with my privacy if they get off on punching down at other people's freedoms. Simultaneously I agree that Eich built some interesting technology. Just like Obama started to put a dent in mass incarceration [1].
[0] https://www.thebureauinvestigates.com/stories/2017-01-17/oba...
[1] https://www.vox.com/policy-and-politics/2017/1/6/14189862/ob...
If using entropy emission as the indicator, how would we distinguish the exhaust of life from any other energy source? Wouldn't it make sense to look for pockets of negative entropy or would those be hidden by all the opposite reactions?
Not a physicist obviously!
EDIT: and good on you for honouring her.
There's also https://github.com/jruizgit/rules but haven't tried it yet.
There is a minimum level of mutual co-operation and diplomacy required to nurture commitment and ownership, and alas it seems so uncommon as soon as a team goes over 5 people IME, unless the business is REALLY careful about hiring for openness and agreeableness.
My approach to AI is somewhat conservative because of working in a law-adjacent field where explainability is paramount. When it comes to getting "smart" I prefer forward-chaining logic over facts, and facts include predictions from models too. But at least there is a "judge"/engine to coordinate how the predictions from the ensemble of models maps to actions. I love me some pertained neural nets, but use them more as black box appliances.
I feel like you are right about the need for an original purpose. And would add that at such a momentous time when everyone can see the consequences of private, centralized media selling attention so efficiently, is it really impossible that the situation rises to that level of original purpose? The seed of a new community might just need a great spark.
Or not join at all, which is fine, but punching down and across at your coworkers comes across as not being a team player.
I also have a lot of experience starting with very lo-fi and manual scripting prototypes to validate user needs and run a process like release management or db admin, which would then need to be wrapped in some light abstractions to hide some of the messy details to share with non-maintainers.
Problem is, I've noticed that more junior developers tend to look at a complex prototype that hits all the user cases, and see it as being complicated. Then they go shopping for some shiny toy that can only support a fraction of the necessary cases, and then I have to spend an inordinate amount of time explaining why it's not sufficient and that all the past work should be leverages with a little bit of abstraction if they don't like the number of steps in the prototype.
So, not-generic can also end up failing from a team dynamic perspective. Unless everyone can understand the complexity, somebody is going to come along and massively oversimplify the problem, which is a siren song. Queue the tech debt and rewrite circle of life.
It is possible to join these across tables, and therefore treat the matching nodes as having the same meaning for classification. However, it doesn't make sense to concatenate trees with different roots because it would just look like regular nesting.
Even if I make it clear at the column level like resource_table.node_label::ltree and predicate_table.edge_label::ltree, there would still be no obvious way to parse where in the forest we traverse over nodes and edges, since they all look and function the same.
I feel like this calls for a well thought-out naming convention using the only thing LTREE allows, alphanumeric and underscore characters. Something like root0.__node__name0.__edge__name0.__node__name1. This "merged" forest could be a "projection" within queries/views.
Thanks again, happy topologizing :)
In PG you can do a kind of KNN for things that are X LTREE degrees away as well as ordering by distance from trigrams of text. With an ensemble of online learning models for different blobs of taxa, it is a way to prevent concept drift and give weights to the different subdomains of training data to fight bias.
This kind of topological approach is great. One challenge in SQL is that class membership can only be so expressive and I have a nagging desire for slightly more RDF-like edges of predicates/verbs, but that still feels like overkill to me since I can already do rule engines with facts based on the labels. Therefore I end up with class names like "things that verb" or "things that are verbable" like would be done for naming interfaces.
Scanning the paper I don't understand the math well enough (am more of a code plumber). How would different "types" of edges be encoded to get past the perceived limitations of class membership?
Every time I try just 400 IU per day for a week it makes me dizzy and woozy. I eat plenty of meat and veggies with K2, and nuts and fish with magnesium. Vitamin-D containing foods like milk, eggs and fish are totally fine. I can bake all day in the sun and don't burn easily.
There's something different about synthetic D3, and I wish I could get all the benefits that people here claim.
But every new release is the same or worse for memory. Is there something about these new architectures that I'm missing which should negate my desire?
Why can't I get a machine with 32GB RAM for under $3k or whatever they are now?