Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Hans W Borchers]

Oh, right. I now see the same behavior in Matlab. Never went into this trap
-- probably because I was always using commas in array constructions.
Unfortunately (for me), there is a difference with these two spellings in 
Julia.


On Monday, January 5, 2015 11:47:25 PM UTC+1, Stefan Karpinski wrote:
>
> Splitting expressions inside of array syntax is space sensitive as well:
>
> julia> [1 + 2]
> 1-element Array{Int64,1}:
>  3
>
> julia> [1 +2]
> 1x2 Array{Int64,2}:
>  1  2
>
>
> Of course this bothers me too, but it's another example of 
> space-sensitivity..
>
> On Mon, Jan 5, 2015 at 5:42 PM, Hans W Borchers  > wrote:
>
>> Style guides are not syntax rules. Every body writes n+1 at times.
>> Is there any other place in Julia where putting spaces (or not putting 
>> spaces) 
>> around arithmetical operators makes a difference?
>> Would this be allowed by the general Julia philosophy?
>> Will it not lead to errors very difficult to track down?
>>
>>
>

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Jeff Bezanson]

Yes, we should try to restrict parsing of hex float literals more if
we're going to keep them. The `p` should only be special after
0xd.d...

In fact, I didn't notice before that this is actually a simple bug in
the parser. `2p+1` gives an internal error. That needs to be fixed in
any case.

On Mon, Jan 5, 2015 at 5:46 PM, Stefan Karpinski  wrote:
> Splitting expressions inside of array syntax is space sensitive as well:
>
> julia> [1 + 2]
> 1-element Array{Int64,1}:
>  3
>
> julia> [1 +2]
> 1x2 Array{Int64,2}:
>  1  2
>
>
> Of course this bothers me too, but it's another example of
> space-sensitivity..
>
> On Mon, Jan 5, 2015 at 5:42 PM, Hans W Borchers 
> wrote:
>>
>> Style guides are not syntax rules. Every body writes n+1 at times.
>> Is there any other place in Julia where putting spaces (or not putting
>> spaces)
>> around arithmetical operators makes a difference?
>> Would this be allowed by the general Julia philosophy?
>> Will it not lead to errors very difficult to track down?
>>
>>
>>
>> On Monday, January 5, 2015 9:33:41 PM UTC+1, Jeff Waller wrote:
>>>
>>> The cause for this thread is mainly a lexical analyzer bug for hex
>>> notation. Except for the error in #9617, I'm fine with the current behavior
>>> and syntax even with the semi e-ambiguity if you want the scientific
>>> notation literal, use no spaces.  This is only ambiguous because Julia
>>> permits a number literal N to proceed an identifier I as a shortcut for N*I,
>>> which is different than many languages and part of Julia's charm.  I'd be
>>> sorry to see it go.
>>>
>>> [0-9]+(.[0-9]+)?e(+|-)?[0-9]+< scientific notation literal
>>>
>>> 2e+1 is 2x10^1
>>> 2e + 1   is 2*e + 1
>>> 2e+ 1is a syntax error because to the lexical analyzer 2e+ is an
>>> error without at least 1 trailing digit (no spaces)
>>>
>>> typing 2e+1 (without the space) and expecting it to mean 2*e + 1 is way
>>> over emphasizing the need to not type a space.  All of the other language
>>> style guides are consistent about this being bad style.
>>>
>>> Finally consider this
>>>
>>> julia> 2e-1e
>>> 0.5436563656918091
>>>
>>>
>>> This is parsed as (2*10^-1)e  = .2e which I assert is the right thing to
>>> do.
>
>

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Stefan Karpinski]

Splitting expressions inside of array syntax is space sensitive as well:

julia> [1 + 2]
1-element Array{Int64,1}:
 3

julia> [1 +2]
1x2 Array{Int64,2}:
 1  2


Of course this bothers me too, but it's another example of
space-sensitivity..

On Mon, Jan 5, 2015 at 5:42 PM, Hans W Borchers 
wrote:

