The speed of light is an integer. Why should we care?

[ggggggggg]

What if there was a tutorial mode in the REPL, kind of like how a lot of video games start of popping up info on the screen about what button do what to gradually introduce the information. The first time you define an integer from an integer literal it would pop up some info about what you just did, including a warning about integer overflow and link to the manual. Likewise, the first time you write a for loop in the REPL outside a function, maybe it links you to the performance tips about not working in global scope, and to info about scoping rules for julia. Are there enough items like this to make a tutorial mode useful? Maybe every-time you start up it picks some info from it’s library to put at the top of the REPL.

[gevis]

@orialb

I’m sure that if you write a nice tutorial emphasizing the things you find important, people will appreciate it.

Actually, everything has already been written in the my first post in this thread.

In my view, the subsection Overflow Behavior only lacks the following link and may include the following example:

@gevis

Since 1983, the speed of light is defined to be exactly equal to 299,792,458 meters per second. So, it seems natural to define it as an integer while doing some culculations with Julia, for example, to calculate a Planck’s length. This is how it can be done in Julia REPL:

c = 299_792_458;  # the speed of light
G = 6.67430e-11;  # Gravitational constant
h = 6.62607015e-34;  # Planck's contant 
h_bar = h / (2*pi);  # reduced Planck's constant
planks_length = sqrt(G*h_bar/c^3)

As a result, we immediately get 3.5793584153084007e-32 which at first sight is what the Planck’s length should be.

However, Wikipedia says that the Planck’s length is equal to 1.616255e-35 .

You probably already realized that the reason for this is the integer overflow that happens when raising c to the power of 3 . Moreover, it is easy to fix this redefining c to be a float:

c = 2.99792458e8

After doing so, we get the value of the Planck’s length to be equal to 1.6162550244237053e-35 , which coincides with the value stated in Wikipedia.

If the corresponding git pull request will be accepted, I can prepare it.

The link above can be introduced at the end of the said subsection as follows:
“For further discussion of this topic see link.”

The example above, can be introduced with as follows:
“If your previous experience make you think that integer overflow is quite rare and almost never happen in “real life”, concider the following example:”

[johnh]

Actually as a physicsit it does not seem natural to me to define c as an integer.
Clearly it is define as a whole number of metres in the SI system since 1983
Then again I started my undergrad degree in 1981…

I would first of all reach for PhysicalConstants.jl

I also saw mention of SaferIntegers.jl in this thread. Mind. Blown.
Are there similar things in other modern languages?

[Ian_Slagle]

@johnh

Are there similar things in other modern languages?

IIRC, Rust (which was designed for very safe code) doesn’t have overflow in debug code, but allows it in release code

Integer overflow

[Mason]

@johnh

Actually as a physicsit it does not seem natural to me to define c as an integer.
Clearly it is define as a whole number of metres in the SI system since 1983
Then again I started my undergrad degree in 1981…

I’d strongly disagree. The speed of light in my view is the dimensionless integer 1 GitHub - MasonProtter/NaturallyUnitful.jl: Facilities for using natural units with Unitful.jl

[anon37204545]

@Mason

I’d strongly disagree. The speed of light in my view is the dimensionless integer 1 GitHub - MasonProtter/NaturallyUnitful.jl: Facilities for using natural units with Unitful.jl

This is the only acceptable solution.
Bonus: it saves you from integer overflows.

[mbauman]

@gevis, one of the core tenets of my interactions on this board is to assume the best of faith when interacting with others here. I don’t see folks shoving things in your face, nor do I see folks saying you can’t read, nor do I see folks saying that the documentation is in the best possible state and should not be changed. At the same time, I totally empathize with getting bit by a bug like this and feeling frustrated — and I get how the discussion here might feel like pushback. I’d just ask that you (and others here) focus on the potential improvements and avoid putting words in others mouths (or reacting to such). Remember that we’re all here because we enjoy the language and want to see it improve and succeed.

This discussion has already spurred one concrete improvement to the docs, and I’d further support cross-linking the FAQ to the overflow behaviors. I’m not as certain about the speed-of-light example simply because it’s rather long and complicated for non-physicists. It could be as simple as:

julia> c = 299_792_458
299792458

julia> 100c^2
8987551787368176400

julia> 200c^2
-471640498973198816

But I’m not sure it’d get accepted. There’s a tension in trying to keep things terse as too much detail can also get in the way; I’m not sure where this one falls. We’ve also seen molecular biologists hit this in defining Avogadro’s constant as 6.022*10^23 — should we also include that? What about other domains?

@gevis

Especially at the time when Python has already established the standard for dealing with integer overflow by a higher level languages.

I do want to emphasize that numpy has the same behavior — and also relegates its discussion of overflow to the third major section of their user guide, even though they’re violating the behavior of their own language.

[kevbonham]

@gevis

Did you take the trouble to view the video in the reference above explaining how documentation should be organized and what is the difference between tutorial and reference guide?

Currently the Julia tutorial is the mixture of them.

