Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

Renaming the sparse matrix functions should absolutely be done. And this is coming from a long-time former user of Matlab who works with sparse matrices much more often than I work with strings. SparseMatrixCSC is far from the only sparse matrix format in the world when you venture beyond what

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

On Tue, Apr 28 2015, François Fayard wrote: > [1] One can't compare Julia and C. C is one of the smallest language than > can exist. Therefore, small names are not too much of a problem. Julia aims > to be a langage with a huge standard library (kind of "batteries included") > which makes it a

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

Hi Jiahao, Distributions is an awesome example of a package that explains what I was trying to say about using multi-dispatch instead of compound function names -- a work of art. I hope to use it in the future. Have you had an uproar from the community that the names don't follow the MATLAB "

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

You should look at Distributions.jl, which already overloads rand to provide the functionality of the first two methods of "random" that you want. On Apr 27, 2015 8:10 PM, "François Fayard" wrote: > Hi Stefan, > > I am just expressing my point of view here as a Mathematica user. > > [1] One can't

[julia-users] Re: Help to optimize a loop through a list

Hi Ronan, Please ignore my last post. I misunderstood (got a little mixed up when you were talking about bits) what the issue was, but after reading a little more carefully I see where your challenge is. Some of the points in the algorithm I showed you before will still be valid but in general

[julia-users] Re: Help to optimize a loop through a list

Hi Ronan, Please ignore my last post. I miss understood (got a little mixed up when you were talking about bits) what the issue was, but after reading a little more carefully I see where your challenge is. Some of the points in the algorithm I showed you before will still be valid but in genera

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

+1 for using multi-dispatch to separate concepts and to make things more readable: cholfact -> factorize(Cholesky, ) sprandn -> Sparse(Normal, m, n) The main benefit isn't readability but for speed and generality. If you want to use a different distribution (in sprandn) or a different fac

[julia-users] WAV.jl changes in upcoming 0.5.0 release

Hi, I would like everyone to know that there will be a couple of minor changes in the upcoming release. First, float arrays will no longer be clamped by default. This was a bad default. See Issue #23 (https://github.com/dancasimiro/WAV.jl/issues/23) for details. Second, wavread will now retu

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

Hi Stefan, I am just expressing my point of view here as a Mathematica user. [1] One can't compare Julia and C. C is one of the smallest language than can exist. Therefore, small names are not too much of a problem. Julia aims to be a langage with a huge standard library (kind of "batteries inc

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

I'm not sure what the problem with sprandn is. If you're working with sparse matrices, you'll know what this is. If you're not, then you're unlikely to accidentally use it. Sure, it's kind of an ugly name, but it's the traditional, well-known name for this function. I don't see anyone complaining a

Re: [julia-users] Why `using` new module shadows old methods?

No problem. It's a long and somewhat hard-to-follow discussion. On Mon, Apr 27, 2015 at 6:40 PM, Andrei Zh wrote: > Ah, I saw this topic in the digest, but didn't understand it is about name > shadowing. Thanks and sorry for inconvenience. > > On Tuesday, April 28, 2015 at 1:06:45 AM UTC+3, Stef

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

On Monday, April 27, 2015 at 5:21:27 PM UTC-5, Scott Jones wrote: > > Why can't we have our cake and eat it too? > > I'd suggest that all of these methods be given maximally understandable > names... > such as sparse_random_normal for sprandn. > Can't you then simply define sprandn as an alias for

Re: [julia-users] Re: Defining a function in different modules

On Sunday, April 26, 2015 at 8:24:15 PM UTC+10, Scott Jones wrote: > > Yes, precisely... and I *do* want Julia to protect the user *in that case*. > If a module has functions that are potentially ambiguous, then 1) if the > module writer intends to extend something, they should do it *explicitly

Re: [julia-users] Why `using` new module shadows old methods?

Ah, I saw this topic in the digest, but didn't understand it is about name shadowing. Thanks and sorry for inconvenience. On Tuesday, April 28, 2015 at 1:06:45 AM UTC+3, Stefan Karpinski wrote: > > https://groups.google.com/forum/#!topic/julia-users/sk8Gxq7ws3w > > On Mon, Apr 27, 2015 at 5:42 P

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

Why can't we have our cake and eat it too? I'd suggest that all of these methods be given maximally understandable names... such as sparse_random_normal for sprandn. Can't you then simply define sprandn as an alias for sparse_random_normal? Would there be maybe a to have only the long names expor