> Style guides are not syntax rules. Every body writes n+1 at times.
> Is there any other place in Julia where putting spaces (or not putting
> spaces)
> around arithmetical operators makes a difference?
> Would this be allowed by the general Julia philosophy?
> Will it not lead to errors very difficult to track down?
>
>
>
> On Monday, January 5, 2015 9:33:41 PM UTC+1, Jeff Waller wrote:
>>
>> The cause for this thread is mainly a lexical analyzer bug for hex
>> notation. Except for the error in #9617, I'm fine with the current behavior
>> and syntax even with the semi e-ambiguity if you want the scientific
>> notation literal, use no spaces.  This is only ambiguous because Julia
>> permits a number literal N to proceed an identifier I as a shortcut for
>> N*I, which is different than many languages and part of Julia's charm.  I'd
>> be sorry to see it go.
>>
>> [0-9]+(.[0-9]+)?e(+|-)?[0-9]+< scientific notation literal
>>
>> 2e+1 is 2x10^1
>> 2e + 1   is 2*e + 1
>> 2e+ 1is a syntax error because to the lexical analyzer 2e+ is an
>> error without at least 1 trailing digit (no spaces)
>>
>> typing 2e+1 (without the space) and expecting it to mean 2*e + 1 is way
>> over emphasizing the need to not type a space.  All of the other language
>> style guides are consistent about this being bad style.
>>
>> Finally consider this
>>
>> *julia> *
>> *2e-1e**0.5436563656918091*
>>
>> This is parsed as (2*10^-1)e  = .2e which I assert is the right thing to
>> do.
>>
>

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Hans W Borchers]

Style guides are not syntax rules. Every body writes n+1 at times.
Is there any other place in Julia where putting spaces (or not putting 
spaces) 
around arithmetical operators makes a difference?
Would this be allowed by the general Julia philosophy?
Will it not lead to errors very difficult to track down?


On Monday, January 5, 2015 9:33:41 PM UTC+1, Jeff Waller wrote:
>
> The cause for this thread is mainly a lexical analyzer bug for hex 
> notation. Except for the error in #9617, I'm fine with the current behavior 
> and syntax even with the semi e-ambiguity if you want the scientific 
> notation literal, use no spaces.  This is only ambiguous because Julia 
> permits a number literal N to proceed an identifier I as a shortcut for 
> N*I, which is different than many languages and part of Julia's charm.  I'd 
> be sorry to see it go.
>
> [0-9]+(.[0-9]+)?e(+|-)?[0-9]+< scientific notation literal
>
> 2e+1 is 2x10^1
> 2e + 1   is 2*e + 1
> 2e+ 1is a syntax error because to the lexical analyzer 2e+ is an 
> error without at least 1 trailing digit (no spaces)
>
> typing 2e+1 (without the space) and expecting it to mean 2*e + 1 is way 
> over emphasizing the need to not type a space.  All of the other language 
> style guides are consistent about this being bad style.
>
> Finally consider this
>
> *julia> *
> *2e-1e**0.5436563656918091*
>
> This is parsed as (2*10^-1)e  = .2e which I assert is the right thing to 
> do.
>

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Stefan Karpinski]

I would also be sad to see hex literals go, and I've found the binary
literals quite nice. Octal literals can go jump in a lake (the only real
use case is for specifying permissions).

On Mon, Jan 5, 2015 at 5:34 PM, Simon Byrne  wrote:

> On Monday, 5 January 2015 20:13:51 UTC, Jeff Bezanson wrote:
>>
>> Hex float literals are a different story. It's an understatement to
>> say they are VERY rarely used, and that most programmers don't need
>> them and have never heard of them. They also don't currently work
>> under MSVC (issue #6349). We have not had them very long. I say we
>> remove them. They can be replaced with a custom string literal.
>>
>
> While I can see that they do make things complicated, I for one would be
> sad to see them go: they still are the easiest way to ensure you have the
> exact constant you want, and don't get bitten by some obscure rounding
> error. I don't really lisp enough to understand the parser, but would it be
> possible to make the parsing of "p" conditional on the prefix?
>

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Simon Byrne]

