[julia-users] Re: Int64 and NaN

[elextr]

On Saturday, December 27, 2014 5:29:27 PM UTC+10, Kenan KARAGÜL wrote:
>
> Hi everybody,
>
> I am working about integer arrays and I need Int64 NaN.
>

A NaN is a floating point value using an otherwise illegal set of bits, 
there is no set of bitse of an int64 that does not represent a valid 
integer.  Depending on your use-case perhaps you could use a 
Nullable 
http://docs.julialang.org/en/latest/manual/types/?highlight=nullable#nullable-types-representing-missing-values.

Cheers
Lex
 

> Have any solutions for this problem?
> Thanks in advance.
> Kenan
>

[julia-users] Int64 and NaN

[Kenan KARAGÜL]

Hi everybody,

I am working about integer arrays and I need Int64 NaN.
Have any solutions for this problem?
Thanks in advance.
Kenan

Re: [julia-users] basic scoping question, and creating locals

[jgabriele382]

On Wednesday, December 24, 2014 5:29:45 PM UTC-5, Milan Bouchet-Valat wrote:

>
> Again, if you can improve the manual, feel free to make suggestions. It 
> looks like the meaning of "global" could use some more explicit 
> definition. 
>
>
Thanks, Milan. Created issue #9469. I'm happy to try my hand at making 
additional clarifications to the docs, though I need to learn how it works 
first. :)

-- John

[julia-users] Silence package output

[Robert Gates]

Dear Julia Users,

I would like to silence the output of packages, but am having trouble doing so. 
This applies to package-generated info() messages occuring due to "using" calls 
as well as to the output of external programs, e.g. a solver. Basically I'd 
like to redirect everything except my own specific print-outs to /dev/null.

Any way to accomplish this?

Best regards, Robert

Re: [julia-users] compilation problem on OS X for v0.4

[Tony Kelman]

It generates Makefile by default, but it can also generate project files 
for MSVC or XCode, or you can generate Ninja files which can be quite a bit 
faster than make for incremental builds. At the moment the only thing we're 
using it for by default is libgit2, which uses cmake as its only build 
system. If you install a binary of libgit2 and set USE_SYSTEM_LIBGIT2=1 in 
your Make.user file, then you shouldn't need cmake at the moment. There was 
some talk of trying to hand-write simple makefiles for libgit2 to avoid the 
cmake dependency, but making that work across every platform we support 
would be a lot of work. Cmake's a little strange and different, but once 
you get used to it it's not that bad. Certainly the least bad option out of 
every alternative that provides equivalent functionality.

It might be a good idea to leverage cmake for further improvements in 
Julia's build system, such as checking that all dependencies are properly 
installed and working on your machine in a "configure"-like step before 
actually starting to compile everything. There's some early work starting 
in this direction.


On Friday, December 26, 2014 2:24:01 PM UTC-8, Kevin Squire wrote:
>
> My understanding is that cmake is more a replacement for autotools than 
> make, since on *nix platforms (at least), it generates Makefiles. 
>
> Cheers!
>   Kevin 
>
> On Friday, December 26, 2014, Stefan Karpinski  wrote:
>
>> It's sort of unfortunate that we need to depend on both make and cmake, 
>> but c'est la vie – we also depend on both C and Fortran compilers. Life's 
>> complicated when you need to build a lot of software.
>>
>> On Fri, Dec 26, 2014 at 2:14 PM, John Myles White  wrote:
>>
>>> No worries. Adding a cmake dependency is a big change for Julia.
>>>
>>>  -- John
>>>
>>> On Dec 26, 2014, at 2:13 PM, Ethan Anderes  wrote:
>>>
>>> Thanks John. I guess that was obvious from the error message. Sorry for 
>>> the noise.
>>>
>>> --Ethan
>>>
>>> On Friday, December 26, 2014 11:09:04 AM UTC-8, John Myles White wrote:

 You need to install cmake and make it available on your path: 
 http://www.cmake.org/download/

  -- John

 On Dec 26, 2014, at 2:07 PM, Ethan Anderes  wrote:

 Hi Everyone:

 I just decided to upgrade to Julia v0.4 and ran into the following 
 error when trying to compile from source (I’m running Yosemite 10.10.1). 
 Anyone else run into this problem and know how to fix it? —Cheers

 == 
 All 3 tests passed 
 == 
 Making check in cxx 
 == 
 All 0 tests passed 
 == 
 Making check in mpn 
 Making check in mpz 
 Making check in mpq 
 Making check in mpf 
 Making check in printf 
 Making check in scanf 
 Making check in rand 
 Making check in cxx 
 Making check in demos 
 Making check in calc 
 Making check in expr 
 Making check in tune 
 Making check in doc 
 /bin/sh: cmake: command not found 
 make[2]: *** [libgit2-0.21.3/build/Makefile] Error 127 
 make[1]: *** [julia-release] Error 2 
 make: *** [release] Error 2

 ​



>>>
>> 

[julia-users] Re: Puzzled by conflicting imports

[Petr Krysl]

Having read the issues (https://github.com/JuliaLang/julia/issues/4345), I 
think I have a better understanding of the complexity involved in importing 
functions of the same name. While I think some legitimate uses are 
eliminated if such imports are prohibited, the potential tripping points 
are probably too many and a clean solution may not have been possible..

Thinking about the two-methods problem for a while in fact led to  the 
recognition of a better solution  (re-factoring,  and elimination  of the 
duplicated method names).

Thanks for your help,

Petr

On Friday, December 26, 2014 5:58:35 PM UTC-8, ele...@gmail.com wrote:
>
> IIUC import collisions are on name only, not by signature.
>
> From https://github.com/JuliaLang/julia/issues/4345 I understand that 
> this is because the two `distribloads` methods are methods of different 
> functions, one function defined in FEMMHeatDiffusionModule and one 
> in FEMMAcousticsModule.  Its the functions that clash. The issues suggests 
> that combining the functions is hard/risky/brittle/error prone and in 
> general a bad idea (tm).
>
> Cheers
> Lex
>
> On Saturday, December 27, 2014 5:27:31 AM UTC+10, Petr Krysl wrote:
>>
>> Here are two methods in two different modules:
>>
>> julia> methods(FEMMHeatDiffusionModule.distribloads)
>> # 1 method for generic function "distribloads":
>>
>> distribloads(self::FEMMHeatDiffusion,assembler,geom::NodalField{Float64},temp::N
>> odalField{Float64},fi::ForceIntensity{Float64},m::Int64) at 
>> C:\Users\pkrysl\Docu
>> ments\GitHub\jfineale\./src/FEMMHeatDiffusionModule.jl:201
>>
>> julia> methods(FEMMAcousticsModule.distribloads)
>> # 1 method for generic function "distribloads":
>>
>> distribloads{T<:Number}(self::FEMMAcoustics,assembler,geom::NodalField{T<:Number
>> },P::NodalField{T<:Number},fi::ForceIntensity{T<:Number},m::Int64) at 
>> C:\Users\p
>> krysl\Documents\GitHub\jfineale\./src/FEMMAcousticsModule.jl:180
>>
>> I cannot do "importall" on both modules at the same time: Julia complains 
>> about conflicting imports.
>> I have a trouble making sense of that: The functions clearly have 
>> different signatures, so shouldn't the compiler be able to make sense of 
>> them?
>>
>> Any ideas?  Thanks!
>>
>> Petr
>>
>>
>>

Re: [julia-users] Re: Revision release notes

[Eric Davies]

Thanks for the link, I didn't know about that Github feature.

While most of the commits are bugfixes, there are some new features, e.g.
https://github.com/JuliaLang/julia/commit/e00a07a02a93fbec40d44ff473328a4897a6d5f5
and
https://github.com/JuliaLang/julia/commit/1c2799699bee432b0f5db5a6f6df603f9c31c8bb
. They don't break backward compatibility but they do add functionality.

On Fri, Dec 26, 2014 at 5:30 AM, Elliot Saba  wrote:

> I should point out that although Tony answered your question for looking
> at 0.3.1 vs. 0.3.0, we are just now releasing 0.3.4, so you can substitute
> the 0.3.1 with 0.3.4 in the URL linked above for the same effect.
> -E
>
> On Fri, Dec 26, 2014 at 3:03 AM, Tony Kelman  wrote:
>
>> We have not been doing a very good job of updating NEWS.md on the
>> release-0.3 branch, so there's nothing specific. Lots of bug fixes have
>> been getting backported, you can compare the commit list via
>> https://github.com/JuliaLang/julia/compare/v0.3.0...v0.3.1 or similar
>> url's.
>>
>> On Thursday, December 25, 2014 10:14:59 PM UTC-8, Eric Davies wrote:
>>>
>>> Are there release notes for 0.3.1+? Looking at NEWS.md, it seems that
>>> only 0.3.0 appears.
>>>
>>
>

Re: [julia-users] Re: Julia v0.3.4

[Elliot Saba]

Try again?
-E

[julia-users] Re: Porting a Matlab function, mvtrnd, multivariate t distribution number generation

[Simon Byrne]

You might also be interested in MvTDist in Distributions.jl:
https://github.com/JuliaStats/Distributions.jl/blob/master/src/multivariate/mvtdist.jl

On Friday, 26 December 2014 19:50:03 UTC-6, jspark wrote:
>
> Hi,
>
> I am porting a matlab random number generation from multivariate T 
> distribution and attached, I am converting the mvtrnd.m function of Matlab.
>
> This is mixed version of Julia and original Matlab scripts and nonetheless 
> of my series of the modifications, it still making a error to me.
>
> Last error message is "* in apply, expected Function, got Int 64 in 
> mvtrnd3 at C:\\~mvtrnd3.jl:32 "*
>
> Thank you.
>
>  
>

[julia-users] Re: Using Julia with other (GC) languages

[elextr]

On Saturday, December 27, 2014 8:54:28 AM UTC+10, Páll Haraldsson wrote:
>
> I know you can call C from Julia and therefore most other (non-GC) 
> languages. And with embedding, vice versa.
>
> Of course you always can call other languages, say with RPC etc. but 
> wander what the limitations are to call directly.
>
> It seems to me you can call C because it is not a garbage-controlled 
> language. And when embedding Julia in C then you get the whole runtime and 
> it is similar to embedding Prolog in C. I've just not looked to much into 
> embedding. Would you say calling in that direction is more difficult 
> because of it or some other reason?
>
> It seems to me you would want Julia to be the "master language" on top 
> because it has GC (and is the more "powerful language").
>
> In theory, calling other GC languages such as Java or C# should be 
> possible but not in practice (without copying/RPC) because you can have 
> only on GC, right? Still calling Python is possible, because it uses 
> reference counting, not true GC? But it also has GC for cycles. So maybe 
> there is no difficulty with GC or is that part just disabled?
>
>
>
See http://aviks.github.io/JavaCall.jl/
 

> And:
> I know about the current situation with calling C++. For old Python code 
> (even on Windows) and numpy (or whatever) that calls C++ (Microsoft's 
> Visual Studio), since Julia can call Python, should there really be any 
> reason for it be difficult to call C++ if it is only indirectly?
>

C++ is not C.  C++ has significantly more complex semantics than C, 
overloaded functions, more calling conventions, templates, name mangling 
etc.  Even C++ compilers sometimes are not compatible with other C++ 
compilers (eg VC++ and G++).  It is much more complex to call C++ that has 
not been specifically declared to be C compatible (extern "C" ) from any 
other language.  The C++ calling capabilities being developed for Julia are 
awesome, bordering on witchcraft :)

Python by comparison is just plain old C.

Cheers
Lex


> Best regards,
> Palli.
>
>

[julia-users] Re: Porting a Matlab function, mvtrnd, multivariate t distribution number generation

[J Luis]

You have a typo at line 31. It's not

nagrin=3;

but

nargin=3

Sábado, 27 de Dezembro de 2014 1:50:03 UTC, jspark escreveu:
>
> Hi,
>
> I am porting a matlab random number generation from multivariate T 
> distribution and attached, I am converting the mvtrnd.m function of Matlab.
>
> This is mixed version of Julia and original Matlab scripts and nonetheless 
> of my series of the modifications, it still making a error to me.
>
> Last error message is "* in apply, expected Function, got Int 64 in 
> mvtrnd3 at C:\\~mvtrnd3.jl:32 "*
>
> Thank you.
>
>  
>

[julia-users] Re: Puzzled by conflicting imports

[elextr]

IIUC import collisions are on name only, not by signature.

>From https://github.com/JuliaLang/julia/issues/4345 I understand that this 
is because the two `distribloads` methods are methods of different 
functions, one function defined in FEMMHeatDiffusionModule and one 
in FEMMAcousticsModule.  Its the functions that clash. The issues suggests 
that combining the functions is hard/risky/brittle/error prone and in 
general a bad idea (tm).

Cheers
Lex

On Saturday, December 27, 2014 5:27:31 AM UTC+10, Petr Krysl wrote:
>
> Here are two methods in two different modules:
>
> julia> methods(FEMMHeatDiffusionModule.distribloads)
> # 1 method for generic function "distribloads":
>
> distribloads(self::FEMMHeatDiffusion,assembler,geom::NodalField{Float64},temp::N
> odalField{Float64},fi::ForceIntensity{Float64},m::Int64) at 
> C:\Users\pkrysl\Docu
> ments\GitHub\jfineale\./src/FEMMHeatDiffusionModule.jl:201
>
> julia> methods(FEMMAcousticsModule.distribloads)
> # 1 method for generic function "distribloads":
>
> distribloads{T<:Number}(self::FEMMAcoustics,assembler,geom::NodalField{T<:Number
> },P::NodalField{T<:Number},fi::ForceIntensity{T<:Number},m::Int64) at 
> C:\Users\p
> krysl\Documents\GitHub\jfineale\./src/FEMMAcousticsModule.jl:180
>
> I cannot do "importall" on both modules at the same time: Julia complains 
> about conflicting imports.
> I have a trouble making sense of that: The functions clearly have 
> different signatures, so shouldn't the compiler be able to make sense of 
> them?
>
> Any ideas?  Thanks!
>
> Petr
>
>
>

[julia-users] Porting a Matlab function, mvtrnd, multivariate t distribution number generation

[jspark]

Hi,

I am porting a matlab random number generation from multivariate T 
distribution and attached, I am converting the mvtrnd.m function of Matlab.

This is mixed version of Julia and original Matlab scripts and nonetheless 
of my series of the modifications, it still making a error to me.

Last error message is "* in apply, expected Function, got Int 64 in mvtrnd3 
at C:\\~mvtrnd3.jl:32 "*

Thank you.

 


mvtrnd3.jl
Description: Binary data

Re: [julia-users] Julia for large scale software development

[cdm]

and in support of Stefan's language/software observations, the hardware 
aspect is nearly as important,
but perhaps more subtle ...

AMD and ARM are committed to the HSA movement (bit.ly/1E2mOWq) recognizing 
that CPUs, GP/GPUs,
FPGAs and perhaps other new SoC developments will increasingly become part 
of a dynamic computational
system that becomes more broadly accessible to people.

the efficiency of any particular solution across the problem lifecycle, 
from problem realisation to problem
solution, will be metric defining the tools in use at any particular time.

best,
cdm


