[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
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
Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
On Mon, Jan 5, 2015 at 3:41 AM, Ronald L. Rivest rivest@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 :-\
[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
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
[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
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 ??
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 ??
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 ??
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?
[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
* 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 ??
On Mon, Jan 05 2015, Simon Byrne simonby...@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
Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
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 https://github.com/JuliaLang/julia/blob/7d4c3a5c725cb697590411da3f75a3cfe136b30e/base/constants.jl#L68 (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.
Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
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 ??
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 ??
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
[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
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 ??
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 hwborch...@gmail.com
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 ??
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 ??
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 ste...@karpinski.org 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 hwborch...@gmail.com
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 ??
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 hwbor...@gmail.com
javascript: 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 ??
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 ??
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 simonby...@gmail.com 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 ??
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 ??
Already there: #6770 On Mon, Jan 5, 2015 at 4:27 PM, Tim Holy tim.h...@gmail.com 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
[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
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
Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
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 vi...@mayin.org 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 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`.
Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
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. hex1a3b7), 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 ??
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 jwmerr...@gmail.com 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. hex1a3b7), 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 ??
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 ??
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`.
Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
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 pe...@cicayda.com javascript: 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 ??
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 pe...@cicayda.com 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 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`.
Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
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 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`.
Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
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 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`.
Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
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 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`.
Re: [julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
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 christop...@gmail.com javascript: 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
[julia-users] Re: Why does the following give an error: p = 1; 2p+1 ??
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*