On Monday, 5 January 2015 20:13:51 UTC, Jeff Bezanson wrote:
>
> Hex float literals are a different story. It's an understatement to 
> say they are VERY rarely used, and that most programmers don't need 
> them and have never heard of them. They also don't currently work 
> under MSVC (issue #6349). We have not had them very long. I say we 
> remove them. They can be replaced with a custom string literal. 
>

While I can see that they do make things complicated, I for one would be 
sad to see them go: they still are the easiest way to ensure you have the 
exact constant you want, and don't get bitten by some obscure rounding 
error. I don't really lisp enough to understand the parser, but would it be 
possible to make the parsing of "p" conditional on the prefix?

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Jeff Bezanson]

Already there: #6770

On Mon, Jan 5, 2015 at 4:27 PM, Tim Holy  wrote:
> On Monday, January 05, 2015 08:15:03 AM Hans W Borchers wrote:
>> By the way, has the bug x = 10; x.1 returning 1.0 been handled in 0.4? It's
>> still there in 0.3.
>
> Nope. If you haven't filed an issue already, please do.
>
> --Tim
>
>>
>> On Monday, January 5, 2015 2:32:00 PM UTC+1, Simon Byrne wrote:
>> > *  julia> 3e+1*
>> >
>> >> *  30.0*
>> >>
>> >>   *julia> 3e + 1*
>> >>
>> >> *  9.154845485377136*
>> >
>> > Perhaps this is a good reason to change behaviour such that e is no longer
>> > a constant: it has always seemed bit odd to use a valuable latin singleton
>> > in this way. We could use a unicode script e (U+212F) instead, as
>> > suggested
>> > by wikipedia:
>> >
>> > http://en.wikipedia.org/wiki/Numerals_in_Unicode#Characters_for_mathematic
>> > al_constants
>> >
>> > s
>

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Tim Holy]

On Monday, January 05, 2015 08:15:03 AM Hans W Borchers wrote:
> By the way, has the bug x = 10; x.1 returning 1.0 been handled in 0.4? It's
> still there in 0.3.

Nope. If you haven't filed an issue already, please do.

--Tim

> 
> On Monday, January 5, 2015 2:32:00 PM UTC+1, Simon Byrne wrote:
> > *  julia> 3e+1*
> > 
> >> *  30.0*
> >> 
> >>   *julia> 3e + 1*
> >> 
> >> *  9.154845485377136*
> > 
> > Perhaps this is a good reason to change behaviour such that e is no longer
> > a constant: it has always seemed bit odd to use a valuable latin singleton
> > in this way. We could use a unicode script e (U+212F) instead, as
> > suggested
> > by wikipedia:
> > 
> > http://en.wikipedia.org/wiki/Numerals_in_Unicode#Characters_for_mathematic
> > al_constants
> > 
> > s

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Jeff Waller]

The cause for this thread is mainly a lexical analyzer bug for hex 
notation. Except for the error in #9617, I'm fine with the current behavior 
and syntax even with the semi e-ambiguity if you want the scientific 
notation literal, use no spaces.  This is only ambiguous because Julia 
permits a number literal N to proceed an identifier I as a shortcut for 
N*I, which is different than many languages and part of Julia's charm.  I'd 
be sorry to see it go.

[0-9]+(.[0-9]+)?e(+|-)?[0-9]+< scientific notation literal

2e+1 is 2x10^1
2e + 1   is 2*e + 1
2e+ 1is a syntax error because to the lexical analyzer 2e+ is an error 
without at least 1 trailing digit (no spaces)

typing 2e+1 (without the space) and expecting it to mean 2*e + 1 is way 
over emphasizing the need to not type a space.  All of the other language 
style guides are consistent about this being bad style.

Finally consider this

*julia> *
*2e-1e**0.5436563656918091*