On Friday, December 26, 2014 3:59:52 PM UTC-8, Stefan Karpinski wrote:
>
> I think we need more languages if only because I think we've barely 
> started to explore the programming language design space – it's a very 
> non-convex optimization problem. Sure, some languages are close to local 
> optima, but you never know what's going to happen when you start combining 
> things in new ways and find yourself in a totally new part of the space. 
> Clojure, Go, Rust, Ceylon, Scala, Swift and lots of others are trying 
> really new and innovative things, some of which are working out really 
> nicely. People need to try these things if we're going have better tools.
>

[julia-users] Re: Julia v0.3.4

[Carlos P]

when trying to download "Mac OS X Package (.dmg)"


  NoSuchKey
  The specified key does not exist.
  bin/osx/x64/0.3/julia-0.3.4-osx10.7 .dmg
...

also tried to remove the space between 10.7 and .dmg on the path, but same 
"NoSuchKey"

Re: [julia-users] Re: package proposal

[Evan Pu]

is this thread still alive? a phc package would be good...

On Monday, June 23, 2014 5:26:34 AM UTC-7, Andrei Berceanu wrote:
>
> By the way I recently stumbled upon NLSolve.jl, and asked them if they 
> would be interested in PHCpack
> https://github.com/EconForge/NLsolve.jl/issues/12
>
> Still no reply on their part yet though.
>
> On Monday, June 23, 2014 1:06:03 PM UTC+2, Andrei Berceanu wrote:
>>
>> Free binary versions for Mac and Windows of the gnu-ada compiler are 
>> available at http://libre.adacore.com/ and are very easy to install.
>> As for HOMPACK, the main difference is that PHCpack is specifically 
>> targeted for polynomial systems. HOMPACK provides continuation methods for 
>> general nonlinear systems and has extra drivers for polynomial systems. 
>> Another main difference is that PHCpack offers polyhedral homotopies, which 
>> are absent from HOMPACK. So I guess it depends on what we want really, 
>> personally I am interested in polynomial systems. Please let me know if you 
>> succeed in installing the ada compiler for Mac from the above link.
>>
>>
>> On Friday, June 20, 2014 11:36:01 PM UTC+2, Tony Kelman wrote:
>>>
>>> That sounds like the best plan for the PHCpack code. Have you looked at 
>>> or are you familiar with whether HOMPACK as Hans mentioned would be able to 
>>> provide similar functionality? I say that just because more of us are used 
>>> to building Fortran code than Ada. Ada should be reasonable to work with on 
>>> Linux, and maybe even in MinGW or Cygwin, but it doesn't look like it's set 
>>> up in Homebrew for Mac users. If you know of a standard way to install GNAT 
>>> and can get the library building on at least your platform of choice, go 
>>> for it.
>>>
>>>
>>> On Friday, June 20, 2014 2:14:18 PM UTC-7, Andrei Berceanu wrote:

 I have contacted the author (
 https://github.com/janverschelde/PHCpack/issues/3) and it seems 
 redistribution under a different license is not really an option.
 However, if what Milan says is correct, then we should be able to 
 include it 'as-is'.
 Now for the interface, I was thinking that, since there already exists 
 a comprehensive C API to the Ada code, we could call that from Julia, what 
 do you guys reckon?

 On Friday, June 6, 2014 2:18:33 PM UTC+2, Milan Bouchet-Valat wrote:
>
>  Le vendredi 06 juin 2014 à 03:43 -0700, Hans W Borchers a écrit : 
>
> Please notice that PHCpack is distributed under GPL license, so your 
> first 
>
>  step should be to contact the author and ask for his approval to 
> distribute  
>
>  it under a lesser license such as MIT. 
>
>
> Though since it's a package rather than code to be included in Julia 
> Base, GPL is fine too.
>
>
> Regards 
>

Re: [julia-users] Rounding and the IEEE rule

[Stefan Karpinski]

On Fri, Dec 26, 2014 at 6:00 PM, Hans W Borchers 
wrote:

> What irritates me a bit are these back-and-forth decisions. I accepted
> ".+" for scalar plus vector operations (with a bit of teeth grinding, but
> listening to a good mathematical analogy), used it in some programs, only
> learning a few weeks later that a change agent had struck again.
>

I agree it's annoying, but I think it's important to try things and
recognize when an experiment was a mistake. Fortunately, we haven't done
this very often.


> I know about (some of) the problems with rounding. The perhaps
> mathematically most complete and correct arithmetic computing system,
> PARI/GP, still uses "round-to-+Inf" and 'generations' of mathematicians
> have lived well with that. And the "problems with the digit argument"
> mentioned are perhaps a reason why many systems like Octave, Matlab (up to
> 2014a), Mathematica, PARI/GP do not allow for a second parameter in their
> 'round' functions. Maybe there is really no satisfying solution here for
> this problem.
>

I would also be ok with round-to-Inf behavior since to me that's what the
mathematical round function does. Of course, it's also nice that round(-x)
== -round(x) for all x. Also, we've traditionally tried to keep things
close to C when there aren't other languages (Matlab, Python) that serve as
better models.

Re: [julia-users] Julia for large scale software development

[Stefan Karpinski]

I think we need more languages if only because I think we've barely started
to explore the programming language design space – it's a very non-convex
optimization problem. Sure, some languages are close to local optima, but
you never know what's going to happen when you start combining things in
new ways and find yourself in a totally new part of the space. Clojure, Go,
Rust, Ceylon, Scala, Swift and lots of others are trying really new and
innovative things, some of which are working out really nicely. People need
to try these things if we're going have better tools.

On Fri, Dec 26, 2014 at 6:19 PM, Páll Haraldsson 
wrote:

> Note, I said "I know". You may know more languages. Wander what the top 3
> are (if Julia isn't top 1).
>
> Still, languages have died out (mostly) and I think we need fewer
> languages, not more.
>
> I do not see a good reason for C++ any more (is the exception handling in
> Julia as least as good as C++/Java?). Just my preference. I would also
> think MATLAB is legacy (do not know APL..). With the endless
> bufferoverflows and security issues in general, C should be replaced as
> much as possible. Java isn't better in my view and just do not know C#.
> Maybe not as verbose.
>
> Just do not know the pure functional languages really. Haskell is a
> minority language, maybe I should know more, just hope Julia is at least
> practically better. Do not really know Erlang, good for it's purpose, but
> couldn't Julia do as well (at the language level). What are the
> requirements really in that area? Just not convinced an obscure language
> there is better. Hard-realtime, Julia may not work - for now. Since Java
> can work there, Julia should to, but maybe something different is even
> better there. I assume no changes needed at the language level just
> improved GC, and it should be possible. Any reason why not?
>
> Julia might have some safety issues, but I'm not too worried.
>
> A little intrigued by Racket, but any (primarily) S-expression language, I
> just will not get mainstream.
>
> --
> Palli.
>
>
> On Friday, December 26, 2014 10:50:58 PM UTC, Spencer Russell wrote:
>>
>> On Friday, December 26, 2014 5:32:39 PM UTC-5, Páll Haraldsson wrote:
>>>
>>>
>>> Maybe I should just put my blinders on, just not look at other languages
>>> more. I'm pretty convinced all the others I know are obsolete (for new
>>> code).. I just might be missing something with the newer languages.
>>>
>>
>> Julia is wonderful and in my top 3 favorite languages to code in, but
>> there's a lot to be learned from other languages. Also often different
>> circumstances call for different tools. I'd hesitate to make claims like
>> "all the others I know are obsolete" (I reserve that sort of hyperbole for
>> clickbait Wired headlines).
>>
>

Re: [julia-users] Julia for large scale software development

[Páll Haraldsson]

Note, I said "I know". You may know more languages. Wander what the top 3 
are (if Julia isn't top 1).

Still, languages have died out (mostly) and I think we need fewer 
languages, not more.

I do not see a good reason for C++ any more (is the exception handling in 
Julia as least as good as C++/Java?). Just my preference. I would also 
think MATLAB is legacy (do not know APL..). With the endless 
bufferoverflows and security issues in general, C should be replaced as 
much as possible. Java isn't better in my view and just do not know C#. 
Maybe not as verbose.

Just do not know the pure functional languages really. Haskell is a 
minority language, maybe I should know more, just hope Julia is at least 
practically better. Do not really know Erlang, good for it's purpose, but 
couldn't Julia do as well (at the language level). What are the 
requirements really in that area? Just not convinced an obscure language 
there is better. Hard-realtime, Julia may not work - for now. Since Java 
can work there, Julia should to, but maybe something different is even 
better there. I assume no changes needed at the language level just 
improved GC, and it should be possible. Any reason why not?

Julia might have some safety issues, but I'm not too worried.

A little intrigued by Racket, but any (primarily) S-expression language, I 
just will not get mainstream.

-- 
Palli.

On Friday, December 26, 2014 10:50:58 PM UTC, Spencer Russell wrote:
>
> On Friday, December 26, 2014 5:32:39 PM UTC-5, Páll Haraldsson wrote:
>>
>>
>> Maybe I should just put my blinders on, just not look at other languages 
>> more. I'm pretty convinced all the others I know are obsolete (for new 
>> code).. I just might be missing something with the newer languages.
>>
>
> Julia is wonderful and in my top 3 favorite languages to code in, but 
> there's a lot to be learned from other languages. Also often different 
> circumstances call for different tools. I'd hesitate to make claims like 
> "all the others I know are obsolete" (I reserve that sort of hyperbole for 
> clickbait Wired headlines).
>

Re: [julia-users] Rounding and the IEEE rule

[Hans W Borchers]

Don't worry. I am a long-term ... user and as such got used to really harsh 
criticism. As others have noted, this is - besides Ruby - the most friendly 
mailing list I have seen (and I am sometimes not living up to that 
standard). What irritates me a bit are these back-and-forth decisions. I 
accepted ".+" for scalar plus vector operations (with a bit of teeth 
grinding, but listening to a good mathematical analogy), used it in some 
programs, only learning a few weeks later that a change agent had struck 
again.

I know about (some of) the problems with rounding. The perhaps 
mathematically most complete and correct arithmetic computing system, 
PARI/GP, still uses "round-to-+Inf" and 'generations' of mathematicians 
have lived well with that. And the "problems with the digit argument" 
mentioned are perhaps a reason why many systems like Octave, Matlab (up to 
2014a), Mathematica, PARI/GP do not allow for a second parameter in their 
'round' functions. Maybe there is really no satisfying solution here for 
this problem.

[julia-users] Using Julia with other (GC) languages

[Páll Haraldsson]

I know you can call C from Julia and therefore most other (non-GC) 
languages. And with embedding, vice versa.

Of course you always can call other languages, say with RPC etc. but wander 
what the limitations are to call directly.

It seems to me you can call C because it is not a garbage-controlled 
language. And when embedding Julia in C then you get the whole runtime and 
it is similar to embedding Prolog in C. I've just not looked to much into 
embedding. Would you say calling in that direction is more difficult 
because of it or some other reason?

It seems to me you would want Julia to be the "master language" on top 
because it has GC (and is the more "powerful language").

In theory, calling other GC languages such as Java or C# should be possible 
but not in practice (without copying/RPC) because you can have only on GC, 
right? Still calling Python is possible, because it uses reference 
counting, not true GC? But it also has GC for cycles. So maybe there is no 
difficulty with GC or is that part just disabled?


And:
I know about the current situation with calling C++. For old Python code 
(even on Windows) and numpy (or whatever) that calls C++ (Microsoft's 
Visual Studio), since Julia can call Python, should there really be any 
reason for it be difficult to call C++ if it is only indirectly?

Best regards,
Palli.

Re: [julia-users] Julia for large scale software development

[Spencer Russell]

On Friday, December 26, 2014 5:32:39 PM UTC-5, Páll Haraldsson wrote:
>
>
> Maybe I should just put my blinders on, just not look at other languages 
> more. I'm pretty convinced all the others I know are obsolete (for new 
> code).. I just might be missing something with the newer languages.
>

Julia is wonderful and in my top 3 favorite languages to code in, but 
there's a lot to be learned from other languages. Also often different 
circumstances call for different tools. I'd hesitate to make claims like 
"all the others I know are obsolete" (I reserve that sort of hyperbole for 
clickbait Wired headlines).

[julia-users] Re: Can't round Rational{Int} using new rounding functions

[Tomas Lycken]

Submitted: https://github.com/JuliaLang/Compat.jl/pull/34

// T

