Re: [julia-users] Re: Curious parsing behavior

2016-09-14 Thread Chris Rackauckas
Some are unavoidable: [1 -2] vs [1 - 2] (though I think there should be a 
row-concatenation operator, like ; does column-concatenation. That would 
stop this problem).



On Wednesday, September 14, 2016 at 10:01:07 AM UTC-7, Erik Schnetter wrote:
>
> There was a talk at JuliaCon suggesting that parsing ambiguities are often 
> best resolved by throwing an error: "Fortress: Features and Lessons 
> Learned".
>
> -erik
>
> On Wed, Sep 14, 2016 at 12:01 PM, David P. Sanders  > wrote:
>
>>
>>
>> El miércoles, 14 de septiembre de 2016, 11:12:52 (UTC-4), David Gleich 
>> escribió:
>>>
>>> Ahah! That explains it.
>>>
>>> Is there a better way to create floating point literals that avoid this?
>>>
>>
>> I think using 1782.0 instead of 1782. (without the 0) will solve this?
>> I seem to remember there was an issue to deprecate the style without the 
>> 0.
>>  
>>
>>>
>>> David
>>>
>>> On Wednesday, September 14, 2016 at 9:26:42 AM UTC-4, Steven G. Johnson 
>>> wrote:



 On Wednesday, September 14, 2016 at 9:18:11 AM UTC-4, David Gleich 
 wrote:
>
> Can anyone give me a quick explanation for why these statements seem 
> to parse differently?
>
> julia> 1782.^12. + 1841.^12.
>

 .^ and .+ are (elementwise/broadcasting) operators in Julia, and there 
 is a parsing ambiguity here because it is not clear whether the . goes 
 with 
 the operator or the number.

 See also the discussion at

  https://github.com/JuliaLang/julia/issues/15731
  https://github.com/JuliaLang/julia/pull/11529

 for possible ways that this might be made less surprising in the future.

>>>
>
>
> -- 
> Erik Schnetter  
> http://www.perimeterinstitute.ca/personal/eschnetter/
>


Re: [julia-users] Re: Curious parsing behavior

2016-09-14 Thread Stefan Karpinski
It's a really appealing idea.

On Wed, Sep 14, 2016 at 1:01 PM, Erik Schnetter  wrote:

> There was a talk at JuliaCon suggesting that parsing ambiguities are often
> best resolved by throwing an error: "Fortress: Features and Lessons
> Learned".
>
> -erik
>
> On Wed, Sep 14, 2016 at 12:01 PM, David P. Sanders 
> wrote:
>
>>
>>
>> El miércoles, 14 de septiembre de 2016, 11:12:52 (UTC-4), David Gleich
>> escribió:
>>>
>>> Ahah! That explains it.
>>>
>>> Is there a better way to create floating point literals that avoid this?
>>>
>>
>> I think using 1782.0 instead of 1782. (without the 0) will solve this?
>> I seem to remember there was an issue to deprecate the style without the
>> 0.
>>
>>
>>>
>>> David
>>>
>>> On Wednesday, September 14, 2016 at 9:26:42 AM UTC-4, Steven G. Johnson
>>> wrote:



 On Wednesday, September 14, 2016 at 9:18:11 AM UTC-4, David Gleich
 wrote:
>
> Can anyone give me a quick explanation for why these statements seem
> to parse differently?
>
> julia> 1782.^12. + 1841.^12.
>

 .^ and .+ are (elementwise/broadcasting) operators in Julia, and there
 is a parsing ambiguity here because it is not clear whether the . goes with
 the operator or the number.

 See also the discussion at

  https://github.com/JuliaLang/julia/issues/15731
  https://github.com/JuliaLang/julia/pull/11529

 for possible ways that this might be made less surprising in the future.

>>>
>
>
> --
> Erik Schnetter  http://www.perimeterinstitute.
> ca/personal/eschnetter/
>


Re: [julia-users] Re: Curious parsing behavior

2016-09-14 Thread Erik Schnetter
There was a talk at JuliaCon suggesting that parsing ambiguities are often
best resolved by throwing an error: "Fortress: Features and Lessons
Learned".

-erik

On Wed, Sep 14, 2016 at 12:01 PM, David P. Sanders 
wrote:

>
>
> El miércoles, 14 de septiembre de 2016, 11:12:52 (UTC-4), David Gleich
> escribió:
>>
>> Ahah! That explains it.
>>
>> Is there a better way to create floating point literals that avoid this?
>>
>
> I think using 1782.0 instead of 1782. (without the 0) will solve this?
> I seem to remember there was an issue to deprecate the style without the 0.
>
>
>>
>> David
>>
>> On Wednesday, September 14, 2016 at 9:26:42 AM UTC-4, Steven G. Johnson
>> wrote:
>>>
>>>
>>>
>>> On Wednesday, September 14, 2016 at 9:18:11 AM UTC-4, David Gleich wrote:

 Can anyone give me a quick explanation for why these statements seem to
 parse differently?

 julia> 1782.^12. + 1841.^12.