This is parsed as (2*10^-1)e  = .2e which I assert is the right thing to do.

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Jeff Bezanson]

Yes, sometimes saving one character is a big deal. It also allows
editors to color them as numbers. But this is a minor point. For
something as marginal as hex float literals, custom string literals
are fine.

On Mon, Jan 5, 2015 at 3:21 PM, Jason Merrill  wrote:
> On Monday, January 5, 2015 12:13:51 PM UTC-8, Jeff Bezanson wrote:
>>
>> > We might be able to find a more scalable syntax for different types of
>> numbers. For example the syntax x@000 is available; `@ then digit` is
>> always a syntax error currently.
>
>
> Compared to a custom string literal (e.g. hex"1a3b7"), is the advantage that
> you don't have to use a closing quote?

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Jason Merrill]

On Monday, January 5, 2015 12:13:51 PM UTC-8, Jeff Bezanson wrote:

> > We might be able to find a more scalable syntax for different types of 
> numbers. For example the syntax x@000 is available; `@ then digit` is 
> always a syntax error currently.
>

Compared to a custom string literal (e.g. hex"1a3b7"), is the advantage 
that you don't have to use a closing quote?

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Jeff Bezanson]

My take on this is that 3e+1 has become a standard notation for
numbers in programming languages. I'm comfortable having that as an
exception to the concise multiplication syntax.

Hex float literals are a different story. It's an understatement to
say they are VERY rarely used, and that most programmers don't need
them and have never heard of them. They also don't currently work
under MSVC (issue #6349). We have not had them very long. I say we
remove them. They can be replaced with a custom string literal.

We might be able to find a more scalable syntax for different types of
numbers. For example the syntax x@000 is available; `@ then digit` is
always a syntax error currently.

On Mon, Jan 5, 2015 at 2:40 PM, Viral Shah  wrote:
> There is also an issue filed:
>
> https://github.com/JuliaLang/julia/issues/9617
>
> -viral
>
>
> On Tuesday, January 6, 2015 12:29:33 AM UTC+5:30, Peter Mancini wrote:
>>
>> No. I'm tongue in cheek pointing out the absurdity of the situation.
>>
>> On Monday, January 5, 2015 12:57:45 PM UTC-6, Hans W Borchers wrote:
>>>
>>> Does this mean you suggest to disallow variables names 'e', 'f', 'p' (and
>>> possibly
>>> others) in a programming environment for scientific computing? Hard to
>>> believe.
>>>
>>>
>>> On Monday, January 5, 2015 7:41:49 PM UTC+1, Peter Mancini wrote:

 That is a case of e being overloaded. It helps with the OP's issue
 though. For the scientific notation issue I would suggest choosing which is
 more useful, natural e or using e for a base ten exponent.

 On Monday, January 5, 2015 12:22:11 PM UTC-6, Stefan Karpinski wrote:
>
> On Mon, Jan 5, 2015 at 12:55 PM, Peter Mancini 
> wrote:
>>
>> Usually a language handles this problem by making the constants such
>> as p and e as reserved. Thus you can't create a new variable with those
>> names and since they are constant you can't assign to them without 
>> raising
>> an error.
>
>
> That doesn't help here since `2e+1` would still mean something
> different than `2e + 1`.

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Viral Shah]

There is also an issue filed:

https://github.com/JuliaLang/julia/issues/9617

-viral

On Tuesday, January 6, 2015 12:29:33 AM UTC+5:30, Peter Mancini wrote:
>
> No. I'm tongue in cheek pointing out the absurdity of the situation.
>
> On Monday, January 5, 2015 12:57:45 PM UTC-6, Hans W Borchers wrote:
>>
>> Does this mean you suggest to disallow variables names 'e', 'f', 'p' (and 
>> possibly 
>> others) in a programming environment for scientific computing? Hard to 
>> believe.
>>
>>
>> On Monday, January 5, 2015 7:41:49 PM UTC+1, Peter Mancini wrote:
>>>
>>> That is a case of e being overloaded. It helps with the OP's issue 
>>> though. For the scientific notation issue I would suggest choosing which is 
>>> more useful, natural e or using e for a base ten exponent. 
>>>
>>> On Monday, January 5, 2015 12:22:11 PM UTC-6, Stefan Karpinski wrote:

 On Mon, Jan 5, 2015 at 12:55 PM, Peter Mancini  
 wrote:

