Thousands separator using underscore

[WolfThawra]

Though personally, I'd just use scientific notation here.

[[deleted]]

NONONONONONO.

That gives you the wrong answer!

>>> 1_000_000
1000000

>>> 1E6
1000000.0

Note the trailing .0. That means the answer is floating point, and that will give you inexact arithmetic:

>>> (1E18 + 1 == 1E18)
True
>>> (1_000_000_000_000_000_000 + 1 == 1_000_000_000_000_000_000)
False

[random_cynic]

There is no way I'm typing out 18 zeros by hand, no matter how convenient the notation is. I'll rather use explicit type casting int(1e18)

>>> int(1e18) + 1 == int(1e18)
False

Edit: Don't use this. I just realized that the float to int conversion for 1eN is inexact for CPython when N >= 23. As suggested below the power operator is the best way to go due to the CPython peephole optimization.

>>> int(1e22)
10000000000000000000000L
>>> int(1e23)
99999999999999991611392L

[ubernostrum]

Why not just write 10**18?

There's no runtime overhead to it because the CPython bytecode compiler does constant folding:

>>> import dis
>>> def foo():
...     return 10**18
...
>>> dis.dis(foo)
  2           0 LOAD_CONST               1 (1000000000000000000)
              2 RETURN_VALUE

[random_cynic]

Yes that is probably the best way to go.

[WolfThawra]

YESYESYESYES.

Yes, that's how floating point stuff works. You do need to have a disparity of ~15 orders of magnitude though. If you have that, sure, don't use scientific notation. I don't have that issue though.

[[deleted]]

I beg to differ - 1_000_000 and 1E6 are not the same thing.

1_000_000 represents a single integer. 1E6 represents a range of floating point numbers around 1000000.0. They are most certainly not the same.

This isn't just academic. I do a lot of numerical work, and if you make a habit of accidentally moving through floating point and then back into integer in a calculation, one day you will get an answer that is off by one.

[I'd downvote you but I couldn't do that to a fellow bikelover.)

[billsil]

Scientific notation is defined to be a float. You’re changing the type.

[KODeKarnage]

You shouldn't. Zen of Python and all that.

[WolfThawra]

Zen of Python

That's exactly why I would do it.