On Friday, December 26, 2014 11:08:16 PM UTC+1, Tomas Lycken wrote:
>
> Thanks - then at least I know that it's not a user error. I'll take a look 
> at Compat and see if I can figure out a fix.
>
> // Tomas
>
> On Friday, December 26, 2014 11:07:14 PM UTC+1, Ivar Nesje wrote:
>>
>> If it can't be fixed in Compat, we might consider it a bug in Julia 0.3 
>> and fix it in a new 0.3.5 point release.
>>
>> Ivar
>>
>> kl. 23:03:51 UTC+1 fredag 26. desember 2014 skrev Ivar Nesje følgende:
>>>
>>> I think this have to be fixed in Compat, so that's probably the right 
>>> place to open an issue (or preferably a PR).
>>>
>>> You also don't need @compat, because (currently) Compat just generically 
>>> defines 
>>> the new functions 
>>> 
>>>  
>>> on Julia 0.3.
>>>
>>> Ivar
>>>
>>> kl. 19:52:34 UTC+1 fredag 26. desember 2014 skrev Tomas Lycken følgende:

 I don't know if this is a problem with core Julia, with Compat.jl or 
 with my own code, but I can't figure out how to get this working.

 On Julia 0.3, I can do iround(1//2) without problems (yielding 1), but 
 I can't figure out how to do this with the 0.4 method names and Compat: 

 julia> using Compat

 julia> @compat round(Int, 1//2)
 ERROR: `iround` has no method matching iround(::Type{Int64}, 
 ::Rational{Int64})
  in round at /home/tlycken/.julia/v0.3/Compat/src/Compat.jl:45

 Am I doing something wrong here, or should I file an issue? If I 
 should, is the problem with Compat.jl or with core Julia?

 Thanks,

 // T

>>>

Re: [julia-users] Julia for large scale software development

[Kevin Squire]

LOL!!!  (A good xkcd link always does that.)

On Friday, December 26, 2014, Tomas Lycken  wrote:

> Duty calls...!
>
> http://xkcd.com/386/
>
> On Friday, December 26, 2014 10:58:06 PM UTC+1, Stefan Karpinski wrote:
>>
>> Oh, man. Suggesting a different language on a language's mailing list –
>> that's throwing down the gauntlet! I think I'll write a reply on the ceylon
>> list about some of the factual claims about Julia.
>>
>> On Fri, Dec 26, 2014 at 4:41 PM, Páll Haraldsson 
>> wrote:
>>
>>>
>>> I mentioned Julia as a good alternative to Ceylon language in their
>>> forum (for linear algebra).
>>>
>>> First of all, I assume you could call Ceylon (in theory at least, or
>>> vice versa, I don't know to much about Ceylon). And second, I'm not sure I
>>> agree with the responses I got. It seems they (or I?) misunderstand Julia.
>>> Am I wrong to think that Julia has all the important properties of "static
>>> languages" and should really be considered as such? I'm still not sure
>>> about (e.g.) this part "Julia does not have inheritance, so I could not
>>> build complex hierarchies of classes". It seems to me Julia has type
>>> hierarchies and I've not looked enough into multiple dispatch vs.
>>> "conventional OO" to see if it has any big downsides. On its own or
>>> interfacing with other OO languages, say C++. I do not care about every
>>> conceivable OO feature such as C++'s multiple inheritance, just that you
>>> have good abstraction capabilities (and can call other OO code in other
>>> languages).
>>>
>>> https://groups.google.com/forum/#!topic/ceylon-users/Qs9m1SgdThI
>>>
>>> It seems to be that the module system is excellent (no worse than other
>>> languages I know) and the exception handling. The data hiding part I'm
>>> conflicted about. Are there any major trade-offs the designers regret
>>> (related to large-scale) or would like to change (breaking code).
>>>
>>> Best regards,
>>> Palli.
>>>
>>>
>>

Re: [julia-users] Julia for large scale software development

[Páll Haraldsson]

I'm sorry, I wanted to correct them myself. Not expecting anyone (else) to 
since I started this.. I think I know a good thing when I see one. I just 
though maybe I'm missing something getting those responses and wandered if 
my admiration of Julia was somewhat misplaced.

Maybe I should just put my blinders on, just not look at other languages 
more. I'm pretty convinced all the others I know are obsolete (for new 
code).. I just might be missing something with the newer languages.

Multiple dispatch was new to me. I looked into Dylan when Newton came out 
but probably not enough.. Did again recently. I assume there is no good 
reason to learn it anymore..

-- 
Palli.

On Friday, December 26, 2014 9:58:06 PM UTC, Stefan Karpinski wrote:
>
> Oh, man. Suggesting a different language on a language's mailing list – 
> that's throwing down the gauntlet! I think I'll write a reply on the ceylon 
> list about some of the factual claims about Julia.
>
> On Fri, Dec 26, 2014 at 4:41 PM, Páll Haraldsson  > wrote:
>
>>
>> I mentioned Julia as a good alternative to Ceylon language in their forum 
>> (for linear algebra).
>>
>> First of all, I assume you could call Ceylon (in theory at least, or vice 
>> versa, I don't know to much about Ceylon). And second, I'm not sure I agree 
>> with the responses I got. It seems they (or I?) misunderstand Julia. Am I 
>> wrong to think that Julia has all the important properties of "static 
>> languages" and should really be considered as such? I'm still not sure 
>> about (e.g.) this part "Julia does not have inheritance, so I could not 
>> build complex hierarchies of classes". It seems to me Julia has type 
>> hierarchies and I've not looked enough into multiple dispatch vs. 
>> "conventional OO" to see if it has any big downsides. On its own or 
>> interfacing with other OO languages, say C++. I do not care about every 
>> conceivable OO feature such as C++'s multiple inheritance, just that you 
>> have good abstraction capabilities (and can call other OO code in other 
>> languages). 
>>
>> https://groups.google.com/forum/#!topic/ceylon-users/Qs9m1SgdThI
>>
>> It seems to be that the module system is excellent (no worse than other 
>> languages I know) and the exception handling. The data hiding part I'm 
>> conflicted about. Are there any major trade-offs the designers regret 
>> (related to large-scale) or would like to change (breaking code).
>>
>> Best regards,
>> Palli.
>>
>>
>

Re: [julia-users] compilation problem on OS X for v0.4

[Kevin Squire]

My understanding is that cmake is more a replacement for autotools than
make, since on *nix platforms (at least), it generates Makefiles.

Cheers!
  Kevin

On Friday, December 26, 2014, Stefan Karpinski  wrote:

> It's sort of unfortunate that we need to depend on both make and cmake,
> but c'est la vie – we also depend on both C and Fortran compilers. Life's
> complicated when you need to build a lot of software.
>
> On Fri, Dec 26, 2014 at 2:14 PM, John Myles White <
> johnmyleswh...@gmail.com
> > wrote:
>
>> No worries. Adding a cmake dependency is a big change for Julia.
>>
>>  -- John
>>
>> On Dec 26, 2014, at 2:13 PM, Ethan Anderes > > wrote:
>>
>> Thanks John. I guess that was obvious from the error message. Sorry for
>> the noise.
>>
>> --Ethan
>>
>> On Friday, December 26, 2014 11:09:04 AM UTC-8, John Myles White wrote:
>>>
>>> You need to install cmake and make it available on your path:
>>> http://www.cmake.org/download/
>>>
>>>  -- John
>>>
>>> On Dec 26, 2014, at 2:07 PM, Ethan Anderes  wrote:
>>>
>>> Hi Everyone:
>>>
>>> I just decided to upgrade to Julia v0.4 and ran into the following error
>>> when trying to compile from source (I’m running Yosemite 10.10.1). Anyone
>>> else run into this problem and know how to fix it? —Cheers
>>>
>>> ==
>>> All 3 tests passed
>>> ==
>>> Making check in cxx
>>> ==
>>> All 0 tests passed
>>> ==
>>> Making check in mpn
>>> Making check in mpz
>>> Making check in mpq
>>> Making check in mpf
>>> Making check in printf
>>> Making check in scanf
>>> Making check in rand
>>> Making check in cxx
>>> Making check in demos
>>> Making check in calc
>>> Making check in expr
>>> Making check in tune
>>> Making check in doc
>>> /bin/sh: cmake: command not found
>>> make[2]: *** [libgit2-0.21.3/build/Makefile] Error 127
>>> make[1]: *** [julia-release] Error 2
>>> make: *** [release] Error 2
>>>
>>> ​
>>>
>>>
>>>
>>
>

Re: [julia-users] Julia for large scale software development

[Tomas Lycken]

Duty calls...!

http://xkcd.com/386/

On Friday, December 26, 2014 10:58:06 PM UTC+1, Stefan Karpinski wrote:
>
> Oh, man. Suggesting a different language on a language's mailing list – 
> that's throwing down the gauntlet! I think I'll write a reply on the ceylon 
> list about some of the factual claims about Julia.
>
> On Fri, Dec 26, 2014 at 4:41 PM, Páll Haraldsson  > wrote:
>
>>
>> I mentioned Julia as a good alternative to Ceylon language in their forum 
>> (for linear algebra).
>>
>> First of all, I assume you could call Ceylon (in theory at least, or vice 
>> versa, I don't know to much about Ceylon). And second, I'm not sure I agree 
>> with the responses I got. It seems they (or I?) misunderstand Julia. Am I 
>> wrong to think that Julia has all the important properties of "static 
>> languages" and should really be considered as such? I'm still not sure 
>> about (e.g.) this part "Julia does not have inheritance, so I could not 
>> build complex hierarchies of classes". It seems to me Julia has type 
>> hierarchies and I've not looked enough into multiple dispatch vs. 
>> "conventional OO" to see if it has any big downsides. On its own or 
>> interfacing with other OO languages, say C++. I do not care about every 
>> conceivable OO feature such as C++'s multiple inheritance, just that you 
>> have good abstraction capabilities (and can call other OO code in other 
>> languages). 
>>
>> https://groups.google.com/forum/#!topic/ceylon-users/Qs9m1SgdThI
>>
>> It seems to be that the module system is excellent (no worse than other 
>> languages I know) and the exception handling. The data hiding part I'm 
>> conflicted about. Are there any major trade-offs the designers regret 
>> (related to large-scale) or would like to change (breaking code).
>>
>> Best regards,
>> Palli.
>>
>>
>

[julia-users] Re: Can't round Rational{Int} using new rounding functions

[Tomas Lycken]

Thanks - then at least I know that it's not a user error. I'll take a look 
at Compat and see if I can figure out a fix.

// Tomas

On Friday, December 26, 2014 11:07:14 PM UTC+1, Ivar Nesje wrote:
>
> If it can't be fixed in Compat, we might consider it a bug in Julia 0.3 
> and fix it in a new 0.3.5 point release.
>
> Ivar
>
> kl. 23:03:51 UTC+1 fredag 26. desember 2014 skrev Ivar Nesje følgende:
>>
>> I think this have to be fixed in Compat, so that's probably the right 
>> place to open an issue (or preferably a PR).
>>
>> You also don't need @compat, because (currently) Compat just generically 
>> defines 
>> the new functions 
>> 
>>  
>> on Julia 0.3.
>>
>> Ivar
>>
>> kl. 19:52:34 UTC+1 fredag 26. desember 2014 skrev Tomas Lycken følgende:
>>>
>>> I don't know if this is a problem with core Julia, with Compat.jl or 
>>> with my own code, but I can't figure out how to get this working.
>>>
>>> On Julia 0.3, I can do iround(1//2) without problems (yielding 1), but I 
>>> can't figure out how to do this with the 0.4 method names and Compat: 
>>>
>>> julia> using Compat
>>>
>>> julia> @compat round(Int, 1//2)
>>> ERROR: `iround` has no method matching iround(::Type{Int64}, 
>>> ::Rational{Int64})
>>>  in round at /home/tlycken/.julia/v0.3/Compat/src/Compat.jl:45
>>>
>>> Am I doing something wrong here, or should I file an issue? If I should, 
>>> is the problem with Compat.jl or with core Julia?
>>>
>>> Thanks,
>>>
>>> // T
>>>
>>

[julia-users] Re: Can't round Rational{Int} using new rounding functions

[Ivar Nesje]

If it can't be fixed in Compat, we might consider it a bug in Julia 0.3 and 
fix it in a new 0.3.5 point release.

Ivar

kl. 23:03:51 UTC+1 fredag 26. desember 2014 skrev Ivar Nesje følgende:
>
> I think this have to be fixed in Compat, so that's probably the right 
> place to open an issue (or preferably a PR).
>
> You also don't need @compat, because (currently) Compat just generically 
> defines 
> the new functions 
> 
>  
> on Julia 0.3.
>
> Ivar
>
> kl. 19:52:34 UTC+1 fredag 26. desember 2014 skrev Tomas Lycken følgende:
>>
>> I don't know if this is a problem with core Julia, with Compat.jl or with 
>> my own code, but I can't figure out how to get this working.
>>
>> On Julia 0.3, I can do iround(1//2) without problems (yielding 1), but I 
>> can't figure out how to do this with the 0.4 method names and Compat: 
>>
>> julia> using Compat
>>
>> julia> @compat round(Int, 1//2)
>> ERROR: `iround` has no method matching iround(::Type{Int64}, 
>> ::Rational{Int64})
>>  in round at /home/tlycken/.julia/v0.3/Compat/src/Compat.jl:45
>>
>> Am I doing something wrong here, or should I file an issue? If I should, 
>> is the problem with Compat.jl or with core Julia?
>>
>> Thanks,
>>
>> // T
>>
>

[julia-users] Re: Can't round Rational{Int} using new rounding functions

[Ivar Nesje]

I think this have to be fixed in Compat, so that's probably the right place 
to open an issue (or preferably a PR).

You also don't need @compat, because (currently) Compat just generically 
defines 
the new functions 

 
on Julia 0.3.

Ivar

kl. 19:52:34 UTC+1 fredag 26. desember 2014 skrev Tomas Lycken følgende:
>
> I don't know if this is a problem with core Julia, with Compat.jl or with 
> my own code, but I can't figure out how to get this working.
>
> On Julia 0.3, I can do iround(1//2) without problems (yielding 1), but I 
> can't figure out how to do this with the 0.4 method names and Compat: 
>
> julia> using Compat
>
> julia> @compat round(Int, 1//2)
> ERROR: `iround` has no method matching iround(::Type{Int64}, 
> ::Rational{Int64})
>  in round at /home/tlycken/.julia/v0.3/Compat/src/Compat.jl:45
>
> Am I doing something wrong here, or should I file an issue? If I should, 
> is the problem with Compat.jl or with core Julia?
>
> Thanks,
>
> // T
>

Re: [julia-users] Julia for large scale software development

[Stefan Karpinski]

Oh, man. Suggesting a different language on a language's mailing list –
that's throwing down the gauntlet! I think I'll write a reply on the ceylon
list about some of the factual claims about Julia.

On Fri, Dec 26, 2014 at 4:41 PM, Páll Haraldsson 
wrote:

>
> I mentioned Julia as a good alternative to Ceylon language in their forum
> (for linear algebra).
>
> First of all, I assume you could call Ceylon (in theory at least, or vice
> versa, I don't know to much about Ceylon). And second, I'm not sure I agree
> with the responses I got. It seems they (or I?) misunderstand Julia. Am I
> wrong to think that Julia has all the important properties of "static
> languages" and should really be considered as such? I'm still not sure
> about (e.g.) this part "Julia does not have inheritance, so I could not
> build complex hierarchies of classes". It seems to me Julia has type
> hierarchies and I've not looked enough into multiple dispatch vs.
> "conventional OO" to see if it has any big downsides. On its own or
> interfacing with other OO languages, say C++. I do not care about every
> conceivable OO feature such as C++'s multiple inheritance, just that you
> have good abstraction capabilities (and can call other OO code in other
> languages).
>
> https://groups.google.com/forum/#!topic/ceylon-users/Qs9m1SgdThI
>
> It seems to be that the module system is excellent (no worse than other
> languages I know) and the exception handling. The data hiding part I'm
> conflicted about. Are there any major trade-offs the designers regret
> (related to large-scale) or would like to change (breaking code).
>
> Best regards,
> Palli.
>
>

Re: [julia-users] Julia for large scale software development

[Mike Innes]

None of those are particularly good reasons. It boils down to "Julia
doesn't do Java-style OO well", but believe it or not Java-style OO isn't
the only way you can build a large program.

To take a couple of specific points as examples, you can use composition

as a replacement for inheritance just fine, and you can get great
autocomplete  for Julia as well.

On 26 December 2014 at 21:41, Páll Haraldsson 
wrote:

>
> I mentioned Julia as a good alternative to Ceylon language in their forum
> (for linear algebra).
>
> First of all, I assume you could call Ceylon (in theory at least, or vice
> versa, I don't know to much about Ceylon). And second, I'm not sure I agree
> with the responses I got. It seems they (or I?) misunderstand Julia. Am I
> wrong to think that Julia has all the important properties of "static
> languages" and should really be considered as such? I'm still not sure
> about (e.g.) this part "Julia does not have inheritance, so I could not
> build complex hierarchies of classes". It seems to me Julia has type
> hierarchies and I've not looked enough into multiple dispatch vs.
> "conventional OO" to see if it has any big downsides. On its own or
> interfacing with other OO languages, say C++. I do not care about every
> conceivable OO feature such as C++'s multiple inheritance, just that you
> have good abstraction capabilities (and can call other OO code in other
> languages).
>
> https://groups.google.com/forum/#!topic/ceylon-users/Qs9m1SgdThI
>
> It seems to be that the module system is excellent (no worse than other
> languages I know) and the exception handling. The data hiding part I'm
> conflicted about. Are there any major trade-offs the designers regret
> (related to large-scale) or would like to change (breaking code).
>
> Best regards,
> Palli.
>
>

Re: [julia-users] Julia modifies variable outside of function when operating on different variable inside of function

[Stefan Karpinski]

Whether this is surprising to you or not depends entirely what language you
are coming from. For Matlab and R users, this is a significant difference.
For people coming from C, C++, Fortran, Python, Ruby, Perl, Java, and Lisp,
this is unsurprising. You can easily implement the non-mutating behavior
starting from pass-by-sharing semantics. Starting from Matlab/R
pass-by-value semantics, it's basically impossible to recover efficiency
and avoid copying reliably – and any mechanisms to do so are complicated
and hard to reason about (copy-on-write is one such mechanism). This is one
of the main reasons why people write MEX extensions in Matlab and C/C++
extensions in R – so that they can modify arrays without copying them and
have fast for loops. Since Julia aims to never force you to use a lower
level language, the only real choice is the way we do it.

On Fri, Dec 26, 2014 at 4:04 PM, Páll Haraldsson 
wrote:

>
> I wander if the convention should have been made the other way as not all
> will know it at first..
>
> If you do not want your arguments touched then you can trivially make a
> non-mutating wrapper using the similar function. It seems that could have
> been automated.. Maybe you can with a macro?
>
> Would it be easy to give a warning or an error for functions that are
> mutating? Or really, if it can be detected then shouldn't the function be
> renamed to the ! variant and a wrapper be made?
>
> Best regards,
> Palli.
>
>
> On Friday, December 26, 2014 8:42:18 PM UTC, Tomas Lycken wrote:
>>
>> Glad to be of service! =)
>>
>> Languages treat both aliasing and argument passing differently, so it
>> really just takes a little while to experiment and see how this language
>> plays out what you're trying to do. For what it's worth, Julia also has
>> a style convention to end all method names with a bang ("!") if they mutate
>> their arguments. So with your first example, the function could have been
>> named square!(arg), and then users of that function would be immediately
>> aware that arg would be changed. This convention isn't really enforced in
>> any way (except code review) - it's perfectly valid Julia to mutate
>> function arguments even if the function name doesn't end with ! - but the
>> core libraries as well as most packages do follow it.
>>
>> Happy coding!
>>
>> // Tomas
>>
>> On Friday, December 26, 2014 9:33:12 PM UTC+1, Bradley Setzler wrote:
>>>
>>> Thanks Tomas, the similar command will be very useful in avoiding this
>>> issue.
>>>
>>> Thank you also for a thoughtful and informative response, Tomas.
>>>
>>> Bradley
>>>
>>> PS - For what it's worth, R does not have this behavior.
>>>
>>>
>>>
>>> On Friday, December 26, 2014 2:05:44 PM UTC-6, Tomas Lycken wrote:

 The main reason is performance; passing and aliasing arrays this way
 (those are two different concepts, which work together to make this
 particular example a little confusing) allow for writing code that is as
 fast as possible, by leaving the coder in control of when a copy is made
 and when it is not. A more idiomatic way of writing your square function,
 which would do what you expect, would be

 ```
 function square(A)
 A2 = similar(A)
 for i = 1:length(A)
 A2[i] = A[i]^2
 end
 A2
 end
 ```

 The funciton `similar` allocates new memory for an array of similar
 size and type as `A`. You could also have left your entire method untouch
 except setting `inner_var = copy(arg)`, but this would have meant both
 reading and writing more to memory than you need to. As you see, Julia's
 behavior allows you to write more performant code than what you'd do
 otherwise.

 // Tomas

 On Friday, December 26, 2014 8:58:04 PM UTC+1, Bradley Setzler wrote:
>
> Why would you want this behavior? How could you possibly benefit from
> modifying X anytime you modify Y just because Y=X initially? If I wanted 
> to
> modify X, I would modify X itself, not Y.
>
> Bradley
>
>
>
>
> On Friday, December 26, 2014 1:53:12 PM UTC-6, John Myles White wrote:
>>
>> This is aliasing. Almost all languages allow this.
>>
>>  -- John
>>
>> Sent from my iPhone
>>
>> On Dec 26, 2014, at 2:49 PM, Bradley Setzler 
>> wrote:
>>
>> Hi,
>>
>> I cannot explain this behavior. I apply a function to a variable in
>> the workspace, the function initializes its local variable at the 
>> workspace
>> variable, then modifies the local variable and produces the desired 
>> output.
>> However, it turns out the Julia modifies both the local and workspace
>> variable with each operation on the local variable. Only the local 
>> variable
>> is supposed to be modified.
>>
>> *This is very dangerous behavior, as Julia is modifying the data
>> itself between performing operations on the data; the data itse

[julia-users] Julia for large scale software development

[Páll Haraldsson]

I mentioned Julia as a good alternative to Ceylon language in their forum 
(for linear algebra).

First of all, I assume you could call Ceylon (in theory at least, or vice 
versa, I don't know to much about Ceylon). And second, I'm not sure I agree 
with the responses I got. It seems they (or I?) misunderstand Julia. Am I 
wrong to think that Julia has all the important properties of "static 
languages" and should really be considered as such? I'm still not sure 
about (e.g.) this part "Julia does not have inheritance, so I could not 
build complex hierarchies of classes". It seems to me Julia has type 
hierarchies and I've not looked enough into multiple dispatch vs. 
"conventional OO" to see if it has any big downsides. On its own or 
interfacing with other OO languages, say C++. I do not care about every 
conceivable OO feature such as C++'s multiple inheritance, just that you 
have good abstraction capabilities (and can call other OO code in other 
languages). 

https://groups.google.com/forum/#!topic/ceylon-users/Qs9m1SgdThI

It seems to be that the module system is excellent (no worse than other 
languages I know) and the exception handling. The data hiding part I'm 
conflicted about. Are there any major trade-offs the designers regret 
(related to large-scale) or would like to change (breaking code).

Best regards,
Palli.

Re: [julia-users] Julia modifies variable outside of function when operating on different variable inside of function

[Tomas Lycken]

The problem lies in detecting (or, rather, teaching the compiler to detect) 
if a function - or any of the functions it calls - mutates an argument; 
this is a fairly difficult problem.

If you take a look at the Julia standard library, you'll see that a lot of 
functions have both mutating and non-mutating variants, usually implemented 
with the non-mutating variant as a thin wrapper that just copies the input 
arguments and calls the mutating variant:

function foo(a, b)
foo!(copy(a), copy(b))
end

function foo!(a, b)
   # do whatever, including mutating a and b
end

Of course, one could argue that the opposite (wrapping the non-mutating 
variant with a mutating variant) would be just the same, but copying 
explicitly is easier to do with fewer language constructs. We can agree (I 
hope) that there is merit in allowing pass-by-reference behavior *sometimes*, 
since it does allow for (sometimes very significant) performance gains, so 
if we don't have it by default we have to figure out a way to specify that 
it should be by reference. And by the way, should that be done by the 
caller, or by the callee? For example, consider foo! above - either, we 
could imagine a keyword ref that specifies pass-by-reference (like & in 
C++):

foo!(ref a, ref b)
# do whatever
end

Now, however, we still have the problem that the caller doesn't necessarily 
know that foo! will mutate its arguments (it has the bang, but that's just 
convention...), so it could be equally confusing to a new user. We could 
instead demand that pass-by-reference was specified at the call site:

a = [1:4]
b = [5:7]
foo!(ref a, ref b)

but that would litter our code with ref keywords everywhere in order to not 
lose a lot of performance from unnecessary copying (exactly the problem 
that C++ suffers from). Additionally, some functions might just not work 
without pass-by-reference - take, for instance, A_mul_B! from the linalg 
library - it's signature is A_mul_B!(C, A, B), and it multiplies the 
matrices A and B and stores the result in the (pre-allocated) array C. With 
the ref construct, that would have to be A_mul_B!(ref C, A, B) in order to 
work at all - but what should happen if you forget ref, and call 
A_mul_B!(C, A, B)? By using pass-by-reference everywhere, you never have to 
reason about this - it behaves the same every time. If you need a copy, 
make one - and since you make one explicitly, you may notice optimization 
possibilities that you wouldn't have thought of otherwise.

As you can see, although there are of course back-sides of the 
pass-by-reference convention, there are sound arguments in favor of it 
also. It is a little different than how some other languages work, but 
"different" and "dangerous" are not synonyms :) It is well documented, and 
- as you've noticed - we learn from each other. Give it a chance, and 
within a couple of weeks of writing Julia code both the argument passing 
behavior, the bang convention and a bunch of other stuff will feel as 
natural as any other way of doing it =)

// T

On Friday, December 26, 2014 10:04:57 PM UTC+1, Páll Haraldsson wrote:
>
>
> I wander if the convention should have been made the other way as not all 
> will know it at first..
>
> If you do not want your arguments touched then you can trivially make a 
> non-mutating wrapper using the similar function. It seems that could have 
> been automated.. Maybe you can with a macro?
>
> Would it be easy to give a warning or an error for functions that are 
> mutating? Or really, if it can be detected then shouldn't the function be 
> renamed to the ! variant and a wrapper be made?
>
> Best regards,
> Palli.
>
> On Friday, December 26, 2014 8:42:18 PM UTC, Tomas Lycken wrote:
>>
>> Glad to be of service! =)
>>
>> Languages treat both aliasing and argument passing differently, so it 
>> really just takes a little while to experiment and see how this language 
>> plays out what you're trying to do. For what it's worth, Julia also has 
>> a style convention to end all method names with a bang ("!") if they mutate 
>> their arguments. So with your first example, the function could have been 
>> named square!(arg), and then users of that function would be immediately 
>> aware that arg would be changed. This convention isn't really enforced in 
>> any way (except code review) - it's perfectly valid Julia to mutate 
>> function arguments even if the function name doesn't end with ! - but the 
>> core libraries as well as most packages do follow it.
>>
>> Happy coding!
>>
>> // Tomas
>>
>> On Friday, December 26, 2014 9:33:12 PM UTC+1, Bradley Setzler wrote:
>>>
>>> Thanks Tomas, the similar command will be very useful in avoiding this 
>>> issue. 
>>>
>>> Thank you also for a thoughtful and informative response, Tomas.
>>>
>>> Bradley
>>>
>>> PS - For what it's worth, R does not have this behavior.
>>>
>>>
>>>
>>> On Friday, December 26, 2014 2:05:44 PM UTC-6, Tomas Lycken wrote:

 The main reason is performance; passi

[julia-users] Re: Julia & Mongo

[Charles Wiese]

Thank you for that fix!   Works for me.  

On Wednesday, December 3, 2014 9:09:46 PM UTC-5, Tobias Jone wrote:
>
> Inside the "Mongo.jl" file,  what is  const MONGO_LIB defined as?  If 
> it's currently "libmongoc", try explicitly setting the suffix, eg const 
> MONGO_LIB = "libmongoc-1.0" 
> Bit of a late response, but you never know.
>

[julia-users] Re: Julia documentation is ready for translation/internationalization on Transifex!

[Ismael VC]

Well I was told that historicaly people were encouraged not to spend too 
much energy translating the docs because they are not static (and I see 
that still hasn't changed). I thought there wasn't much interest, so I left 
the idea for a while and stoped looking for advance in this field.

But I've been planing this for a while, after all I want to be a 
programmer, and learn how to automate this kind of stuff the most I can and 
solve problems, etc (I don't mind about non-staticness, as a matter of fact 
I like the idea of keep on learning Julia at the same time I do this):

   - How to translate the docs: http://bit.ly/13Kgt18
   - Does anyone has any experience in computer aided translating?: 
   http://bit.ly/144ZIyy
   - Advice about git repository layout: http://bit.ly/1zncd0b


I'm just so tired of JIT translating from the manual when I'm in the 
classroom or when explaining what Julia is and why it is important to learn 
and use, to someone, over and over again, I think I can get a group of 
students from my school to aid me in the review process, I've talked to one 
of my profesors about giving them some extra credits or something.

Waldir I would love to get feedback from you, I just followed the sphinx 
instructions, but if there are better options that benefit all the non 
english people, I would like to implement them as soon as posible (while my 
vacations last), this would be the best time to do this since the project 
is just starting, but either way I'm not stoping this time, I just want to 
get it done and done well.

My ulitmate goal is that once most of the strings are translated and 
reviewed, make a program automatically update the resources, when the 
tracked files are changed and get a notification, if I can get some people 
to translate or review in trasifex (even if it is just one string a day, 5 
minutes of their time) from their cellphones instead of watching them waste 
all day playing candycrush or whatever (most of the smarphone people I know 
do this), then that would make me very very happy.

I absoulutely want this manual on my school library!

El viernes, 26 de diciembre de 2014 11:27:38 UTC-6, Waldir Pimenta escribió:
>
> Hi Ismael,
>
> First of all, thanks for doing this :)
>
> I am not sure if you announced your plans to work on this in advance, so 
> sorry if I missed it and thus the opportunity to provide early feedback. 
> The last time I saw the issue of translating the documentation using a 
> translation platform being discussed, I mentioned my concerns about the 
> choice of platform 
> , 
> particularly regarding two features I consider extremely useful: 
> translation memory / machine translation (which ends up saving a lot of 
> typing, as well as ensuring consistency), and the ability for users to 
> choose their language fallback chain (e.g. a Portuguese user could pick 
> Brazilian Portuguese, Galician, and Spanish as fallback languages), which 
> again allows a much more efficient translation workflow and often help 
> escaping ambiguity holes due to insufficient context.
>
> IIRC Transifex doesn't provide these features, while e.g. Crowdin and 
> TranslateWiki do. Have you considered either of them? Would it be feasible 
> to change the platform at this time?
>
> On Thursday, December 25, 2014 5:34:01 PM UTC, Ismael VC wrote:
>>
>> Merry Christmas everyone!
>>
>> I have an announcement and an invitation to make to the Julia community.
>>
>> Yesterday I finally finished seting-up, julialang docs on Transifex 
>> (online crowdsourcing localization platform) something I wanted to do ever 
>> since last year, but sadly never had time to actually invest on it, my 
>> intention is to translate the docs to spanish, and also make an invitation 
>> to anyone interested in helping me out or translating them to their native 
>> language.
>>
>> You can see my setup here: 
>> https://github.com/Ismael-VC/julia/tree/julia-translations/doc
>>
>> Please don't hesitate to ask me any question or give me advice I really 
>> want to do this well. If any of you have experience with any of this I 
>> would really really love to have a chat with you!
>>
>> ! I'm still testing the current setup (I don't know why `make gettext` 
>> takes so much time, yesterday it was done in a breeze:
>>
>> [ismaelvc@toybox doc]$ time ./update_resources.sh 
>> Enter passphrase for key '/home/ismaelvc/.ssh/id_rsa': 
>> From github.com:JuliaLang/julia
>>  * branchmaster -> FETCH_HEAD
>> Already up-to-date.
>> . /home/ismaelvc/julia/deps/julia-env/bin/activate && sphinx-build -b 
>> gettext   . _build/locale
>> Running Sphinx v1.2.3
>> loading pickled environment... done
>> building [gettext]: targets for 0 template files
>> building [gettext]: targets for 56 source files that are out of date
>> updating environment: 0 added, 2 changed, 0 removed
>> reading sources... [ 50%] manual/faq 
>>
>> It just stays there (

Re: [julia-users] compilation problem on OS X for v0.4

[Stefan Karpinski]

It's sort of unfortunate that we need to depend on both make and cmake, but
c'est la vie – we also depend on both C and Fortran compilers. Life's
complicated when you need to build a lot of software.

On Fri, Dec 26, 2014 at 2:14 PM, John Myles White 
wrote:

> No worries. Adding a cmake dependency is a big change for Julia.
>
>  -- John
>
> On Dec 26, 2014, at 2:13 PM, Ethan Anderes  wrote:
>
> Thanks John. I guess that was obvious from the error message. Sorry for
> the noise.
>
> --Ethan
>
> On Friday, December 26, 2014 11:09:04 AM UTC-8, John Myles White wrote:
>>
>> You need to install cmake and make it available on your path:
>> http://www.cmake.org/download/
>>
>>  -- John
>>
>> On Dec 26, 2014, at 2:07 PM, Ethan Anderes  wrote:
>>
>> Hi Everyone:
>>
>> I just decided to upgrade to Julia v0.4 and ran into the following error
>> when trying to compile from source (I’m running Yosemite 10.10.1). Anyone
>> else run into this problem and know how to fix it? —Cheers
>>
>> ==
>> All 3 tests passed
>> ==
>> Making check in cxx
>> ==
>> All 0 tests passed
>> ==
>> Making check in mpn
>> Making check in mpz
>> Making check in mpq
>> Making check in mpf
>> Making check in printf
>> Making check in scanf
>> Making check in rand
>> Making check in cxx
>> Making check in demos
>> Making check in calc
>> Making check in expr
>> Making check in tune
>> Making check in doc
>> /bin/sh: cmake: command not found
>> make[2]: *** [libgit2-0.21.3/build/Makefile] Error 127
>> make[1]: *** [julia-release] Error 2
>> make: *** [release] Error 2
>>
>> ​
>>
>>
>>
>

Re: [julia-users] Julia modifies variable outside of function when operating on different variable inside of function

[Páll Haraldsson]

I wander if the convention should have been made the other way as not all 
will know it at first..

If you do not want your arguments touched then you can trivially make a 
non-mutating wrapper using the similar function. It seems that could have 
been automated.. Maybe you can with a macro?

Would it be easy to give a warning or an error for functions that are 
mutating? Or really, if it can be detected then shouldn't the function be 
renamed to the ! variant and a wrapper be made?

Best regards,
Palli.

On Friday, December 26, 2014 8:42:18 PM UTC, Tomas Lycken wrote:
>
> Glad to be of service! =)
>
> Languages treat both aliasing and argument passing differently, so it 
> really just takes a little while to experiment and see how this language 
> plays out what you're trying to do. For what it's worth, Julia also has a 
> style convention to end all method names with a bang ("!") if they mutate 
> their arguments. So with your first example, the function could have been 
> named square!(arg), and then users of that function would be immediately 
> aware that arg would be changed. This convention isn't really enforced in 
> any way (except code review) - it's perfectly valid Julia to mutate 
> function arguments even if the function name doesn't end with ! - but the 
> core libraries as well as most packages do follow it.
>
> Happy coding!
>
> // Tomas
>
> On Friday, December 26, 2014 9:33:12 PM UTC+1, Bradley Setzler wrote:
>>
>> Thanks Tomas, the similar command will be very useful in avoiding this 
>> issue. 
>>
>> Thank you also for a thoughtful and informative response, Tomas.
>>
>> Bradley
>>
>> PS - For what it's worth, R does not have this behavior.
>>
>>
>>
>> On Friday, December 26, 2014 2:05:44 PM UTC-6, Tomas Lycken wrote:
>>>
>>> The main reason is performance; passing and aliasing arrays this way 
>>> (those are two different concepts, which work together to make this 
>>> particular example a little confusing) allow for writing code that is as 
>>> fast as possible, by leaving the coder in control of when a copy is made 
>>> and when it is not. A more idiomatic way of writing your square function, 
>>> which would do what you expect, would be
>>>
>>> ```
>>> function square(A)
>>> A2 = similar(A)
>>> for i = 1:length(A)
>>> A2[i] = A[i]^2
>>> end
>>> A2
>>> end
>>> ```
>>>
>>> The funciton `similar` allocates new memory for an array of similar size 
>>> and type as `A`. You could also have left your entire method untouch except 
>>> setting `inner_var = copy(arg)`, but this would have meant both reading and 
>>> writing more to memory than you need to. As you see, Julia's behavior 
>>> allows you to write more performant code than what you'd do otherwise.
>>>
>>> // Tomas
>>>
>>> On Friday, December 26, 2014 8:58:04 PM UTC+1, Bradley Setzler wrote:

 Why would you want this behavior? How could you possibly benefit from 
 modifying X anytime you modify Y just because Y=X initially? If I wanted 
 to 
 modify X, I would modify X itself, not Y. 

 Bradley




 On Friday, December 26, 2014 1:53:12 PM UTC-6, John Myles White wrote:
>
> This is aliasing. Almost all languages allow this.
>
>  -- John
>
> Sent from my iPhone
>
> On Dec 26, 2014, at 2:49 PM, Bradley Setzler  
> wrote:
>
> Hi,
>
> I cannot explain this behavior. I apply a function to a variable in 
> the workspace, the function initializes its local variable at the 
> workspace 
> variable, then modifies the local variable and produces the desired 
> output. 
> However, it turns out the Julia modifies both the local and workspace 
> variable with each operation on the local variable. Only the local 
> variable 
> is supposed to be modified. 
>
> *This is very dangerous behavior, as Julia is modifying the data 
> itself between performing operations on the data; the data itself is 
> supposed to remain fixed between operations on it.*
>
> *Minimal working example:*
>
> data=[1,2,3]
> function square(arg)
> inner_var = arg
> for i=1:length(inner_var)
> inner_var[i] = inner_var[i]^2
> end
> return inner_var
> end
> output=square(data)
>
> julia> print(data)
>
> [1,4,9]
>
> The data has been squared due to the local variable, which was 
> initialized at the data values, being squared. Now, if i wish to apply a 
> different function to the data, the result will be incorrect because the 
> data has been modified unintentionally.
>
> How long has Julia been doing this? Was this behavior intentional?
> Bradley
>
>
>

Re: [julia-users] Re: Why doesn't Dict() accept an output from zip?

[Stefan Karpinski]

Unfortunately, backporting the new Dict constructor approach to 0.3 would
be a fairly large breaking change, so people will have to rely on Compat
for now for that functionality.

On Fri, Dec 26, 2014 at 5:07 AM, Ismael VC  wrote:

> You'll need to use `@compat` in v0.3.3:
>
> julia> Dict(zip("abc","123"))
> ERROR: `Dict{K,V}` has no method matching Dict{K,V}(::Zip2{ASCIIString,
> ASCIIString})
>
> julia> using Compat
>
> julia> @compat Dict(zip("abc","123"))
> Dict{Char,Char} with 3 entries:
>   'c' => '3'
>   'b' => '2'
>   'a' => '1'
>
>
>
>

Re: [julia-users] Rounding and the IEEE rule

[Stefan Karpinski]

I'm also sorry if you felt like you were being criticized in any way for
proposing alternate behaviors. Please keep in mind that any disagreement is
just that – disagreement. Even if everyone seems disagree with you, please
do make your case. As you've noted, they may change their minds – or they
might not. We can't come to decisions unless everyone tries to make the
case for what they believe is the best behavior in a civil, reasoned
fashion. To me, the fact that these behavior both changed, despite
initially being unpopular, indicates just how important this kind of
discussion is.

Regarding this particular change, I'm personally not really in favor of the
default being the IEEE ties-to-even behavior – I don't think the numerical
argument in its favor is really compelling and I think the current C-like
round-ties-from-zero behavior is less surprising and should continue to be
the default. But I'm not the one doing the work on this and I'm not the
most informed person to make such a decision. So let's try the IEEE
behavior and see how it goes. If this turns out to be problematic or
annoying (I kind of suspect it will), we can still change our minds before
Julia 1.0, so now is the time to give it a shot.

On Fri, Dec 26, 2014 at 3:08 PM, Simon Byrne  wrote:

> On Friday, 26 December 2014 06:14:34 UTC-6, Hans W Borchers wrote:
>>
>> I started this thread long time ago with a question about rounding rules
>> and the IEEE floating point standard. I felt like being criticized for even
>> thinking Julia could follow the "round-to-even" rule. Now I learn that
>> Julia version 0.4 will apply this rule (as default?).
>>
>
> I apologise if you felt I was being critical, that was not at all my
> intention. These are complicated issues, and I don't claim to have all the
> solutions. In fact, we still have yet to resolve the problem with the
> digits argument: I have just opened an issue explaining the problem here:
>
> https://github.com/JuliaLang/julia/issues/9464
>
> Contributions to the discussion are certainly welcome.
>
> -simon
>

Re: [julia-users] Julia modifies variable outside of function when operating on different variable inside of function

[Tomas Lycken]

Glad to be of service! =)

Languages treat both aliasing and argument passing differently, so it 
really just takes a little while to experiment and see how this language 
plays out what you're trying to do. For what it's worth, Julia also has a 
style convention to end all method names with a bang ("!") if they mutate 
their arguments. So with your first example, the function could have been 
named square!(arg), and then users of that function would be immediately 
aware that arg would be changed. This convention isn't really enforced in 
any way (except code review) - it's perfectly valid Julia to mutate 
function arguments even if the function name doesn't end with ! - but the 
core libraries as well as most packages do follow it.

Happy coding!

// Tomas

On Friday, December 26, 2014 9:33:12 PM UTC+1, Bradley Setzler wrote:
>
> Thanks Tomas, the similar command will be very useful in avoiding this 
> issue. 
>
> Thank you also for a thoughtful and informative response, Tomas.
>
> Bradley
>
> PS - For what it's worth, R does not have this behavior.
>
>
>
> On Friday, December 26, 2014 2:05:44 PM UTC-6, Tomas Lycken wrote:
>>
>> The main reason is performance; passing and aliasing arrays this way 
>> (those are two different concepts, which work together to make this 
>> particular example a little confusing) allow for writing code that is as 
>> fast as possible, by leaving the coder in control of when a copy is made 
>> and when it is not. A more idiomatic way of writing your square function, 
>> which would do what you expect, would be
>>
>> ```
>> function square(A)
>> A2 = similar(A)
>> for i = 1:length(A)
>> A2[i] = A[i]^2
>> end
>> A2
>> end
>> ```
>>
>> The funciton `similar` allocates new memory for an array of similar size 
>> and type as `A`. You could also have left your entire method untouch except 
>> setting `inner_var = copy(arg)`, but this would have meant both reading and 
>> writing more to memory than you need to. As you see, Julia's behavior 
>> allows you to write more performant code than what you'd do otherwise.
>>
>> // Tomas
>>
>> On Friday, December 26, 2014 8:58:04 PM UTC+1, Bradley Setzler wrote:
>>>
>>> Why would you want this behavior? How could you possibly benefit from 
>>> modifying X anytime you modify Y just because Y=X initially? If I wanted to 
>>> modify X, I would modify X itself, not Y. 
>>>
>>> Bradley
>>>
>>>
>>>
>>>
>>> On Friday, December 26, 2014 1:53:12 PM UTC-6, John Myles White wrote:

 This is aliasing. Almost all languages allow this.

  -- John

 Sent from my iPhone

 On Dec 26, 2014, at 2:49 PM, Bradley Setzler  
 wrote:

 Hi,

 I cannot explain this behavior. I apply a function to a variable in the 
 workspace, the function initializes its local variable at the workspace 
 variable, then modifies the local variable and produces the desired 
 output. 
 However, it turns out the Julia modifies both the local and workspace 
 variable with each operation on the local variable. Only the local 
 variable 
 is supposed to be modified. 

 *This is very dangerous behavior, as Julia is modifying the data itself 
 between performing operations on the data; the data itself is supposed to 
 remain fixed between operations on it.*

 *Minimal working example:*

 data=[1,2,3]
 function square(arg)
 inner_var = arg
 for i=1:length(inner_var)
 inner_var[i] = inner_var[i]^2
 end
 return inner_var
 end
 output=square(data)

 julia> print(data)

 [1,4,9]

 The data has been squared due to the local variable, which was 
 initialized at the data values, being squared. Now, if i wish to apply a 
 different function to the data, the result will be incorrect because the 
 data has been modified unintentionally.

 How long has Julia been doing this? Was this behavior intentional?
 Bradley

Re: [julia-users] Julia modifies variable outside of function when operating on different variable inside of function

[Bradley Setzler]

Thanks Tomas, the similar command will be very useful in avoiding this 
issue. 

Thank you also for a thoughtful and informative response, Tomas.

Bradley

PS - For what it's worth, R does not have this behavior.



On Friday, December 26, 2014 2:05:44 PM UTC-6, Tomas Lycken wrote:
>
> The main reason is performance; passing and aliasing arrays this way 
> (those are two different concepts, which work together to make this 
> particular example a little confusing) allow for writing code that is as 
> fast as possible, by leaving the coder in control of when a copy is made 
> and when it is not. A more idiomatic way of writing your square function, 
> which would do what you expect, would be
>
> ```
> function square(A)
> A2 = similar(A)
> for i = 1:length(A)
> A2[i] = A[i]^2
> end
> A2
> end
> ```
>
> The funciton `similar` allocates new memory for an array of similar size 
> and type as `A`. You could also have left your entire method untouch except 
> setting `inner_var = copy(arg)`, but this would have meant both reading and 
> writing more to memory than you need to. As you see, Julia's behavior 
> allows you to write more performant code than what you'd do otherwise.
>
> // Tomas
>
> On Friday, December 26, 2014 8:58:04 PM UTC+1, Bradley Setzler wrote:
>>
>> Why would you want this behavior? How could you possibly benefit from 
>> modifying X anytime you modify Y just because Y=X initially? If I wanted to 
>> modify X, I would modify X itself, not Y. 
>>
>> Bradley
>>
>>
>>
>>
>> On Friday, December 26, 2014 1:53:12 PM UTC-6, John Myles White wrote:
>>>
>>> This is aliasing. Almost all languages allow this.
>>>
>>>  -- John
>>>
>>> Sent from my iPhone
>>>
>>> On Dec 26, 2014, at 2:49 PM, Bradley Setzler  
>>> wrote:
>>>
>>> Hi,
>>>
>>> I cannot explain this behavior. I apply a function to a variable in the 
>>> workspace, the function initializes its local variable at the workspace 
>>> variable, then modifies the local variable and produces the desired output. 
>>> However, it turns out the Julia modifies both the local and workspace 
>>> variable with each operation on the local variable. Only the local variable 
>>> is supposed to be modified. 
>>>
>>> *This is very dangerous behavior, as Julia is modifying the data itself 
>>> between performing operations on the data; the data itself is supposed to 
>>> remain fixed between operations on it.*
>>>
>>> *Minimal working example:*
>>>
>>> data=[1,2,3]
>>> function square(arg)
>>> inner_var = arg
>>> for i=1:length(inner_var)
>>> inner_var[i] = inner_var[i]^2
>>> end
>>> return inner_var
>>> end
>>> output=square(data)
>>>
>>> julia> print(data)
>>>
>>> [1,4,9]
>>>
>>> The data has been squared due to the local variable, which was 
>>> initialized at the data values, being squared. Now, if i wish to apply a 
>>> different function to the data, the result will be incorrect because the 
>>> data has been modified unintentionally.
>>>
>>> How long has Julia been doing this? Was this behavior intentional?
>>> Bradley
>>>
>>>
>>>

Re: [julia-users] Rounding and the IEEE rule

[Simon Byrne]

On Friday, 26 December 2014 06:14:34 UTC-6, Hans W Borchers wrote:
>
> I started this thread long time ago with a question about rounding rules 
> and the IEEE floating point standard. I felt like being criticized for even 
> thinking Julia could follow the "round-to-even" rule. Now I learn that 
> Julia version 0.4 will apply this rule (as default?).
>

I apologise if you felt I was being critical, that was not at all my 
intention. These are complicated issues, and I don't claim to have all the 
solutions. In fact, we still have yet to resolve the problem with the 
digits argument: I have just opened an issue explaining the problem here:

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

Contributions to the discussion are certainly welcome.

-simon

Re: [julia-users] Julia modifies variable outside of function when operating on different variable inside of function

[Tomas Lycken]

The main reason is performance; passing and aliasing arrays this way (those 
are two different concepts, which work together to make this particular 
example a little confusing) allow for writing code that is as fast as 
possible, by leaving the coder in control of when a copy is made and when 
it is not. A more idiomatic way of writing your square function, which 
would do what you expect, would be

```
function square(A)
A2 = similar(A)
for i = 1:length(A)
A2[i] = A[i]^2
end
A2
end
```

The funciton `similar` allocates new memory for an array of similar size 
and type as `A`. You could also have left your entire method untouch except 
setting `inner_var = copy(arg)`, but this would have meant both reading and 
writing more to memory than you need to. As you see, Julia's behavior 
allows you to write more performant code than what you'd do otherwise.

// Tomas

On Friday, December 26, 2014 8:58:04 PM UTC+1, Bradley Setzler wrote:
>
> Why would you want this behavior? How could you possibly benefit from 
> modifying X anytime you modify Y just because Y=X initially? If I wanted to 
> modify X, I would modify X itself, not Y. 
>
> Bradley
>
>
>
>
> On Friday, December 26, 2014 1:53:12 PM UTC-6, John Myles White wrote:
>>
>> This is aliasing. Almost all languages allow this.
>>
>>  -- John
>>
>> Sent from my iPhone
>>
>> On Dec 26, 2014, at 2:49 PM, Bradley Setzler  
>> wrote:
>>
>> Hi,
>>
>> I cannot explain this behavior. I apply a function to a variable in the 
>> workspace, the function initializes its local variable at the workspace 
>> variable, then modifies the local variable and produces the desired output. 
>> However, it turns out the Julia modifies both the local and workspace 
>> variable with each operation on the local variable. Only the local variable 
>> is supposed to be modified. 
>>
>> *This is very dangerous behavior, as Julia is modifying the data itself 
>> between performing operations on the data; the data itself is supposed to 
>> remain fixed between operations on it.*
>>
>> *Minimal working example:*
>>
>> data=[1,2,3]
>> function square(arg)
>> inner_var = arg
>> for i=1:length(inner_var)
>> inner_var[i] = inner_var[i]^2
>> end
>> return inner_var
>> end
>> output=square(data)
>>
>> julia> print(data)
>>
>> [1,4,9]
>>
>> The data has been squared due to the local variable, which was 
>> initialized at the data values, being squared. Now, if i wish to apply a 
>> different function to the data, the result will be incorrect because the 
>> data has been modified unintentionally.
>>
>> How long has Julia been doing this? Was this behavior intentional?
>> Bradley
>>
>>
>>

Re: [julia-users] Julia modifies variable outside of function when operating on different variable inside of function

[Bradley Setzler]

Why would you want this behavior? How could you possibly benefit from 
modifying X anytime you modify Y just because Y=X initially? If I wanted to 
modify X, I would modify X itself, not Y. 

Bradley




On Friday, December 26, 2014 1:53:12 PM UTC-6, John Myles White wrote:
>
> This is aliasing. Almost all languages allow this.
>
>  -- John
>
> Sent from my iPhone
>
> On Dec 26, 2014, at 2:49 PM, Bradley Setzler  > wrote:
>
> Hi,
>
> I cannot explain this behavior. I apply a function to a variable in the 
> workspace, the function initializes its local variable at the workspace 
> variable, then modifies the local variable and produces the desired output. 
> However, it turns out the Julia modifies both the local and workspace 
> variable with each operation on the local variable. Only the local variable 
> is supposed to be modified. 
>
> *This is very dangerous behavior, as Julia is modifying the data itself 
> between performing operations on the data; the data itself is supposed to 
> remain fixed between operations on it.*
>
> *Minimal working example:*
>
> data=[1,2,3]
> function square(arg)
> inner_var = arg
> for i=1:length(inner_var)
> inner_var[i] = inner_var[i]^2
> end
> return inner_var
> end
> output=square(data)
>
> julia> print(data)
>
> [1,4,9]
>
> The data has been squared due to the local variable, which was initialized 
> at the data values, being squared. Now, if i wish to apply a different 
> function to the data, the result will be incorrect because the data has 
> been modified unintentionally.
>
> How long has Julia been doing this? Was this behavior intentional?
> Bradley
>
>
>

Re: [julia-users] Julia modifies variable outside of function when operating on different variable inside of function

[Isaiah Norton]

Julia passes arrays by reference and always has:
http://julia.readthedocs.org/en/latest/manual/arrays/#multi-dimensional-arrays

On Fri, Dec 26, 2014 at 2:49 PM, Bradley Setzler 
wrote:

> Hi,
>
> I cannot explain this behavior. I apply a function to a variable in the
> workspace, the function initializes its local variable at the workspace
> variable, then modifies the local variable and produces the desired output.
> However, it turns out the Julia modifies both the local and workspace
> variable with each operation on the local variable. Only the local variable
> is supposed to be modified.
>
> *This is very dangerous behavior, as Julia is modifying the data itself
> between performing operations on the data; the data itself is supposed to
> remain fixed between operations on it.*
>
> *Minimal working example:*
>
> data=[1,2,3]
> function square(arg)
> inner_var = arg
> for i=1:length(inner_var)
> inner_var[i] = inner_var[i]^2
> end
> return inner_var
> end
> output=square(data)
>
> julia> print(data)
>
> [1,4,9]
>
> The data has been squared due to the local variable, which was initialized
> at the data values, being squared. Now, if i wish to apply a different
> function to the data, the result will be incorrect because the data has
> been modified unintentionally.
>
> How long has Julia been doing this? Was this behavior intentional?
> Bradley
>
>
>

Re: [julia-users] Julia modifies variable outside of function when operating on different variable inside of function

[John Myles White]

This is aliasing. Almost all languages allow this.

 -- John

Sent from my iPhone

> On Dec 26, 2014, at 2:49 PM, Bradley Setzler  
> wrote:
> 
> Hi,
> 
> I cannot explain this behavior. I apply a function to a variable in the 
> workspace, the function initializes its local variable at the workspace 
> variable, then modifies the local variable and produces the desired output. 
> However, it turns out the Julia modifies both the local and workspace 
> variable with each operation on the local variable. Only the local variable 
> is supposed to be modified. 
> 
> This is very dangerous behavior, as Julia is modifying the data itself 
> between performing operations on the data; the data itself is supposed to 
> remain fixed between operations on it.
> 
> Minimal working example:
> 
> data=[1,2,3]
> function square(arg)
> inner_var = arg
> for i=1:length(inner_var)
> inner_var[i] = inner_var[i]^2
> end
> return inner_var
> end
> output=square(data)
> 
> julia> print(data)
> [1,4,9]
> 
> The data has been squared due to the local variable, which was initialized at 
> the data values, being squared. Now, if i wish to apply a different function 
> to the data, the result will be incorrect because the data has been modified 
> unintentionally.
> 
> How long has Julia been doing this? Was this behavior intentional?
> Bradley
> 
> 

[julia-users] Julia modifies variable outside of function when operating on different variable inside of function

[Bradley Setzler]

Hi,

I cannot explain this behavior. I apply a function to a variable in the 
workspace, the function initializes its local variable at the workspace 
variable, then modifies the local variable and produces the desired output. 
However, it turns out the Julia modifies both the local and workspace 
variable with each operation on the local variable. Only the local variable 
is supposed to be modified. 

*This is very dangerous behavior, as Julia is modifying the data itself 
between performing operations on the data; the data itself is supposed to 
remain fixed between operations on it.*

*Minimal working example:*

data=[1,2,3]
function square(arg)
inner_var = arg
for i=1:length(inner_var)
inner_var[i] = inner_var[i]^2
end
return inner_var
end
output=square(data)

julia> print(data)

[1,4,9]

The data has been squared due to the local variable, which was initialized 
at the data values, being squared. Now, if i wish to apply a different 
function to the data, the result will be incorrect because the data has 
been modified unintentionally.

How long has Julia been doing this? Was this behavior intentional?
Bradley

Re: [julia-users] Re: Julia v0.3.4

[Elliot Saba]

I've identified the problem.  fixup-libgfortran was sad because all the
consumers of libgfortran linked to lib{gfortran,quadmath,gcc_s} via the
"public" paths, which look like /usr/local/lib/gcc/4.9/xxx, whereas
libgfortran internally linked to libquadmath via a "private" path, which
looks like /usr/local/Cellar/gcc/4.9.1_2/lib/xxx.  I've since fixed up
fixup-libgfortran.sh and uploaded a new binary.
-E

On Fri, Dec 26, 2014 at 9:20 AM, Mike Innes  wrote:

> If it helps at all, I saw that exact issue a few days back, on 0.3 and
> 0.4. I had to delete and rebuild the openblas included in the Julia repo. I
> don't know exactly how the Julia 0.3.x builds work but a stale openblas may
> be causing issues.
>
> On 26 December 2014 at 16:13, Tony Kelman  wrote:
>>
>> Hm, strange. We should be including libquadmath.0.dylib in the mac
>> binaries, making them self-contained is the goal and we have some
>> libgfortran-related code that should be working. That error is definitely a
>> homebrew-ism, do you know whether you already had a libopenblas.dylib on
>> your path when you were getting the error? I'm not sure what order the
>> library paths get searched on mac, I would hope we search our bundled
>> libraries before whatever happens to be on the user's system. But looking
>> at the code for blas_vendor() in base/util.jl, we might be picking up
>> system openblas first.
>>
>>
>> On Friday, December 26, 2014 6:44:30 AM UTC-8, Ed Scheinerman wrote:
>>>
>>> I had a (fixable) problem installing on my Macbook Air. Upon first
>>> launch in a terminal window I got this error:
>>>
>>> Warning: error initializing module LinAlg:
>>>
>>> ErrorException("error compiling __init__: error compiling check_blas:
>>> error compiling openblas_get_config: could not load module libopenblas:
>>> dlopen(libopenblas.dylib, 1): Library not loaded:
>>> /usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/libquadmath.0.dylib
>>>
>>>   Referenced from: /Applications/Julia-0.3.4.app/
>>> Contents/Resources/julia/lib/julia//libgfortran.3.dylib
>>>
>>>   Reason: image not found")
>>>
>>>
>>> Julia then started up but (not surprisingly) it wouldn't invert a
>>> matrix. The reference to "cellar" suggested a homebrew fix so I did
>>>
>>> $ brew install homebrew/science/openblas
>>>
>>> and relaunched Julia. All seems fine now. My Julia 0.3.3 worked fine. I
>>> think making the distribution self-contained would be preferable. Or might
>>> there be something odd with my setup?
>>>
>>>
>>>
>>>
>>>
>>> On Friday, December 26, 2014 6:43:42 AM UTC-5, Elliot Saba wrote:

 Hello all!  The latest bugfix release of the 0.3.X Julia line has been
 released.  Binaries are available from the usual place
 , and as is typical with such things,
 please report all issues to either the issue tracker
 , or email this list.

 As this is a bugfix release, there are not too many new big-item
 features to announce, but if you are interested in the bugs fixed since
 0.3.3, this commit log
  should
 give you an idea of the effort put in by our team of backporters, as they
 faithfully toiled to bring you an extremely early 2015 Christmas present.

 This is a recommended upgrade for anyone using any of the previous
 0.3.x releases, and should act as a drop-in replacement for any of the
 0.3.x line. We would like to get feedback if someone has a correctly
 working program that doesn't work after this upgrade.

 Happy Hacking,
 -E

>>>

[julia-users] Puzzled by conflicting imports

[Petr Krysl]

Here are two methods in two different modules:

julia> methods(FEMMHeatDiffusionModule.distribloads)
# 1 method for generic function "distribloads":
distribloads(self::FEMMHeatDiffusion,assembler,geom::NodalField{Float64},temp::N
odalField{Float64},fi::ForceIntensity{Float64},m::Int64) at 
C:\Users\pkrysl\Docu
ments\GitHub\jfineale\./src/FEMMHeatDiffusionModule.jl:201

julia> methods(FEMMAcousticsModule.distribloads)
# 1 method for generic function "distribloads":
distribloads{T<:Number}(self::FEMMAcoustics,assembler,geom::NodalField{T<:Number
},P::NodalField{T<:Number},fi::ForceIntensity{T<:Number},m::Int64) at 
C:\Users\p
krysl\Documents\GitHub\jfineale\./src/FEMMAcousticsModule.jl:180

I cannot do "importall" on both modules at the same time: Julia complains 
about conflicting imports.
I have a trouble making sense of that: The functions clearly have different 
signatures, so shouldn't the compiler be able to make sense of them?

Any ideas?  Thanks!

Petr

Re: [julia-users] compilation problem on OS X for v0.4

[John Myles White]

No worries. Adding a cmake dependency is a big change for Julia.

 -- John

On Dec 26, 2014, at 2:13 PM, Ethan Anderes  wrote:

> Thanks John. I guess that was obvious from the error message. Sorry for the 
> noise.
> 
> --Ethan
> 
> On Friday, December 26, 2014 11:09:04 AM UTC-8, John Myles White wrote:
> You need to install cmake and make it available on your path: 
> http://www.cmake.org/download/
> 
>  -- John
> 
> On Dec 26, 2014, at 2:07 PM, Ethan Anderes  wrote:
> 
>> Hi Everyone:
>> 
>> I just decided to upgrade to Julia v0.4 and ran into the following error 
>> when trying to compile from source (I’m running Yosemite 10.10.1). Anyone 
>> else run into this problem and know how to fix it? —Cheers
>> 
>> == 
>> All 3 tests passed 
>> == 
>> Making check in cxx 
>> == 
>> All 0 tests passed 
>> == 
>> Making check in mpn 
>> Making check in mpz 
>> Making check in mpq 
>> Making check in mpf 
>> Making check in printf 
>> Making check in scanf 
>> Making check in rand 
>> Making check in cxx 
>> Making check in demos 
>> Making check in calc 
>> Making check in expr 
>> Making check in tune 
>> Making check in doc 
>> /bin/sh: cmake: command not found 
>> make[2]: *** [libgit2-0.21.3/build/Makefile] Error 127 
>> make[1]: *** [julia-release] Error 2 
>> make: *** [release] Error 2
>> ​
> 

Re: [julia-users] compilation problem on OS X for v0.4

[Ethan Anderes]

Thanks John. I guess that was obvious from the error message. Sorry for the 
noise.

--Ethan

On Friday, December 26, 2014 11:09:04 AM UTC-8, John Myles White wrote:
>
> You need to install cmake and make it available on your path: 
> http://www.cmake.org/download/
>
>  -- John
>
> On Dec 26, 2014, at 2:07 PM, Ethan Anderes  > wrote:
>
> Hi Everyone:
>
> I just decided to upgrade to Julia v0.4 and ran into the following error 
> when trying to compile from source (I’m running Yosemite 10.10.1). Anyone 
> else run into this problem and know how to fix it? —Cheers
>
> == 
> All 3 tests passed 
> == 
> Making check in cxx 
> == 
> All 0 tests passed 
> == 
> Making check in mpn 
> Making check in mpz 
> Making check in mpq 
> Making check in mpf 
> Making check in printf 
> Making check in scanf 
> Making check in rand 
> Making check in cxx 
> Making check in demos 
> Making check in calc 
> Making check in expr 
> Making check in tune 
> Making check in doc 
> /bin/sh: cmake: command not found 
> make[2]: *** [libgit2-0.21.3/build/Makefile] Error 127 
> make[1]: *** [julia-release] Error 2 
> make: *** [release] Error 2
>
> ​
>
>
>

Re: [julia-users] Rounding and the IEEE rule

[cdm]

thank you for the cross reference, H.W. Borchers ...

and thank you for the link out to issues, A. Noack.



as a fellow user, i appreciate having these.

best,

cdm



On Friday, December 26, 2014 6:49:30 AM UTC-8, Andreas Noack wrote:
>
> It can be difficult to remember all threads on the mailing list that 
> relate to changes made in Julia. Hence, it is very helpful when users make 
> cross references such that you are doing here. A link to the exact issues 
> on github would be even better so here they are
>
> https://github.com/JuliaLang/julia/issues/8750
>
> https://github.com/JuliaLang/julia/pull/9344
>

Re: [julia-users] compilation problem on OS X for v0.4

[John Myles White]

You need to install cmake and make it available on your path: 
http://www.cmake.org/download/

 -- John

On Dec 26, 2014, at 2:07 PM, Ethan Anderes  wrote:

> Hi Everyone:
> 
> I just decided to upgrade to Julia v0.4 and ran into the following error when 
> trying to compile from source (I’m running Yosemite 10.10.1). Anyone else run 
> into this problem and know how to fix it? —Cheers
> 
> == 
> All 3 tests passed 
> == 
> Making check in cxx 
> == 
> All 0 tests passed 
> == 
> Making check in mpn 
> Making check in mpz 
> Making check in mpq 
> Making check in mpf 
> Making check in printf 
> Making check in scanf 
> Making check in rand 
> Making check in cxx 
> Making check in demos 
> Making check in calc 
> Making check in expr 
> Making check in tune 
> Making check in doc 
> /bin/sh: cmake: command not found 
> make[2]: *** [libgit2-0.21.3/build/Makefile] Error 127 
> make[1]: *** [julia-release] Error 2 
> make: *** [release] Error 2
> ​

[julia-users] compilation problem on OS X for v0.4

[Ethan Anderes]

Hi Everyone:

I just decided to upgrade to Julia v0.4 and ran into the following error 
when trying to compile from source (I’m running Yosemite 10.10.1). Anyone 
else run into this problem and know how to fix it? —Cheers

== 
All 3 tests passed 
== 
Making check in cxx 
== 
All 0 tests passed 
== 
Making check in mpn 
Making check in mpz 
Making check in mpq 
Making check in mpf 
Making check in printf 
Making check in scanf 
Making check in rand 
Making check in cxx 
Making check in demos 
Making check in calc 
Making check in expr 
Making check in tune 
Making check in doc 
/bin/sh: cmake: command not found 
make[2]: *** [libgit2-0.21.3/build/Makefile] Error 127 
make[1]: *** [julia-release] Error 2 
make: *** [release] Error 2

​

[julia-users] Can't round Rational{Int} using new rounding functions

[Tomas Lycken]

I don't know if this is a problem with core Julia, with Compat.jl or with 
my own code, but I can't figure out how to get this working.

On Julia 0.3, I can do iround(1//2) without problems (yielding 1), but I 
can't figure out how to do this with the 0.4 method names and Compat: 

julia> using Compat

julia> @compat round(Int, 1//2)
ERROR: `iround` has no method matching iround(::Type{Int64}, 
::Rational{Int64})
 in round at /home/tlycken/.julia/v0.3/Compat/src/Compat.jl:45

Am I doing something wrong here, or should I file an issue? If I should, is 
the problem with Compat.jl or with core Julia?

Thanks,

// T

[julia-users] Re: Julia documentation is ready for translation/internationalization on Transifex!

[Waldir Pimenta]

Hi Ismael,

First of all, thanks for doing this :)

I am not sure if you announced your plans to work on this in advance, so 
sorry if I missed it and thus the opportunity to provide early feedback. 
The last time I saw the issue of translating the documentation using a 
translation platform being discussed, I mentioned my concerns about the 
choice of platform 
, 
particularly regarding two features I consider extremely useful: 
translation memory / machine translation (which ends up saving a lot of 
typing, as well as ensuring consistency), and the ability for users to 
choose their language fallback chain (e.g. a Portuguese user could pick 
Brazilian Portuguese, Galician, and Spanish as fallback languages), which 
again allows a much more efficient translation workflow and often help 
escaping ambiguity holes due to insufficient context.

IIRC Transifex doesn't provide these features, while e.g. Crowdin and 
TranslateWiki do. Have you considered either of them? Would it be feasible 
to change the platform at this time?

On Thursday, December 25, 2014 5:34:01 PM UTC, Ismael VC wrote:
>
> Merry Christmas everyone!
>
> I have an announcement and an invitation to make to the Julia community.
>
> Yesterday I finally finished seting-up, julialang docs on Transifex 
> (online crowdsourcing localization platform) something I wanted to do ever 
> since last year, but sadly never had time to actually invest on it, my 
> intention is to translate the docs to spanish, and also make an invitation 
> to anyone interested in helping me out or translating them to their native 
> language.
>
> You can see my setup here: 
> https://github.com/Ismael-VC/julia/tree/julia-translations/doc
>
> Please don't hesitate to ask me any question or give me advice I really 
> want to do this well. If any of you have experience with any of this I 
> would really really love to have a chat with you!
>
> ! I'm still testing the current setup (I don't know why `make gettext` 
> takes so much time, yesterday it was done in a breeze:
>
> [ismaelvc@toybox doc]$ time ./update_resources.sh 
> Enter passphrase for key '/home/ismaelvc/.ssh/id_rsa': 
> From github.com:JuliaLang/julia
>  * branchmaster -> FETCH_HEAD
> Already up-to-date.
> . /home/ismaelvc/julia/deps/julia-env/bin/activate && sphinx-build -b 
> gettext   . _build/locale
> Running Sphinx v1.2.3
> loading pickled environment... done
> building [gettext]: targets for 0 template files
> building [gettext]: targets for 56 source files that are out of date
> updating environment: 0 added, 2 changed, 0 removed
> reading sources... [ 50%] manual/faq 
>
> It just stays there (half an hour already ...tried several times). Anyway 
> that's only for updating resources, but I can get to work with what I 
> already  have.
>
> You can find the project here: 
> https://www.transifex.com/projects/p/julia-doc/
>
>
> Ismael VC
>
>  
>

Re: [julia-users] Re: Julia v0.3.4

[Mike Innes]

If it helps at all, I saw that exact issue a few days back, on 0.3 and 0.4.
I had to delete and rebuild the openblas included in the Julia repo. I
don't know exactly how the Julia 0.3.x builds work but a stale openblas may
be causing issues.

On 26 December 2014 at 16:13, Tony Kelman  wrote:
>
> Hm, strange. We should be including libquadmath.0.dylib in the mac
> binaries, making them self-contained is the goal and we have some
> libgfortran-related code that should be working. That error is definitely a
> homebrew-ism, do you know whether you already had a libopenblas.dylib on
> your path when you were getting the error? I'm not sure what order the
> library paths get searched on mac, I would hope we search our bundled
> libraries before whatever happens to be on the user's system. But looking
> at the code for blas_vendor() in base/util.jl, we might be picking up
> system openblas first.
>
>
> On Friday, December 26, 2014 6:44:30 AM UTC-8, Ed Scheinerman wrote:
>>
>> I had a (fixable) problem installing on my Macbook Air. Upon first launch
>> in a terminal window I got this error:
>>
>> Warning: error initializing module LinAlg:
>>
>> ErrorException("error compiling __init__: error compiling check_blas:
>> error compiling openblas_get_config: could not load module libopenblas:
>> dlopen(libopenblas.dylib, 1): Library not loaded:
>> /usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/libquadmath.0.dylib
>>
>>   Referenced from: /Applications/Julia-0.3.4.app/
>> Contents/Resources/julia/lib/julia//libgfortran.3.dylib
>>
>>   Reason: image not found")
>>
>>
>> Julia then started up but (not surprisingly) it wouldn't invert a matrix.
>> The reference to "cellar" suggested a homebrew fix so I did
>>
>> $ brew install homebrew/science/openblas
>>
>> and relaunched Julia. All seems fine now. My Julia 0.3.3 worked fine. I
>> think making the distribution self-contained would be preferable. Or might
>> there be something odd with my setup?
>>
>>
>>
>>
>>
>> On Friday, December 26, 2014 6:43:42 AM UTC-5, Elliot Saba wrote:
>>>
>>> Hello all!  The latest bugfix release of the 0.3.X Julia line has been
>>> released.  Binaries are available from the usual place
>>> , and as is typical with such things,
>>> please report all issues to either the issue tracker
>>> , or email this list.
>>>
>>> As this is a bugfix release, there are not too many new big-item
>>> features to announce, but if you are interested in the bugs fixed since
>>> 0.3.3, this commit log
>>>  should
>>> give you an idea of the effort put in by our team of backporters, as they
>>> faithfully toiled to bring you an extremely early 2015 Christmas present.
>>>
>>> This is a recommended upgrade for anyone using any of the previous 0.3.x
>>> releases, and should act as a drop-in replacement for any of the 0.3.x
>>> line. We would like to get feedback if someone has a correctly working
>>> program that doesn't work after this upgrade.
>>>
>>> Happy Hacking,
>>> -E
>>>
>>

[julia-users] Re: Julia documentation is ready for translation/internationalization on Transifex!

[Ismael VC]

Thank you very much Ivar!

There has been requests for adding more languages to the project already, 
Russian and Portuguese, but actually translating them will be 
responsibility of whomever works for them, I can only focus in Spanish.

I'm well aware that the docs aren't static, which is in fact one of the 
reason that I have studied and planned the way to do it and waited up until 
now to actually start with the translation (I don't want to wait until it 
reaches 1.0 or something like that). You can check out the repo I'm working 
on here:

https://github.com/Ismael-VC/julia/tree/julia-translations/doc 

And the sphinx internationalization page: 

http://sphinx-doc.org/latest/intl.html


I'll try to describe the workflow briefly.

   1. Periodically pull changes from Julia
   2. use gettet to compile a catalog of pot iles
   3. update the pot files in transifex from these files

All while one keeps translating the files and idealy, once one finishes 
translating "all", then it's just a matter of translating only the 
changed/new strings from the update at a time.

I do it with this script (which I'm still testing): 
https://github.com/Ismael-VC/julia/blob/julia-translations/doc/update_resources.sh

When the `pot` files are translated, they are pulled back again, 
transformed into `mo` files, and then it's the same (using 
`transifex-client`).

I'm using `sphinx-intl` and `transifex-client`, which let me work towards 
continuos internationalization and localization, and transifex enables us 
to work together in the same platform, without having each project doing 
their own setup.

I just want for people to start translating, and focus on that, instead on 
focusing on managing the resources, separately.

I decided to start now, because even while it's true that the docs are a 
moving target, it's not like it's a major rewrite of it all the time. And I 
want excellent and up to date documentation available in my language with 
the exact same look and feel as the original version, so pherhaps one day 
we could integrate it.

Sorry for my english I'm not that good at it. :P


Cheers

Ismael VC

[julia-users] Re: Julia v0.3.4

[Tony Kelman]

Hm, strange. We should be including libquadmath.0.dylib in the mac 
binaries, making them self-contained is the goal and we have some 
libgfortran-related code that should be working. That error is definitely a 
homebrew-ism, do you know whether you already had a libopenblas.dylib on 
your path when you were getting the error? I'm not sure what order the 
library paths get searched on mac, I would hope we search our bundled 
libraries before whatever happens to be on the user's system. But looking 
at the code for blas_vendor() in base/util.jl, we might be picking up 
system openblas first.


On Friday, December 26, 2014 6:44:30 AM UTC-8, Ed Scheinerman wrote:
>
> I had a (fixable) problem installing on my Macbook Air. Upon first launch 
> in a terminal window I got this error:
>
> Warning: error initializing module LinAlg:
>
> ErrorException("error compiling __init__: error compiling check_blas: 
> error compiling openblas_get_config: could not load module libopenblas: 
> dlopen(libopenblas.dylib, 1): Library not loaded: 
> /usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/libquadmath.0.dylib
>
>   Referenced from: 
> /Applications/Julia-0.3.4.app/Contents/Resources/julia/lib/julia//libgfortran.3.dylib
>
>   Reason: image not found")
>
>
> Julia then started up but (not surprisingly) it wouldn't invert a matrix. 
> The reference to "cellar" suggested a homebrew fix so I did 
>
> $ brew install homebrew/science/openblas
>
> and relaunched Julia. All seems fine now. My Julia 0.3.3 worked fine. I 
> think making the distribution self-contained would be preferable. Or might 
> there be something odd with my setup?
>
>
>
>
>
> On Friday, December 26, 2014 6:43:42 AM UTC-5, Elliot Saba wrote:
>>
>> Hello all!  The latest bugfix release of the 0.3.X Julia line has been 
>> released.  Binaries are available from the usual place 
>> , and as is typical with such things, 
>> please report all issues to either the issue tracker 
>> , or email this list.
>>
>> As this is a bugfix release, there are not too many new big-item 
>> features to announce, but if you are interested in the bugs fixed since 
>> 0.3.3, this commit log 
>>  should give 
>> you an idea of the effort put in by our team of backporters, as they 
>> faithfully toiled to bring you an extremely early 2015 Christmas present.
>>
>> This is a recommended upgrade for anyone using any of the previous 0.3.x 
>> releases, and should act as a drop-in replacement for any of the 0.3.x 
>> line. We would like to get feedback if someone has a correctly working 
>> program that doesn't work after this upgrade.
>>
>> Happy Hacking,
>> -E
>>
>

Re: [julia-users] Rounding and the IEEE rule

[Andreas Noack]

It can be difficult to remember all threads on the mailing list that relate
to changes made in Julia. Hence, it is very helpful when users make cross
references such that you are doing here. A link to the exact issues on
github would be even better so here they are

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

https://github.com/JuliaLang/julia/pull/9344


2014-12-26 13:14 GMT+01:00 Hans W Borchers :

> I started this thread long time ago with a question about rounding rules
> and the IEEE floating point standard. I felt like being criticized for even
> thinking Julia could follow the "round-to-even" rule. Now I learn that
> Julia version 0.4 will apply this rule (as default?).
>
> We had similar discussions about whether Julia should use the "+" or ".+"
> operator for adding scalars to vectors. One strong argument was that,
> mathematically, there is no addition of scalars to vectors. Since then
> Julia has switched back to using "+" again.
>
> I would wish the replies were not that strict when questions or requests
> come up for a different behavior of Julia operators or functions. And
> because mailing lists are also an information source for users, it may be
> appropriate to mention such changes at the end of threads like this one.
>
>
> On Thursday, June 5, 2014 7:18:43 PM UTC+2, Stefan Karpinski wrote:
>>
>> Right, calling one particular rounding style round_ieee would be very odd
>> – the IEEE 754 spec lists various functions for rounding floats to integers
>> and doesn't favor any of them over the others. This is unlike rounding
>> modes where it does indicate that the default mode should be ties to even.
>>
>>
>> On Thu, Jun 5, 2014 at 8:42 AM, Simon Byrne  wrote:
>>
>>> On Thursday, 5 June 2014 09:47:21 UTC+1, Hans W Borchers wrote:

 What I would like to have is a function round_ieee(x,n) such that

 julia> round_ieee(0.025, 2)
 0.02

 Can I do this somehow with with_rounding() do ... end ?

>>>
>>> Not generally: the IEEE notions of even and odd only pertain to binary
>>> arithmetic (as determined by the last bit of the mantissa), trying to force
>>> this notion into approximate decimal representations is going to cause all
>>> sorts of confusion: technically the Float64 represented by 0.025 is
>>> actually 1.39e-18 larger than the exact 0.025, so should it be rounded to
>>> 0.03 instead?
>>>
>>> The IEEE754 spec itself only defines explicit rounding (as opposed to
>>> rounding after calculations) to integers (section 5.9 for those following
>>> along at home). According to the standard, IEEE754 compatible languages are
>>> required to provide methods for the following:
>>> a) round to nearest integral: ties to even
>>> b) round to nearest integral: ties to away (round)
>>> c) round to integral toward zero (trunc)
>>> d) round to integral toward positive (ceil)
>>> e) round to integral toward negative (floor)
>>> f) round to integral using rounding mode
>>>
>>> At the moment, I don't think we implement (a) or (f).
>>>
>>
>>

[julia-users] Re: Julia v0.3.4

[Ed Scheinerman]

I had a (fixable) problem installing on my Macbook Air. Upon first launch 
in a terminal window I got this error:

Warning: error initializing module LinAlg:

ErrorException("error compiling __init__: error compiling check_blas: error 
compiling openblas_get_config: could not load module libopenblas: 
dlopen(libopenblas.dylib, 1): Library not loaded: 
/usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/libquadmath.0.dylib

  Referenced from: 
/Applications/Julia-0.3.4.app/Contents/Resources/julia/lib/julia//libgfortran.3.dylib

  Reason: image not found")


Julia then started up but (not surprisingly) it wouldn't invert a matrix. 
The reference to "cellar" suggested a homebrew fix so I did 

$ brew install homebrew/science/openblas

and relaunched Julia. All seems fine now. My Julia 0.3.3 worked fine. I 
think making the distribution self-contained would be preferable. Or might 
there be something odd with my setup?





On Friday, December 26, 2014 6:43:42 AM UTC-5, Elliot Saba wrote:
>
> Hello all!  The latest bugfix release of the 0.3.X Julia line has been 
> released.  Binaries are available from the usual place 
> , and as is typical with such things, 
> please report all issues to either the issue tracker 
> , or email this list.
>
> As this is a bugfix release, there are not too many new big-item features 
> to announce, but if you are interested in the bugs fixed since 0.3.3, this 
> commit log  
> should 
> give you an idea of the effort put in by our team of backporters, as they 
> faithfully toiled to bring you an extremely early 2015 Christmas present.
>
> This is a recommended upgrade for anyone using any of the previous 0.3.x 
> releases, and should act as a drop-in replacement for any of the 0.3.x 
> line. We would like to get feedback if someone has a correctly working 
> program that doesn't work after this upgrade.
>
> Happy Hacking,
> -E
>

Re: [julia-users] Rounding and the IEEE rule

[Hans W Borchers]

I started this thread long time ago with a question about rounding rules 
and the IEEE floating point standard. I felt like being criticized for even 
thinking Julia could follow the "round-to-even" rule. Now I learn that 
Julia version 0.4 will apply this rule (as default?).

We had similar discussions about whether Julia should use the "+" or ".+" 
operator for adding scalars to vectors. One strong argument was that, 
mathematically, there is no addition of scalars to vectors. Since then 
Julia has switched back to using "+" again.

I would wish the replies were not that strict when questions or requests 
come up for a different behavior of Julia operators or functions. And 
because mailing lists are also an information source for users, it may be 
appropriate to mention such changes at the end of threads like this one.


On Thursday, June 5, 2014 7:18:43 PM UTC+2, Stefan Karpinski wrote:
>
> Right, calling one particular rounding style round_ieee would be very odd 
> – the IEEE 754 spec lists various functions for rounding floats to integers 
> and doesn't favor any of them over the others. This is unlike rounding 
> modes where it does indicate that the default mode should be ties to even.
>
>
> On Thu, Jun 5, 2014 at 8:42 AM, Simon Byrne  > wrote:
>
>> On Thursday, 5 June 2014 09:47:21 UTC+1, Hans W Borchers wrote:
>>>
>>> What I would like to have is a function round_ieee(x,n) such that
>>>
>>> julia> round_ieee(0.025, 2)
>>> 0.02
>>>
>>> Can I do this somehow with with_rounding() do ... end ?
>>>
>>
>> Not generally: the IEEE notions of even and odd only pertain to binary 
>> arithmetic (as determined by the last bit of the mantissa), trying to force 
>> this notion into approximate decimal representations is going to cause all 
>> sorts of confusion: technically the Float64 represented by 0.025 is 
>> actually 1.39e-18 larger than the exact 0.025, so should it be rounded to 
>> 0.03 instead?
>>
>> The IEEE754 spec itself only defines explicit rounding (as opposed to 
>> rounding after calculations) to integers (section 5.9 for those following 
>> along at home). According to the standard, IEEE754 compatible languages are 
>> required to provide methods for the following:
>> a) round to nearest integral: ties to even
>> b) round to nearest integral: ties to away (round)
>> c) round to integral toward zero (trunc)
>> d) round to integral toward positive (ceil)
>> e) round to integral toward negative (floor)
>> f) round to integral using rounding mode 
>>
>> At the moment, I don't think we implement (a) or (f).
>>
>
> 

[julia-users] Julia v0.3.4

[Elliot Saba]

Hello all!  The latest bugfix release of the 0.3.X Julia line has been
released.  Binaries are available from the usual place
, and as is typical with such things,
please report all issues to either the issue tracker
, or email this list.

As this is a bugfix release, there are not too many new big-item features
to announce, but if you are interested in the bugs fixed since 0.3.3, this
commit log  should
give you an idea of the effort put in by our team of backporters, as they
faithfully toiled to bring you an extremely early 2015 Christmas present.

This is a recommended upgrade for anyone using any of the previous 0.3.x
releases, and should act as a drop-in replacement for any of the 0.3.x
line. We would like to get feedback if someone has a correctly working
program that doesn't work after this upgrade.

Happy Hacking,
-E

Re: [julia-users] Re: Revision release notes

[Elliot Saba]

I should point out that although Tony answered your question for looking at
0.3.1 vs. 0.3.0, we are just now releasing 0.3.4, so you can substitute the
0.3.1 with 0.3.4 in the URL linked above for the same effect.
-E

On Fri, Dec 26, 2014 at 3:03 AM, Tony Kelman  wrote:

> We have not been doing a very good job of updating NEWS.md on the
> release-0.3 branch, so there's nothing specific. Lots of bug fixes have
> been getting backported, you can compare the commit list via
> https://github.com/JuliaLang/julia/compare/v0.3.0...v0.3.1 or similar
> url's.
>
> On Thursday, December 25, 2014 10:14:59 PM UTC-8, Eric Davies wrote:
>>
>> Are there release notes for 0.3.1+? Looking at NEWS.md, it seems that
>> only 0.3.0 appears.
>>
>

[julia-users] Re: Revision release notes

[Tony Kelman]

We have not been doing a very good job of updating NEWS.md on the 
release-0.3 branch, so there's nothing specific. Lots of bug fixes have 
been getting backported, you can compare the commit list 
via https://github.com/JuliaLang/julia/compare/v0.3.0...v0.3.1 or similar 
url's.

On Thursday, December 25, 2014 10:14:59 PM UTC-8, Eric Davies wrote:
>
> Are there release notes for 0.3.1+? Looking at NEWS.md, it seems that only 
> 0.3.0 appears. 
>

[julia-users] Re: Revision release notes

[Ivar Nesje]

No, the release-0.3 branch (that we tag 0.3.x releases from) only receives 
bug fixes that (hopefully) doesn't break backward compatibility. Everything 
is captured in the "Numerous bugfixes" bullet.

You can look at the list of commits 
 if you 
need more specific what was actually fixed.

Ivar

kl. 07:14:59 UTC+1 fredag 26. desember 2014 skrev Eric Davies følgende:
>
> Are there release notes for 0.3.1+? Looking at NEWS.md, it seems that only 
> 0.3.0 appears. 
>

[julia-users] Re: Julia documentation is ready for translation/internationalization on Transifex!

[Ivar Nesje]

This is great!

transifex looks good, and I wish you the best of luck. I'm no use in 
Spanish or German, but if I see a great (updated) manual in a few languages 
in 6 month time, I might look into translating to Norwegian.

I just want to give a word of warning that the Julia documentation isn't 
static, so you will need some simple (and partially automated) way of 
keeping everything up to date.

Ivar

kl. 22:39:47 UTC+1 torsdag 25. desember 2014 skrev Ismael VC følgende:
>
>
> 
> Here is a screenshot of the transifex editor in action, I wonder if it 
> works from a smartphone!
>
>
>

Re: [julia-users] Multiple dispatch on values, not types

[Mauro]

How about making a type for your solver methods like so

immutable Method{Name}
 para1::Int
 para2::Float64
 ...
end

method_a = Method{:A}(p1, p2, ...)
method_b = Method{:B}(p1, p2, ...)

# Then the solve function could be

function solve(data::DataFrame, method::Method{:A})
# common setup
out = setup(data)
# solve for method A
...
# common finish
out = finish(out)
end

function solve(data::DataFrame, method::Method{:B})
# common setup
out = setup(data)
# solve for method B
...
# common finish
out = finish(out)
end

If your Methods do not need any data, just make a type without any
fields

immutable Method{Name} end
method_a = Method{:A}()
method_b = Method{:B}()

PS: Style tip: functions and variables are in lower case by convention.
Types are capitalised.

On Fri, 2014-12-26 at 11:10, Oliver Pewter  wrote:
> Hello,
> I have a function, Solve(Data::DataFrame, Method::String), where I do some 
> math operations on Data, but these operations are vastly different for each 
> Method. I call one function, Solve, because I don't want to obfuscate my 
> code when I'm calling this.
>
> So that leaves me with sorting out the code within Solve(). The way it's 
> done currently is
>
> function Solve(...)
> # prep stuff, common to all methods
>
> if Method == "MethodA"
> # long piece of code
>
> else if Method == "MethodB"
> # another long piece of code
>
> # [five other methods]
>
> end
>
>
> # finish and return stuff
> end
>
> My question is then what's the best way to organise the code? I could
>
> 1. Include an external file instead of each [long piece of code] bit. 
> Doesn't seem very clean.
> 2. Have functions MethodA(), MethodB() etc. and call them in each if/elseif 
> statement
> 3. Have the functions from #2 and use some sort of eval/call or something 
> instead of the whole if-else bit. So just call the right function based on 
> the argument Method.
> 4. Have separate and completely self contained functions MethodA, MethodB 
> etc. and call them directly from the code where I call Solve(). This is not 
> ideal since the method is contained in the Method string and I'd have to do 
> all the if-else charade every time.
>
> The reason the thread is called 'multiple dispatch on values' is because 
> the ideal way, for me, would be to have something like 
> Solve(Data::DataFrame, Method::MethodA), Solve(Data::DataFrame, 
> Method::MethodB) etc. (where MethodA and MethodB are values, not types) So 
> I could have separate methods for my solution, wouldn't worry about all the 
> if-else mess.
>
> So my code works just fine, I'm just asking about best practice tips. Sorry 
> if the description above is unclear.
>
> Thanks,
> Oli

[julia-users] Multiple dispatch on values, not types

[Oliver Pewter]

Hello,
I have a function, Solve(Data::DataFrame, Method::String), where I do some 
math operations on Data, but these operations are vastly different for each 
Method. I call one function, Solve, because I don't want to obfuscate my 
code when I'm calling this.

So that leaves me with sorting out the code within Solve(). The way it's 
done currently is

function Solve(...)
# prep stuff, common to all methods

if Method == "MethodA"
# long piece of code

else if Method == "MethodB"
# another long piece of code

# [five other methods]

end


# finish and return stuff
end

My question is then what's the best way to organise the code? I could

1. Include an external file instead of each [long piece of code] bit. 
Doesn't seem very clean.
2. Have functions MethodA(), MethodB() etc. and call them in each if/elseif 
statement
3. Have the functions from #2 and use some sort of eval/call or something 
instead of the whole if-else bit. So just call the right function based on 
the argument Method.
4. Have separate and completely self contained functions MethodA, MethodB 
etc. and call them directly from the code where I call Solve(). This is not 
ideal since the method is contained in the Method string and I'd have to do 
all the if-else charade every time.

The reason the thread is called 'multiple dispatch on values' is because 
the ideal way, for me, would be to have something like 
Solve(Data::DataFrame, Method::MethodA), Solve(Data::DataFrame, 
Method::MethodB) etc. (where MethodA and MethodB are values, not types) So 
I could have separate methods for my solution, wouldn't worry about all the 
if-else mess.

So my code works just fine, I'm just asking about best practice tips. Sorry 
if the description above is unclear.

Thanks,
Oli

[julia-users] Re: Why doesn't Dict() accept an output from zip?

[Ismael VC]

You'll need to use `@compat` in v0.3.3:

julia> Dict(zip("abc","123"))
ERROR: `Dict{K,V}` has no method matching Dict{K,V}(::Zip2{ASCIIString,
ASCIIString})

julia> using Compat

julia> @compat Dict(zip("abc","123"))
Dict{Char,Char} with 3 entries:
  'c' => '3'
  'b' => '2'
  'a' => '1'

Re: [julia-users] basic scoping question, and creating locals

[Milan Bouchet-Valat]

Le jeudi 25 décembre 2014 à 23:32 -0800, ele...@gmail.com a écrit :
> I had thought that top level == global, but Milan's statement:
> 
> 
> > No, `global n` is only needed when `n` is in the global scope. Here `n` 
> > is not global, it's local to the enclosing scope.
> 
> 
> suggests its not the case.  Thats why I suggested the manual needs to
> clarify that if it is the case.
Actually what I meant is that `n` is here *also* local to the enclosing
scope, the enclosing scope being the global scope. Thus you don't *need*
to state `global n`. This happens because you're executing code at the
top-level.

(At least that's my understanding of how it works...)


Regards

> 
> Cheers
> Lex
> 
> On Friday, December 26, 2014 4:41:41 PM UTC+10, jgabri...@gmail.com
> wrote:
> On Wednesday, December 24, 2014 6:08:51 PM UTC-5,
> ele...@gmail.com wrote:
> 
> On Thursday, December 25, 2014 8:29:45 AM UTC+10,
> Milan Bouchet-Valat wrote:
> Le mercredi 24 décembre 2014 à 10:21 -0800,
> jgabri...@gmail.com a 
> écrit : 
> 
> > 
> > ~~~julia 
> > #!/usr/bin/julia 
> > 
> > n = 1  # top-level variable, aka global 
> 
> 
> I think the thing missing from the manual is if this
> assignment does in fact create a global, or a name in
> some sort of file scope?
> 
> 
> 
> I'd just assumed that a global in Julia is a variable defined
> at file-scope (i.e., top-level). Is that indeed the case?
> 
> 

[julia-users] warnings including module multiple times

[Kuba Roth]

Hi there,
I'd like to load a custom module from a custom location. In order to do 
this via import/using I need to first put include(moduleFile.jl) statement.
Every time I have include() in more then one file I get: Warning: replacing 
module.

The custom module is in the same location as my main file and the directory 
where files are located are not in the LOAD_PATH.  
If I omit "include" this leads me to a "not found" error.

Is there any kind of include guards I need to add to silent this warning? 
Or perhaps there is a better way to work load modules from custom 
locations? Can you please provide some guidelines. 

Thanks,
kuba