Why does scientific notation break the range function?

[StefanKarpinski]

Create a new issue at Issues · JuliaLang/julia · GitHub and give an example of the error message and what you think might be a better wording. Discourse is good for discussion but an issue acts like a todo for someone to actually fix something. Thanks!

[nilshg]

As far as I can see it is printed first? In that, it is the first entry in the stacktrace.

Also the stacktrace is specific to VS Code, this is what it looks like in a “regular” notebook, i.e. Jupyter via IJulia:

So here it shows you the information @ In[12]:5, i.e. the input cell and line in the input cell. I’m not sure whether this is a Julia VSCode issue or VSCode more generally - the notebook support in VSCode is still quite new and I’m not sure how “production ready” it is considered to be (judging from open issues on the VSCode repo it seems there’s still a lot of usability issues)

[chadagreene]

I see what you mean by first, because it’s on the first line of the Stacktrace, but I’ll point out that it’s at the end of the fourth line of text that users must read. This means users are tasked with scanning through 30 lines of encoded messages in the Stacktrace to find one tiny number that’s printed at the end of the fourth line of the error message, and is presented without any units. I think the line number could be presented more prominently, and with more clarity, by stating Error on Line 5: at the very start of the error message.

[Henrique_Becker]

When you want to know where the problem happened you always go directly to the stacktrace, this is its purpose, no?

The stracktrace is always printed as filename:line_number, however, Jupyter changes this to [cell_evaluation_number]:line_number what makes it a little harder to parse (if I see mycode.jl:10 I immediately understand that 10 is a line number, couldn’t be anything else, but [7]:10 is far more cryptic).

On the subject of making the error messages more human-readable, besides changing Union{A, B, C, ...} to one among A, or B, or C, or ... could we also prefix each abstract type with a subtype of? Not sure if concrete types need any prefix, I am more interested in having abstract and concrete types to be immediately distinguishable in the message. On special cases, we could also replace Nothing by nothing as it is its only value (same for Missing). Do not really mind if things stay the way they are (found the original message to be legible) but these are my two cents.

[chadagreene]

Done.

[DNF]

@Henrique_Becker

On the subject of making the error messages more human-readable, besides changing Union{A, B, C, ...} to one among A, or B, or C, or ... could we also prefix each abstract type with a subtype of ?

This is perhaps clearer for beginners (so new they haven’t heard of Union yet), but is it better for everyone? I’m afraid it could be less readable for experienced programmers (it could become quite verbose).

Could an alternative be to keep the message, but make it really simple to find out what Union{Nothing, Integer} means?

[suavesito]

@DNF

Could an alternative be to keep the message, but make it really simple to find out what Union{Nothing, Integer} means?

And also improve the doc-string of Union

@nilshg

  A type union is an abstract type which includes all instances of any of its argument types. The empty union Union{} is the bottom type of Julia.

While I think I understand that phrase, I easily see how this is not going to be understandable at all for a newbie (bottom type? Instances? abstract type?).

I would propose to have an easier to read doc-string, something like

Union{Types...}

An Union type is an abstract type that can reference any of the values of one of its argument. It cannot be instantiated.

Examples
≡≡≡≡≡≡≡≡≡≡

julia> IntOrString = Union{Int,AbstractString}
Union{Int64, AbstractString}

julia> 1 :: IntOrString
1

julia> "Hello!" :: IntOrString
"Hello!"

julia> 1.0 :: IntOrString # Float64 is neither Int64, nor AbstractString
ERROR: TypeError: in typeassert, expected Union{Int64, AbstractString}, got a value of type Float64

julia> IntOrString(1) # Error, cannot instantiate
ERROR: MethodError: no method matching Union{Int64, AbstractString}(::Int64)

Note:

The empty Union{} is the bottom type of Julia

[stevengj]

@suavesito

I would propose to have an easier to read doc-string, something like

Note that it is quite easy to submit a pull request for this. The Union documentation is here, and you can just click the “Edit this file” button

to modify the documentation and submit a patch.

[suavesito]

Done

[owiecc]

@chadagreene

Yep, and after that there’s 30 lines of Stacktrace garbage that buries the tiny morsel of the error message that could potentially be helpful.

Let me introduce you to AbbreviatedStackTraces.jl It is not in registry yet, so you will need to follow their installation guide.

[TS-CUBED]

@chadagreene

But back to the original issue: Should the range function be updated to allow whole numbers for the length definition, even if they’re Floats?

You are trying to make Julia behave like Matlab. Unfortunately that would break Julia and make it like Matlab.

The reason why Julia is so much faster than Matlab (even when we take Matlab’s JIT compiler efforts into account) is that Julia is essentially a typed language, less high-level than Matlab (which, tbh, I’d argue is not a programming language at its core).

If your idea would be integrated, then every time you use a float, where an integer is needed, you’d break type stability and make the code slower.

In the end you’d have a language that may be as easy to learn as Matlab, but just as limited when it comes to optimisation. And then you’d need to learn C in addition to Matlab, which would be a lot more painful than to learn to cope with Julia.

So what you describe is the cost you need to pay for getting a more powerful tool.

Or as in the car analogy you use later: automatic transmissions were never used in high-performance cars.

[pfitzseb]

FWIW, that specific issue is fixed already (and should be in a released version of the extension soonish).

[TS-CUBED]

This is indeed a nice extension. And I’d second that that should potentially be considered default behaviour. While I can filter the error message, many of my students struggle with that kind of error. And, most of the stack trace is going down the rabbit hole of the modules that are loaded. Which are very likely not the cause of the error I’m looking at. So the reduced stacktrace makes a lot of sense to me. In particular, with the “err for full stacktrace” at the end.

[DNF]

Cool! Is there some way for this to work together with something like: GitHub - MichaelHatherly/InteractiveErrors.jl: Interactive error messages for the Julia REPL. or Terminal Menus, where you can interactively expand the stacktrace, instead of choosing either full or compressed printing?

[chadagreene]

@TS-CUBED That’s an incredibly helpful explanation, thank you! OK, I’m starting to understand the underlying philosophy a little bit better: Sacrifice a few “creature comforts” to keep performance at center stage. That makes sense.

[chadagreene]

@DNF Yes, I love the idea of a stacktrace that’s collapsed by default, but could easily be expanded on Click for anyone who wants to explore the layers of details in the error.