Re: [julia-users] Re: Curious parsing behavior
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
It's a really appealing idea. On Wed, Sep 14, 2016 at 1:01 PM, Erik Schnetterwrote: > 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
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. Sanderswrote: > > > 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
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
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
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
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 >