|
Boris Galerkin posted:e: nevermind this only half works. __repr__ returns an actual Name object so I can't do things like "country.name+country.name['de']". Sad. __repr__ only gets called to turn your object into a string, so "country.name+country.name['de']" doesn't call __repr__ at all. This is also the essence of why what you want is a bad idea. What type of thing is "country.name"? It can't be a string, because you can't index a string with ['de'], but it needs to behave like a string almost all the time. This means that it needs to be some kind of nearly-a-string object that behaves like the string "Belgium" except in some very special circumstances, and making an object like that will surprise people. That's what you've built with Name, except __repr__ only covers behaving like a string when you print it, and not when do other string things like concatenating or slicing. If you want to do something like this in a simple and not-surprising way then use a function. It's not semantically wrong for it to be a function because it's a thing that behaves differently depending on what arguments you pass it. If you're really upset about typing country.name() instead of country.name you can do this: code:
|
#
¿
Mar 10, 2017 10:57
|
|
|
|
| # ¿ May 3, 2024 02:27 |
|
|
Boris Galerkin posted:(but mostly because I don't think it's semantically correct to call a function to return a value that I've already computed). This is a pretty weird thing to think.
|
|
#
¿
Mar 10, 2017 19:38
|
|
|
You need to tell sorted what it's sorting. In your last example, how does it know it's supposed to be sorting the list of cars? You should probably also get used to looking up the documentation for functions you are using. Even if you don't understand everything its a good habit to get into because because a lot of these types of questions have answers that live in the documentation.
|
|
#
¿
Mar 12, 2017 02:59
|
|
|
Boris Galerkin posted:I think the proper term is using the __new__ constructor as a factory function? Is this an accepted way to do something or is this one of these things I shouldn't do in python? Yes, this is what you're doing and no it is not a normal thing to do. I can't think of anything really wrong with it, but it's definitely weird and you will surprise people if you do it.
|
|
#
¿
Mar 18, 2017 10:59
|
|
|
There's a lot of slightly strange things in the collections module. Like docstrings using ''' instead of """, or single line doc strings using 1 quote instead of 3, or the whole implementation of namedtuple.
|
|
#
¿
Apr 16, 2017 09:44
|
|
|
How aboutcode:
|
|
#
¿
Apr 19, 2017 00:27
|
|
|
Eela6 posted:Numerical Analysis is not an easy subject and it frustrates me when people pretend it's simple & intuitive. In the vast (vast) majority of cases they are in fact very simple and intuitive. It's extremely rare to need a mental model of floating point that is more sophisticated than "they're like real numbers except that they get funny when they're really big or really small" even if you work with them every day.
|
|
#
¿
Jun 11, 2017 19:41
|
|
|
Python code:
|
|
#
¿
Jun 11, 2017 19:52
|
|
|
Thermopyle posted:That's why its confusing to beginners. That's why I'm suggesting a very simple mental model that is intuitive and also sufficient for even non-beginners. Teaching people that floating point numbers are dark and spooky and complicated isn't very productive, because very few people need to care about that level of detail. I'm responding to "Numerical Analysis is not an easy subject and it frustrates me when people pretend it's simple & intuitive" by pointing out that for most practical purposes it can be made to be exactly that.
|
|
#
¿
Jun 11, 2017 19:58
|
|
|
LochNessMonster posted:If I'm running into that in my 2nd project with basic funtionality I'd say it's defintely something almost everyone will care about rather sooner than later. Floating point numbers are not real numbers, and you need to be aware of this when using them. The particular way in which they are not real numbers is quite complicated, and is rarely relevant. I offered some additional guidance on how to think about the relationship between floats and reals. Floating point weirdness is also one of those topics that programmers love to expand on at length when it comes up (I'm slightly surprised no one has warned you about storing currency in floats yet) and my suggestion to "not worry about it" should be taken in the context of your post triggering a page of responses. The fact that you went away from the discussion with the impression that you should "watch out" when using floats is exactly what I was trying to mitigate.
|
|
#
¿
Jun 11, 2017 20:53
|
|
|
baka kaba posted:But you should worry about it though? To the point that you're aware that there are some basic pitfalls, and then keep them in mind when you're using floats. The poster you're replying to was already not worrying about it, that's why they hit a problem and had no idea what was going wrong My stance is that you should be aware floats are not reals, and but you should also not worry about it. The poster I was replying to was not aware of this (and they got lots of explanations in this thread, so that part worked out well).
|
|
#
¿
Jun 11, 2017 21:16
|
|
|
Eela6 posted:I mostly posted the point about currency to tweak Nippanish's nose, but I'm actually glad I did. More people should know. I used to write modelling software for an insurance company and we did 100% of our currency calculations with floats. I hope this annoys you  .
|
|
#
¿
Jun 11, 2017 21:23
|
|
|
QuarkJets posted:This is the level of worrying that Nippashish said a newbie shouldn't be at, and he was 100% right. "Why is this single line of floating-point arithmetic giving me a funny-looking answer" requires a very basic understanding of the issue, not "read this essay on the difficult subject of numerical analysis" I'd actually go further and say that it's not just beginners, but most programmers. If you need to worry about the details of floating point numbers then you are doing something quite unusual.
|
|
#
¿
Jun 11, 2017 22:00
|
|
|
pmchem posted:Nah, floating point correctness and approximations come up all the time in scientific computing, especially if you have unit tests. Scientific computing isn't "quite unusual"; it's the primary driver for the biggest floating-point computers in the world: https://www.top500.org/lists/2016/11/ I'm well aware of this, pushing floats around is my day job. Most of the careful thinking about stability is done in at the level of BLAS and friends and very few people actually write that kind of code (the few that do do need to care about the details of floats). When you're writing scientific software your reasoning about stability typically happens at a higher level of abstraction than the properties of floats. Instead you think about the properties of matrix factorizations and DE solvers and other high level operations (which inherit their properties from floats, but not in ways you control). Reasoning at the boundary is dominated by "things can get weird with really big or really small numbers", which I why I suggested that as a mental model earlier.
|
|
#
¿
Jun 11, 2017 22:47
|
|
|
pmchem posted:Cool, mine too. You ignored the point about unit tests in my post. If you write scientific software that has numerical tests of floating point results, then as I'm sure you're aware, when you change (compiler / compiler flags / arch / libraries), the float results may slightly change. That's a pretty common occurrence, and is a reason why anyone involved with scientific software should be aware of floats. Not unusual at all. Yes sorry I forgot to respond to the unit test part. The the version of this that I see most often is that the results of parallel reductions change because floats aren't associative so results can change even between multiple runs of the same binary on the same hardware. I deal with this in exactly the same way I deal with any other float comparison. Anyway the point I'm making isn't that people should ignore that floats are not a perfect representation of real numbers. My point is that although the precise behavior of floats is quite complicated, there are very simple ways of thinking about them that explain their behavior at a level that is appropriate for the vast majority of people, including most of the people writing scientific software.
|
|
#
¿
Jun 12, 2017 00:01
|
|
|
Thermopyle posted:Depending upon what your crawler is actually doing, you should probably use asyncio or greenlet instead of threads/multiprocessing anyway. I/O bound tasks work great with async. Is it possible to use async without making the code async "all the way down"? Maybe I'm just dense, but afaict anything that blocks in a non-async way (read: all legacy code ever) ends up blocking the world?
|
|
#
¿
Aug 1, 2017 18:10
|
|
|
Thermopyle posted:The absolute easiest is to use eventlet or greenlet which will patch the standard library at runtime to make all the I/O functions (like the socket library and thus http, urllib, requests, etc) use yielding versions. This will make your legacy python code automatically async-friendly. This is the thing I was missing. I understand what async is for, but last time I tried it I gave up because I convinced myself I'd need to rewrite all my existing non-async-aware code to see benefits.
|
|
#
¿
Aug 1, 2017 20:51
|
|
|
Cingulate posted:If it's tabular data, just use pandas read_csv (and make plots in seaboard). Seriously, do this. Do not even consider the csv reader in the stdlib. Pandas is infinitely superior.
|
|
#
¿
Aug 14, 2017 19:53
|
|
|
You should though, especially since the next step is "make charts".
|
|
#
¿
Aug 14, 2017 19:58
|
|
|
Eela6 posted:I don't feel that way. I don't particularly like pandas, and I prefer using the stdlib where possible. You have to consider the audience of your code, too. Jose is very new to python; the last thing he needs is a thousand different APIs to understand. The audience is someone who wants to load data from csvs to produce charts. Someone who is already using matplotlib and is enrolled in something called "data camp". Pandas is a cornerstone of the python data science toolchain. Avoiding it is pretty much the data science equivalent of rolling your own web server.
|
|
#
¿
Aug 14, 2017 20:34
|
|
|
I put stickers on my laptop because I work in an office with 500 people and 99% of them use macbook pros. Gotta have some way to tell which one is mine.
|
|
#
¿
Sep 1, 2017 22:28
|
|
|
creatine posted:Question: input_list.index(data) effectively looks like this on the inside: code:
|
|
#
¿
Oct 6, 2017 00:14
|
|
|
SurgicalOntologist posted:In short, I can't figure out a good way to reliably get the closest index with floats. I really don't want to do something like argmin(abs(time_series - time_values)) for a frequently used lookup function, but is that the only way? Searchsorted doesn't look for the index of the nearest-to-target value, it looks for the index where you could insert the target value while keeping the original vector sorted. If searchsorted returns idx for target it doesn't tell you if target is closer to values[idx-1] or values[idx], you need to check that separately. Here's a solution from stackoverflow: code:
|
|
#
¿
Nov 16, 2017 22:05
|
|
|
Another option is to fix the script to work with the updated pandas version.
|
|
#
¿
Nov 21, 2017 09:12
|
|
|
Tigren posted:This seems like it's no longer just an implementation detail, but Guido proclaiming dicts are now ordered by design starting in 3.7. It seems like they're also keeping collections.OrderedDict but intentionally having a different implementation optimized around different usage patterns, which seems like an odd choice.
|
|
#
¿
Dec 20, 2017 00:34
|
|
|
unpacked robinhood posted:It gives the following tree, in this case the longest path is 9 bits long, which isn't an inprovement when storing 8 bit values I think ? A Huffman code minimizes the average code length for the data used to build it. If you compare a Huffman code to the shortest fixed width code then some words will have longer codes and some will have shorter codes, but it is specifically the common words that are short and the rare ones that are long. If you encode the input data and compute total_encoded_bits / number_of_words then this ratio will be smaller for the Huffman code.
|
|
#
¿
Dec 20, 2017 10:00
|
|
|
Slimchandi posted:But even if the object I'm describing in my class is 'abstract' (e.g. Bird), which I never call directly, and I only use it to subclass instances of 'real' birds (Gull, Eagle, Owl), this situation wouldn't benefit from using an ABC. I would be better off with a standard Bird class that I inherit from, right? I wouldn't use an ABC unless at least one of the methods was going to be abstract. In this case the advantage of an abstract foo over def foo(): pass in the base class is that python will yell at you if you forget to implement foo in the subclass, instead of just calling the empty method and plowing ahead. If this is not a thing you care about then you have no reason to use ABCs.
|
|
#
¿
Jan 17, 2018 20:57
|
|
|
NtotheTC posted:To be clear, the behaviour I want to replicate is I have endless copies of code:
|
|
#
¿
Jan 21, 2018 17:08
|
|
|
ZarathustraFollower posted:filename=('HeteroFreq2.txt'), That comma one the end makes it a tuple with one element. Delete the comma (and maybe also the parens because they're not doing anything).
|
|
#
¿
Jan 25, 2018 22:15
|
|
|
Portland Sucks posted:I know floating point math is a nontrivial issue, but is there a standard way to handle this stuff when doing routine calculations on numbers that are very precise? My current thought is to just change my tests to pass if there is less than n% difference between the Excel values and the python computed values, but that seems a little hand wavy. You're opening a huge can of worms here by asking about precision, although almost certainly the answer you want is "learn to live with small amounts of precision difference". However, if you're seeing differences as early as just reading the values and looking at what you read it is extremely likely that excel actually has the same precision loss as python and is just rounding differently for display purposes.
|
|
#
¿
Jan 29, 2018 00:40
|
|
|
Seventh Arrow posted:Wait, I just realized that the index - or row number, whatever you want to call it - is being included in "collector_key": No this is not what you need to do. to_json is not storing "superflous" data, but it's also not storing the data in the format you need. When you look at a json file you can read [] and {} just like you do in python. When you call json.load on the file [] becomes a list and {} becomes a dict. What's going on is you have a table of data like: code:code:Pandas .to_json stores the data differently though. to_json stores it like this: code:For what you are trying to do I think the "json" part is leading you down a garden path. You need to do something like this: code:
|
|
#
¿
Mar 3, 2018 11:14
|
|
|
Seventh Arrow posted:I'm not sure (yet) how to call a dataframe row by row That's what iterrows does.
|
|
#
¿
Mar 3, 2018 14:26
|
|
|
You can also run an http server in the python 3 process and have the python 2 process interact with that to signal when it should do things.
|
|
#
¿
Apr 1, 2018 23:56
|
|
|
Linear Zoetrope posted:In numpy (or some interoperable library like pandas) is there a way to create basic shapes like triangles or circles in an ndarray/tensor/table/whatever? I'm featurizing a space of entities represented like {pos = (x,y) , shape = Triangle{base_len = 1.5}, ...} or whatever and while I'm entirely capable of writing this myself* it would be nice to be able to just have python do it. Numpy isn't an image library so it doesn't have functions like this. Your best bet I think is to use Pillow to draw a greyscale image for each channel and then convert those to numpy arrays and stack them. Pillow has a polygon function that should suit your needs, and you can convert a Pillow image to a numpy array with np.asarray(my_image).
|
|
#
¿
May 21, 2018 10:07
|
|
|
SpaceSDoorGunner posted:Anyone know why this: Yours finds non-prime factors.
|
|
#
¿
Jun 2, 2018 22:27
|
|
|
cinci zoo sniper posted:Yeah NumPy will internally route stuff to C or Fortran code to speed things up, including hardware-specific optimisations. Pandas does the same twofold, since it has both its own C stuff and is largely built on top of NumPy (wrt data structures and such). This doesn't help for constructs like apply though, since they need to invoke a python function (and thus interact with the interpreter) for each element of whatever you are applying to.
|
|
#
¿
Jun 10, 2018 19:25
|
|
|
The arange and the reciprocal aren't helping with memory use either.
|
|
#
¿
Sep 9, 2018 19:32
|
|
|
salisbury shake posted:I'm just learning to use NumPy and had to poke around the docs to do what I want. While the above code finds the solution correctly, I'm unsure if I'm using NumPy efficiently or even canonically. The problem is that the pattern of indices you need to accumulate into is a bunch of irregularly scattered rectangles. There is good syntax for working with single rectangles of locations, or with irregularly scattered single locations, but irregularly scattered rectangles is a case that is not handled well. If you build all of the indexes explicitly (e.g using np.meshgrid or np.mgrid) and concatenate them together then you could probably get away to a single call to np.add.at (by changing the problem from indexing at an irregular collection of rectangles to indexing at an irregular collection of points), but this doesn't solve the real problem which is that you need to loop over all of the claims to collect the indices in the first place. It might be worth trying as an exercise to learn the tools, but it won't be any more efficient and will probably be harder to understand. For count_overlapping it would be more idiomatic to write np.sum(fabric > 1), but your way is fine too. It would also be more idiomatic to write fabric[indices] += increment instead of np.add.at(fabric, indices, increment) unless you are making use of the fact that np.add.at will increment repeated indices multiple times. Nippashish fucked around with this message at 09:21 on Dec 7, 2018 |
|
#
¿
Dec 7, 2018 09:06
|
|
|
You could also just commit to not import your scripts as modules and then you don't need any double underscore shenanigans.
|
|
#
¿
Dec 18, 2018 20:22
|
|
|
|
| # ¿ May 3, 2024 02:27 |
|
|
QuarkJets posted:It's cool and good to have a file that is both importable and runnable as a script I guess what I'm trying to say is that having a slightly weird syntax to do a slightly weird thing is one of the less objectionable features of python imo.
|
|
#
¿
Dec 18, 2018 21:18
|
|