-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
updated ellipsis chars #8600
updated ellipsis chars #8600
Conversation
Thanks for doing this – I'm sure we can hall get this done in short order. |
can either take a single tuple of dimension sizes or a series of | ||
dimension sizes passed as a variable number of arguments. | ||
|
||
===================================== ===================================================================== | ||
Function Description | ||
===================================== ===================================================================== | ||
``Array(type, dims...)`` an uninitialized dense array |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These could arguably be correct as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about that for a while, and I'm still not sure, but my reasoning is this:
- First thing worth learning is probably something like Array(Float64, 1) or Array(Float64, 1, 2)
- Array also accepts a tuple like Array(Float64, (1, 2)) as the text above says
- There's no need to splat a tuple like Array(Float64, (1,2)...) which is the same as syntax 2
- You can splat an array like Array(Float64, [1, 2]...) which doesn't work without the ... but I would consider this to be a less-used case. And if you understand syntax 1 and you (separately) learn about splatting/splicing, then this one is automatic
Of course, I can't get into the mind of the original author. The most difficult cases for me were ones like this, which perhaps should be written with a comma such as Array(type, dim, ⋯) to reduce ambiguity. But the fact that it's ambiguous is all the more reason why it should be clarified one way or another.
Conflicts: doc/stdlib/base.rst
something has been deleted here
Um, this seems to have deleted the entire repository? |
I always wondered what a PR would look like to need a "Lock Pull Request" feature. :) |
As long as you don't have push access (and nobody merges your PR), there is nothing wrong you can do (except creating noise). As this PR stands, merging it will delete all files in the Julia repository, which is obviously not good, and probably why @StefanKarpinski closed the PR. We're usually pretty helpful if you have trouble with git, especially if you have read a few tutorials you have specific questions/problems. This PR is from your
(I have assumed that you have the official repo as the |
As discussed in #8593, here are changes to documentation to use midline ellipsis ⋯ to refer to etc., to distinguish from the splice notation ... (three periods in a row). It was confusing because the same string of characters had two different meanings, which could only be distinguished by guessing the author's intent. I believe that ⋯ was intended in the majority of cases, and I have attempted to preserve explicit correct use of splice (...) where appropriate.
I am new to Julia. I would appreciate if someone could look through all of the many changes to verify their correctness.