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:
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
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 t
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
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
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.
>
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:
>
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 nu
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:
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. he
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 progr
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 wr
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
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
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 ca
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
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 d
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
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? I
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
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 i
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
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.
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 Un
> 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_U
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 singl
>
> * 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+
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:
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
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 exp
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
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 us
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
Also in 0.4.x this
*julia> *
*2p+*
*(type-error double number #f)*
*unexpected error: #0 (read-number # #f #f)**ERROR: syntax:
malformed expression*
35 matches
Mail list logo
