[julia-users] Re: Starting Julia with Julia -p 2 provides 1 worker

[Iacopo Poli]

Calling *addprocs()* from REPL with for example *CPU_CORES* as argument 
returns 5 procs and 4 workers as expected, CPU_CORES returns 4 (physical 
cores are 2, but logical ones are 4). Also *rmprocs(n) *works fine, it lets 
me remove all procs but the first as I would expect.

Il giorno mercoledì 20 aprile 2016 23:07:57 UTC+2, Greg Plowman ha scritto:
>
> Sorry, I can't really help you with command line julia -p 2
> But what happens when you call addprocs() from REPL?
> Also, what is the value of CPU_CORES (typed at REPL)?
>
>

Re: [julia-users] Creating symbols

[Tomas Lycken]

I am all for changing this, but in the specific case of symbol/Symbol this is 
going to be massively breaking, and even if the fix is pretty simple (applying 
s/symbol\(/Symbol\(/ probably fixes 99% of the code) the timing needs to be 
right. 

What other cases are there of such functions that should be merged into 
constructors? Is there an issue to track them? 

Also, when is a good time to introduce such a change?  Should they be tackled 
at the same time, or at a different one? 

I'm willing to pitch in some time to help here, if the timing works out.

// T 

[julia-users] Re: Starting Julia with Julia -p 2 provides 1 worker

[Iacopo Poli]

Calling *addprocs()* from REPL with for example *CPU_CORES* as argument 
returns 5 procs and 4 workers as expected, CPU_CORES returns 4 (physical 
cores are 2, but logical ones are 4). Also *rmprocs() *works fine, removing 
all procs but the first.

Il giorno mercoledì 20 aprile 2016 23:07:57 UTC+2, Greg Plowman ha scritto:
>
> Sorry, I can't really help you with command line julia -p 2
> But what happens when you call addprocs() from REPL?
> Also, what is the value of CPU_CORES (typed at REPL)?
>
>

[julia-users] Grant funding and Julia Computing?

[Sheehan Olver]

Has anyone included "Julia Computing" charges in a grant proposal?  Is this 
something that should be encouraged?

 I'm thinking of including this in my next grant proposal, maybe for some 
specific goal.  For example, I could include something along the lines of 
"ApproxFun v0.5 compatibility", and then I could use grant funds to pay 
Julia Computing  to fix the relevant issue:

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


Or it could be something broader: an HPC grant could include "Thread 
support in Julia" / "OpenCL support in Julia".  

[julia-users] Multi capable sorted/hash maps

[fblscode]

Hi all,
I put together a multi capable sorted set based on a skip list and a 
complementary hash adapter.
SkipMap is currently about as fast as DataStructures.SortedDict, has per 
key multi/unique- and separate insert/update semantics. HashMap is about 
ten times slower than a regular Dict, and inherits everything but range 
functionality from SkipMap. SkipMaps are created with a specific number of 
levels, HashMaps with number of slots and levels; resize! is cooking atm. 
No fancy examples yet, only tests so far.

https://github.com/fblscode/Fbls.jl/blob/master/SkipMap.jl
https://github.com/fblscode/Fbls.jl/blob/master/SkipMapTests.jl

https://github.com/fblscode/Fbls.jl/blob/master/HashMap.jl
https://github.com/fblscode/Fbls.jl/blob/master/HashMapTests.jl

Peace

[julia-users] Re: a'*b and svds for custom operators

['Greg Plowman' via julia-users]

>
>
> 3. Any other methods I should implement for my operator?
>
>
 http://docs.julialang.org/en/release-0.4/manual/interfaces/#abstract-arrays

[julia-users] Re: a'*b and svds for custom operators

['Greg Plowman' via julia-users]

On Thursday, April 21, 2016 at 11:17:32 AM UTC+10, Madeleine Udell wrote:
>
> Hi, 
>
> I'm trying to define my own custom operator type that will allow me to 
> implement my own * and '* operations for use inside eigenvalue or singular 
> value routines like eigs and svds. But I'm having trouble making this work.
>
> Here's a simple example reimplementing matrix multiplication, with 
> questions sprinkled as comments in the code.
>
> ---
>
> import Base: *, Ac_mul_b, size
> # Ac_mul_b doesn't seem to live in base; where does it live?
>
> It's Ac_mul_B (capital B)
 

> type MyOperator
> A::Array{Float64}
> end
>

type can subtype from AbstractMatrix
can also parameterise to use concrete Array

type MyOperator{T} <: AbstractMatrix{T}
A::Matrix{T}
end
 

>
> o = MyOperator(randn(5,4))
>
> *(o::MyOperator, v::AbstractVector) = (println("using custom * method"); 
> o.A*v)
> o*rand(4) # this works
>
> Ac_mul_b(o::MyOperator, v::AbstractVector) = (println("using custom '* 
> method"); o.A'*b)
>

 Ac_mul_B(o::MyOperator, v::AbstractVector) = (println("using custom '* 
method"); Ac_mul_B(o.A, v))

o'*rand(5) # this doesn't work; instead, it calls ctranspose(o)*v, which is 
> not what I want
>
> size(o::MyOperator) = size(o.A)
> size(o::MyOperator, i::Int) = size(o)[i]
>
> svds(o, nsv=1)
> # this doesn't work; svds requires a `zero` method for the parametrized 
> type of my operator. If I know the type will always be Float64, what's the 
> easiest way to tell this to svds?
>

you get zero() for free when MyOperator is a subtype of AbstractMatrix
 

>
> ---
>
> Questions, collected:
> 1. Ac_mul_b doesn't seem to live in base; where does it live? Or should I 
> be extending a different function? This causes o'*v to call 
> ctranspose(o)*v, which is not what I want. (The default ctranspose for new 
> types seems to be the identity.)
> 2. svds requires a `zero` method for the parametrized type of my operator. 
> If I know the type will always be Float64, what's the easiest way to tell 
> this to svds? Here's the eigs/svds 
>  
> code, but I haven't been able to track down enough information on 
> AbstractMatrices and parametrized types to make this work.
> 3. Any other methods I should implement for my operator?
>
> Thanks!
> Madeleine
>


import Base: *, Ac_mul_B, size, show

type MyOperator{T} <: AbstractMatrix{T}
A::Matrix{T}
end

*(o::MyOperator, v::AbstractVector) = (println("using custom * method"); 
o.A*v)
Ac_mul_B(o::MyOperator, v::AbstractVector) = (println("using custom '* 
method"); Ac_mul_B(o.A, v))
size(o::MyOperator) = size(o.A)

o = MyOperator(randn(5,4))
o * rand(4)
o' * rand(5)
svds(o, nsv=1)

Re: [julia-users] round(Int, typemin(Float64))

[Yichao Yu]

On Wed, Apr 20, 2016 at 9:32 PM, K leo  wrote:
> julia> round(Int, typemin(Float64))
> ERROR: InexactError()
>  in round at ./float.jl:181
>
> Should this be handled this way?  Or is it better to make round(Int,
> typemin(Float64)) to be typemin(Int)?

That's not how it (rounding to the closest integer) is defined.

>
> Also, why is typemin(Float64) -Inf but typemin(Int) -9223372036854775808?
> Can typemin(Int) be made -Inf as well?

It doesn't exist as a machine Int.

>

Re: [julia-users] Options for constructing a 3D surface from a point cloud

[Chris]

I am hoping for a solution I can use from Julia itself, but this is a good 
idea, thanks.

On Wednesday, April 20, 2016 at 5:38:20 PM UTC-4, Kristoffer Carlsson wrote:
>
> You could use WriteVTK.jl and render the point cloud in Paraview. 

[julia-users] round(Int, typemin(Float64))

[K leo]

julia> round(Int, typemin(Float64))
ERROR: InexactError()
 in round at ./float.jl:181

Should this be handled this way?  Or is it better to make round(Int,
typemin(Float64)) to be typemin(Int)?

Also, why is typemin(Float64) -Inf but typemin(Int) -9223372036854775808?
Can typemin(Int) be made -Inf as well?

[julia-users] a'*b and svds for custom operators

[Madeleine Udell]

Hi, 

I'm trying to define my own custom operator type that will allow me to 
implement my own * and '* operations for use inside eigenvalue or singular 
value routines like eigs and svds. But I'm having trouble making this work.

Here's a simple example reimplementing matrix multiplication, with 
questions sprinkled as comments in the code.

---

import Base: *, Ac_mul_b, size
# Ac_mul_b doesn't seem to live in base; where does it live?

type MyOperator
A::Array{Float64}
end

o = MyOperator(randn(5,4))

*(o::MyOperator, v::AbstractVector) = (println("using custom * method"); 
o.A*v)
o*rand(4) # this works

Ac_mul_b(o::MyOperator, v::AbstractVector) = (println("using custom '* 
method"); o.A'*b)
o'*rand(5) # this doesn't work; instead, it calls ctranspose(o)*v, which is 
not what I want

size(o::MyOperator) = size(o.A)
size(o::MyOperator, i::Int) = size(o)[i]

svds(o, nsv=1)
# this doesn't work; svds requires a `zero` method for the parametrized 
type of my operator. If I know the type will always be Float64, what's the 
easiest way to tell this to svds?

---

Questions, collected:
1. Ac_mul_b doesn't seem to live in base; where does it live? Or should I 
be extending a different function? This causes o'*v to call 
ctranspose(o)*v, which is not what I want. (The default ctranspose for new 
types seems to be the identity.)
2. svds requires a `zero` method for the parametrized type of my operator. 
If I know the type will always be Float64, what's the easiest way to tell 
this to svds? Here's the eigs/svds 
 
code, but I haven't been able to track down enough information on 
AbstractMatrices and parametrized types to make this work.
3. Any other methods I should implement for my operator?

Thanks!
Madeleine

Re: [julia-users] In these two ways to "create functions", which one is a better way?

[Po Choi]

Thanks. I need to pass a set of orthogonal functions and coefficients into 
my routines. So I want to know the best practice in Julia to do this.

On Wednesday, April 20, 2016 at 12:51:47 AM UTC-7, David P. Sanders wrote:
>
> If this is your actual use case, then I suggest checking out the 
> Polynomials.jl package. 
>
> In particular, there is a more efficient algorithm (Horner's algorithm) 
> that you can use to actually evaluate such a function. 
>

Re: [julia-users] Re: are macros hygienic?

[Yichao Yu]

On Wed, Apr 20, 2016 at 6:12 PM, Didier Verna  wrote:
> Yichao Yu  wrote:
>
>>> julia> macro finish()
>>>  :(t)
>>>end
>>> julia> macroexpand(:(@finish()))
>>> :t
>>>
>>> as expected. BTW, this is not really "global", as the manual says. It
>>> really is "outer scope".
>>
>> This is a bug, (the one I linked). It should be `Main.t` (or whatever
>> module that the macro is defined in).
>
>   So you mean that if I do this:
>
>   t = 10
>   function foo()
> t = 5
> @finish()
>   end
>
>   I will presently get 5 but when the bug is fixed, I will get 10 (or
>   whatever value t had in the macro definition's module) ?

Correct. (Assuming @finish is defined as returning :t)

>
>
>> This should be `bar(Main.t)`. use as function argument name is talking
>> about defining a function.
>
>   Oh, right. Thanks.
>
> --
> ELS'16 registration open! http://www.european-lisp-symposium.org
>
> Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: [julia-users] Re: are macros hygienic?

[Didier Verna]

Yichao Yu  wrote:

>> julia> macro finish()
>>  :(t)
>>end
>> julia> macroexpand(:(@finish()))
>> :t
>>
>> as expected. BTW, this is not really "global", as the manual says. It
>> really is "outer scope".
>
> This is a bug, (the one I linked). It should be `Main.t` (or whatever
> module that the macro is defined in).

  So you mean that if I do this:

  t = 10
  function foo()
t = 5
@finish()
  end

  I will presently get 5 but when the bug is fixed, I will get 10 (or
  whatever value t had in the macro definition's module) ?


> This should be `bar(Main.t)`. use as function argument name is talking
> about defining a function.

  Oh, right. Thanks.

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: [julia-users] Options for constructing a 3D surface from a point cloud

[Kristoffer Carlsson]

You could use WriteVTK.jl and render the point cloud in Paraview. 

Re: [julia-users] Re: Ambiguous method definitions

[Milan Bouchet-Valat]

Le mercredi 20 avril 2016 à 08:50 -0700, Robert Gates a écrit :
> I wonder if this should be an issue in julia itself. Perhaps it would
> be good to require at least one argument?
There has been some discussion about syntax to specify a minimum and
maximum number of arguments. But nothing has been decided yet. See
https://github.com/JuliaLang/julia/pull/10691#issuecomment-88509128


Regards

> > Yes I would say this is dangerous.  Assuming there must be at least
> > one input, the signature should probably be:
> > 
> > > f(firstval::T, rest::T...) = <...>
> > though it certainly doesn't look as pretty. 
> > 
> > On Wed, Apr 20, 2016 at 10:54 AM, Robert Gates  > > wrote:
> > > Okay, perfect, that answered my question! I thought that at least
> > > one of the vararg arguments is mandatory. A philosophical
> > > thought: isn't this use-case kind of dangerous when overloading
> > > Base functions in packages? In my case, MultiPoly and Lazy both
> > > overload Base.+ with a varargs function (like the one above).
> > > 
> > > 
> > > > I was wondering how this can happen:
> > > > 
> > > > julia> type T1; end
> > > > 
> > > > julia> type T2; end
> > > > 
> > > > julia> f(a::T1...) = ()
> > > > f (generic function with 1 method)
> > > > 
> > > > julia> f(a::T2...) = ()
> > > > WARNING: New definition 
> > > >     f(Main.T2...) at none:1
> > > > is ambiguous with: 
> > > >     f(Main.T1...) at none:1.
> > > > To fix, define 
> > > >     f()
> > > > before the new definition.
> > > > f (generic function with 2 methods)
> > > > 
> > > > This is a fresh julia 0.4.5 session. I actually encountered
> > > > this when using two packages and then built this MWE.
> > > > 
> > > > 
> > 

Re: [julia-users] Re: are macros hygienic?

[Yichao Yu]

On Wed, Apr 20, 2016 at 4:15 PM, Didier Verna  wrote:
> Yichao Yu  wrote:
>
 julia> macro finish()
  t = 5
end
>
>>> Your macro is also simply returning a `5` btw.
>
> Sorry, I meant :(t = 5).
>
>
>> Just to be clear, the behavior you observer is correct and expected.
>> Non-escaped variables used in macro is not supposed to affect the user
>> of the macro. The bug report I pasted is merely a FYI since you are
>> getting very closed to discover it.
>
>   Right :-) There's still something I'm not sure about. The manual says:
>   "A variable is considered local if it is assigned to (and not declared
>   global), declared local, or used as a function argument name."
>
> So:
>
> julia> macro finish()
>  :(t)
>end
> julia> macroexpand(:(@finish()))
> :t
>
> as expected. BTW, this is not really "global", as the manual says. It
> really is "outer scope".

This is a bug, (the one I linked). It should be `Main.t` (or whatever
module that the macro is defined in).

>
>
> julia> macro finish()
>  :(t = 5)
>end
> julia> macroexpand(:(@finish()))
> :(#8#t = 5)
>
> as expected as well.
>
> But:
> julia> macro finish()
>  :(bar(t))
>end
> julia> macroexpand(:(@finish()))
> :(bar(t))
>
> unexpected. t is used as a function argument name, so shouldn't it be
> considered local and hence gensym'ed ?

This should be `bar(Main.t)`. use as function argument name is talking
about defining a function. The classification (mentioned in the issue
below) is that the values assigned to will be made local unless it is
escaped or declared as global.

There's also https://github.com/JuliaLang/julia/issues/10887 although
I haven't checked lately if anything has changed.

>
> --
> ELS'16 registration open! http://www.european-lisp-symposium.org
>
> Lisp, Jazz, Aïkido: http://www.didierverna.info

[julia-users] Re: Starting Julia with Julia -p 2 provides 1 worker

['Greg Plowman' via julia-users]

Sorry, I can't really help you with command line julia -p 2
But what happens when you call addprocs() from REPL?
Also, what is the value of CPU_CORES (typed at REPL)?

Re: [julia-users] Options for constructing a 3D surface from a point cloud

[Chris]

I've attached a sample dataset. It's a set of 500 x,y,z points. I still 
haven't been able to make much headway on this, so if someone could take 
the time to show me what's possible, I'd be very appreciative.

On Monday, February 22, 2016 at 3:55:14 PM UTC-5, Chris wrote:
>
> I will work on creating a small sample dataset, but the shape is 
> essentially a "kidney bean" in 3D space. In fact, the actual "point cloud" 
> is (right now) actually samples from a 3D probability density function, 
> i.e. it's a "blob", and I want the 3D bounding surface of that blob. I 
> imagine this makes things more difficult (at least computationally), and so 
> I'm thinking of ways to go from "blob" to the "convex hull" of this point 
> cloud -- even though convex hull isn't exactly what I want, since there is 
> some concavity.
>
> On Saturday, February 20, 2016 at 8:05:44 PM UTC-5, Steve Kelly wrote:
>>
>> Do you have a sample dataset? The algorithms for triangulating a signed 
>> distance field can be found in Meshing.jl. I implemented Marching Cubes 
>> recently and started Marching Squares today, but have yet to tag a release 
>> because I need to settle on an API.
>>
>> I currently am working on solid modeling via implicit functions. More 
>> generally I work in digital fabrication (Fab Lab) and would love to have 3D 
>> scanning in the Julia workflow. If you can share more about the dataset you 
>> have, I'll see if we can make it work with the tools we have available now. 
>> On Feb 19, 2016 2:36 AM, "Igor"  wrote:
>>
>>> Chris , I'm interested in this area too.  Please post here if you come 
>>> up with some solution you would like.
>>>
>>> Best regards, Igor
>>
>>

testpts.jld
Description: Binary data

Re: [julia-users] Re: are macros hygienic?

[Didier Verna]

Yichao Yu  wrote:

>>> julia> macro finish()
>>>  t = 5
>>>end

>> Your macro is also simply returning a `5` btw.

Sorry, I meant :(t = 5).


> Just to be clear, the behavior you observer is correct and expected.
> Non-escaped variables used in macro is not supposed to affect the user
> of the macro. The bug report I pasted is merely a FYI since you are
> getting very closed to discover it.

  Right :-) There's still something I'm not sure about. The manual says:
  "A variable is considered local if it is assigned to (and not declared
  global), declared local, or used as a function argument name."

So:

julia> macro finish()
 :(t)
   end
julia> macroexpand(:(@finish()))
:t

as expected. BTW, this is not really "global", as the manual says. It
really is "outer scope".


julia> macro finish()
 :(t = 5)
   end
julia> macroexpand(:(@finish()))
:(#8#t = 5)

as expected as well.

But:
julia> macro finish()
 :(bar(t))
   end
julia> macroexpand(:(@finish()))
:(bar(t))

unexpected. t is used as a function argument name, so shouldn't it be
considered local and hence gensym'ed ?

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

[julia-users] Re: Stuck with using and LOAD_PATH

[Gregory Salvan]

Thanks for replies (sorry I was not notified)
The matter was for running tests often (BDD) and Pkg doesn't seem to be the 
solution.
Finally I resolved it but still don't understand what was the matter. :)
I've defined all modules in package.jl with exports and include then use 
"using Package.ModuleA.typeA" in moduleB for example.

Le lundi 21 mars 2016 04:13:24 UTC+1, James Dang a écrit :
>
> If MyDir is on the LOAD_PATH, this works for me:
>
> LOAD_PATH/
>   Foo/
> src/
>   Foo.jl
>
> Foo.jl:
>   module Foo
>   ...
>   end
>
> in separate code:
>import Foo
>
>
>
>
>
>
> On Wednesday, March 16, 2016 at 9:42:37 PM UTC+8, Gregory Salvan wrote:
>>
>> Hi,
>> I don't understand the way of importing/using modules, or including files.
>> I've look at documentation (FAQ and modules) and into this list for old 
>> subjects, and tested all solutions I found.
>>
>> with julia version 0.4.3 on gentoo
>>
>> directory structure looks like:
>>
>> package.jl (directory)
>>   |_ src
>>   |  |_ fileA.jl
>>   |  |_ fileB.jl
>>   |  |_ fileC.jl
>>   |  |_ fileD.jl
>>   |  |_ package.jl
>>   |_ test
>>  |_ testA.jl
>>
>> The* first issue* I had was with "using" in tests, for example I've 
>> tried:
>>
>> push!(LOAD_PATH, string(dirname(@__FILE__), "/..src")) # just to try - 
>> ModuleA is in fileA.jl in ../src
>> using ModuleA
>> # alternativelly:
>> # using ModuleA.TypeA1 or using ModuleA: TypeA1...
>> facts("Test ModuleA") do
>>   context("create") do
>>  type_a1 = ModuleA.TypeA1()
>>   end
>> end
>>
>>
>> I've tested launching this test with :
>> JULIA_LOAD_PATH=./src/ LOAD_PATH=./src julia --color=yes test/testA.jl
>>
>> (no differences with import too)
>>
>> The error message is:
>> ERROR: LoadError: ArgumentError: ModuleA not found in path
>>
>> Instead of import/using (but that's not what I wanted), It's OK if I use :
>> include("../src/fileA.jl")
>>
>>
>>
>> The *second issue* is when I wanted to define modules in package.jl this 
>> way:
>>
>> module Package
>>   module ModA
>> include("fileA.jl")
>> include("fileB.jl")
>>   end
>>   module ModC
>> include("fileC.jl")
>>   end
>> end
>>
>> And have for example a fileD.jl included in fileA.jl and fileB.jl (or 
>> fileC.jl) with and immutable type. (I've included fileD.jl because I 
>> couldn't use "using" but I would prefer "using")
>> I have an error ERROR: LoadError: LoadError: LoadError: LoadError: 
>> LoadError: invalid redefinition of constant ImmutableType
>>
>> So as I can't use "using" to avoid the reloading what can I do? 
>> what I've not understood about julia import/using and include ?
>>
>> NOTE:
>> some things I've tried: fileD.jl with a module ModuleD and "using" with 
>> and without  __precompile__
>> setting LOAD_PATH and JULIA_LOAD_PATH globally with bashrc or passing it 
>> to shell
>> ...
>>
>>

Re: [julia-users] Re: Ambiguous method definitions

[Michael Borregaard]

There are many cases where it is convenient to be able to give 0 kwargs. Is 
it not better to test for 
isempty(a)
when the behavior is undefined for 0 arguments?

Re: [julia-users] Re: are macros hygienic?

[Yichao Yu]

On Wed, Apr 20, 2016 at 2:54 PM, Yichao Yu  wrote:
> On Wed, Apr 20, 2016 at 2:33 PM, Didier Verna  wrote:
>> I wrote:
>>
>>> Could someone explain what's hygienic about Julia's macros? Because I
>>> cannot figure out an example by myself...
>>
>>   OK, I think I get it:
>>
>> julia> macro finish()
>>  t = 5
>>end
>>
>> julia> function foo()
>>  t = 10
>>  @finish()
>>  t
>>end
>> foo (generic function with 1 method)
>>
>> julia> foo()
>> 10
>>
>>
>> Still, it seems to me extremely abusive to call this macro system
>> hygienic...
>
> There's https://github.com/JuliaLang/julia/issues/14893
> Your macro is also simply returning a `5` btw.

Just to be clear, the behavior you observer is correct and expected.
Non-escaped variables used in macro is not supposed to affect the user
of the macro. The bug report I pasted is merely a FYI since you are
getting very closed to discover it.

>
>>
>> --
>> ELS'16 registration open! http://www.european-lisp-symposium.org
>>
>> Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: [julia-users] Re: are macros hygienic?

[Yichao Yu]

On Wed, Apr 20, 2016 at 2:33 PM, Didier Verna  wrote:
> I wrote:
>
>> Could someone explain what's hygienic about Julia's macros? Because I
>> cannot figure out an example by myself...
>
>   OK, I think I get it:
>
> julia> macro finish()
>  t = 5
>end
>
> julia> function foo()
>  t = 10
>  @finish()
>  t
>end
> foo (generic function with 1 method)
>
> julia> foo()
> 10
>
>
> Still, it seems to me extremely abusive to call this macro system
> hygienic...

There's https://github.com/JuliaLang/julia/issues/14893
Your macro is also simply returning a `5` btw.

>
> --
> ELS'16 registration open! http://www.european-lisp-symposium.org
>
> Lisp, Jazz, Aïkido: http://www.didierverna.info

[julia-users] Re: are macros hygienic?

[Didier Verna]

I wrote:

> Could someone explain what's hygienic about Julia's macros? Because I
> cannot figure out an example by myself...

  OK, I think I get it:

julia> macro finish()
 t = 5
   end

julia> function foo()
 t = 10
 @finish()
 t
   end
foo (generic function with 1 method)

julia> foo()
10


Still, it seems to me extremely abusive to call this macro system
hygienic...

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

[julia-users] Re: OT: entering Unicode characters

[Henri Girard]

Wonderfull answer ! I am new to julia (ijulia) today's exactly... But I was 
wondering how to get symbols... You save me a good lot of time !
So I will enjoy longer my favorite "Saumur Champigny" ! lol


Le mercredi 15 janvier 2014 17:26:57 UTC+1, Stefan Karpinski a écrit :
>
> Since Julia source code can use Unicode identifiers, I thought this 
> slightly off-topic blog post by John D. Cook might be useful to people:
>
> http://www.johndcook.com/symbols/2013/12/how-to-enter-unicode-characters/
>
> In particular, I learned about the Unicode Hex input mode for OS X.
>

[julia-users] Re: Starting Julia with Julia -p 2 provides 1 worker

[Iacopo Poli]

I downloaded version 0.4.5, again calling it with -p 2 returns 1 process 
and 1 worker... I really can't understand why

Il giorno martedì 19 aprile 2016 17:37:05 UTC+2, Andre Bieler ha scritto:
>
> Huh.. I just tried julia -p 2 on version 0.4.5 and it actually starts with 
> 3 processes and 2 workers.
>
> So the docs are correct.
>
> Sorry i cant help with the 0.5 version..
>
>

Re: [julia-users] What is the situation

[Yichao Yu]

Hi,

On Wed, Apr 20, 2016 at 1:15 PM,   wrote:
> Hi, JuMP
> I am wondering if its possible to use JuMP, AML to call equation solvers
> like Sundials. What is the situation? is it possible now? or is it on the
> road-map?

While this list is perfectly fine for general questions about julia
and its packages (you might want a more informative title though) you
might have better luck getting an answer from the julia-opt list[1].

[1] https://groups.google.com/forum/#!forum/julia-opt

> Thanks

[julia-users] What is the situation

[rafzalan]

Hi, JuMP 
I am wondering if its possible to use JuMP, AML to call equation solvers 
like Sundials. What is the situation? is it possible now? or is it on the 
road-map?
Thanks

Re: [julia-users] Re: Change bold text in REPL to normal

[Yichao Yu]

On Wed, Apr 20, 2016 at 11:53 AM,   wrote:
> Good, this works. But, I don't think the preference for expressions over
> strings is mentioned in the Metaprogramming section of the manual.

I didn't know parsing was even part of it. It really shouldn't be.

>
> John
>
> On Wednesday, April 20, 2016 at 4:19:18 PM UTC+2, Yichao Yu wrote:
>>
>> On Wed, Apr 20, 2016 at 10:11 AM,   wrote:
>> > I see. To get normal weight, red, warn() text, this works for me:
>> >
>> > Base.text_colors[:rednormal] = "\033[0m\033[31m"
>> > Base.eval(parse("default_color_warn = :rednormal"))
>>
>> Base.eval(:(default_color_warn = :rednormal))
>>
>> at least. You almost never want to use `parse` and then `eval`.
>>
>> >
>> > text_colors is defined in base/client.jl
>> >
>> > On Wednesday, April 20, 2016 at 3:10:19 PM UTC+2, cormu...@mac.com
>> > wrote:
>> >>
>> >> Thanks, useful info. Although, I don't mind the colors. It's the forced
>> >> bolding that looks so bad... :(

Re: [julia-users] How to change REPL mode on startup?

[lapeyre . math122a]

You can try this branch https://github.com/jlapeyre/julia/tree/gjl/replhooks

In .juliarc.jl, you can include code like this:

if isdefined(Base, :atreplrun)
Base.atreplrun( (repl)->repl.interface.modes[1].prompt = "newprompt>" )
end

to install a hook. Call atreplrun repeatedly to push hooks, all of which 
are run (more or less) just before the loop is entered.

John


On Wednesday, April 20, 2016 at 5:54:22 AM UTC+2, Rafael Fourquet wrote:
>
> > Again, I don't know if there is any demand for adding a general 
> > facility for this. 
>
> If you have in mind to make a PR, I would be a client for such a 
> facility. IIUC, this would e.g. allow me to change automatically the 
> prompt by calling a function from .juliarc.jl ? (which I do manually 
> now with "Base.active_repl.interface.modes[1].prompt = ..."). 
>

Re: [julia-users] Re: Change bold text in REPL to normal

[lapeyre . math122a]

Good, this works. But, I don't think the preference for expressions over 
strings is mentioned in the Metaprogramming section of the manual.

John

On Wednesday, April 20, 2016 at 4:19:18 PM UTC+2, Yichao Yu wrote:
>
> On Wed, Apr 20, 2016 at 10:11 AM,  > 
> wrote: 
> > I see. To get normal weight, red, warn() text, this works for me: 
> > 
> > Base.text_colors[:rednormal] = "\033[0m\033[31m" 
> > Base.eval(parse("default_color_warn = :rednormal")) 
>
> Base.eval(:(default_color_warn = :rednormal)) 
>
> at least. You almost never want to use `parse` and then `eval`. 
>
> > 
> > text_colors is defined in base/client.jl 
> > 
> > On Wednesday, April 20, 2016 at 3:10:19 PM UTC+2, cormu...@mac.com 
> wrote: 
> >> 
> >> Thanks, useful info. Although, I don't mind the colors. It's the forced 
> >> bolding that looks so bad... :( 
>

Re: [julia-users] Re: Ambiguous method definitions

[Robert Gates]

I wonder if this should be an issue in julia itself. Perhaps it would be 
good to require at least one argument?

On Wednesday, April 20, 2016 at 5:00:39 PM UTC+2, Tom Breloff wrote:
>
> Yes I would say this is dangerous.  Assuming there must be at least one 
> input, the signature should probably be:
>
> f(firstval::T, rest::T...) = <...>
>
>
> though it certainly doesn't look as pretty. 
>
> On Wed, Apr 20, 2016 at 10:54 AM, Robert Gates  > wrote:
>
>> Okay, perfect, that answered my question! I thought that at least one of 
>> the vararg arguments is mandatory. A philosophical thought: isn't this 
>> use-case kind of dangerous when overloading Base functions in packages? In 
>> my case, MultiPoly and Lazy both overload Base.+ with a varargs function 
>> (like the one above).
>>
>>
>> On Wednesday, April 20, 2016 at 4:30:49 PM UTC+2, Robert Gates wrote:
>>>
>>> I was wondering how this can happen:
>>>
>>> *julia> **type T1; end*
>>>
>>>
>>> *julia> **type T2; end*
>>>
>>>
>>> *julia> **f(a::T1...) = ()*
>>>
>>> *f (generic function with 1 method)*
>>>
>>>
>>> *julia> **f(a::T2...) = ()*
>>>
>>> WARNING: New definition 
>>>
>>> f(Main.T2...) at none:1
>>>
>>> is ambiguous with: 
>>>
>>> f(Main.T1...) at none:1.
>>>
>>> To fix, define 
>>>
>>> f()
>>>
>>> before the new definition.
>>>
>>> *f (generic function with 2 methods)*
>>>
>>> This is a fresh julia 0.4.5 session. I actually encountered this when 
>>> using two packages and then built this MWE.
>>>
>>>
>

Re: [julia-users] Re: Rounding to zero from positive or negative numbers results in positive or negative zero.

[Andrew Gibb]

On Wednesday, 20 April 2016 15:18:06 UTC+1, Stefan Karpinski wrote:
>
> IEEE has not made the programming language designer's life easy here.
>

Perhaps it's a subtle attempt to incentivise more designers of mathematical 
programming languages into IEEE standards committees?!

 

>
> On Wed, Apr 20, 2016 at 5:51 AM, Milan Bouchet-Valat  > wrote:
>
>> Le mardi 19 avril 2016 à 22:10 -0700, Jeffrey Sarnoff a écrit :
>> > Hi,
>> >
>> > You have discovered that IEEE standard floating point numbers have
>> > two distinct zeros: 0.0 and -0.0.  They compare `==` even though they
>> > are not `===`.  If you want to consider +0.0 and -0.0 to be the same,
>> > use `==` or `!=` not `===`  or `!==` when testing floating point
>> > values (the other comparisons <=, <, >=, > treat the two zeros as a
>> > single value).
>> There's actually an open issue about what to do with -0.0 and NaN in
>> Dicts: https://github.com/JuliaLang/julia/issues/9381
>>
>> It turns out it's very hard to find a good solution.
>>
>>
>> Regards
>>
>> > > Hello everyone!
>> > > I was wondering if the following behavior of round() has an special
>> > > purpouse:
>> > >
>> > > a = round(0.1)
>> > > 0.0
>> > >
>> > > b = round(-0.1)
>> > > -0.0
>> > >
>> > > a == b
>> > > true
>> > >
>> > > a === b
>> > > false
>> > >
>> > > bits(a)
>> > > ""
>> > >
>> > >
>> > > bits(b)
>> > > "1000"
>> > >
>> > > So the sign stays around...
>> > >
>> > > I am using this rounded numbers as keys in a dictionary and julia
>> > > can tell the difference. 
>> > >
>> > > For example, I expected something like this:
>> > > dict = [i => exp(i) for i in [a,b]]
>> > > Dict{Any,Any} with 1 entry:
>> > >  0.0 => 1.0
>> > >
>> > > but got this:
>> > > dict = [i => exp(i) for i in [a,b]]
>> > > Dict{Any,Any} with 2 entries:
>> > >   0.0  => 1.0
>> > >   -0.0 => 1.0
>> > >
>> > > It is not a big problem really but I would like to know where can
>> > > this behaviour come handy.
>> > >
>> > > Cheers!
>> > >
>>
>
>

Re: [julia-users] Re: macros design

[Milan Bouchet-Valat]

Le mercredi 20 avril 2016 à 16:22 +0100, Didier Verna a écrit :
> Milan Bouchet-Valat  wrote:
> 
> > 
> > OTOH, short-circuit operators are in limited number (&& and ||).
> > Packages authors cannot create new ones without the user knowing
>   Do you mean it's possible to create new short-circuit operators ?
No, precisely that it's not possible, so we don't need a special syntax
like @.

Regards

> > 
> > Yes. For example, DataFrames.jl and DataFramesMeta.jl provide
> > functions like where(), by() and aggregate() both in function and
> > macro forms.  The former takes a function, while the latter offers
> > a
> > convenience syntax which creates a function under the hood.
> > 
> > See in particular this section:
> > https://github.com/JuliaStats/DataFramesMeta.jl#operations-on-group
> > eddataframes
>   Thanks.
> 
> 
> > 
> > I don't think that's possible, as the short-circuit behavior of &&
> > means it does not evaluate its second operand if the first one is
> > false. So it cannot be a standard function.
>   Sure. It would have to be built-in.
> 

Re: [julia-users] Re: macros design

[Didier Verna]

Milan Bouchet-Valat  wrote:

> OTOH, short-circuit operators are in limited number (&& and ||).
> Packages authors cannot create new ones without the user knowing

  Do you mean it's possible to create new short-circuit operators ?

> Yes. For example, DataFrames.jl and DataFramesMeta.jl provide
> functions like where(), by() and aggregate() both in function and
> macro forms.  The former takes a function, while the latter offers a
> convenience syntax which creates a function under the hood.
>
> See in particular this section:
> https://github.com/JuliaStats/DataFramesMeta.jl#operations-on-groupeddataframes

  Thanks.


> I don't think that's possible, as the short-circuit behavior of &&
> means it does not evaluate its second operand if the first one is
> false. So it cannot be a standard function.

  Sure. It would have to be built-in.

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: [julia-users] Re: macros design

[Didier Verna]

Isaiah Norton  wrote:

> Just to follow up on this a bit: we've continually reworked the
> metaprogramming documentation because it can be an especially
> difficult concept for people who don't have a compiler background or
> Lisp experience. The most common sources of misunderstanding have been
> rooted in people not internalizing that macros, from a definition
> standpoint, are just functions that return expressions. A lot of
> questions on the mailing list treated macros as "spooky magic" (I'll
> admit to feeling this way for a long time!). We want to make them less
> so. Showing explicit returns, and emphasizing macros as
> transformations first, was an attempt to reduce the level of implicit
> knowledge required to understand what is happening.

  Makes sense. Thanks. But now that you've had the opposite reaction,
  perhaps you could add a note that the return is actually not
  needed. :-D

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: [julia-users] Re: modules (documentation)

[Didier Verna]

Kristoffer Carlsson  wrote:

> Does the following examples help?

  I get it now, I think. Import also loads a module from somewhere if
  it's not present in the environment.

Thanks.

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: [julia-users] Re: Ambiguous method definitions

[Tom Breloff]

Yes I would say this is dangerous.  Assuming there must be at least one
input, the signature should probably be:

f(firstval::T, rest::T...) = <...>


though it certainly doesn't look as pretty.

On Wed, Apr 20, 2016 at 10:54 AM, Robert Gates 
wrote:

> Okay, perfect, that answered my question! I thought that at least one of
> the vararg arguments is mandatory. A philosophical thought: isn't this
> use-case kind of dangerous when overloading Base functions in packages? In
> my case, MultiPoly and Lazy both overload Base.+ with a varargs function
> (like the one above).
>
>
> On Wednesday, April 20, 2016 at 4:30:49 PM UTC+2, Robert Gates wrote:
>>
>> I was wondering how this can happen:
>>
>> *julia> **type T1; end*
>>
>>
>> *julia> **type T2; end*
>>
>>
>> *julia> **f(a::T1...) = ()*
>>
>> *f (generic function with 1 method)*
>>
>>
>> *julia> **f(a::T2...) = ()*
>>
>> WARNING: New definition
>>
>> f(Main.T2...) at none:1
>>
>> is ambiguous with:
>>
>> f(Main.T1...) at none:1.
>>
>> To fix, define
>>
>> f()
>>
>> before the new definition.
>>
>> *f (generic function with 2 methods)*
>>
>> This is a fresh julia 0.4.5 session. I actually encountered this when
>> using two packages and then built this MWE.
>>
>>

[julia-users] Re: Ambiguous method definitions

[Robert Gates]

Okay, perfect, that answered my question! I thought that at least one of 
the vararg arguments is mandatory. A philosophical thought: isn't this 
use-case kind of dangerous when overloading Base functions in packages? In 
my case, MultiPoly and Lazy both overload Base.+ with a varargs function 
(like the one above).

On Wednesday, April 20, 2016 at 4:30:49 PM UTC+2, Robert Gates wrote:
>
> I was wondering how this can happen:
>
> *julia> **type T1; end*
>
>
> *julia> **type T2; end*
>
>
> *julia> **f(a::T1...) = ()*
>
> *f (generic function with 1 method)*
>
>
> *julia> **f(a::T2...) = ()*
>
> WARNING: New definition 
>
> f(Main.T2...) at none:1
>
> is ambiguous with: 
>
> f(Main.T1...) at none:1.
>
> To fix, define 
>
> f()
>
> before the new definition.
>
> *f (generic function with 2 methods)*
>
> This is a fresh julia 0.4.5 session. I actually encountered this when 
> using two packages and then built this MWE.
>
>

Re: [julia-users] Re: macros design

[Didier Verna]

cormull...@mac.com wrote:

> https://github.com/JuliaLang/julia/blob/3c354b4a391307d84915445bdd6fb464371f30fc/doc/at_macro_reasons
>

Nice, thanks :-)

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: [julia-users] Re: macros design

[Milan Bouchet-Valat]

Le mercredi 20 avril 2016 à 15:34 +0100, Didier Verna a écrit :
> Matt Bauman  wrote:
> 
> > 
> > It's nice for both humans (it's obvious that there could be some
> > non-standard evaluation semantics or other such funniness)
>   Maybe for /some/ humans ;-), but I don't like this. It exposes
>   implementation details to the programmer. It breaks the functor
>   syntactic uniformity (consider that a single expression could
>   otherwise have different semantics in different contexts which gives a
>   lot of expressiveness) and makes Julia much less convenient for DSLs
>   design for instance. Also, it's not coherent with the rest of the
>   language. Short-circuit operators[1] and some built-in constructs also
>   have non-standard evaluation semantics, but they don't have a funny
>   calling syntax.
The fact that you're calling a macro and not a function is certainly
not an implementation detail. The @ is here to warn you that the call
might have any kind of side-effects, or at least does not behave like
functions.

OTOH, short-circuit operators are in limited number (&& and ||).
Packages authors cannot create new ones without the user knowing, so
the potential for confusion is much lower.

> > and the parser (it knows exactly which symbols it needs to resolve in
> > order to expand the macros since nothing else can contain the @
> > character).  
>   Making life easier to the internals should never be a valid argument
>   to corrupt the externals :-) Besides, I don't see how it would be
>   difficult to figure out if a symbol refers to a macro, or to a regular
>   function. In fact, Julia already does something similar, according to
>   whether a function or a functor is called. Well, I guess that macros
>   are not first-class enough...
> 
> > 
> > Are you talking about the optional parentheses?  That is: `@m(x,y)` vs
> > `@m x y`?
>   Yes, sorry.
> 
> > 
> >  It's very convenient to have the parentheses-less version for macros
> > like @inline and @simd which annotate or transform existing
> > structures.  And parentheses with comma-separated arguments can be
> > nice in cases where the distinction between several arguments might
> > get fuzzy otherwise.
>   OK. Not much convinced here either. Not sure the convenience was worth
>   the syntactic trouble it causes in the rest of the language
>   (e.g. deprecating the foo() syntax).
> 
> 
>   One final remark: a corollary of this specific calling syntax is that
>   eponymous functions and macros may co-exist (they seem to live in
>   separate namespaces). Anyone ever saw a use for this?
Yes. For example, DataFrames.jl and DataFramesMeta.jl provide functions
like where(), by() and aggregate() both in function and macro forms.
The former takes a function, while the latter offers a convenience
syntax which creates a function under the hood.

See in particular this section:
https://github.com/JuliaStats/DataFramesMeta.jl#operations-on-groupeddataframes

> Footnotes: 
> [1]  BTW, is there a functional equivalent to && and friends? I mean, a
> logical AND short-circuit function usable in prefix notation? I was
> surprised that I can do +(1,2) but not &&(true,false).
I don't think that's possible, as the short-circuit behavior of &&
means it does not evaluate its second operand if the first one is
false. So it cannot be a standard function.


Regards

Re: [julia-users] Re: macros design

[Isaiah Norton]

>
> Yup, implicit return works for macros, too.  The manual makes it explicit
> to emphasize the function-like syntax transformation (as opposed to
> CPP-like textual substitution).


Just to follow up on this a bit: we've continually reworked the
metaprogramming documentation because it can be an especially difficult
concept for people who don't have a compiler background or Lisp experience.
The most common sources of misunderstanding have been rooted in people not
internalizing that macros, from a definition standpoint, are just functions
that return expressions. A lot of questions on the mailing list treated
macros as "spooky magic" (I'll admit to feeling this way for a long time!).
We want to make them less so. Showing explicit returns, and emphasizing
macros as transformations first, was an attempt to reduce the level of
implicit knowledge required to understand what is happening.

On Wed, Apr 20, 2016 at 9:50 AM, Matt Bauman  wrote:

> On Wednesday, April 20, 2016 at 8:58:35 AM UTC-4, Didier Verna wrote:
>>
>>
>>   What's the rationale behind this particular way of invoking macros
>>   (the @ character) ?
>
>
> It's nice for both humans (it's obvious that there could be some
> non-standard evaluation semantics or other such funniness) and the parser
> (it knows exactly which symbols it needs to resolve in order to expand the
> macros since nothing else can contain the @ character).
>
>
>> And why a single macro concept for two different
>>   things (with or without arguments) ?
>>
>
> Are you talking about the optional parentheses?  That is: `@m(x,y)` vs `@m
> x y`?  It's very convenient to have the parentheses-less version for macros
> like @inline and @simd which annotate or transform existing structures.
> And parentheses with comma-separated arguments can be nice in cases where
> the distinction between several arguments might get fuzzy otherwise.
>
> On Wednesday, April 20, 2016 at 9:19:03 AM UTC-4, Didier Verna wrote:
>>
>>  Also, I'm wondering about the use of RETURN in all the one-liner
>> macro examples from the manual.
>
>
> Yup, implicit return works for macros, too.  The manual makes it explicit
> to emphasize the function-like syntax transformation (as opposed to
> CPP-like textual substitution).
>

[julia-users] Re: modules (documentation)

[Kristoffer Carlsson]

Does the following examples help?


julia> NearestNeighbors.KDTree
ERROR: UndefVarError: NearestNeighbors not defined
 in eval(::Module, ::Any) at ./boot.jl:243

julia> import NearestNeighbors

julia> NearestNeighbors.KDTree # Can use dot notation on the imported module
NearestNeighbors.KDTree{T<:AbstractFloat,M<:Union{Distances.Chebyshev,
Distances.Cityblock,Distances.Euclidean,Distances.Minkowski{T<:Real}}}

julia> KDTree # Without dot, type is not found
ERROR: UndefVarError: KDTree not defined
 in eval(::Module, ::Any) at ./boot.jl:243

julia> import NearestNeighbors.KDTree # Importing the type

julia> KDTree # Now we don't need to qualify the module because it is in 
scope
NearestNeighbors.KDTree{T<:AbstractFloat,M<:Union{Distances.Chebyshev,Distances.Cityblock,Distances.Euclidean,Distances.Minkowski{T<:Real}}}



On Wednesday, April 20, 2016 at 4:12:31 PM UTC+2, Didier Verna wrote:
>
>
>   There are a couple of things that I find obscure in the modules 
>   documentation. 
>
> It says that import operates on a single name at a time, but there's a 
> counter-example in the table right below this sentence: import MyModule 
> which looks like it imports a module as a whole. 
>
> On the other hand, the table in question says that with such a 
> directive, MyModule.x (and y and p) are "brought into scope" and 
> "available for method extension". But from what I could gather, it seems 
> to me that the dot notation always makes everything available. So it 
> would rather seem that import MyModule is a no-op. Is that correct? 
>
> -- 
> ELS'16 registration open! http://www.european-lisp-symposium.org 
>
> Lisp, Jazz, Aïkido: http://www.didierverna.info 
>

Re: [julia-users] Ambiguous method definitions

[Keno Fischer]

Could you be more specific about your confusion? Both those methods
match `f()` so there's an ambiguity.

On Wed, Apr 20, 2016 at 10:30 AM, Robert Gates  wrote:
> I was wondering how this can happen:
>
> julia> type T1; end
>
>
> julia> type T2; end
>
>
> julia> f(a::T1...) = ()
>
> f (generic function with 1 method)
>
>
> julia> f(a::T2...) = ()
>
> WARNING: New definition
>
> f(Main.T2...) at none:1
>
> is ambiguous with:
>
> f(Main.T1...) at none:1.
>
> To fix, define
>
> f()
>
> before the new definition.
>
> f (generic function with 2 methods)
>
>
> This is a fresh julia 0.4.5 session. I actually encountered this when using
> two packages and then built this MWE.
>

[julia-users] Ambiguous method definitions

[Robert Gates]

I was wondering how this can happen:

*julia> **type T1; end*


*julia> **type T2; end*


*julia> **f(a::T1...) = ()*

*f (generic function with 1 method)*


*julia> **f(a::T2...) = ()*

WARNING: New definition 

f(Main.T2...) at none:1

is ambiguous with: 

f(Main.T1...) at none:1.

To fix, define 

f()

before the new definition.

*f (generic function with 2 methods)*

This is a fresh julia 0.4.5 session. I actually encountered this when using 
two packages and then built this MWE.

Re: [julia-users] How to change REPL mode on startup?

[lapeyre . math122a]

Yes, AFAIK it is not possible to modify the REPL in .juliarc.jl because it 
is executed before the REPL runs. A tedious workaround is to use 
.juliarc.jl to create a REPL and then exit() upon completion before the 
usual REPL is started. I hadn't thought about a PR, but I can take a look 
at it.
John
 

On Wednesday, April 20, 2016 at 5:54:22 AM UTC+2, Rafael Fourquet wrote:
>
> > Again, I don't know if there is any demand for adding a general 
> > facility for this. 
>
> If you have in mind to make a PR, I would be a client for such a 
> facility. IIUC, this would e.g. allow me to change automatically the 
> prompt by calling a function from .juliarc.jl ? (which I do manually 
> now with "Base.active_repl.interface.modes[1].prompt = ..."). 
>

Re: [julia-users] Re: Rounding to zero from positive or negative numbers results in positive or negative zero.

[Stefan Karpinski]

IEEE has not made the programming language designer's life easy here.

On Wed, Apr 20, 2016 at 5:51 AM, Milan Bouchet-Valat 
wrote:

> Le mardi 19 avril 2016 à 22:10 -0700, Jeffrey Sarnoff a écrit :
> > Hi,
> >
> > You have discovered that IEEE standard floating point numbers have
> > two distinct zeros: 0.0 and -0.0.  They compare `==` even though they
> > are not `===`.  If you want to consider +0.0 and -0.0 to be the same,
> > use `==` or `!=` not `===`  or `!==` when testing floating point
> > values (the other comparisons <=, <, >=, > treat the two zeros as a
> > single value).
> There's actually an open issue about what to do with -0.0 and NaN in
> Dicts: https://github.com/JuliaLang/julia/issues/9381
>
> It turns out it's very hard to find a good solution.
>
>
> Regards
>
> > > Hello everyone!
> > > I was wondering if the following behavior of round() has an special
> > > purpouse:
> > >
> > > a = round(0.1)
> > > 0.0
> > >
> > > b = round(-0.1)
> > > -0.0
> > >
> > > a == b
> > > true
> > >
> > > a === b
> > > false
> > >
> > > bits(a)
> > > ""
> > >
> > >
> > > bits(b)
> > > "1000"
> > >
> > > So the sign stays around...
> > >
> > > I am using this rounded numbers as keys in a dictionary and julia
> > > can tell the difference.
> > >
> > > For example, I expected something like this:
> > > dict = [i => exp(i) for i in [a,b]]
> > > Dict{Any,Any} with 1 entry:
> > >  0.0 => 1.0
> > >
> > > but got this:
> > > dict = [i => exp(i) for i in [a,b]]
> > > Dict{Any,Any} with 2 entries:
> > >   0.0  => 1.0
> > >   -0.0 => 1.0
> > >
> > > It is not a big problem really but I would like to know where can
> > > this behaviour come handy.
> > >
> > > Cheers!
> > >
>

Re: [julia-users] Creating symbols

[Stefan Karpinski]

It should be made part of the Symbol constructor. There used to be a
technical limitation that only composite types could be called as
constructors. As a result, there are still a fair number of lowercase
functions that that should be merged into constructors like Symbol.

On Wed, Apr 20, 2016 at 6:26 AM, Didier Verna 
wrote:

>
>   Out of curiosity, why the symbol function? I mean, why not making
>   this functionality part of the Symbol constructor?
>
> --
> ELS'16 registration open! http://www.european-lisp-symposium.org
>
> Lisp, Jazz, Aïkido: http://www.didierverna.info
>

Re: [julia-users] julia make julia-deps error: (I may have solved a case)

[Yichao Yu]

On Wed, Apr 20, 2016 at 5:46 AM, louis scott  wrote:
> I think I solved at least one case.
> It helps that I just did a fresh install of mint rosa xfce edition, so it
> looks more like a machine that hasn't done development.
> A dev machine would have the missing parts as a matter of course.

The required tools/libraries are listed here:
https://github.com/JuliaLang/julia#required-build-tools-and-external-libraries
Feel free to report any missing/out-of-date info.

>
> The issue is that make does not get all dependencies.  I was missing cmake
> and libssl-dev.
>
> To see this, I reran saving the output and searched for "rror".
>
>>> make -j 2 2>&1 | tee makejulia.txt
>
> Making clean in m4
> patching file CMakeLists.txt
> Hunk #1 succeeded at 274 (offset 57 lines).
> /bin/sh: 2: cmake: not found
> make[1]: ***
> [build/libgit2-785d8c48ea8725691da3c50e7dae8751523d4c30/Makefile] Error 127
>
> 
> So I install cmake, try again
> 
>
> :
> -- checking for module 'libcurl'
> --   package 'libcurl' not found
> CMake Error at
> /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108
> (message):
>   Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
>   system variable OPENSSL_ROOT_DIR (missing: OPENSSL_LIBRARIES
>   OPENSSL_INCLUDE_DIR)
> Call Stack (most recent call first):
>   /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315
> (_FPHSA_FAILURE_MESSAGE)
>   /usr/share/cmake-2.8/Modules/FindOpenSSL.cmake:313
> (find_package_handle_standard_args)
>   CMakeLists.txt:277 (FIND_PACKAGE)
>
>
> -- Configuring incomplete, errors occurred!
> :
> :
> OpenBLAS build complete. (BLAS CBLAS LAPACK LAPACKE)
>
>   OS   ... Linux
>   Architecture ... x86_64
>   BINARY   ... 64bit
>   Use 64 bits int(equivalent to "-i8" in Fortran)
>   C compiler   ... GCC  (command line : gcc -m64)
>   Fortran compiler ... GFORTRAN  (command line : gfortran -m64)
>   Library Name ... libopenblas64_p-r0.2.18.a (Multi threaded; Max
> num-threads is 16)
>
> To install the library, you can run "make PREFIX=/path/to/your/installation
> install".
>
> make: *** [julia-deps] Error 2
>
> ~~~
> It stops at gfortran, but the problem is actually here:
>
> The lines in CMAkeLists.tct:277 are here:
>
> IF (NOT AMIGA AND USE_OPENSSL)
> FIND_PACKAGE(OpenSSL REQUIRED)
> ENDIF ()
>
> I check
> dpkg -s libcurl3  is OK
> dpkg -s openssl is OK
> dpkg -s openssl-dev is missing, I install it
>
> make now runs to completion.
>

Re: [julia-users] Re: Change bold text in REPL to normal

[Yichao Yu]

On Wed, Apr 20, 2016 at 10:11 AM,   wrote:
> I see. To get normal weight, red, warn() text, this works for me:
>
> Base.text_colors[:rednormal] = "\033[0m\033[31m"
> Base.eval(parse("default_color_warn = :rednormal"))

Base.eval(:(default_color_warn = :rednormal))

at least. You almost never want to use `parse` and then `eval`.

>
> text_colors is defined in base/client.jl
>
> On Wednesday, April 20, 2016 at 3:10:19 PM UTC+2, cormu...@mac.com wrote:
>>
>> Thanks, useful info. Although, I don't mind the colors. It's the forced
>> bolding that looks so bad... :(

[julia-users] julia make julia-deps error: (I may have solved a case)

[louis scott]

I think I solved at least one case.  
It helps that I just did a fresh install of mint rosa xfce edition, so it 
looks more like a machine that hasn't done development.
A dev machine would have the missing parts as a matter of course.

The issue is that make does not get all dependencies.  I was missing cmake 
and libssl-dev.

To see this, I reran saving the output and searched for "rror".

>> make -j 2 2>&1 | tee makejulia.txt

Making clean in m4
patching file CMakeLists.txt
Hunk #1 succeeded at 274 (offset 57 lines).
/bin/sh: 2: cmake: not found
make[1]: *** 
[build/libgit2-785d8c48ea8725691da3c50e7dae8751523d4c30/Makefile] Error 127


So I install cmake, try again


:
-- checking for module 'libcurl'
--   package 'libcurl' not found
CMake Error at 
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 
(message):
  Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
  system variable OPENSSL_ROOT_DIR (missing: OPENSSL_LIBRARIES
  OPENSSL_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315 
(_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-2.8/Modules/FindOpenSSL.cmake:313 
(find_package_handle_standard_args)
  CMakeLists.txt:277 (FIND_PACKAGE)


-- Configuring incomplete, errors occurred!
:
:
OpenBLAS build complete. (BLAS CBLAS LAPACK LAPACKE)

  OS   ... Linux 
  Architecture ... x86_64   
  BINARY   ... 64bit 
  Use 64 bits int(equivalent to "-i8" in Fortran)  
  C compiler   ... GCC  (command line : gcc -m64)
  Fortran compiler ... GFORTRAN  (command line : gfortran -m64)
  Library Name ... libopenblas64_p-r0.2.18.a (Multi threaded; Max 
num-threads is 16)

To install the library, you can run "make PREFIX=/path/to/your/installation 
install".

make: *** [julia-deps] Error 2

~~~
It stops at gfortran, but the problem is actually here:

The lines in CMAkeLists.tct:277 are here:

IF (NOT AMIGA AND USE_OPENSSL)
FIND_PACKAGE(OpenSSL REQUIRED)
ENDIF ()

I check 
dpkg -s libcurl3  is OK
dpkg -s openssl is OK
dpkg -s openssl-dev is missing, I install it

make now runs to completion.

[julia-users] Creating symbols

[Didier Verna]

  Out of curiosity, why the symbol function? I mean, why not making
  this functionality part of the Symbol constructor?

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

[julia-users] Re: an error with DataFrames on Ubuntu 16.04 64bits

[Henri Girard]

I compile version 5.0 without any problems on 16.04 and the repos ones are 
working fine.

Le dimanche 17 avril 2016 14:15:35 UTC+2, K leo a écrit :
>
> Run my julia code for the first time after setting julia up on Ubuntu 
> 16.04, I got the following errors:
>
> INFO: Precompiling module DataFrames...
> ERROR: LoadError: LoadError: error compiling anonymous: could not load 
> library "libz"
> libz: cannot open shared object file: No such file or directory
> while loading /home/xxx/.julia/v0.4/GZip/src/zlib_h.jl, in expression 
> starting on line 8
> while loading /home/xxx/.julia/v0.4/GZip/src/GZip.jl, in expression 
> starting on line 75
> ERROR: LoadError: Failed to precompile GZip to 
> /home/xxx/.julia/lib/v0.4/GZip.ji
> while loading /home/xxx/.julia/v0.4/DataFrames/src/DataFrames.jl, in 
> expression starting on line 15
> ERROR: LoadError: LoadError: LoadError: Failed to precompile DataFrames to 
> /home/xxx/.julia/lib/v0.4/DataFrames.ji
>  in compilecache at ./loading.jl:400
>
>
> After some searching, I found that I had to install lib32z1 and 
> lib32z1-dev on Ubuntu.  Not sure why these are missing with the new Ubuntu.
>

[julia-users] modules (documentation)

[Didier Verna]

  There are a couple of things that I find obscure in the modules
  documentation.

It says that import operates on a single name at a time, but there's a
counter-example in the table right below this sentence: import MyModule
which looks like it imports a module as a whole.

On the other hand, the table in question says that with such a
directive, MyModule.x (and y and p) are "brought into scope" and
"available for method extension". But from what I could gather, it seems
to me that the dot notation always makes everything available. So it
would rather seem that import MyModule is a no-op. Is that correct?

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

[julia-users] Re: Mathematical Computing course in Julia

[Henri Girard]

Thank you very much... I am trying to start julia with jupyter notebook and 
your course is really helpfull
Kind regards
Henri

Le vendredi 15 avril 2016 04:17:40 UTC+2, Sheehan Olver a écrit :
>
>
>
> I'm currently lecturing the course MATH3076/3976 Mathematical Computing at 
> U. Sydney in Julia, and thought that others may be interested in the 
> resources I've provided:
>
> http://www.maths.usyd.edu.au/u/olver/teaching/MATH3976/
>
> The lecture notes and labs are all Jupyter notebooks.  I've also included 
> a "cheat sheet" of Julia commands used in the course
>
>
> http://nbviewer.jupyter.org/url/www.maths.usyd.edu.au/u/olver/teaching/MATH3976/cheatsheet.ipynb
>
> The course is ongoing (it's about half through) and will continue to take 
> shape, but any feedback is of course welcome!
>
>
> Sheehan Olver
>

[julia-users] Re: Change bold text in REPL to normal

[lapeyre . math122a]

I see. To get normal weight, red, warn() text, this works for me:

Base.text_colors[:rednormal] = "\033[0m\033[31m"
Base.eval(parse("default_color_warn = :rednormal"))

text_colors is defined in base/client.jl

On Wednesday, April 20, 2016 at 3:10:19 PM UTC+2, cormu...@mac.com wrote:
>
> Thanks, useful info. Although, I don't mind the colors. It's the forced 
> bolding that looks so bad... :(
>>
>>

[julia-users] Re: methods ambiguity

[Cedric St-Jean]

Julia has parametric types though.

f{T}(x::Vector{T}, b::Int) = 1
f{T<:Real}(x::Vector{T}, b) = 2

f([1,2], 5)


On Wednesday, April 20, 2016 at 7:43:08 AM UTC-4, Tamas Papp wrote:
>
> On Monday, April 18, 2016 at 9:38:40 PM UTC+2, Steven G. Johnson wrote:
>>
>>
>>
>> On Monday, April 18, 2016 at 10:38:28 AM UTC-4, Didier Verna wrote:
>>>
>>>
>>>   Julia warns you when there's an ambiguity in method specificity, and 
>>>   picks one "arbitrarily" (according to the manual). I guess arbitrarily 
>>>   doesn't mean random. Is there a particular reason for not 
>>>   standardizing a tie-breaker (possibly the one currently in use) ? 
>>>
>>
>> Because any practical tie-breaker rules are probably too complicated to 
>> be useful?
>>
>
> The tie-breaking rule of CLOS (lexicographic/left to right) doesn't look 
> so complicated, especially given that Julia has no multiple inheritance or 
> method combinations.
>
> Best,
>
> Tamas
>

[julia-users] Re: macros design

[Matt Bauman]

On Wednesday, April 20, 2016 at 8:58:35 AM UTC-4, Didier Verna wrote:
>
>
>   What's the rationale behind this particular way of invoking macros 
>   (the @ character) ?


It's nice for both humans (it's obvious that there could be some 
non-standard evaluation semantics or other such funniness) and the parser 
(it knows exactly which symbols it needs to resolve in order to expand the 
macros since nothing else can contain the @ character).
 

> And why a single macro concept for two different 
>   things (with or without arguments) ? 
>

Are you talking about the optional parentheses?  That is: `@m(x,y)` vs `@m 
x y`?  It's very convenient to have the parentheses-less version for macros 
like @inline and @simd which annotate or transform existing structures. 
 And parentheses with comma-separated arguments can be nice in cases where 
the distinction between several arguments might get fuzzy otherwise.

On Wednesday, April 20, 2016 at 9:19:03 AM UTC-4, Didier Verna wrote:
>
>  Also, I'm wondering about the use of RETURN in all the one-liner 
> macro examples from the manual.


Yup, implicit return works for macros, too.  The manual makes it explicit 
to emphasize the function-like syntax transformation (as opposed to 
CPP-like textual substitution). 

[julia-users] Re: macros design

[cormullion]

https://github.com/JuliaLang/julia/blob/3c354b4a391307d84915445bdd6fb464371f30fc/doc/at_macro_reasons

[julia-users] Re: macros design

[Didier Verna]

I wrote:

>   What's the rationale behind this particular way of invoking macros
>   (the @ character) ? And why a single macro concept for two different
>   things (with or without arguments) ?

Also, I'm wondering about the use of RETURN in all the one-liner
macro examples from the manual. Why not just:

macro sayhello()
  :( println("Hello, world!") )
end

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

[julia-users] Re: Change bold text in REPL to normal

[cormullion]

Thanks, useful info. Although, I don't mind the colors. It's the forced 
bolding that looks so bad... :(
>
>

[julia-users] Re: Warning on operations mixing BigFloat and Float64

[Daan Huybrechs]

I was not aware of that, but it is good to know - thanks!
By now we are actually mixing different precision on purpose here and 
there, using standard conversions, so our current test is to solve a number 
of problems to well below double precision accuracy.

On Wednesday, April 20, 2016 at 11:48:31 AM UTC+2, Paweł Biernat wrote:
>
> Thanks!  I will try that.  I might be wrong, but looking at the code of 
> mpfr.jl I can find some functions that mix BigFloat and Float64 that don't 
> rely on a convert, instead they just pass the arguments directly to the 
> mpfr library (this 
>  line 
> for example).  I ended up writing a minimal implementation of an 
> AbstractNumber type, and so far it worked out pretty well.
>
> W dniu wtorek, 19 kwietnia 2016 15:17:31 UTC+2 użytkownik Daan Huybrechs 
> napisał:
>>
>> I second that - overwriting the conversion worked very well for me while 
>> debugging some time ago. If you throw an error, you get the exact line 
>> number where it happened:
>>
>> Base.convert(::Type{BigFloat}, x::Float64) = throw(InexactError())
>>
>> One case to watch out for, which I only found in my code with the above 
>> trick, is the automatic conversion of builtin constants to Float64. For 
>> example, 2*pi is a Float64. To be safe in a mixed precision environment, if 
>> T is the numeric type you are working with, you could write 2*T(pi).
>>
>> On Tuesday, April 19, 2016 at 12:07:48 AM UTC+2, Greg Plowman wrote:
>>>
>>> Perhaps you could overwrite the convert function to include a warning.
>>> (Maybe just temporarily until you discover all the conversions)
>>>  
>>> As an example, this is a quick hack, modified from definition in mpfr.jl
>>>
>>> @eval begin
>>> function Base.convert(::Type{BigFloat}, x::Float64)
>>> println("*** Warning: converting Float64 to BigFloat")
>>> z = BigFloat()
>>> ccall(($(string(:mpfr_set_,:d)), :libmpfr), Int32, (Ptr{BigFloat
>>> }, Float64, Int32), &z, x, Base.MPFR.ROUNDING_MODE[end])
>>> return z
>>> end
>>> end
>>>
>>>
>>> julia> BigFloat(3.0) + 2.5
>>> *** Warning: converting Float64 to BigFloat
>>>
>>> 5.50
>>>
>>>
>>>
>>>
>>> On Tuesday, April 19, 2016 at 1:50:52 AM UTC+10, Paweł Biernat wrote:
>>>
 I know about the promotion, but this is precisely what I want to 
 avoid.  It might happen that there are hard-coded Float64 constants 
 somewhere in the code and I would like to locate them and replace with 
 higher precision ones.  I could probably just do a direct search in the 
 source code to locate these spots but I still might miss some of them.  I 
 guess it would be safer to just print a warning when an operations mixing 
 both types occurs and then eliminate these spots case by case.

 Maybe defining my own AbstractFloat type with a minimal set of 
 operations and passing it as an argument instead of BigFloat would be a 
 better solution.  Then if I don't implement the operations involving 
 Float64 I will get an error every time the mixing occurs.

 W dniu poniedziałek, 18 kwietnia 2016 17:28:14 UTC+2 użytkownik Tomas 
 Lycken napisał:
>
> Adding a BigFloat and a Float64 should automatically promote both to 
> BigFloats, avoiding precision loss for you.
>
> julia> BigFloat(2.9) + 0.3
> 3.199900079927783735911361873149871826171875
>
> Do you have a case where this doesn’t happen?
>
> // T
>
> On Monday, April 18, 2016 at 4:32:52 PM UTC+2, Paweł Biernat wrote:
>
> Hi,
>>
>> I want to make sure I am not loosing any precision in my code by 
>> accidentally mixing BigFloat and Float64 (e.g. adding two numbers of 
>> different precision).  I was thinking about replacing the definitions of 
>> `+`, `-`, etc. for BigFloat but if you do that for all two argument 
>> functions this would be a lot of redefining, so I started to wonder if 
>> there is a more clever approach.  Is there any simple hack to get a 
>> warning 
>> if this happens?
>>
>> Best,
>> Paweł
>>
>> ​
>

[julia-users] Re: methods ambiguity

[Tamas Papp]

On Monday, April 18, 2016 at 9:38:40 PM UTC+2, Steven G. Johnson wrote:
>
>
>
> On Monday, April 18, 2016 at 10:38:28 AM UTC-4, Didier Verna wrote:
>>
>>
>>   Julia warns you when there's an ambiguity in method specificity, and 
>>   picks one "arbitrarily" (according to the manual). I guess arbitrarily 
>>   doesn't mean random. Is there a particular reason for not 
>>   standardizing a tie-breaker (possibly the one currently in use) ? 
>>
>
> Because any practical tie-breaker rules are probably too complicated to be 
> useful?
>

The tie-breaking rule of CLOS (lexicographic/left to right) doesn't look so 
complicated, especially given that Julia has no multiple inheritance or 
method combinations.

Best,

Tamas

[julia-users] Julia Package Ecosystem Pulse Last updated 2016-03-17?

[Andreas Lobinger]

Hello colleagues,

i learned this is triggered manually and not regularly, however looking at 
the webpage updates of 7 or 14 days are mentioned.

Wishing a happy day,
 Andreas

Re: [julia-users] Re: Rounding to zero from positive or negative numbers results in positive or negative zero.

[Milan Bouchet-Valat]

Le mardi 19 avril 2016 à 22:10 -0700, Jeffrey Sarnoff a écrit :
> Hi,
> 
> You have discovered that IEEE standard floating point numbers have
> two distinct zeros: 0.0 and -0.0.  They compare `==` even though they
> are not `===`.  If you want to consider +0.0 and -0.0 to be the same,
> use `==` or `!=` not `===`  or `!==` when testing floating point
> values (the other comparisons <=, <, >=, > treat the two zeros as a
> single value).
There's actually an open issue about what to do with -0.0 and NaN in
Dicts: https://github.com/JuliaLang/julia/issues/9381

It turns out it's very hard to find a good solution.


Regards

> > Hello everyone!
> > I was wondering if the following behavior of round() has an special
> > purpouse:
> > 
> > a = round(0.1)
> > 0.0
> > 
> > b = round(-0.1)
> > -0.0
> > 
> > a == b
> > true
> > 
> > a === b
> > false
> > 
> > bits(a)
> > ""
> > 
> > 
> > bits(b)
> > "1000"
> > 
> > So the sign stays around...
> > 
> > I am using this rounded numbers as keys in a dictionary and julia
> > can tell the difference. 
> > 
> > For example, I expected something like this:
> > dict = [i => exp(i) for i in [a,b]]
> > Dict{Any,Any} with 1 entry:
> >  0.0 => 1.0
> > 
> > but got this:
> > dict = [i => exp(i) for i in [a,b]]
> > Dict{Any,Any} with 2 entries:
> >   0.0  => 1.0
> >   -0.0 => 1.0
> > 
> > It is not a big problem really but I would like to know where can
> > this behaviour come handy.
> > 
> > Cheers!
> > 

[julia-users] Re: Warning on operations mixing BigFloat and Float64

[Paweł Biernat]

Thanks!  I will try that.  I might be wrong, but looking at the code of 
mpfr.jl I can find some functions that mix BigFloat and Float64 that don't 
rely on a convert, instead they just pass the arguments directly to the 
mpfr library (this 
 line for 
example).  I ended up writing a minimal implementation of an AbstractNumber 
type, and so far it worked out pretty well.

W dniu wtorek, 19 kwietnia 2016 15:17:31 UTC+2 użytkownik Daan Huybrechs 
napisał:
>
> I second that - overwriting the conversion worked very well for me while 
> debugging some time ago. If you throw an error, you get the exact line 
> number where it happened:
>
> Base.convert(::Type{BigFloat}, x::Float64) = throw(InexactError())
>
> One case to watch out for, which I only found in my code with the above 
> trick, is the automatic conversion of builtin constants to Float64. For 
> example, 2*pi is a Float64. To be safe in a mixed precision environment, if 
> T is the numeric type you are working with, you could write 2*T(pi).
>
> On Tuesday, April 19, 2016 at 12:07:48 AM UTC+2, Greg Plowman wrote:
>>
>> Perhaps you could overwrite the convert function to include a warning.
>> (Maybe just temporarily until you discover all the conversions)
>>  
>> As an example, this is a quick hack, modified from definition in mpfr.jl
>>
>> @eval begin
>> function Base.convert(::Type{BigFloat}, x::Float64)
>> println("*** Warning: converting Float64 to BigFloat")
>> z = BigFloat()
>> ccall(($(string(:mpfr_set_,:d)), :libmpfr), Int32, (Ptr{BigFloat
>> }, Float64, Int32), &z, x, Base.MPFR.ROUNDING_MODE[end])
>> return z
>> end
>> end
>>
>>
>> julia> BigFloat(3.0) + 2.5
>> *** Warning: converting Float64 to BigFloat
>>
>> 5.50
>>
>>
>>
>>
>> On Tuesday, April 19, 2016 at 1:50:52 AM UTC+10, Paweł Biernat wrote:
>>
>>> I know about the promotion, but this is precisely what I want to avoid.  
>>> It might happen that there are hard-coded Float64 constants somewhere in 
>>> the code and I would like to locate them and replace with higher precision 
>>> ones.  I could probably just do a direct search in the source code to 
>>> locate these spots but I still might miss some of them.  I guess it would 
>>> be safer to just print a warning when an operations mixing both types 
>>> occurs and then eliminate these spots case by case.
>>>
>>> Maybe defining my own AbstractFloat type with a minimal set of 
>>> operations and passing it as an argument instead of BigFloat would be a 
>>> better solution.  Then if I don't implement the operations involving 
>>> Float64 I will get an error every time the mixing occurs.
>>>
>>> W dniu poniedziałek, 18 kwietnia 2016 17:28:14 UTC+2 użytkownik Tomas 
>>> Lycken napisał:

 Adding a BigFloat and a Float64 should automatically promote both to 
 BigFloats, avoiding precision loss for you.

 julia> BigFloat(2.9) + 0.3
 3.199900079927783735911361873149871826171875

 Do you have a case where this doesn’t happen?

 // T

 On Monday, April 18, 2016 at 4:32:52 PM UTC+2, Paweł Biernat wrote:

 Hi,
>
> I want to make sure I am not loosing any precision in my code by 
> accidentally mixing BigFloat and Float64 (e.g. adding two numbers of 
> different precision).  I was thinking about replacing the definitions of 
> `+`, `-`, etc. for BigFloat but if you do that for all two argument 
> functions this would be a lot of redefining, so I started to wonder if 
> there is a more clever approach.  Is there any simple hack to get a 
> warning 
> if this happens?
>
> Best,
> Paweł
>
> ​

>>>

Re: [julia-users] Re: Add packages as root?

[Maurice Diamantini]

Thank you very much, I'll do that.
But I hope there will be a better way to do that before the 1.0 Julia 
version!
-- Maurice

Le mardi 19 avril 2016 18:04:09 UTC+2, Yichao Yu a écrit :
>
> On Tue, Apr 19, 2016 at 11:22 AM, Maurice Diamantini 
> > wrote: 
> > 
> > Since two years have passed since the original question, is there now a 
> > standard way to install some packages for them to be available for all 
> the 
> > users? 
> > If not wat is the actuel hack to do that? 
>
> You can install into `LOAD_PATH`. `Pkg` operations are still not well 
> supported though (even the read-only ones) 
>
>

Re: [julia-users] In these two ways to "create functions", which one is a better way?

[David P. Sanders]

If this is your actual use case, then I suggest checking out the Polynomials.jl 
package. 

In particular, there is a more efficient algorithm (Horner's algorithm) that 
you can use to actually evaluate such a function. 

[julia-users] Rounding to zero from positive or negative numbers results in positive or negative zero.

[David P. Sanders]

You can avoid the problem using

round(Int, x) 

Which returns the result as an integer. Integers do not have this situation 
(difference between +0.0 and -0.0)