>>>
>>> .^ and .+ are (elementwise/broadcasting) operators in Julia, and there
>>> is a parsing ambiguity here because it is not clear whether the . goes with
>>> the operator or the number.
>>>
>>> See also the discussion at
>>>
>>>  https://github.com/JuliaLang/julia/issues/15731
>>>  https://github.com/JuliaLang/julia/pull/11529
>>>
>>> for possible ways that this might be made less surprising in the future.
>>>
>>


-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/


[julia-users] Re: Curious parsing behavior

2016-09-14 Thread David P. Sanders


El miércoles, 14 de septiembre de 2016, 11:12:52 (UTC-4), David Gleich 
escribió:
>
> Ahah! That explains it.
>
> Is there a better way to create floating point literals that avoid this?
>

I think using 1782.0 instead of 1782. (without the 0) will solve this?
I seem to remember there was an issue to deprecate the style without the 0.
 

>
> David
>
> On Wednesday, September 14, 2016 at 9:26:42 AM UTC-4, Steven G. Johnson 
> wrote:
>>
>>
>>
>> On Wednesday, September 14, 2016 at 9:18:11 AM UTC-4, David Gleich wrote:
>>>
>>> Can anyone give me a quick explanation for why these statements seem to 
>>> parse differently?
>>>
>>> julia> 1782.^12. + 1841.^12.
>>>
>>
>> .^ and .+ are (elementwise/broadcasting) operators in Julia, and there is 
>> a parsing ambiguity here because it is not clear whether the . goes with 
>> the operator or the number.
>>
>> See also the discussion at
>>
>>  https://github.com/JuliaLang/julia/issues/15731
>>  https://github.com/JuliaLang/julia/pull/11529
>>
>> for possible ways that this might be made less surprising in the future.
>>
>

[julia-users] Re: Curious parsing behavior

2016-09-14 Thread David Gleich
Ahah! That explains it.

Is there a better way to create floating point literals that avoid this?

David

On Wednesday, September 14, 2016 at 9:26:42 AM UTC-4, Steven G. Johnson 
wrote:
>
>
>
> On Wednesday, September 14, 2016 at 9:18:11 AM UTC-4, David Gleich wrote:
>>
>> Can anyone give me a quick explanation for why these statements seem to 
>> parse differently?
>>
>> julia> 1782.^12. + 1841.^12.
>>
>
> .^ and .+ are (elementwise/broadcasting) operators in Julia, and there is 
> a parsing ambiguity here because it is not clear whether the . goes with 
> the operator or the number.
>
> See also the discussion at
>
>  https://github.com/JuliaLang/julia/issues/15731
>  https://github.com/JuliaLang/julia/pull/11529
>
> for possible ways that this might be made less surprising in the future.
>


[julia-users] Re: Curious parsing behavior

2016-09-14 Thread Steven G. Johnson


On Wednesday, September 14, 2016 at 9:18:11 AM UTC-4, David Gleich wrote:
>
> Can anyone give me a quick explanation for why these statements seem to 
> parse differently?
>
> julia> 1782.^12. + 1841.^12.
>

.^ and .+ are (elementwise/broadcasting) operators in Julia, and there is a 
parsing ambiguity here because it is not clear whether the . goes with the 
operator or the number.

See also the discussion at

 https://github.com/JuliaLang/julia/issues/15731
 https://github.com/JuliaLang/julia/pull/11529

for possible ways that this might be made less surprising in the future.


[julia-users] Re: Curious parsing behavior

2016-09-14 Thread Kristoffer Carlsson
Does this answer the question?

julia> Base.parse("1782.^12. + 1841.^12.")
:(1782 .^ 12.0 + 1841 .^ 12.0)

julia> Base.parse("1782.^12.+1841.^12.")
:(1782 .^ 12 .+ 1841 .^ 12.0)


On Wednesday, September 14, 2016 at 3:18:11 PM UTC+2, David Gleich wrote:
>
> Can anyone give me a quick explanation for why these statements seem to 
> parse differently?
>
> julia> 1782.^12. + 1841.^12.
>
> 2.5412102586145895e39
>
>
>
> julia> 1782.^12.+1841.^12.
>
> 1.5158124229919557e39
>
> Thanks!
>
> David Gleich
>