> Usually a language handles this problem by making the constants such 
> as p and e as reserved. Thus you can't create a new variable with those 
> names and since they are constant you can't assign to them without 
> raising 
> an error.
>

 That doesn't help here since `2e+1` would still mean something 
 different than `2e + 1`.

>>>

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Peter Mancini]

No. I'm tongue in cheek pointing out the absurdity of the situation.

On Monday, January 5, 2015 12:57:45 PM UTC-6, Hans W Borchers wrote:
>
> Does this mean you suggest to disallow variables names 'e', 'f', 'p' (and 
> possibly 
> others) in a programming environment for scientific computing? Hard to 
> believe.
>
>
> On Monday, January 5, 2015 7:41:49 PM UTC+1, Peter Mancini wrote:
>>
>> That is a case of e being overloaded. It helps with the OP's issue 
>> though. For the scientific notation issue I would suggest choosing which is 
>> more useful, natural e or using e for a base ten exponent. 
>>
>> On Monday, January 5, 2015 12:22:11 PM UTC-6, Stefan Karpinski wrote:
>>>
>>> On Mon, Jan 5, 2015 at 12:55 PM, Peter Mancini  
>>> wrote:
>>>
 Usually a language handles this problem by making the constants such as 
 p and e as reserved. Thus you can't create a new variable with those names 
 and since they are constant you can't assign to them without raising an 
 error.

>>>
>>> That doesn't help here since `2e+1` would still mean something different 
>>> than `2e + 1`.
>>>
>>

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Hans W Borchers]

Does this mean you suggest to disallow variables names 'e', 'f', 'p' (and 
possibly 
others) in a programming environment for scientific computing? Hard to 
believe.


On Monday, January 5, 2015 7:41:49 PM UTC+1, Peter Mancini wrote:
>
> That is a case of e being overloaded. It helps with the OP's issue though. 
> For the scientific notation issue I would suggest choosing which is more 
> useful, natural e or using e for a base ten exponent. 
>
> On Monday, January 5, 2015 12:22:11 PM UTC-6, Stefan Karpinski wrote:
>>
>> On Mon, Jan 5, 2015 at 12:55 PM, Peter Mancini  wrote:
>>
>>> Usually a language handles this problem by making the constants such as 
>>> p and e as reserved. Thus you can't create a new variable with those names 
>>> and since they are constant you can't assign to them without raising an 
>>> error.
>>>
>>
>> That doesn't help here since `2e+1` would still mean something different 
>> than `2e + 1`.
>>
>

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Stefan Karpinski]

To eliminate the ambiguity, one would have to disallow all variable names
that start with the letter "e". At which point, one might as well go all
the way and just disallow using "e" altogether and rename the language to
Gadsby.

On Mon, Jan 5, 2015 at 1:41 PM, Peter Mancini  wrote:

> That is a case of e being overloaded. It helps with the OP's issue though.
> For the scientific notation issue I would suggest choosing which is more
> useful, natural e or using e for a base ten exponent.
>
> On Monday, January 5, 2015 12:22:11 PM UTC-6, Stefan Karpinski wrote:
>>
>> On Mon, Jan 5, 2015 at 12:55 PM, Peter Mancini  wrote:
>>
>>> Usually a language handles this problem by making the constants such as
>>> p and e as reserved. Thus you can't create a new variable with those names
>>> and since they are constant you can't assign to them without raising an
>>> error.
>>>
>>
>> That doesn't help here since `2e+1` would still mean something different
>> than `2e + 1`.
>>
>

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Peter Mancini]

