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
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,
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
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
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
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
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