brahbrah
Joined 3 years ago
Joined 3 years ago
Have you tried? I haven’t tried it with the IRS, but I have tried asking my states permitting and planning department about the legality of various rental schemes for a property (that I didn’t own) and they were happy to look up the permits and tell me that indeed what I was asking about was not legal for that property. And further they let me know that tons of people do it anyway and that they don’t really check, but it’s a risk.
Enjoy the data directly from the source producing them.
American weather agency: https://www.nco.ncep.noaa.gov/pmb/products/gfs/
European weather agency: https://www.ecmwf.int/en/forecasts/datasets/open-data
The data’s not necessarily east to work with, but it’s all there, and you get all the forecast ensembles (potential forecasted weather paths) too
More likely they would just never comment whether it makes them look better or not, because otherwise for the reason you stated you could always gather the information they didn’t want you to have in the negative case.
It’s because most of the people doing these computations don’t have the capacity to become experts in multiple fields. They understand the math and analytics very well, and they expend all their time thinking about that, not about type systems, memory management, etc. Python lets them code without having to think about a lot of that stuff so they can focus on the things they care about. These aren’t computer scientists or programmers, they’re meteorologists, astronomers, oil and gas analysts, investment bankers etc. That’s why some truly great computer scientists and programmers invested their time into building these tools for python vs other languages.
Here is how prices are set in an iso auction. This is from iso New England. But works the same way in all isos including ERCOT.
https://www.iso-ne.com/about/what-we-do/in-depth/how-resourc...
It doesn’t matter to me if the mining operations are running or not, but they’re not helping the grid. Citing a crypto company on this is comically biased.
def add(df1, df2, meta_cols, val_cols=None):
# join on meta cols
# add val cols (default to all non meta cols if None)
# return df with all meta and val cols selected
In theory I think that's fine. The problem is that in practice this will cause a lot of visual noise in your models, since for every operation you would need to specify, at least, your meta columns, and potentially value columns too. If you change the dimensionality of your data, you would need to update everywhere you've specified them. You could get around this a bit by defining the meta columns in a constant, but that's really only maintainable at a global module level. Once you start passing dfs around, you'll have to pass the specified columns as packaged data around with the df as well. There's also the problem that you'd need to use functions instead of standard operators.One thing that would be nice to do is set an (and forgive me, I understand the aversion to the word "index") index on the polars dataframe. Not a real index, just a list of columns that are specified as "metadata columns". This wouldn't actually affect any internal state of the data, but what it would do is affect the path of certain operations. Like if an "index" is set, then `+` does the join from above, rather than the current standard `+` operation.
In any case I realize this is a major philosophical divergence from the polars way of thinking, so more just shooting shit than offering real suggestions.