That is a case of e being overloaded. It helps with the OP's issue though. 
For the scientific notation issue I would suggest choosing which is more 
useful, natural e or using e for a base ten exponent. 

On Monday, January 5, 2015 12:22:11 PM UTC-6, Stefan Karpinski wrote:
>
> On Mon, Jan 5, 2015 at 12:55 PM, Peter Mancini  > wrote:
>
>> Usually a language handles this problem by making the constants such as p 
>> and e as reserved. Thus you can't create a new variable with those names 
>> and since they are constant you can't assign to them without raising an 
>> error.
>>
>
> That doesn't help here since `2e+1` would still mean something different 
> than `2e + 1`.
>

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Stefan Karpinski]

On Mon, Jan 5, 2015 at 12:55 PM, Peter Mancini  wrote:

> Usually a language handles this problem by making the constants such as p
> and e as reserved. Thus you can't create a new variable with those names
> and since they are constant you can't assign to them without raising an
> error.
>

That doesn't help here since `2e+1` would still mean something different
than `2e + 1`.

[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Peter Mancini]

Usually a language handles this problem by making the constants such as p 
and e as reserved. Thus you can't create a new variable with those names 
and since they are constant you can't assign to them without raising an 
error.

--Pete

[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Hans W Borchers]

It's the same with 'f', i.e. 1f+1 gives 10 and 1f + 1 an error (if f is not 
defined, else a different result again).
And if someone introduces 'g' for "engineering notation", there will be an 
exception for this letter, too.

By the way, has the bug x = 10; x.1 returning 1.0 been handled in 0.4? It's 
still there in 0.3.


On Monday, January 5, 2015 2:32:00 PM UTC+1, Simon Byrne wrote:
>
> *  julia> 3e+1*
>> *  30.0*
>>
>>   *julia> 3e + 1*
>>
>> *  9.154845485377136*
>>
>
> Perhaps this is a good reason to change behaviour such that e is no longer 
> a constant: it has always seemed bit odd to use a valuable latin singleton 
> in this way. We could use a unicode script e (U+212F) instead, as suggested 
> by wikipedia:
>
> http://en.wikipedia.org/wiki/Numerals_in_Unicode#Characters_for_mathematical_constants
>
> s
>

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Christoph Ortner]

just noticed that Tamas already recommended that above. Just to reiterate I 
think this is the better way to resolve this particular issue.
   Christoph

On Monday, 5 January 2015 15:04:27 UTC, Eric Forgy wrote:
>
> Maybe its not so bad if you just always include * where it should be, i.e. 
> p = 1; 2*p+1 works fine.
>
> On Mon, Jan 5, 2015 at 10:55 PM, Christoph Ortner  > wrote:
>
>> For what it's worth, it always struck me is as odd that dropping the * 
>> for multiplication is allowed. Is it worth dropping this instead of the p, 
>> e notation?
>> Christoph
>>
>>
>

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Eric Forgy]

Maybe its not so bad if you just always include * where it should be, i.e.
p = 1; 2*p+1 works fine.

On Mon, Jan 5, 2015 at 10:55 PM, Christoph Ortner <
christophortn...@gmail.com> wrote:

> For what it's worth, it always struck me is as odd that dropping the * for
> multiplication is allowed. Is it worth dropping this instead of the p, e
> notation?
> Christoph
>
>

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Christoph Ortner]

For what it's worth, it always struck me is as odd that dropping the * for 
multiplication is allowed. Is it worth dropping this instead of the p, e 
notation?
Christoph

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Eric Forgy]

Oh man. I hope this gets sorted out. I don't think this is a very pretty 
situation. p = 1; 2p+1 should do what you expect it to do.

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Simon Byrne]

On Monday, 5 January 2015 13:48:31 UTC, Tamas Papp wrote:
>
> I think that using Unicode (outside ASCII) for numeric literals would be 
> more trouble than it is worth (typing, visually distinguishing them from 
> other similar-looking characters, etc). I feel that even if a language 
> supports Unicode, it should be usable with ASCII only. 
>
> I would prefer if Julia abandonned the abbreviated multiplication syntax 
> altogether: it looked very nifty when I first saw it, but it seems to be 
> a source of problems. I think that expressions with errors are only the 
> tip of the iceberg, I consider bugs that go unnoticed more noxious.