Re: [julia-users] Why `using` new module shadows old methods?

https://groups.google.com/forum/#!topic/julia-users/sk8Gxq7ws3w On Mon, Apr 27, 2015 at 5:42 PM, Andrei Zh wrote: > Let's say, we have 2 modules: > > module A > export foo > foo(n::Int) = println("A") > end > > > module B > export foo > foo(s::String) = println("B") > end > > and then in REPL: >

[julia-users] Re: Ode solver thought, numerical recipes

On Monday, April 27, 2015 at 2:52:26 PM UTC-5, Alex wrote: > > On Monday, 27 April 2015 21:05:33 UTC+2, François Fayard wrote: > > If one implements y = y + delta_t * dy_dt in the code with a Vector, you > create a lot of heap arrays that has a huge cost (It seems that ODE.jl is > doing that by

[julia-users] Why `using` new module shadows old methods?

Let's say, we have 2 modules: module A export foo foo(n::Int) = println("A") end module B export foo foo(s::String) = println("B") end and then in REPL: julia> using A julia> using B !julia> methods(foo) # 1 method for generic function "foo":

[julia-users] Re: Ode solver thought, numerical recipes

> Unfortunately, I get the feeling that we get the same problems in Julia as in > C++ ;-( > I am actually quite optimistic for the future: problems like inplace-ops are known, actively discussed and already partially adressed. Until there is a "canonical" solution one can use other means to ge

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

For sparse matrix functions, Matlab's nomenclature is the de facto standard, since providing a high level interface to sparse matrices is a Matlab innovation. Renaming these functions can be considered, but will doubtless offend the sensibilities of those accustomed to other languages.

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

Thanks for the nice explanations. I guess that in the open source world, it is very difficult to enforce consistency. On Monday, April 27, 2015 at 9:48:47 PM UTC+2, Patrick O'Leary wrote: > > The chronology goes more like, "we had a method named `sprandn`, then > someone wrote a style guide whic

Re: [julia-users] Sparse cholesky and triangular solve

Right now, we don't support extraction of the sparse Cholesky factor, but I think that it will be supported soon, see https://github.com/JuliaLang/julia/pull/10402 I don't fully understand the structure of your problem, but I think that you can only save flops by using the Cholesky factor when B=

[julia-users] Re: Ode solver thought, numerical recipes

Unfortunately, I get the feeling that we get the same problems in Julia as in C++ ;-( It is obvious that things need to be done inplace: [1] There is no solution so far and I don't think that kind of problems can be solved easily, except passing "memory location" to functions and mutating them.

[julia-users] Re: Ode solver thought, numerical recipes

On Monday, 27 April 2015 21:05:33 UTC+2, François Fayard wrote: > If one implements y = y + delta_t * dy_dt in the code with a Vector, you > create a lot of heap arrays that has a huge cost (It seems that ODE.jl is > doing that by the way). So you are forced to loop over the vector elements, >

[julia-users] overloading assignment operator

The answer is basically no. Assignment to an identifier always creates a new binding for that identifier, possibly after converting the right hand side to the type of the variable in question. For an object x, x[inds...] = a can be overloaded (this is the setindex! function). At some point

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

On Monday, April 27, 2015 at 2:36:40 PM UTC-5, François Fayard wrote: > > Ok thanks. I did not think about normal. And my background is mathematics > (and I don't want to know Matlab ;-) ). Imagine how puzzling it could be > for many people. > > It totally violates the "Style Guide" which claims:

Re: [julia-users] Sparse cholesky and triangular solve

There are a small number of different Bs and different Ds, and I have to compute the quadratic form for a number of different combinations. I can probably do things the way you suggested, but I would lose the nice symmetry that I have in my current R code. (I am trying to switch to Julia for sp

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

Ok thanks. I did not think about normal. And my background is mathematics (and I don't want to know Matlab ;-) ). Imagine how puzzling it could be for many people. It totally violates the "Style Guide" which claims: "conciseness is valued, but avoid abbreviation (indexin() rather than indxin())

[julia-users] overloading assignment operator

Hi, is it possible to overload the assignment operator in Julia like in C++. I cannot really find information whether this is possible or not and if not why not and if there is an alternative. Thanks, Thorsten

Re: [julia-users] Sparse cholesky and triangular solve

If B and D are different then why is it not okay to calculate x = C\D and then B'x afterwards? 2015-04-27 15:24 GMT-04:00 matt : > I would like to compute multiple quadratic forms B'*C^(-1)*D, where B, C, > and D are sparse, and C is always the same symmetric positive matrix. For > fast computati

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

On Monday, April 27, 2015 at 2:18:50 PM UTC-5, François Fayard wrote: > > Back to the original discussion, I just came across sprandn in another > thread. How the hell do you want someone to have a feeling of this > function? I still have no idea what the n is for. > Providing information only--

[julia-users] Re: Solving a linear system with sparse, approximately low rank, and symmetric A

Dear Dominique, I am not sure that "incomplete Cholesky decomposition" is standard terminology. It is used in John Shawe-Taylor's book on kernel methods for pattern analysis. What it means is the following, instead of using the Cholesky decomposition A = R'R where R is upper triangular matrix,

[julia-users] Sparse cholesky and triangular solve

I would like to compute multiple quadratic forms B'*C^(-1)*D, where B, C, and D are sparse, and C is always the same symmetric positive matrix. For fast computation, I would like to do this by computing and re-using the Cholesky factor: C=LL'. However, chol(C) does not work (because C is sparse

Re: [julia-users] Solving a linear system with sparse, approximately low rank, and symmetric A

How large is your system? The calculation U * diagm(D) * U' * b could easily use all of your RAM if the problem is large. Even if it is not really large you should evaluate it from the right and use Diagonal, i.e. U * (Diagonal(D) * (U' * b)) because the you are not construction a large matrix, but

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

Back to the original discussion, I just came across sprandn in another thread. How the hell do you want someone to have a feeling of this function? I still have no idea what the n is for.

Re: [julia-users] Solving a linear system with sparse, approximately low rank, and symmetric A

Dear Andreas, Thank you for your response and I apologize for not writing earlier as I got swamped with teaching. Your suggestion of using cholfact together with "shift" argument is a reasonable one. I need to test it and see what results I'll get for a specific problem at hand. Also, I should

[julia-users] Re: Ode solver thought, numerical recipes

Forgot to give the location of the code: https://github.com/insideloop/odesolver

[julia-users] Re: Ode solver thought, numerical recipes

On Sunday, April 26, 2015 at 10:06:09 AM UTC+2, Alex wrote > > This is also covered in the performance tips, but two points you should > keep in mind: > - put const in front of all globals > - run the function you want to time once before timing otherwise you will > measure (mainly) compilation

Re: [julia-users] Re: Defining a function in different modules

> > I am saying that if I have foo(A.type, T1, T2), in module A, and > foo(B.type, T2, T1), I should be able to call foo(myA, myT1, myT2), and > foo(myB, myT2, myT1) without any > problems. > @Scott: Ah, I see. I apologize for this oversight. I can understand how working under this assumption

Re: [julia-users] Code starting to be slow after 30 min of execution

gc() doesn't clear memory from compiled functions---the overhead of compilation is so high that any function, once compiled, hangs around forever. The solution is to avoid creating so many compiled functions. Can you use anonymous functions? --Tim On Monday, April 27, 2015 10:22:20 AM 'Antoine

Re: [julia-users] Code starting to be slow after 30 min of execution

Just a stab in the dark. If you're creating lots of non-conflicting function names (i.e. all those functions are polluting your module), then dispatch *may* take longer at each call? (someone with more knowledge of the internals should chime in) This code *seems* overly complex for what I th

Re: [julia-users] Code starting to be slow after 30 min of execution

And then (approximatively): * myfunction = eval(code_f)* Le lundi 27 avril 2015 18:21:09 UTC+1, Antoine Messager a écrit : > > I use meta programming to create my function. This is a simpler example. > The parameters are generated randomly in the actual function. > > * lhs = {"ode1"=> :(fy[1]

Re: [julia-users] Code starting to be slow after 30 min of execution

I use meta programming to create my function. This is a simpler example. The parameters are generated randomly in the actual function. * lhs = {"ode1"=> :(fy[1]), "ode2"=> :(fy[2])};* * rhs = {"ode1"=> :(y[1]*y[1]-2.0), "ode2"=> :(y[2]-y[1]*y[1])};* * function code_f(lhs::Dict, rhs::Dict)* *

Re: [julia-users] One line nested loop and @parallel macro

If this is something you think you'd use, it would be good to bump that issue, so that it gets some attention. On Monday, April 27, 2015, Nils Gudat wrote: > Your suggestion brought me to issue #10109 > , which seems to be > exactly the problem I'

Re: [julia-users] Code starting to be slow after 30 min of execution

Can you give us the definition of make_function as well? This is being run in global scope? On Monday, April 27, 2015 at 12:37:48 PM UTC-4, Antoine Messager wrote: > > When I input the following code, where myfunction is only a system of 2 > equations with 2 unknowns, the code starts to be real

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

Thanks On Monday, April 27, 2015 at 6:55:15 PM UTC+2, Patrick O'Leary wrote: > > See also https://github.com/JuliaLang/julia/issues/11030 >

[julia-users] Re: One line nested loop and @parallel macro

Your suggestion brought me to issue #10109 , which seems to be exactly the problem I've described above. I'll wait and see. Thanks!

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

See also https://github.com/JuliaLang/julia/issues/11030 (They came up with julia-infix-operator-debates for the alternative mailing list, which is a better suggestion.) On Monday, April 27, 2015 at 11:37:34 AM UTC-5, Patrick O'Leary wrote: > > On Monday, April 27, 2015 at 11:19:31 AM UTC-5, Fra

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

On Monday, April 27, 2015 at 6:37:34 PM UTC+2, Patrick O'Leary wrote: > > On Monday, April 27, 2015 at 11:19:31 AM UTC-5, François Fayard wrote: >> >> I just found that the project Coq is using ++ for string concatenation. >> It has the advantage of not overloading + and still be similar to Python

Re: [julia-users] Re: Naming convention

Official Julia issue to deprecate *, ^: https://github.com/JuliaLang/julia/issues/11030 On Mon, Apr 27, 2015 at 10:19 AM, François Fayard wrote: > So let's forget about ~ as it is already used by DataFrames which is a > very important package. > > I just found that the project Coq is using ++ fo

Re: [julia-users] Yet Another String Concatenation Thread (was: Re: Naming convention)

On Monday, April 27, 2015 at 11:19:31 AM UTC-5, François Fayard wrote: > > I just found that the project Coq is using ++ for string concatenation. It > has the advantage of not overloading + and still be similar to Python's +. > What do you think ? > (And Haskell, as discussed in innumerable pri

Re: [julia-users] Code starting to be slow after 30 min of execution

When I input the following code, where myfunction is only a system of 2 equations with 2 unknowns, the code starts to be really slow after 10,000 iterations. NLsolve is a non linear solver ( https://github.com/EconForge/NLsolve.jl). * size=2* * for k in 1:10* * myfun=make_function(siz

Re: [julia-users] Re: Naming convention

So let's forget about ~ as it is already used by DataFrames which is a very important package. I just found that the project Coq is using ++ for string concatenation. It has the advantage of not overloading + and still be similar to Python's +. What do you think ?

Re: [julia-users] Re: Naming convention

Also note that other packages are free to define ~ (as a macro) for their own purposes (although there will be a warning when they try to use DataFrames). julia> macro ~(s1, s2) :(string($s1, $s2)) end julia> "Hello" ~ " World!" "Hello World!" julia> using DataFrames Warning: us

Re: [julia-users] Re: Naming convention

1) How readable is that though, unless you know R already? `f = y ~ x1 + x2` really doesn't mean anything at all to me... 2) People say that we should just use `string(a,b,c)` and `repeat(a,n)` for string concatenation and repetition... that makes no sense for code where you find many strin

[julia-users] One line nested loop and @parallel macro

That syntax used to be just syntactic asiat for nested for loops, but it was changed so that break would break all of the loops at once, and given its own format in the AST. I believe the @parallel macro has just not been updated to match, eg it's a bug. Would you mind opening an issue?

Re: [julia-users] Re: Naming convention

~ is an implementation of R's formula interface, which many find useful, even essential for statistics; calling it "pollution" is a somewhat heterodox use of the term. See https://github.com/JuliaStats/DataFrames.jl/blob/master/test/formula.jl for nice examples. Best, Tamas On Mon, Apr 27 2015,

Re: [julia-users] Re: Naming convention

It comes back to the C++ coding guide from Google. One of the most important rule is : "don't polute the global namespace". On Monday, April 27, 2015 at 5:07:15 PM UTC+2, Scott Jones wrote: > > I had actually suggested that... I still think it is a good idea, but I > think some other packages al

Re: [julia-users] Code starting to be slow after 30 min of execution

It is a bit hard to tell what is going wrong with essentially no information. Does the memory usage of Julia go up more than you would expect from storing the results? Any difference between 0.3 and 0.4? Anyway, you should try and make a small self-contained runable example and post it otherwise

Re: [julia-users] Re: Naming convention

For some interesting reading, here are some previous discussions on the topic of string concatenation: https://groups.google.com/d/msg/julia-dev/43N5oYSHWdc/zPVmEVDZ5MwJ https://groups.google.com/d/topic/julia-dev/4K6S7tWnuEs/discussion https://github.com/JuliaLang/julia/issues/2301 https://groups

Re: [julia-users] Re: constant-type global

"during development" I agree with that. When doing a scientific simulation, we typically run the same script several times, but each times with different parameters. On Mon, Apr 27, 2015 at 5:08 PM, Stefan Karpinski < stefan.karpin...@gmail.com> wrote: > It will probably continue to be a warni

Re: [julia-users] Re: Naming convention

On Monday, April 27, 2015 at 11:01:06 AM UTC-4, Yuuki Soho wrote: > > On Monday, April 27, 2015 at 4:21:11 PM UTC+2, Kevin Squire wrote: >> >> Just a note, Matlab-style [a b] concatenation has been deprecated in >> Julia v0.4 >>

Re: [julia-users] Re: constant-type global

It will probably continue to be a warning when possible since redefining constants is often handy for reloading code during development. > On Apr 27, 2015, at 9:14 AM, Zheng Wendell wrote: > > Ah, OK. Currently, the constant-value global doesn't prevent the user to > change its value, it only

Re: [julia-users] Re: Naming convention

I had actually suggested On Monday, April 27, 2015 at 10:59:48 AM UTC-4, François Fayard wrote: > > I tend to think as brackets as containers for things. That's why I am not > a big fan. > > What do you think of string1 ~ string2 ? > I had actually suggested that... I still think it is a good id

Re: [julia-users] Re: Naming convention

Good point... so down with [] also :-( On Monday, April 27, 2015 at 10:58:24 AM UTC-4, Tony Kelman wrote: > > [] already has a meaning, it's an empty array. Trying to make it an infix > operator sounds like making a complicated parsing situation even worse. > > > On Monday, April 27, 2015 at 7:54

Re: [julia-users] Re: Naming convention

On Monday, April 27, 2015 at 4:21:11 PM UTC+2, Kevin Squire wrote: > > Just a note, Matlab-style [a b] concatenation has been deprecated in > Julia v0.4 > .

Re: [julia-users] Re: Naming convention

I tend to think as brackets as containers for things. That's why I am not a big fan. What do you think of string1 ~ string2 ? On Monday, April 27, 2015 at 4:54:52 PM UTC+2, Scott Jones wrote: > > I just remembered, it is the inequality operator in SQL... probably not a > good idea to use it! >

Re: [julia-users] Re: Naming convention

[] already has a meaning, it's an empty array. Trying to make it an infix operator sounds like making a complicated parsing situation even worse. On Monday, April 27, 2015 at 7:54:52 AM UTC-7, Scott Jones wrote: > > I just remembered, it is the inequality operator in SQL... probably not a > goo

Re: [julia-users] Re: Naming convention

I just remembered, it is the inequality operator in SQL... probably not a good idea to use it! You don't like have `[]` as an infix operator? (not `[a b]`!) Scott On Monday, April 27, 2015 at 10:36:27 AM UTC-4, François Fayard wrote: > > Couldn't we use <> for concatenation like in Mathematica?

Re: [julia-users] Problem (BUS ERROR) using build_executable.jl on OS X using Julia 0.4.0

Thanks, I'll go ahead and file an issue. I pulled the latest version of build_executable.jl and still got the same response. On Monday, April 27, 2015 at 10:41:22 AM UTC-4, Isaiah wrote: > > I don't think that script has been tested very much yet on OS X. Throwing > a bus error is considered a

[julia-users] Code starting to be slow after 30 min of execution

Dear all, I need to create a lot of systems of equation, find some characteristics of each system and store the system if of interest. Each system is created under the same name. It works fine for the first 1000 systems but after the program starts to be too slow. I have tried to use the garbag

Re: [julia-users] Re: Naming convention

<> means not equal to in some languages, but that may not be that important, and if it is familiar to the a lot of the current Julia community, it could be a good choice. On Monday, April 27, 2015 at 10:36:27 AM UTC-4, François Fayard wrote: > > Couldn't we use <> for concatenation like in Mathe

Re: [julia-users] Problem (BUS ERROR) using build_executable.jl on OS X using Julia 0.4.0

I don't think that script has been tested very much yet on OS X. Throwing a bus error is considered a bug -- please file an issue so this doesn't get lost. You might want to update to latest master first to see if any changes have fixed this (I believe there was a PR to update that script recently)

Re: [julia-users] Re: Naming convention

On Monday, April 27, 2015 at 10:21:11 AM UTC-4, Kevin Squire wrote: > > Just a note, Matlab-style [a b] concatenation has been deprecated in > Julia v0.4 . See the > linked issues for details. The main issue is that this functionality makes > it

Re: [julia-users] Re: Naming convention

Couldn't we use <> for concatenation like in Mathematica? On Monday, April 27, 2015 at 4:21:11 PM UTC+2, Kevin Squire wrote: > > Just a note, Matlab-style [a b] concatenation has been deprecated in > Julia v0.4 . See the > linked issues for details.

[julia-users] One line nested loop and @parallel macro

I've just discovered that multiple nested loops can be written in one line, as described here in the manual . One thing that slightly threw me off is that this doesn't seem to work with the @parallel macro:

Re: [julia-users] Re: Naming convention

On Monday, April 27, 2015 at 10:09:23 AM UTC-4, François Fayard wrote: > > That's a point. One should see * as a monoid operator rather than > multiplication in the number meaning. I get it. > > But I still believe that we are going way too far. I thought that all > those algebra stuff "for eve

Re: [julia-users] Re: Naming convention

Looks like a nice move. On Monday, April 27, 2015 at 4:16:19 PM UTC+2, Scott Jones wrote: > > Add [] for general concatenation, ... and remove * for strings by 1.0 >

Re: [julia-users] Re: Naming convention

Just a note, Matlab-style [a b] concatenation has been deprecated in Julia v0.4 . See the linked issues for details. The main issue is that this functionality makes it challenging to create arrays of arrays (or arrays of ranges), which are less useful

Re: [julia-users] Re: Naming convention

Looks like a good solution to me. On Monday, April 27, 2015 at 4:16:19 PM UTC+2, Scott Jones wrote: > > Changing to + would still run into the problems where you are using > vectors of UInt8, UInt16, UInt32 (or Char), for mutable strings. > Not good either. > > Add [] for general concatenation, (

Re: [julia-users] Re: Naming convention

.* is the operator for elementwise multiplication, * on two 1-dimensional vectors does not work. There's also a very strong desire from people who've been using the language for some time to remove the concatenation semantics from [], and separate array literal construction from array concatena

Re: [julia-users] Re: Naming convention

Changing to + would still run into the problems where you are using vectors of UInt8, UInt16, UInt32 (or Char), for mutable strings. Not good either. Add [] for general concatenation, (i.e. like vcat on vectors/arrays), and and add a compiler warning for * suggestion replacing with [], and remov

Re: [julia-users] Re: Naming convention

That's a point. One should see * as a monoid operator rather than multiplication in the number meaning. I get it. But I still believe that we are going way too far. I thought that all those algebra stuff "for everyone" was just a bad habit in the french education system for mathematics in the 7

Re: [julia-users] Re: Naming convention

On Monday, April 27, 2015 at 9:50:10 AM UTC-4, Yuuki Soho wrote: > > There's one argument for * over +. That string concatenation is not > commutative, and that + main property is to be commutative. > > Personally I don't mind * for string concatenation. If anything I would > prefer to have mat

Re: [julia-users] Re: Naming convention

On Monday, April 27, 2015 at 9:50:10 AM UTC-4, Yuuki Soho wrote: > > There's one argument for * over +. That string concatenation is not > commutative, and that + main property is to be commutative. > And most people think of * as being commutative also... I would be strongly against overloading

Re: [julia-users] Re: Naming convention

That's a good point. One should see * as a monoid operator rather than multiplication in the number meaning. I get it. On Monday, April 27, 2015 at 3:50:10 PM UTC+2, Yuuki Soho wrote: > > There's one argument for * over +. That string concatenation is not > commutative, and that + main property

Re: [julia-users] Re: Naming convention

On Monday, April 27, 2015 at 8:27:59 AM UTC-4, Tamas Papp wrote: > > On Mon, Apr 27 2015, Scott Jones > > wrote: > > > How is `cholfact` completely clear to the general programming community? > > > I bet most people, just seeing the name, would think it was some fact > about > > "chol"...

Re: [julia-users] Re: Naming convention

I have no idea how much it would cost too change * to + for string concatenation. That's where you value tools such as clang-modernize on C++ or corresponding tools on Go. Perhaps the best way to get rid of it is to enforce the change. Maybe allowing + and * for a few iterations, and removing *

Re: [julia-users] Re: Naming convention

There's one argument for * over +. That string concatenation is not commutative, and that + main property is to be commutative. Personally I don't mind * for string concatenation. If anything I would prefer to have matlab style concatenation, using []; it would make sense to use concatenation s

Re: [julia-users] Re: Naming convention

On Mon, Apr 27 2015, François Fayard wrote: > While I agree that * for strings is unfortunate (in fact, I don't think >> that strinng concatenation warrants infix syntax), IMO this whole issue >> is a red herring: all languages have quirks like this, and while >> minimizing the number of them

Re: [julia-users] Re: Naming convention

It totally agree on this point. It does not rules out the * notation, but there is not a single argument to say that it is better than +. As + is used by many languages, it should be the right choice. On Monday, April 27, 2015 at 3:28:05 PM UTC+2, Toivo Henningsson wrote: > > Strings are do not

Re: [julia-users] Re: Naming convention

Strings are do not form a ring, but just a monoid . On Monday, 27 April 2015 15:01:06 UTC+2, François Fayard wrote: > > > > While I agree that * for strings is unfortunate (in fact, I don't think >> that strinng concatenation warrants infix syntax), IMO this

Re: [julia-users] Re: constant-type global

Ah, OK. Currently, the constant-value global doesn't prevent the user to change its value, it only gives a warning. This makes me think that it _is_ a constant-type global. Imaging that when the constant-type global finally comes out, the behavior of constant-value global will also change -- it wil

[julia-users] Re: constant-type global

On Monday, April 27, 2015 at 7:32:59 AM UTC-5, Sisyphuss wrote: > > In the documentation: > >Currently, type declarations cannot be used in global scope, e.g. in the > REPL, since Julia does not yet have constant-type globals. > But we already have > ``` > const pi = 3.14 > ``` > Isn't it a cons

Re: [julia-users] Re: Naming convention

While I agree that * for strings is unfortunate (in fact, I don't think > that strinng concatenation warrants infix syntax), IMO this whole issue > is a red herring: all languages have quirks like this, and while > minimizing the number of them is a worthy goal, I wouldn't think that > these

Re: [julia-users] Is there a REPL shortcut for a subscript numeral?

On Sunday, April 26, 2015 at 12:10:05 AM UTC-4, Dominique Orban wrote: > > I really enjoy the unicode feature. It's too bad that > > julia> ‖A‖² = 1.234 > ERROR: syntax: invalid character "‖" > >> >> > ‖ is not allowed in identifier

Re: [julia-users] Re: Defining a function in different modules

I am not sure I understand Scott's last comments, but I first want to correct something from my last entry. Sorry about the last entry: 2) "using" seems to pull names/symbols into the global namespace/scope (Main?) instead of the local one (whichever module the code resides). 3) Module develop

[julia-users] constant-type global

In the documentation: >Currently, type declarations cannot be used in global scope, e.g. in the REPL, since Julia does not yet have constant-type globals. But we already have ``` const pi = 3.14 ``` Isn't it a constant-type global?

Re: [julia-users] Re: Naming convention

On Mon, Apr 27 2015, Scott Jones wrote: > How is `cholfact` completely clear to the general programming community? > I bet most people, just seeing the name, would think it was some fact about > "chol"... If there are indeed such people and they are wondering about the function, they can jus

Re: [julia-users] Re: Naming convention

Matlab might be popular for many reasons, but not for the consistency of the tool. The advantages of Matlab are: -1- When it started, it was the only tool with numerical and graphic libraries -2- It was difficult to shoot yourself in the foot with it (think about out of bound array access) -3- I

  1   2   >