I’m really curious what gave you the impression that the Julia manual is a tutorial. It’s not, as @orialb pointed out. It’s a manual - primarily a technical reference (that’s primarily how I use it) with a fair amount of explanation sprinkled in. Nowhere does it claim to be a tutorial.

I 100% agree that more tutorials would be useful, and I think should be tailored to different domains. I don’t think that’s what the manual is for though.

[dpsanders]

To be fair, I believe that historically the manual did take on the role of a tutorial, and was partially written that way.

[gevis]

@mbauman

I’d further support cross-linking the FAQ to the overflow behaviors.

It would be nice.

@mbauman

I’m not as certain about the speed-of-light example

I do not insist on that.

[Tamas_Papp]

@dpsanders

historically the manual did take on the role of a tutorial, and was partially written that way

AFAICT the tutorial-style parts cover concepts that are more or less unique to Julia. A nice example is the sketch of Rational, which brings together various concepts (parametric types, inner and outer constructors, promotion, etc).

I think that these belong in the manual, since otherwise the intent of how basic constructs should be used would be difficult to decipher. This, of course, does not mean that the manual is a tutorial about all things that are necessary to use and understand Julia, especially if they are generic concepts of programming. For example, the Control Flow section does not explain what a conditional is.

That said, just working through (most of) the manual is a very nice way to get started with Julia. But it does require covering about 70% of it, instead of just looking up certain sections.

[Syx_Pek]

It is a great shame that Avogadro’s constant cant be expressed cannot be expressed as a Float64 with no loss in precision.

julia> convert(BigInt, big"6.02214076E23") |> Float64 |> BigInt
602214075999999987023872

julia> convert(BigInt, big"6.02214076E23") |> Float64 |> nextfloat |> BigInt
602214076000000054132736

[TheLateKronos]

I know this has been mentioned, but I did not see a link. The reason that Julia allows integer overflows is explained in great length here:
https://docs.julialang.org/en/v1/manual/faq/#faq-integer-arithmetic-1

[xiaodai]

@tamasgal

I think the problem starts at the physics students not being taught some basic CS or the lack of the need of such during a physics study

I did a course in Numerical Computing and I was taught all sorts of things like catastrophic cancellation etc. I think if you do a lot of computation computers then learnign about Int and floats and how calculations can be messed up is super useful!

[BioTurboNick]

It might be nice if there was a tutorial package that would interactively walk people through the syntax and interfaces, a few key packages, even basic computer science knowledge like this.

[xiaodai]

Not exactly what you are looking for but checking out exercism which has a julia track.

Exercism

[Palli]

At least this is false (for the REPL with alternative REPL modes):

@gevis

At the very least this means that Julia REPL cannot be used as a scientific calculator by an average student.

Your exact code can work with first doing:

julia> using SafeREPL  # note, exact installation instructions (since not yet registered) at: https://github.com/rfourquet/SafeREPL.jl

i.e. without doing:

c = 299_792_458.0; 

what you otherwise could do, to get a floating point number, arguably better.

@oheil

should not be used as scientific calculator by an average student!

I’m not sure about that, I support Julia’s defaults, as it’s faster, while I can see both sides on the topic of the defaults, and thus I agree with you; and because of the danger of getting used to that non-default mode, maybe even it shouldn’t be used/installed by default?

My rule of thumb is that what can be measured, e.g. in meters (per sec), such as the speed of light, should use floating point, and what MUST (can?) be counted, e.g. currency (photons?), should use floats integers. [Those rules are sometimes broken, in banking integer cents or decimal (floating point), for dollars, should be used, while for a hedge fund floats can be appropriate for amounts.]

Since the Avogato constant was also brought up, since its SI redefinition in 2019, it’s exactly 6.02214076×10^23, and as atoms can be counted, its an argument for integers (BigInt then)…, while I guess floats (almost) always used.

[ANN] SafeREPL: use BigInt by default at the REPL

With Julia 1.5 around the corner, I’m happy to present SafeREPL, a little experimental package which by default interprets Int and Int128 REPL literals as BigInt, and Float64 literals as BigFloat: julia> using SafeREPL julia> factorial(40) 815915283247897734345611269596115894272000000000 julia> sqrt(2.0) 1.414213562373095048801688724209698078569671875376948073176679737990732478462102 julia> c = 299_792_458; c^3 # the cube of the speed of light can even be computed safely! 26944002417373989…

GitHub - JeffreySarnoff/SaferIntegers.jl: These integer types use checked...

[gevis]

@Palli

My rule of thumb is that what can be measured, e.g. in meters (per sec), such as the speed of light, should use floating point, and what MUST (can?) be counted, e.g. currency (photons?), should use floats.

So, no place for intergers?

[Palli]

Not in e.g. JavaScript…, yes, integers have a place (I edited that error in my post), and I’m very conflicted if that language has the right idea (Fraudian slip? ), but it does simplify to only have floats (for the user, not the implementer of the language/runtime, or for speed, while JS/V8 is often very fast).