It could still be bound to an ASCII symbol, in the same manner that π (the 
constant) is bound to pi (the symbol). It is also currently bound to eu 

 
(Exponential Unit, I presume?), so we could use this, or something else (
naturalexponent seems like the most explicit one). Of all the constants, I 
feel that e one of the least useful, as it's main applications 
(logarithms/exponents) have their own functions.

[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Jeff Waller]

> Perhaps this is a good reason to change behaviour such that e is no longer 
> a constant: it has always seemed bit odd to use a valuable latin singleton 
> in this way. We could use a unicode script e (U+212F) instead, as suggested 
> by wikipedia:
>
> http://en.wikipedia.org/wiki/Numerals_in_Unicode#Characters_for_mathematical_constants
>
> s
>

Hmm I don't know about that.  True, it is 2015, but how would that look in 
vi and git diff or in an xterm?  How to type it again?  How many 
keystrokes?  

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Tamas Papp]

On Mon, Jan 05 2015, Simon Byrne  wrote:

>>
>> *  julia> 3e+1*
>> *  30.0*
>>
>>   *julia> 3e + 1*
>>
>> *  9.154845485377136*
>>
>
> Perhaps this is a good reason to change behaviour such that e is no longer
> a constant: it has always seemed bit odd to use a valuable latin singleton
> in this way. We could use a unicode script e (U+212F) instead, as suggested
> by wikipedia:
> http://en.wikipedia.org/wiki/Numerals_in_Unicode#Characters_for_mathematical_constants

I think that using Unicode (outside ASCII) for numeric literals would be
more trouble than it is worth (typing, visually distinguishing them from
other similar-looking characters, etc). I feel that even if a language
supports Unicode, it should be usable with ASCII only.

I would prefer if Julia abandonned the abbreviated multiplication syntax
altogether: it looked very nifty when I first saw it, but it seems to be
a source of problems. I think that expressions with errors are only the
tip of the iceberg, I consider bugs that go unnoticed more noxious.

Best,

Tamas

[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Simon Byrne]

>
> *  julia> 3e+1*
> *  30.0*
>
>   *julia> 3e + 1*
>
> *  9.154845485377136*
>

Perhaps this is a good reason to change behaviour such that e is no longer 
a constant: it has always seemed bit odd to use a valuable latin singleton 
in this way. We could use a unicode script e (U+212F) instead, as suggested 
by wikipedia:
http://en.wikipedia.org/wiki/Numerals_in_Unicode#Characters_for_mathematical_constants

s

[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[elextr]

On Monday, January 5, 2015 7:03:21 PM UTC+10, Arch Call wrote:
>
> On Julia version 3.4, the variable "P" also yields the same kind of error.
>

Yes Hex float accepts upper or lower case P its the same issue.

Cheers
Lex
 

>
> On Monday, January 5, 2015 2:44:38 AM UTC-5, Ronald L. Rivest wrote:
>>
>> I'm using Julia 0.3.4 command line.
>> Entering
>> p = 1;  2p+1
>> gives an error:
>>
>> *julia> p = 1; 2p+1*
>>
>> *ERROR: syntax: malformed expression*
>>
>> whereas using a different variable name doesn't give an error
>>
>> *julia> x = 1; 2x+1*
>>
>> *3*
>>
>> There must be some aspect of Julia syntax I have missed??
>>
>> Thanks for any light you can shed on this...
>>
>> Cheers,
>>
>> Ron Rivest
>>
>

Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Stefan Karpinski]

On Mon, Jan 5, 2015 at 3:41 AM, Ronald L. Rivest 
wrote:

> I fear that "numeric literal coefficients" may introduce more hazards than
> its economy of notation justifies... ??


I'm somewhat inclined to agree. It's a really nice syntax, but there are so
many exceptions now that it's pretty hard to keep them all in mind :-\

[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Arch Call]

On Julia version 3.4, the variable "P" also yields the same kind of error.

On Monday, January 5, 2015 2:44:38 AM UTC-5, Ronald L. Rivest wrote:
>
> I'm using Julia 0.3.4 command line.
> Entering
> p = 1;  2p+1
> gives an error:
>
> *julia> p = 1; 2p+1*
>
> *ERROR: syntax: malformed expression*
>
> whereas using a different variable name doesn't give an error
>
> *julia> x = 1; 2x+1*
>
> *3*
>
> There must be some aspect of Julia syntax I have missed??
>
> Thanks for any light you can shed on this...
>
> Cheers,
>
> Ron Rivest
>

[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Ronald L. Rivest]

I now see the description of hex float notation in section 4.2 (Floating
Point Numbers) of the manual (0.4.0-dev), which includes using "p" as
binary exponent notation.  I think that the error message could be improved,
at a minimum.  But there are problems with the current syntax that will 
cause others to get caught too, I fear, such as:

*  julia> 3e+1*
*  30.0*

  *julia> 3e + 1*

*  9.154845485377136*

That is, the spaces around the "+" are significant here, as to whether "e" 
is treated as the math constant or the floating point exponent notation...

I fear that "numeric literal coefficients" may introduce more hazards than 
its economy of notation justifies... ??

Cheers,

Ron


On Sunday, January 4, 2015 9:44:38 PM UTC-10, Ronald L. Rivest wrote:
>
> I'm using Julia 0.3.4 command line.
> Entering
> p = 1;  2p+1
> gives an error:
>
> *julia> p = 1; 2p+1*
>
> *ERROR: syntax: malformed expression*
>
> whereas using a different variable name doesn't give an error
>
> *julia> x = 1; 2x+1*
>
> *3*
>
> There must be some aspect of Julia syntax I have missed??
>
> Thanks for any light you can shed on this...
>
> Cheers,
>
> Ron Rivest
>

[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[elextr]

Raised https://github.com/JuliaLang/julia/issues/9617

Cheers
Lex

On Monday, January 5, 2015 6:00:46 PM UTC+10, ele...@gmail.com wrote:
>
> Think its taking 2p+1 as a malformed hex float literal
>
> Cheers
> Lex
>
> On Monday, January 5, 2015 5:44:38 PM UTC+10, Ronald L. Rivest wrote:
>>
>> I'm using Julia 0.3.4 command line.
>> Entering
>> p = 1;  2p+1
>> gives an error:
>>
>> *julia> p = 1; 2p+1*
>>
>> *ERROR: syntax: malformed expression*
>>
>> whereas using a different variable name doesn't give an error
>>
>> *julia> x = 1; 2x+1*
>>
>> *3*
>>
>> There must be some aspect of Julia syntax I have missed??
>>
>> Thanks for any light you can shed on this...
>>
>> Cheers,
>>
>> Ron Rivest
>>
>

[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[elextr]

Think its taking 2p+1 as a malformed hex float literal

Cheers
Lex

On Monday, January 5, 2015 5:44:38 PM UTC+10, Ronald L. Rivest wrote:
>
> I'm using Julia 0.3.4 command line.
> Entering
> p = 1;  2p+1
> gives an error:
>
> *julia> p = 1; 2p+1*
>
> *ERROR: syntax: malformed expression*
>
> whereas using a different variable name doesn't give an error
>
> *julia> x = 1; 2x+1*
>
> *3*
>
> There must be some aspect of Julia syntax I have missed??
>
> Thanks for any light you can shed on this...
>
> Cheers,
>
> Ron Rivest
>

[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??

[Jeff Waller]

Also in 0.4.x this

*julia> *
*2p+*
*(type-error double number #f)*
*unexpected error: #0 (read-number # #f #f)**ERROR: syntax: 
malformed expression*