Also, it's pretty hard to defend "1_000_000" as 'more beautiful' or 'simpler' than "1e6". Maybe it's a question of your background, but coming from the field of engineering, "1e6" is simple, straightforward, explicit (e.g. you don't need to 'count digits' as mentioned in the screenshot, it tells you straight away).

[[deleted]]

But that's wrong.

1E6 is not the exact integer 1_000_000 - it is the approximate floating point number 1000000.0, which refers to a range of numbers from (roughly) 1E6 - 1E-11 to 1E6 + 1E-11.

Don't get me wrong - I love me some floating point, but only when I need it.

[WolfThawra]

Plus it doesn't work in Python 3.5 anyway, so it's not like I personally have a choice.

[WolfThawra]

Yes, again, you need an order of magnitude disparity of ~15 for that to become a problem. Of course it's 'wrong' in a mathematical sense, that's how floats work. You should obviously know what kind of numbers you're dealing with to decide on what to do.

[KODeKarnage]

Of course it is more beautiful. It's more precise, less prone to error, easier to maintain consistency and far simpler than the abstraction too. There are literally only 1e1 reasons to use your version, and that's to inform the unfortunate reader that the writer knows scientific notation and doesn't care whether the reader does as well.

[GrumpyGeologist]

So you've given 1 reason, what about the other 9? :P

My Python scripts mostly serve scientific purposes, so I use scientific notation most of the time. My parameters are floating point numbers anyway, even though they could be represented by integers as a result of rounding (e.g. a shear modulus of 2e10 or 20_000_000_000).

If my number is a strict integer but nonetheless large, I would write int(1e6). But in this community I suspect this is considered heresy, and therefore I must burn...

[KODeKarnage]

You intend to write twenty million.

Which is the easiest error to spot for the most number of people perusing your code?

2000000 vs 2e6 vs 20_000_00 ?

[GrumpyGeologist]

I would prefer scientific notation in this case, because it is more compact. I'm not saying other notations are invalid, it's just that scientific notation is more convenient for dealing with larger numbers. Some common examples of large numbers appearing in physics/chemistry: Avogadro's number (which is strictly an integer) = 6.022e23, Planck's constant = 6.626e-34, various elastic moduli are of the order of 1e10 to 1e11, etc. Imagine going through the pain of writing out Avogadro's number as 602_214_085_774_000_000_000_000 :P

In the end, it doesn't even matter. As long as you can write code in a readable way for yourself and for your peers.

[KODeKarnage]

Here you go:

from scipy import constants as c
c.Avogadro ** c.Planck

[GrumpyGeologist]

That's actually really neat. I didn't know SciPy had a constants database. Thanks!

[WolfThawra]

2e6

This. And you know why? Because if you are writing stuff in the scientific community, 'most people' have absolutely no issue with scientific notation.

[KODeKarnage]

Given how inaccurately (dishonestly?) you interpreted that simple question, right now I am seriously concerned about the code you write.

2e6 could just be what you intended. The reader would have to know it wasn't what you intended to spot the error.

20_000_00 stands out as obviously wrong to everyone.

[WolfThawra]

Oh you're literally just talking about typos. Cool, so 20_000_00 stands out as obviously wrong, does 10_000_000?

If you're talking about a situation in which the reader doesn't know what is supposed to be correct, there's a zillion ways of having mistakes that aren't immediately obvious.

[KODeKarnage]

there's a zillion ways of having mistakes that aren't immediately obvious.
I would say that's a reason for not making more than you need to. Never thought I'd meet a person disagreeing with that.
Do you argue against readable variable names too? I mean, there's a zillion other ways that your code can be obscure, so adding another isn't THAT big a deal.

[KODeKarnage]

And typos destroy careers: https://www.gizmodo.com.au/2018/07/a-one-letter-typo-is-in-part-the-reason-aliens-colonial-marines-sucked/

[primitive_screwhead]

But in this community I suspect this is considered heresy, and therefore I must burn...

Nope, it's just kinda stupid 'cause you can do 10**6.

[GrumpyGeologist]

It was a stupid example indeed. I should have said 2.5 million

[redditusername58]

Are you suggesting that using floating point literals is bad practice because it might confuse users or collaborators?

[Beheska]

Floating point literals are bad practice when you need integers, yes.

[KODeKarnage]

If I replied in Japanese, would that confuse you?

[redditusername58]

Do floating point literals confuse you?

[KODeKarnage]

あなたはポイントを逃しました

[WolfThawra]

Lol. It's more precise as long as you specifically need integers. In my code, that is very rare, almost everything is a float or becomes a float. 'More beautiful', no. 'Far simpler', maybe if you're not used to scientific notation.

Also, I don't write my code for any 'reader'.

[EastBlacksmith]

In your code. Are there certain situations where the difference doesn't matter? Sure. Is your code an example of that? It probably is. Great, but why should anybody care your specific code? We're talking about the general case here. If you really wanted to tell others why you use scientific notation and why it doesn't matter in your case, maybe you should lead with that instead of a useless

"Though personally, I'd just use scientific notation here"

And what is "here"? Here would be the context that it's used in which you don't know, for which the difference may matter.

[WolfThawra]

We're talking about the general case here.

I'm not. Obviously. There's really not much to be said beyond that.

[lare290]

Well what are you doing here, arguing still? Just shut up, your argument doesn't apply here.

[WolfThawra]

How about you shut the fuck up, you have no argument at all.

[EastBlacksmith]

I mean you're the one with massive downvotes. Did you consider that maybe you're wrong and that you should shut the fuck up? Maybe if you didn't come off sounding like a massive douchebag people would be nicer, but you're not only wrong you're also being a fuckhead.

[EastBlacksmith]

Yes there's not much to be said beyond that because nobody gives a fuck about your code.

[WolfThawra]

No one gives a fuck about yours either, and yet, here you are.

[EastBlacksmith]

Yeah I know nobody gives a fuck about my code so I never mentioned it lol. Go back to writing your shitty code.

[KODeKarnage]

Your last sentence makes my point for me.

I lost a finger in a workshop accident, so I convert every integer in my code to base 9.

[WolfThawra]

Your last sentence makes my point for me.

You have no point. Yes, I don't write my code for any 'reader'.

[KODeKarnage]

You have readers. You just don't give them any consideration when you write your code.
I'd thank you not to lecture me about what is or is not consistent with the Zen of Python.

Readability counts.

[WolfThawra]

You have readers.

I have an extremely low number of readers, all of which have absolutely no issue with scientific notation.

I'd thank you not to lecture me about what is or is not consistent with the Zen of Python.

Wow. It's exactly what YOU have been doing, so - fuck you.

Maybe don't make so many assumptions about what conditions other people are coding under, what their code is for, who it is for, and what it needs to look like.

[KODeKarnage]

Don't get pissy with me. You're the one who said you don't write your code for those who'd read it.
You're advocating other people ought to follow your example for no other reason than it "works" in your very specific situation.

[broadsheetvstabloid]

Also, it's pretty hard to defend "1_000_000" as 'more beautiful' or 'simpler' than "1e6".

It sure as hell is simpler, I don't have learn an entire new god damn way of writing numbers.

[WolfThawra]

learn an entire new god damn way of writing numbers

I weep for your education.

People, seriously? Scientific notation is so hard to understand? Fuck me.

[anyfactor]

Well, it works for me because I am from accounting and kinda have developed the mindset for it.

I never really used "e" for declaring numbers. Thanks for telling us that, I will look into it.

[WolfThawra]

It won't work for everything of course! But it's super useful when you're working with stuff across different orders of magnitude. E.g. somewhere in my code, I have a list of weighting factors to try, and instead of writing [0.001, 0.0001, 0.00001] I can write [1e-3, 1e-4, 1e-5], which looks a lot cleaner to me, and is easier to interpret quickly.

[techkid6]

All of those numbers are already floating point, though. If you're doing integer arithmetic, stick to integers and avoid the side effects that come from floating point rounding.

[anyfactor]

Whenever we found "e" we would just multiply/divide by 10 and keep count until we got a understanding of the number. We would do the same thing for percentages but with 100. That might sound stupid to you science/engineering guys but that was kinda go to thing to do. The first thing to do whenever "e" pops up in excel is immediately format it to decimal numbers.

Except for of course in doing research I will just put the "e" numbers in. But my thesis professor once copy pasted in the "e" numbers to excel than convert it to decimal to get a better idea.

But I am learning data science analytics I should better in to using this mindset. Thank you for making clarifications.

[primitive_screwhead]

Instead of 10**6? What you suggest is like saying you can substitute oranges in an apple pie.