Why does the following give an error: p = 1; 2p+1 ??

[Ronald L. Rivest]

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

[Jeff Waller]

Also in 0.4.x this

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

[ele...@gmail.com]

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

Cheers

Lex

[ele...@gmail.com]

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

Cheers

Lex

[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

[Arch Call]

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

[Stefan Karpinski]

On Mon, Jan 5, 2015 at 3:41 AM, Ronald L. Rivest <rives...@gmail.com> 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 :-\

[ele...@gmail.com]

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

[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

[Tamas Papp]

On Mon, Jan 05 2015, Simon Byrne <simon...@gmail.com> 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

[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?  

[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.

[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.

[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

[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.

[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

[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.

[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

[Stefan Karpinski]

On Mon, Jan 5, 2015 at 12:55 PM, Peter Mancini <pe...@cicayda.com> 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`.

[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. 

[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.

[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.

[Peter Mancini]

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

[Viral Shah]

There is also an issue filed:

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

-viral

[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.

[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?

[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.

[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+ 1    is 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.

[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*
> >

[Jeff Bezanson]

Already there: #6770

[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?

[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).

[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?

[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..

[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.

[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.