-
-
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
1.*[0] returns an Array{Int64,1}, not Array{Float64,1} #5246
Comments
Why would this be a bug? All of the values you've listed are Int's, not Float's. |
I totally get this. On Fri, Dec 27, 2013 at 7:16 PM, John Myles White
Michael |
Yes that’s right,
also works. Thanks! On 28 Dec 2013, at 2:19 pm, Michael Fox [email protected] wrote:
|
Did we already change the way |
I don't think we changed it, although I don't recall why, I thought it seemed more logical to make the switch. (Also, I think last time the discussion was about 1.^-1) |
Yeah, I think the general sentiment stands though, which is that switching would be better. |
I think switching is less confusing:
is more common usage than
which I reckon most users would write as 1*a On 28 Dec 2013, at 4:53 pm, Stefan Karpinski [email protected] wrote:
|
Yes, I agree with this. |
I don't think one is obviously better than the other. The last time this
|
Also things look different if you consider
|
I couldn't remember if we'd switched or not. If we've already switched, then clearly we shouldn't change anything again. |
An ambiguity warning might be the right choice as we definitely have users who will be confused by both behaviors. Something like this issued by the parser, but where we keep the current behaviour? > 1.*[0]
Warning: Ambiguous .* operator. Add spacing to disambiguate "1. *" and "1 .*".
1-element Array{Int64,1}:
0 |
Okay. Here's a fun one: julia> type T
(*)
end
julia> t=T(1)
T(1)
julia> t.*
^C
julia> t.(*)
ERROR: type: getfield: expected Symbol, got Function
julia> dump(t)
T
*: Int64 1
julia> getfield(t, *)
ERROR: type: getfield: expected Symbol, got Function
julia> getfield(t, :*)
1
julia> t.:*
ERROR: type: getfield: expected Symbol, got QuoteNode
julia> t.(:*)
1 Point being, there's too-few wingnuts on the keyboard. You could ditch the It reminds me of this C++ library I occasionally have to deal with. Somewhere it defines every physical unit like |
I wouldn't be so against requiring that |
I think 1. is very common across languages (Mathematica, Matlab, C, …) so I would argue against deprecating it to fix one confusing use case. On 29 Dec 2013, at 4:22 am, Stefan Karpinski [email protected] wrote:
|
A compromise would be to require that the character after |
I'm pretty sure that |
@ivarne – I like it. You're quit good at coming up with these subtle solutions. |
ivarne's solution sounds good to me also. However, I don't think the character before the |
I like @ivarne 's idea. It's also a good practice to write 1.0 instead of 1. though we accept 1. as valid number |
I was going to make the same suggestion, but this happened before I wrote up. :-) I have never been a fan of writing 1. instead of 1.0. |
@vtjnash Good catches! I still think a whitelist is better than a blacklist, because it is easy to add entries to a whitelist, but it will break code in if you add entries to a blacklist. My suggestion would be that a Float64 literal must have one of the following after the As @gitfoxi says, there is problems with the Edit: Removed |
The question is if all charactes allowable in a variable should be allowed. I do not think we should allow |
I think it should be supported:
looks a lot cleaner and easier to read to me than
On 30 Dec 2013, at 8:05 am, Ivar Nesje [email protected] wrote:
|
For an array a, I'm using 1.*a to ensure that it is a Float64 or Complex{Float64}. This doesn't work with
a=[0]
I'm assuming this is a bug? Or is 1.*a bad form for converting?
The text was updated successfully, but these errors were encountered: