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

**URL:** <https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108>\
**Category:** Internals & Design\
**Tags:** integer-overflow\
**Created:** [May 25, 2020, 5:16am UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108 "2020-05-25T05:16:30Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![gevis](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gevis/32/11737_2.png) [@gevis](https://discourse.julialang.org/u/gevis)\
**Post date:** [May 25, 2020, 5:16am UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/1 "2020-05-25T05:16:30Z")

</div>

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:

```julia
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:

```julia
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.

However, it is not so easy for an everage student of Physics, and it is worring how easy such an error can be done in Julia.

Yes, I do know that this is done for speed and that the possibility of integer overflow is mentioned in the documentation.

However, it is quite worrying that Julia produces such a result even without any warning.

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

Unfortunately, I do not know if it can be fixed on the design level. But if not, this example should be put at the very beginning of Julia official documentation so that every single user of Julia would be warned about such a possibility: a simple warning about an **abstact** integer overflow is not enough.

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [May 25, 2020, 5:31am UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/2 "2020-05-25T05:31:20Z")

</div>

This isn’t a serious answer, but one way to deal with this is to use the unit system where `c=1`. Numerical problem solved?

---

<div class="post-metadata">

**Author:** ![baggepinnen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/baggepinnen/32/693_2.png) [@baggepinnen](https://discourse.julialang.org/u/baggepinnen)\
**Post date:** [May 25, 2020, 6:06am UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/3 "2020-05-25T06:06:38Z")

</div>

> [@gevis](#):
>
> However, it is quite worrying that Julia produces such a result even without any warning.

As is the case for most other programming languages using machine integers, this is not unique to Julia. Julia is a programming language and not a scientific calculator. As such, it does require you to learn and understand some things up front.

> [@gevis](#):
>
> this example should be put at the very beginning of Julia official documentation so that every single user of Julia would be warned about such a possibility

This only works until you realize each individual has something different they think is important to warn users about and there is only one beginning of the documentation. Thankfully the documentation is very readable so reading it is a good start before using Julia.

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [May 25, 2020, 6:36am UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/4 "2020-05-25T06:36:47Z")

</div>

idk man, if you just use scientific notation all the way?

```julia
julia> c=3e8
3.0e8

julia> G = 6.67430e-11; # Gravitational constant

julia> h = 6.62607015e-34; # Planck's contant

julia> h_bar = h / (2*pi); # reduced Planck's constant

julia> planks_length = sqrt(G*h_bar/c^3)
1.6145781105309926e-35

```

Also, if you think about it, [Avogadro constant - Wikipedia](https://en.wikipedia.org/wiki/Avogadro_constant) , this is also an Integer, 🤷‍♂️

---

<div class="post-metadata">

**Author:** ![baggepinnen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/baggepinnen/32/693_2.png) [@baggepinnen](https://discourse.julialang.org/u/baggepinnen)\
**Post date:** [May 25, 2020, 6:42am UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/5 "2020-05-25T06:42:29Z")

</div>

The [section on integers and floating-point numbers](https://docs.julialang.org/en/v1/manual/integers-and-floating-point-numbers/#Integers-and-Floating-Point-Numbers-1) starts by listing minimum and maximum values for each built-in numeric type. This is followed by a section dedicated to overflow in the docs  
[https://docs.julialang.org/en/v1/manual/integers-and-floating-point-numbers/#Overflow-behavior-1](https://docs.julialang.org/en/v1/manual/integers-and-floating-point-numbers/#Overflow-behavior-1)

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [May 25, 2020, 6:47am UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/6 "2020-05-25T06:47:47Z")

</div>

Shameless plug. I’d recommend the average Physics students to use [`PhysicalConstants.jl`](https://github.com/JuliaPhysics/PhysicalConstants.jl):

```julia
julia> using PhysicalConstants.CODATA2018

julia> sqrt(NewtonianConstantOfGravitation * (PlanckConstant / 2pi) / SpeedOfLightInVacuum ^ 3)
1.6162550244237053e-35 J^1/2 s kg^-1/2

```

You can also get the exact value in arbitrary precision with

```julia
julia> sqrt(big(NewtonianConstantOfGravitation) * (big(PlanckConstant) / pi / 2) / big(SpeedOfLightInVacuum) ^ 3)
1.616255024423705286500047697249314156917498590079876463568563666973739718761242e-35 J^1/2 s kg^-1/2

```

---

<div class="post-metadata">

**Author:** ![lungben](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lungben/32/12314_2.png) [@lungben](https://discourse.julialang.org/u/lungben)\
**Post date:** [May 25, 2020, 7:53am UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/7 "2020-05-25T07:53:22Z")

</div>

It is an unfortunate trade-off between performance and safety.  
However, I think that the decision to default to fast integers in Julia is correct, most of the time there is no overflow risk.  
However, it would be great if future CPUs would have hardware-support for zero-cost overflow safe integers.

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [May 25, 2020, 9:56am UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/8 "2020-05-25T09:56:38Z")

</div>

They already have hardware support for an integer type supporting values up to `2^53` (about `9e15`), which is enough for most purposes.  
When these integers “overflow” they turn into `Inf`, which will contaminate downstream computations, so that you know something went wrong.  
Further more, while they only support integer values up to `2^53`, they actually support much larger values than this, but at the downside of no longer supporting every integer. For example, at 1e18, the spacing between actually represented integers is `128`.

I think this type is good enough for most computational purposes.

---

<div class="post-metadata">

**Author:** ![Per](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/per/32/10387_2.png) [@Per](https://discourse.julialang.org/u/Per)\
**Post date:** [May 25, 2020, 10:08am UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/9 "2020-05-25T10:08:15Z")

</div>

In theory, it might be possible to detect integer overflow involving _constants_ without any runtime cost. (See my proposal [here](https://discourse.julialang.org/t/branch-on-whether-a-value-is-known-to-the-compiler/34850).), So code like

```julia
const c = 299_792_458; # the speed of light
...
planks_length = sqrt(G*h_bar/c^3)

```

_could_ give a warning.

However, this might actually make things _more_ confusing, because users who see this warning might assume that integer overflow always results in a warning, and then write code that gives overflow at runtime.

---

<div class="post-metadata">

**Author:** ![kevinczimmerman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevinczimmerman/32/13040_2.png) [@kevinczimmerman](https://discourse.julialang.org/u/kevinczimmerman)\
**Post date:** [May 25, 2020, 12:46pm UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/10 "2020-05-25T12:46:24Z")

</div>

> [@Per](#):
>
> However, this might actually make things _more_ confusing, because users who see this warning might assume that integer overflow always results in a warning, and then write code that gives overflow at runtime.

Perhaps just include this information in the warning then? In general, I think more features are better than fewer and then helping the user to use them most appropriately.

---

<div class="post-metadata">

**Author:** ![gevis](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gevis/32/11737_2.png) [@gevis](https://discourse.julialang.org/u/gevis)\
**Post date:** [May 25, 2020, 12:49pm UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/11 "2020-05-25T12:49:02Z")

</div>

> [@baggepinnen](#):
>
> Julia is a programming language and not a scientific calculator. As such, it does require you to learn and understand some things up front.

Python is also a programming language and not a scientific calculator. However, as such, it provides all functionality of a scientific calculator and does not require user to constantly figure out if nowhere during the whole program execution an integer number overflow did not happen and thus the result is correct.

Julia was positioned as a language for scientific calculations which is meant to completely replace Python in this domain. However, with such an approach, it will always remain a **niche** programming language to be used **only** when Python **with all its infrastructure** will prove to be unefficient. However, at this stage it will be too late to re-write the whole project in Julia anyway.

In general, it will go as follows:

1. One morning: “I just need to make some short calculations and I don’t want to bother myself with the integer overflow issues. So, I run Python interpreter. By the way, it starts quicker.” 🙂

2. A few hours later: “Well, it becomes a bit complecated. Let’s save all this into a python script.”

3. A few months later: “Finally, we prototyped all our calculations! But it is a bit slow. Well, let’s vectorize it and use special packages.”

4. Half a year later: “Everything is fine now. However, we still have a few bottlenecks here and here. What? Re-write everything in Julia? Are you crazy? The whole project is already up and running! We just need to re-write these two small places with Cython/C++/Fortran or just use Numba!”

---

<div class="post-metadata">

**Author:** ![baggepinnen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/baggepinnen/32/693_2.png) [@baggepinnen](https://discourse.julialang.org/u/baggepinnen)\
**Post date:** [May 25, 2020, 12:56pm UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/12 "2020-05-25T12:56:27Z")

</div>

> [@gevis](#):
>
> Python is also a programming language and not a scientific calculator. However, as such, it provides all functionality of a scientific calculator

So does julia, you just have to read the manual. No one has ever said that julia solves all your problems without requiring any effort or thought. If integer overflow is a big problem for you, you may consider using [GitHub - JeffreySarnoff/SaferIntegers.jl: These integer types use checked arithmetic, otherwise they are as system types.](https://github.com/JeffreySarnoff/SaferIntegers.jl)

> [@gevis](#):
>
> Julia was positioned as a language for scientific calculations which is meant to completely replace Python in this domain. However, with such an approach, it will always remain a **niche** programming language to be use **only** when Python **with all its infrastructure** will prove to be unefficient.

I bet you can find a lot of people in this forum who disagrees, but if julia does not suit your needs, you’re free to either abandon it or help to improve it. In particular, if you find yourself in the scenario you outlined, then by all means use `Cython/C++/Fortran or just use Numba` (in which case you still need to worry about integer overflow).

---

<div class="post-metadata">

**Author:** ![EHBaozi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ehbaozi/32/14854_2.png) [@EHBaozi](https://discourse.julialang.org/u/EHBaozi)\
**Post date:** [May 25, 2020, 1:16pm UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/13 "2020-05-25T13:16:31Z")

</div>

> Python is also a programming language and not a scientific calculator. However, as such, it provides all functionality of a scientific calculator and does not require user to constantly figure out if nowhere during the whole program execution an integer number overflow did not happen and thus the result is correct.

Not the case if you use `numpy`, which also overflows silently, just like Julia:

```python
>>> import numpy as np
>>> x = np.array([10**10])
>>> x**2
array([7766279631452241920], dtype=int64)

```

`numpy` is the bread and butter of most scientific work done in python, so everything you said about Julia applies to it. And if you insist on using python’s built-in integer, the performance of the program will be so bad it’s actually impossible to do any real-world performance-critical work with it.

---

<div class="post-metadata">

**Author:** ![Per](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/per/32/10387_2.png) [@Per](https://discourse.julialang.org/u/Per)\
**Post date:** [May 25, 2020, 1:27pm UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/14 "2020-05-25T13:27:43Z")

</div>

> [@gevis](#):
>
> I just need to make some short calculations and I don’t want to bother myself with the integer overflow issues

Actually, I was in that situation just last week, writing a function that had large integers as intermediate results.

I still went with Julia, though. I just wrote my function, without worrying about types, and then called it with `BigInt`s.

Later, I wanted to find out at which point overflow became a problem, and it was super easy to write a for-loop that compared the result of `Int` to `BigInt`.

(In the end it turned out that the best approach was to use `Float64` to represent the integers in my specific case. The binary representation of the large integers had a lot of zeros at the end.)

---

<div class="post-metadata">

**Author:** ![Ininterrompue](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ininterrompue/32/5594_2.png) [@Ininterrompue](https://discourse.julialang.org/u/Ininterrompue)\
**Post date:** [May 25, 2020, 1:53pm UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/15 "2020-05-25T13:53:24Z")

</div>

I find that the value of any physical constant is best thought of in scientific notation from the start, e.g. c = 2.998e8 (defaults to Float64) instead of a nine digit integer, since the order of magnitude is explicitly shown. This is especially true for SI units where there span about 50 orders of magnitude between commonly used constants.

Just because some constants can be represented as integers doesn’t mean they should be. In a quick calculation, I find it a bit unwieldy to define c as an integer since it would require specifying all digits when I only care about the first few digits and order of magnitude, and the answer will be limited by the precision of G anyway.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [May 25, 2020, 2:04pm UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/16 "2020-05-25T14:04:55Z")

</div>

> [@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

299792458 is less than 2^{53}, so it is **exactly represented** as a `Float64` value:

```julia
julia> 299_792_458 == 299792458.0
true

```

So, there is absolutely no reason not to use `Float64` to represent this exact integer constant, and doing so greatly reduces the possibility of catastrophic overflow in subsequent calculations.

---

<div class="post-metadata">

**Author:** ![gevis](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gevis/32/11737_2.png) [@gevis](https://discourse.julialang.org/u/gevis)\
**Post date:** [May 25, 2020, 2:17pm UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/17 "2020-05-25T14:17:53Z")

</div>

deleted

---

<div class="post-metadata">

**Author:** ![baggepinnen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/baggepinnen/32/693_2.png) [@baggepinnen](https://discourse.julialang.org/u/baggepinnen)\
**Post date:** [May 25, 2020, 2:19pm UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/18 "2020-05-25T14:19:03Z")

</div>

This is also what Chris was alluding to in the post

> [@The speed of light is an integer. Why should we care?](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/8):
>
> They already have hardware support for an integer type supporting values up to 2^53 (about 9e15), which is enough for most purposes. When these integers “overflow” they turn into Inf, which will contaminate downstream computations, so that you know something went wrong. Further more, while they only support integer values up to 2^53, they actually support much larger values than this, but at the downside of no longer supporting every integer. For example, at 1e18, the spacing between actually …

but it was hidden between the lines… 🙂

---

<div class="post-metadata">

**Author:** ![tamasgal](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamasgal/32/27946_2.png) [@tamasgal](https://discourse.julialang.org/u/tamasgal)\
**Post date:** [May 25, 2020, 2:27pm UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/19 "2020-05-25T14:27:46Z")

</div>

To be honest, 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. We often have bachelor and master (even PhD) students who show up and never ever used anything else than Excel to create plots or even fit(!) some models to them. I think basic CS (which includes understanding at least how primitive data is represented in a computer) is as necessary as understanding integrals and other “basic math”. These (math and computers) are our main tools, that’s a fact.  
Luckily I see some movement and changes in the recent months and few years (at the FAU Erlangen we started enforcing a programming course for the physics bachelors last year).

…also if a student calculates 3.5793584153084007e-32 as Planck’s length and doesn’t notice that something is horribly wrong (downstream), would be kind of worrying 😉 they should learn to question their own results and also their tools and practices; and how to debug them.

I don’t think that it’s Julia _who_ should take over the education in this case.

Edit. btw. it’s rather the `meter` which has been defined to be the path traveled by (monochromatic) light in vaccuum in 1/299 792 458 of a second, not the other way around. 🙈

---

<div class="post-metadata">

**Author:** ![Zhong\_Pan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zhong_pan/32/19872_2.png) [@Zhong\_Pan](https://discourse.julialang.org/u/Zhong_Pan)\
**Post date:** [May 25, 2020, 2:37pm UTC](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/20 "2020-05-25T14:37:20Z")

</div>

I totally agree.

We use speed of light in vacuum a lot. Although our calculations won’t cause an integer overflow, most will habitually write it as “`c0 = 299792458.0`” or simply “`c0 = 299792458.`”

This is true for both Julia and Python users. Those who got trained in Python started with Python 2.x where `3/2` still gives you `1` like in C, unless you `import __future__ `. Julia does automatic conversion from integer to floating number in this use case.

So I don’t see this as a big problem to tell the student that integers and floating numbers are handled differently in computers, and for majority of use cases it’s just easier to always use floating numbers when working with physical constants. In addition, it’s also important to put units either in comments/docstrings, or in the variable name. Or to handle both, use a dedicated package like `PhysicalConstants` with unit handling, which is a more organized and scalable approach with a little bit of overhead.

That said, I think having an optional integer overflow warning that can be turned off may not be a bad idea for Julia.

[Next page](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108.md?page=2)