Re: [julia-users] Forming a structure made of complex and real numbers?

[Mauro]

> type DB
>   Y::Vector{Complex128}
>   W::Vector{Float64}
> end
>
> y = Array(Complex128,100)
> w = Array(Float64,100)
>
> data = Array(DB,100) # making an array of 100 elements of type DB

This just creates an array of pointers to DB objects but the DB objects
themselves are not created.  Thus if you look at it:

julia> data
100-element Array{DB,1}:
 #undef
 #undef


Note that Array(Complex128,100) doesn't contain undefs as its elements
are isbits types thus not accessed via pointer indirection. (but its
elements are random).

> data[10].Y = 2.0+3.0im   # this results in an getindex error as there is no 
> method to support the assignment. 

So this tries to access an undef object, further it also tries
assigning a scalar to a vector.  You can do for instance:

julia> data[10] = DB(y,w)
DB(Complex{Float64}[6.03421e-316+

If you want to fill them all, then iteration is the way forward.  Better
get used to iteration, it crops up a lot...

> Can someone advise the correct syntax for making data an array with 100 
> elements of type DB and filling it with vectors instead of iterating 
> through the assignment of the elements?
>
>
>>>  

Re: [julia-users] Warning: gc_disable() can cause Travis to kill process, and fail tests

[Keno Fischer]

You can put `sudo dmesg` in your travis script block, which will show you
messages from the OOM killer if the job did run out of memory.

On Sun, Jul 26, 2015 at 2:20 AM, Sheehan Olver 
wrote:

>
> I spent a bit of time trying to figure out why tests were failing on
> Travis but not locally.  It turned out that the issue was a call to
> gc_disable() causing the test to reach Travis's 3gig memory limit.
>
> I thought I should post a note so that people are aware of this possible
> cause for failing Travis checks.
>

[julia-users] Warning: gc_disable() can cause Travis to kill process, and fail tests

[Sheehan Olver]

I spent a bit of time trying to figure out why tests were failing on Travis 
but not locally.  It turned out that the issue was a call to gc_disable() 
causing the test to reach Travis's 3gig memory limit.  

I thought I should post a note so that people are aware of this possible 
cause for failing Travis checks.

Re: [julia-users] Forming a structure made of complex and real numbers?

[Joe Tusek]

Tom thanks, sorry to be asking such basic questions, I have access to the 
reference manual but can't get enough out of it to see what the correct 
syntax is. I settled on trying just some simple code as below that 
was making a structure DB and then trying to make an array of 100 elements 
with that  structure 

type DB
  Y::Vector{Complex128}
  W::Vector{Float64}
end

y = Array(Complex128,100)
w = Array(Float64,100)

data = Array(DB,100) # making an array of 100 elements of type DB

data[10].Y = 2.0+3.0im   # this results in an getindex error as there is no 
method to support the assignment. 

Can someone advise the correct syntax for making data an array with 100 
elements of type DB and filling it with vectors instead of iterating 
through the assignment of the elements?


>>  

[julia-users] Re: San Francisco Bay meetup: Jeff Bezanson on Aug 13, future meetups

[Tony Kelman]

Thanks for picking up the organization on this Christian!


On Saturday, July 25, 2015 at 4:15:47 PM UTC-7, Christian Peel wrote:
>
> We will have a meetup in San Francisco on Aug 13 with Jeff Bezanson 
> speaking on "Julia: future directions and speculations", and Kyle Barbary 
> speaking on JuliaAstro.  See 
> http://www.meetup.com/Bay-Area-Julia-Users/events/223908654/ for more 
> info and to register. We're grateful to Forio for hosting.
>
> If you are now or will be in the San Francisco Bay area and are working on 
> Julia, we'd love to hear from you. We're looking for refreshed versions of 
> JuliaCon talks (as Jeff and Kyle are doing), new results, or even talks on 
> the history of scientific computing.  The more lead-time before your visit, 
> the easier it is to schedule something; send me an email and we'll make 
> plans.
>
> My best
> -- 
> chris...@ieee.org 
>  

[julia-users] Re: John L. Gustafson's UNUMs

[Scott Jones]

This seems interesting, I'd like to know what David Sanders 
(https://github.com/dpsanders) thinks of the math (I missed his talk at 
JuliaCon, I'm waiting for the video, but the description made it sound 
relevant).

There also doesn't seem to be any representation of -0.0, which from what 
I've read, is important to represent negative underflows.
(however, I really don't understand why there isn't a corresponding value 
for positive underflows in the IEEE formats, in addition to an exact 0)
Why it is displayed as -0.0, instead of something like -Und, 0, and Und, 
similarly to -Inf and Inf, I just don't get.
(If any mathematicians would please explain that to me, I'd appreciate it!)

I also wonder how well this would work for all the array based math used in 
Julia, where you'd really like all the values to have a fixed size
for fast indexing.
I can think of some ways, using an extra bit to say that the real value is 
not in place, but rather in an overflow vector, and then have those
allocated with a big enough size to handle larger precision, I'm not sure 
how that would perform though, it would depend a lot on how many values had 
to be promoted to a larger size.

Finally, I'd wonder, in the absence of hardware that could directly handle 
UNUMs, if this would really be any better than the packing I've been doing 
for decades (to save space in a database and in in-memory structures, where 
things are read much more than written or modified).
(in my old format, I used length/type bytes (which could be 1 or 2 bytes 
normally, or more, to handle up to 8-byte lengths), followed by packed 
data, for example, non-negative integers were represented by 0-n bytes 
after the type/length info), negative integers represented by 0-n without 
any trailing 0xFF bytes, scaled decimals had a 1 or 2 byte signed scale, 
followed by 0-n bytes (same separation of negative/non-negative for ease of 
packing/unpacking).  The format also handles Null, packed strings (binary, 
8-bit text, and Unicode), and binary floating point values
(also packed, first using float format instead of double, if (float)x == x, 
and then eliminating LSBs of 0, which makes a 0 not take any extra bytes, 
and many small values just take 1 or 2 extra bytes).

-Scott

On Saturday, July 25, 2015 at 5:46:32 PM UTC-4, Job van der Zwan wrote:
>
> On Saturday, 25 July 2015 23:34:45 UTC+3, Simon Byrne wrote:
>>
>> Some HN discussion here:
>> https://news.ycombinator.com/item?id=9943589
>>
>
> Oh, hadn't seen that. The linked presentation is also more recent! I found 
> the "slidecast" version of it, where he presents the slides in podcast 
> form.  He's evangelizing a 
> bit, but, well... I guess that makes sense given the topic.
>
> I'd be keen to know more but he hasn't really published any details other 
>> than his book 
>> . 
>> Based 
>> on the free preview, it looks like a bit of a diatribe rather than a 
>> detailed technical proposal, but you can look at his mathematica code 
>> here 
>> 
>> .
>>
>
> Well, if you decide to go against something as well-established as the way 
> we've been doing integer and floating point arithmetic, you're probably 
> going to need a lot of explanation in a very accessible style - because you 
> definitely won't have the experts on your side.
>

[julia-users] Re: Using a macro argument as a symbol, inside the returned quote

[Tomas Lycken]

For reference: https://github.com/JuliaLang/julia/pull/12314

On Sunday, July 26, 2015 at 2:04:01 AM UTC+2, Tomas Lycken wrote:
>
> Actually, I probably don't need a macro for this - all I need to do is to 
> call both `workspace()` and `include(`~/.juliarc.jl`) :)
>
> It turns out there's already a function that does most of the plumbing: 
> `Base.load_juliarc()`. Thus, `workspace(); Base.load_juliarc()` does 
> exactly what I need.
>
> I'll file a PR that makes `workspace()` call `load_juliarc()`, since it 
> feels intuitive that it should, but since it's possible to just call both 
> functions manually I'm in no way blocked by it :)
>
> Thanks for the help!
>
> // T
>
> On Sunday, July 26, 2015 at 1:48:43 AM UTC+2, David Gold wrote:
>>
>> Hmm...
>>
>> You could write an `@workspace` macro that calls `workspace()` and then 
>> declares itself and the `quickload` macro... =p
>>
>> On Saturday, July 25, 2015 at 7:09:26 PM UTC-4, Tomas Lycken wrote:
>>>
>>> Fantastic - thanks a lot!
>>>
>>> The final form of the macro is then the following:
>>>
>>> macro quickload(m)
>>> _m = Expr(:quote, m)
>>>
>>> quote
>>> if isdefined(:LastMain) && isdefined(LastMain, $_m)
>>> using LastMain.$m
>>> else
>>> using $m
>>> end
>>> end
>>> end
>>>
>>> This works very well - except that I have to define it in each new 
>>> workspace… Adding it to .juliarc.jl does make it available on start, 
>>> but after workspace() it’s not available anymore, and kind-of looses 
>>> its point…
>>>
>>> Any suggestions?
>>>
>>> // T
>>>
>>> On Sunday, July 26, 2015 at 12:58:28 AM UTC+2, David Gold wrote:
>>>
>>> This seems to work:

 julia> macro foo(bar)
_bar = Expr(:quote, bar) 
res = Expr(:call, :isdefined, :($_bar)) 
return res 
end 

 julia> macroexpand(:( @foo(baz) )) 
 :(isdefined(:baz))



 On Saturday, July 25, 2015 at 6:30:08 PM UTC-4, Tomas Lycken wrote:
>
> Hi everybody!
>
> Is there a way to use a macro argument as an actual Symbol in the 
> quote that the macro returns? The following can hopefully help explaining 
> what I want:
>
> ```
> julia> macro foo(bar)
>:(isdefined($bar))
>end
>
> julia> macroexpand(:(@foo baz))
> :(isdefined(baz)) # I had hoped for :(isdefined(:baz)) - with :baz 
> instead of baz
> ```
>
> I've tried various combinations of interpolation, escaping and passing 
> arguments to `symbol`, but to no avail. Is there a way to accomplish this?
>
> --- Actual use case below ---
>
> I noticed a very common pattern in my workflow that I wanted to 
> abstract away to make it quicker and easier:
>
> *I want to load module X. If it's in LastMain, it's much faster to get 
> it from there, but otherwise I need to load it from scratch.*
>
> I can easily write code that does this. Take, for example, Gadfly:
>
> ```
> (isdefined(:LastMain) && isdefined(LastMain, :Gadfly) && using 
> LastMain.Gadfly) || using Gadfly
> ```
>
> When I execute that code, Gadfly will load from LastMain if available 
> there, and from scratch otherwise. And it won't error out if I haven't 
> called `workspace()` at all yet. Perfect! But having to type that for 
> each 
> module I want to use the workflow for is a hassle - what if `@quickload 
> Gadfly` would do the same thing? This is my attempt so far:
>
> ```
> julia> macro quickload(m)
>:((isdefined(:LastMain) && isdefined(LastMain, $m #= what do I 
> put here?=#) && using LastMain.$m) || using $m)
>end
>
> julia> macroexpand(:(@quickload Gadfly))
> :((isdefined(:LastMain) && isdefined(LastMain,Gadfly #= <-- ...to make 
> that :Gadfly instead of Gadfly =#)) && using LastMain.Gadfly || using 
> Gadfly)
>
> ```
>
> Thanks in advance!
>
> // T
>
 ​
>>>
>>

[julia-users] Re: Using a macro argument as a symbol, inside the returned quote

[Tomas Lycken]

Actually, I probably don't need a macro for this - all I need to do is to 
call both `workspace()` and `include(`~/.juliarc.jl`) :)

It turns out there's already a function that does most of the plumbing: 
`Base.load_juliarc()`. Thus, `workspace(); Base.load_juliarc()` does 
exactly what I need.

I'll file a PR that makes `workspace()` call `load_juliarc()`, since it 
feels intuitive that it should, but since it's possible to just call both 
functions manually I'm in no way blocked by it :)

Thanks for the help!

// T

On Sunday, July 26, 2015 at 1:48:43 AM UTC+2, David Gold wrote:
>
> Hmm...
>
> You could write an `@workspace` macro that calls `workspace()` and then 
> declares itself and the `quickload` macro... =p
>
> On Saturday, July 25, 2015 at 7:09:26 PM UTC-4, Tomas Lycken wrote:
>>
>> Fantastic - thanks a lot!
>>
>> The final form of the macro is then the following:
>>
>> macro quickload(m)
>> _m = Expr(:quote, m)
>>
>> quote
>> if isdefined(:LastMain) && isdefined(LastMain, $_m)
>> using LastMain.$m
>> else
>> using $m
>> end
>> end
>> end
>>
>> This works very well - except that I have to define it in each new 
>> workspace… Adding it to .juliarc.jl does make it available on start, but 
>> after workspace() it’s not available anymore, and kind-of looses its 
>> point…
>>
>> Any suggestions?
>>
>> // T
>>
>> On Sunday, July 26, 2015 at 12:58:28 AM UTC+2, David Gold wrote:
>>
>> This seems to work:
>>>
>>> julia> macro foo(bar)
>>>_bar = Expr(:quote, bar) 
>>>res = Expr(:call, :isdefined, :($_bar)) 
>>>return res 
>>>end 
>>>
>>> julia> macroexpand(:( @foo(baz) )) 
>>> :(isdefined(:baz))
>>>
>>>
>>>
>>> On Saturday, July 25, 2015 at 6:30:08 PM UTC-4, Tomas Lycken wrote:

 Hi everybody!

 Is there a way to use a macro argument as an actual Symbol in the quote 
 that the macro returns? The following can hopefully help explaining what I 
 want:

 ```
 julia> macro foo(bar)
:(isdefined($bar))
end

 julia> macroexpand(:(@foo baz))
 :(isdefined(baz)) # I had hoped for :(isdefined(:baz)) - with :baz 
 instead of baz
 ```

 I've tried various combinations of interpolation, escaping and passing 
 arguments to `symbol`, but to no avail. Is there a way to accomplish this?

 --- Actual use case below ---

 I noticed a very common pattern in my workflow that I wanted to 
 abstract away to make it quicker and easier:

 *I want to load module X. If it's in LastMain, it's much faster to get 
 it from there, but otherwise I need to load it from scratch.*

 I can easily write code that does this. Take, for example, Gadfly:

 ```
 (isdefined(:LastMain) && isdefined(LastMain, :Gadfly) && using 
 LastMain.Gadfly) || using Gadfly
 ```

 When I execute that code, Gadfly will load from LastMain if available 
 there, and from scratch otherwise. And it won't error out if I haven't 
 called `workspace()` at all yet. Perfect! But having to type that for each 
 module I want to use the workflow for is a hassle - what if `@quickload 
 Gadfly` would do the same thing? This is my attempt so far:

 ```
 julia> macro quickload(m)
:((isdefined(:LastMain) && isdefined(LastMain, $m #= what do I 
 put here?=#) && using LastMain.$m) || using $m)
end

 julia> macroexpand(:(@quickload Gadfly))
 :((isdefined(:LastMain) && isdefined(LastMain,Gadfly #= <-- ...to make 
 that :Gadfly instead of Gadfly =#)) && using LastMain.Gadfly || using 
 Gadfly)

 ```

 Thanks in advance!

 // T

>>> ​
>>
>

[julia-users] Re: Using a macro argument as a symbol, inside the returned quote

[David Gold]

Hmm...

You could write an `@workspace` macro that calls `workspace()` and then 
declares itself and the `quickload` macro... =p

On Saturday, July 25, 2015 at 7:09:26 PM UTC-4, Tomas Lycken wrote:
>
> Fantastic - thanks a lot!
>
> The final form of the macro is then the following:
>
> macro quickload(m)
> _m = Expr(:quote, m)
>
> quote
> if isdefined(:LastMain) && isdefined(LastMain, $_m)
> using LastMain.$m
> else
> using $m
> end
> end
> end
>
> This works very well - except that I have to define it in each new 
> workspace… Adding it to .juliarc.jl does make it available on start, but 
> after workspace() it’s not available anymore, and kind-of looses its 
> point…
>
> Any suggestions?
>
> // T
>
> On Sunday, July 26, 2015 at 12:58:28 AM UTC+2, David Gold wrote:
>
> This seems to work:
>>
>> julia> macro foo(bar)
>>_bar = Expr(:quote, bar) 
>>res = Expr(:call, :isdefined, :($_bar)) 
>>return res 
>>end 
>>
>> julia> macroexpand(:( @foo(baz) )) 
>> :(isdefined(:baz))
>>
>>
>>
>> On Saturday, July 25, 2015 at 6:30:08 PM UTC-4, Tomas Lycken wrote:
>>>
>>> Hi everybody!
>>>
>>> Is there a way to use a macro argument as an actual Symbol in the quote 
>>> that the macro returns? The following can hopefully help explaining what I 
>>> want:
>>>
>>> ```
>>> julia> macro foo(bar)
>>>:(isdefined($bar))
>>>end
>>>
>>> julia> macroexpand(:(@foo baz))
>>> :(isdefined(baz)) # I had hoped for :(isdefined(:baz)) - with :baz 
>>> instead of baz
>>> ```
>>>
>>> I've tried various combinations of interpolation, escaping and passing 
>>> arguments to `symbol`, but to no avail. Is there a way to accomplish this?
>>>
>>> --- Actual use case below ---
>>>
>>> I noticed a very common pattern in my workflow that I wanted to abstract 
>>> away to make it quicker and easier:
>>>
>>> *I want to load module X. If it's in LastMain, it's much faster to get 
>>> it from there, but otherwise I need to load it from scratch.*
>>>
>>> I can easily write code that does this. Take, for example, Gadfly:
>>>
>>> ```
>>> (isdefined(:LastMain) && isdefined(LastMain, :Gadfly) && using 
>>> LastMain.Gadfly) || using Gadfly
>>> ```
>>>
>>> When I execute that code, Gadfly will load from LastMain if available 
>>> there, and from scratch otherwise. And it won't error out if I haven't 
>>> called `workspace()` at all yet. Perfect! But having to type that for each 
>>> module I want to use the workflow for is a hassle - what if `@quickload 
>>> Gadfly` would do the same thing? This is my attempt so far:
>>>
>>> ```
>>> julia> macro quickload(m)
>>>:((isdefined(:LastMain) && isdefined(LastMain, $m #= what do I 
>>> put here?=#) && using LastMain.$m) || using $m)
>>>end
>>>
>>> julia> macroexpand(:(@quickload Gadfly))
>>> :((isdefined(:LastMain) && isdefined(LastMain,Gadfly #= <-- ...to make 
>>> that :Gadfly instead of Gadfly =#)) && using LastMain.Gadfly || using 
>>> Gadfly)
>>>
>>> ```
>>>
>>> Thanks in advance!
>>>
>>> // T
>>>
>> ​
>

[julia-users] San Francisco Bay meetup: Jeff Bezanson on Aug 13, future meetups

[Christian Peel]

We will have a meetup in San Francisco on Aug 13 with Jeff Bezanson
speaking on "Julia: future directions and speculations", and Kyle Barbary
speaking on JuliaAstro.  See
http://www.meetup.com/Bay-Area-Julia-Users/events/223908654/ for more info
and to register. We're grateful to Forio for hosting.

If you are now or will be in the San Francisco Bay area and are working on
Julia, we'd love to hear from you. We're looking for refreshed versions of
JuliaCon talks (as Jeff and Kyle are doing), new results, or even talks on
the history of scientific computing.  The more lead-time before your visit,
the easier it is to schedule something; send me an email and we'll make
plans.

My best
-- 
chris.p...@ieee.org

[julia-users] Re: Using a macro argument as a symbol, inside the returned quote

[Tomas Lycken]

Fantastic - thanks a lot!

The final form of the macro is then the following:

macro quickload(m)
_m = Expr(:quote, m)

quote
if isdefined(:LastMain) && isdefined(LastMain, $_m)
using LastMain.$m
else
using $m
end
end
end

This works very well - except that I have to define it in each new 
workspace… Adding it to .juliarc.jl does make it available on start, but 
after workspace() it’s not available anymore, and kind-of looses its point…

Any suggestions?

// T

On Sunday, July 26, 2015 at 12:58:28 AM UTC+2, David Gold wrote:

This seems to work:
>
> julia> macro foo(bar)
>_bar = Expr(:quote, bar) 
>res = Expr(:call, :isdefined, :($_bar)) 
>return res 
>end 
>
> julia> macroexpand(:( @foo(baz) )) 
> :(isdefined(:baz))
>
>
>
> On Saturday, July 25, 2015 at 6:30:08 PM UTC-4, Tomas Lycken wrote:
>>
>> Hi everybody!
>>
>> Is there a way to use a macro argument as an actual Symbol in the quote 
>> that the macro returns? The following can hopefully help explaining what I 
>> want:
>>
>> ```
>> julia> macro foo(bar)
>>:(isdefined($bar))
>>end
>>
>> julia> macroexpand(:(@foo baz))
>> :(isdefined(baz)) # I had hoped for :(isdefined(:baz)) - with :baz 
>> instead of baz
>> ```
>>
>> I've tried various combinations of interpolation, escaping and passing 
>> arguments to `symbol`, but to no avail. Is there a way to accomplish this?
>>
>> --- Actual use case below ---
>>
>> I noticed a very common pattern in my workflow that I wanted to abstract 
>> away to make it quicker and easier:
>>
>> *I want to load module X. If it's in LastMain, it's much faster to get it 
>> from there, but otherwise I need to load it from scratch.*
>>
>> I can easily write code that does this. Take, for example, Gadfly:
>>
>> ```
>> (isdefined(:LastMain) && isdefined(LastMain, :Gadfly) && using 
>> LastMain.Gadfly) || using Gadfly
>> ```
>>
>> When I execute that code, Gadfly will load from LastMain if available 
>> there, and from scratch otherwise. And it won't error out if I haven't 
>> called `workspace()` at all yet. Perfect! But having to type that for each 
>> module I want to use the workflow for is a hassle - what if `@quickload 
>> Gadfly` would do the same thing? This is my attempt so far:
>>
>> ```
>> julia> macro quickload(m)
>>:((isdefined(:LastMain) && isdefined(LastMain, $m #= what do I put 
>> here?=#) && using LastMain.$m) || using $m)
>>end
>>
>> julia> macroexpand(:(@quickload Gadfly))
>> :((isdefined(:LastMain) && isdefined(LastMain,Gadfly #= <-- ...to make 
>> that :Gadfly instead of Gadfly =#)) && using LastMain.Gadfly || using 
>> Gadfly)
>>
>> ```
>>
>> Thanks in advance!
>>
>> // T
>>
> ​

[julia-users] Re: Using a macro argument as a symbol, inside the returned quote

[David Gold]

This seems to work:

julia> macro foo(bar)
   _bar = Expr(:quote, bar) 
   res = Expr(:call, :isdefined, :($_bar)) 
   return res 
   end 

julia> macroexpand(:( @foo(baz) )) 
:(isdefined(:baz))



On Saturday, July 25, 2015 at 6:30:08 PM UTC-4, Tomas Lycken wrote:
>
> Hi everybody!
>
> Is there a way to use a macro argument as an actual Symbol in the quote 
> that the macro returns? The following can hopefully help explaining what I 
> want:
>
> ```
> julia> macro foo(bar)
>:(isdefined($bar))
>end
>
> julia> macroexpand(:(@foo baz))
> :(isdefined(baz)) # I had hoped for :(isdefined(:baz)) - with :baz instead 
> of baz
> ```
>
> I've tried various combinations of interpolation, escaping and passing 
> arguments to `symbol`, but to no avail. Is there a way to accomplish this?
>
> --- Actual use case below ---
>
> I noticed a very common pattern in my workflow that I wanted to abstract 
> away to make it quicker and easier:
>
> *I want to load module X. If it's in LastMain, it's much faster to get it 
> from there, but otherwise I need to load it from scratch.*
>
> I can easily write code that does this. Take, for example, Gadfly:
>
> ```
> (isdefined(:LastMain) && isdefined(LastMain, :Gadfly) && using 
> LastMain.Gadfly) || using Gadfly
> ```
>
> When I execute that code, Gadfly will load from LastMain if available 
> there, and from scratch otherwise. And it won't error out if I haven't 
> called `workspace()` at all yet. Perfect! But having to type that for each 
> module I want to use the workflow for is a hassle - what if `@quickload 
> Gadfly` would do the same thing? This is my attempt so far:
>
> ```
> julia> macro quickload(m)
>:((isdefined(:LastMain) && isdefined(LastMain, $m #= what do I put 
> here?=#) && using LastMain.$m) || using $m)
>end
>
> julia> macroexpand(:(@quickload Gadfly))
> :((isdefined(:LastMain) && isdefined(LastMain,Gadfly #= <-- ...to make 
> that :Gadfly instead of Gadfly =#)) && using LastMain.Gadfly || using 
> Gadfly)
>
> ```
>
> Thanks in advance!
>
> // T
>

[julia-users] Using a macro argument as a symbol, inside the returned quote

[Tomas Lycken]

Hi everybody!

Is there a way to use a macro argument as an actual Symbol in the quote 
that the macro returns? The following can hopefully help explaining what I 
want:

```
julia> macro foo(bar)
   :(isdefined($bar))
   end

julia> macroexpand(:(@foo baz))
:(isdefined(baz)) # I had hoped for :(isdefined(:baz)) - with :baz instead 
of baz
```

I've tried various combinations of interpolation, escaping and passing 
arguments to `symbol`, but to no avail. Is there a way to accomplish this?

--- Actual use case below ---

I noticed a very common pattern in my workflow that I wanted to abstract 
away to make it quicker and easier:

*I want to load module X. If it's in LastMain, it's much faster to get it 
from there, but otherwise I need to load it from scratch.*

I can easily write code that does this. Take, for example, Gadfly:

```
(isdefined(:LastMain) && isdefined(LastMain, :Gadfly) && using 
LastMain.Gadfly) || using Gadfly
```

When I execute that code, Gadfly will load from LastMain if available 
there, and from scratch otherwise. And it won't error out if I haven't 
called `workspace()` at all yet. Perfect! But having to type that for each 
module I want to use the workflow for is a hassle - what if `@quickload 
Gadfly` would do the same thing? This is my attempt so far:

```
julia> macro quickload(m)
   :((isdefined(:LastMain) && isdefined(LastMain, $m #= what do I put 
here?=#) && using LastMain.$m) || using $m)
   end

julia> macroexpand(:(@quickload Gadfly))
:((isdefined(:LastMain) && isdefined(LastMain,Gadfly #= <-- ...to make that 
:Gadfly instead of Gadfly =#)) && using LastMain.Gadfly || using Gadfly)

```

Thanks in advance!

// T

[julia-users] Re: John L. Gustafson's UNUMs

[Job van der Zwan]

On Saturday, 25 July 2015 23:34:45 UTC+3, Simon Byrne wrote:
>
> Some HN discussion here:
> https://news.ycombinator.com/item?id=9943589
>

Oh, hadn't seen that. The linked presentation is also more recent! I found 
the "slidecast" version of it, where he presents the slides in podcast form. 
 He's evangelizing a bit, but, 
well... I guess that makes sense given the topic.

I'd be keen to know more but he hasn't really published any details other 
> than his book 
> . 
> Based 
> on the free preview, it looks like a bit of a diatribe rather than a 
> detailed technical proposal, but you can look at his mathematica code here 
> 
> .
>

Well, if you decide to go against something as well-established as the way 
we've been doing integer and floating point arithmetic, you're probably 
going to need a lot of explanation in a very accessible style - because you 
definitely won't have the experts on your side.

[julia-users] Re: John L. Gustafson's UNUMs

[Simon Byrne]

Some HN discussion here:
https://news.ycombinator.com/item?id=9943589

I'd be keen to know more but he hasn't really published any details other 
than his book 
. 
Based 
on the free preview, it looks like a bit of a diatribe rather than a 
detailed technical proposal, but you can look at his mathematica code here 

.

On Saturday, 25 July 2015 15:22:31 UTC+1, Simon Danisch wrote:
>
> How cool!
> I don't know much about this matter, but this looks very exciting! 
> Julia seems to be a good fit to prototype this! 
>
> Am Samstag, 25. Juli 2015 15:11:54 UTC+2 schrieb Job van der Zwan:
>>
>> So I came across the concept of UNUMs on the Pony language mailing list 
>>  this 
>> morning. I hadn't heard of them before, and a quick search doesn't show up 
>> anything on this mailing list, so I guess most people here haven't either. 
>> They're a proposed alternate encoding for numbers by John L. Gustafson. 
>> This presentation by him sums it up nicely:
>>
>> http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf
>>
>> “Unums”(universal numbers) are to floating point what floating point is 
>>> to fixed point.
>>> Floating-point values self-describe their scale factor, but fix the 
>>> exponent and fraction size. Unums self-describe the exponent size, fraction 
>>> size, and inexact state, and include fixed point and IEEE floats as special 
>>> cases.
>>>
>>
>> The presentation can be seen here, provided you have the Silverlight 
>> plugin:
>>
>>
>> http://sites.ieee.org/scv-cs/archives/right-sizing-precision-to-save-energy-power-and-storage
>>
>> Now, I don't know enough about this topic to say if they're a good or bad 
>> idea, but I figured the idea is interesting/relevant enough to share with 
>> the Julia crowd.
>>
>> I'm also wondering if they could be implemented (relatively) easily 
>> within Julia, given its flexible type system. If so, they might provide an 
>> interesting advanced example, no?
>>
>

[julia-users] Re: new problem in Juno with TkWidget

[Alex Ames]

Looks like the root cause is a breaking change in Winston in preparation
for Julia v0.4 (see here ).
The fix is Pkg.pin("Winston", v"0.11.0"), which shouldn't be necessary once
v0.4 is released.

On Fri, Jul 24, 2015 at 10:16 AM, Warwick Louw 
wrote:

> I just ran into the same issue, any change?
>
> On Tuesday, 16 June 2015 00:37:11 UTC+2, Alex Ames wrote:
>>
>> I submitted an issue
>> to Julia-LT; it
>> seems we're running into the same bug. No responses to the issue yet on
>> Github.
>>
>>
>> On Wednesday, June 10, 2015 at 9:17:58 AM UTC-5, JKPie wrote:
>>>
>>> Hi,
>>> From one the latest update of Julia I started to have the following
>>> error after each line in Juno:
>>> TkWidget has no method matching TkWidget(::UTF8String,::ASCIIString)
>>> Do you have an idea how to fix it, the code works, but this 'result' is
>>> really annoying.
>>>
>>> thank you for help,
>>> Jakub
>>>
>>>
>>>
>>>
>>> 
>>>
>>>

[julia-users] Re: New variables overwrite old variables in certain cases.

[Christopher Fisher]

Thanks for the additional clarification David. 

On Saturday, July 25, 2015 at 12:00:24 PM UTC-4, David Gold wrote:
>
> To supplement John's resource (which explains that the behavior you 
> indicate is indeed a property of the language):
>
> Currently (and in the version you're using), range indexing such as `x[:]` 
> returns a copy of `x`. So does applying an operation like `y * 4`. That's 
> why writing `y = x[:]` or `y = y * 4` doesn't reassign `y` in such a way 
> that subsequent modifications to `y` impact `x`.
>
> On Saturday, July 25, 2015 at 11:13:33 AM UTC-4, Christopher Fisher wrote:
>>
>> I am writing a program (in .3.1) that takes a one dimensional array of 
>> indices (x) and creates a new one dimensional array of indices  (x = y) and 
>> switches a given pair of elements in the new array. For some reason, the 
>> original array (x) changes when I change the new array (see below). 
>>
>> In [16]:
>>
>> x = [1:5]
>>
>> y = x
>>
>> y[[3;4]] = y[[4;3]]
>>
>> [x y]
>>
>> Out[16]:
>>
>> 5x2 Array{Int64,2}:
>>  1  1
>>  2  2
>>  4  4
>>  3  3
>>
>>
>>
>> However, if I change y = x to y = x[:], the problem does not occur, even 
>> though x and x[:] appear to be the same type.
>>
>>
>> In [15]:
>>
>> x = [1:5]
>>
>> y = x[:]
>>
>> y[[3;4]] = y[[4;3]]
>>
>> [x y]
>>
>> Out[15]:
>>
>> 5x2 Array{Int64,2}:
>>  1  1
>>  2  2
>>  3  4
>>  4  3
>>  5  5
>>
>>
>> The code below shows that this does not seem to be a general property of the 
>> language. As in the previous cases, I define y as x and change y. 
>>
>>
>> In [13]:
>>
>> x = [1:5]
>>
>> y = x
>>
>> y = y*4
>>
>> [x y]
>>
>> Out[13]:
>>
>> 5x2 Array{Int64,2}:
>>  1   4
>>  2   8
>>  3  12
>>  4  16
>>  5  20
>>
>>
>>
>> Certainly, I could use y = x[:] or simply change the original array. 
>> Nonetheless, the inconsistency seems undesirable from my point of view. Is 
>> this a bug? Any help would be appreciated. 
>>
>>
>>

[julia-users] Re: New variables overwrite old variables in certain cases.

[Christopher Fisher]

This is the first time I encountered this issue since I began using Julia 
about a year ago. Thank you for the clarification John. 

On Saturday, July 25, 2015 at 11:48:36 AM UTC-4, John Myles White wrote:
>
>
> http://www.johnmyleswhite.com/notebook/2014/09/06/values-vs-bindings-the-map-is-not-the-territory/
>
> On Saturday, July 25, 2015 at 8:13:33 AM UTC-7, Christopher Fisher wrote:
>>
>> I am writing a program (in .3.1) that takes a one dimensional array of 
>> indices (x) and creates a new one dimensional array of indices  (x = y) and 
>> switches a given pair of elements in the new array. For some reason, the 
>> original array (x) changes when I change the new array (see below). 
>>
>> In [16]:
>>
>> x = [1:5]
>>
>> y = x
>>
>> y[[3;4]] = y[[4;3]]
>>
>> [x y]
>>
>> Out[16]:
>>
>> 5x2 Array{Int64,2}:
>>  1  1
>>  2  2
>>  4  4
>>  3  3
>>
>>
>>
>> However, if I change y = x to y = x[:], the problem does not occur, even 
>> though x and x[:] appear to be the same type.
>>
>>
>> In [15]:
>>
>> x = [1:5]
>>
>> y = x[:]
>>
>> y[[3;4]] = y[[4;3]]
>>
>> [x y]
>>
>> Out[15]:
>>
>> 5x2 Array{Int64,2}:
>>  1  1
>>  2  2
>>  3  4
>>  4  3
>>  5  5
>>
>>
>> The code below shows that this does not seem to be a general property of the 
>> language. As in the previous cases, I define y as x and change y. 
>>
>>
>> In [13]:
>>
>> x = [1:5]
>>
>> y = x
>>
>> y = y*4
>>
>> [x y]
>>
>> Out[13]:
>>
>> 5x2 Array{Int64,2}:
>>  1   4
>>  2   8
>>  3  12
>>  4  16
>>  5  20
>>
>>
>>
>> Certainly, I could use y = x[:] or simply change the original array. 
>> Nonetheless, the inconsistency seems undesirable from my point of view. Is 
>> this a bug? Any help would be appreciated. 
>>
>>
>>

[julia-users] Re: New variables overwrite old variables in certain cases.

[David Gold]

To supplement John's resource (which explains that the behavior you 
indicate is indeed a property of the language):

Currently (and in the version you're using), range indexing such as `x[:]` 
returns a copy of `x`. So does applying an operation like `y * 4`. That's 
why writing `y = x[:]` or `y = y * 4` doesn't reassign `y` in such a way 
that subsequent modifications to `y` impact `x`.

On Saturday, July 25, 2015 at 11:13:33 AM UTC-4, Christopher Fisher wrote:
>
> I am writing a program (in .3.1) that takes a one dimensional array of 
> indices (x) and creates a new one dimensional array of indices  (x = y) and 
> switches a given pair of elements in the new array. For some reason, the 
> original array (x) changes when I change the new array (see below). 
>
> In [16]:
>
> x = [1:5]
>
> y = x
>
> y[[3;4]] = y[[4;3]]
>
> [x y]
>
> Out[16]:
>
> 5x2 Array{Int64,2}:
>  1  1
>  2  2
>  4  4
>  3  3
>
>
>
> However, if I change y = x to y = x[:], the problem does not occur, even 
> though x and x[:] appear to be the same type.
>
>
> In [15]:
>
> x = [1:5]
>
> y = x[:]
>
> y[[3;4]] = y[[4;3]]
>
> [x y]
>
> Out[15]:
>
> 5x2 Array{Int64,2}:
>  1  1
>  2  2
>  3  4
>  4  3
>  5  5
>
>
> The code below shows that this does not seem to be a general property of the 
> language. As in the previous cases, I define y as x and change y. 
>
>
> In [13]:
>
> x = [1:5]
>
> y = x
>
> y = y*4
>
> [x y]
>
> Out[13]:
>
> 5x2 Array{Int64,2}:
>  1   4
>  2   8
>  3  12
>  4  16
>  5  20
>
>
>
> Certainly, I could use y = x[:] or simply change the original array. 
> Nonetheless, the inconsistency seems undesirable from my point of view. Is 
> this a bug? Any help would be appreciated. 
>
>
>

[julia-users] Re: New variables overwrite old variables in certain cases.

[John Myles White]

http://www.johnmyleswhite.com/notebook/2014/09/06/values-vs-bindings-the-map-is-not-the-territory/

On Saturday, July 25, 2015 at 8:13:33 AM UTC-7, Christopher Fisher wrote:
>
> I am writing a program (in .3.1) that takes a one dimensional array of 
> indices (x) and creates a new one dimensional array of indices  (x = y) and 
> switches a given pair of elements in the new array. For some reason, the 
> original array (x) changes when I change the new array (see below). 
>
> In [16]:
>
> x = [1:5]
>
> y = x
>
> y[[3;4]] = y[[4;3]]
>
> [x y]
>
> Out[16]:
>
> 5x2 Array{Int64,2}:
>  1  1
>  2  2
>  4  4
>  3  3
>
>
>
> However, if I change y = x to y = x[:], the problem does not occur, even 
> though x and x[:] appear to be the same type.
>
>
> In [15]:
>
> x = [1:5]
>
> y = x[:]
>
> y[[3;4]] = y[[4;3]]
>
> [x y]
>
> Out[15]:
>
> 5x2 Array{Int64,2}:
>  1  1
>  2  2
>  3  4
>  4  3
>  5  5
>
>
> The code below shows that this does not seem to be a general property of the 
> language. As in the previous cases, I define y as x and change y. 
>
>
> In [13]:
>
> x = [1:5]
>
> y = x
>
> y = y*4
>
> [x y]
>
> Out[13]:
>
> 5x2 Array{Int64,2}:
>  1   4
>  2   8
>  3  12
>  4  16
>  5  20
>
>
>
> Certainly, I could use y = x[:] or simply change the original array. 
> Nonetheless, the inconsistency seems undesirable from my point of view. Is 
> this a bug? Any help would be appreciated. 
>
>
>

[julia-users] New variables overwrite old variables in certain cases.

[Christopher Fisher]

I am writing a program (in .3.1) that takes a one dimensional array of 
indices (x) and creates a new one dimensional array of indices  (x = y) and 
switches a given pair of elements in the new array. For some reason, the 
original array (x) changes when I change the new array (see below). 

In [16]:

x = [1:5]

y = x

y[[3;4]] = y[[4;3]]

[x y]

Out[16]:

5x2 Array{Int64,2}:
 1  1
 2  2
 4  4
 3  3



However, if I change y = x to y = x[:], the problem does not occur, even though 
x and x[:] appear to be the same type.


In [15]:

x = [1:5]

y = x[:]

y[[3;4]] = y[[4;3]]

[x y]

Out[15]:

5x2 Array{Int64,2}:
 1  1
 2  2
 3  4
 4  3
 5  5


The code below shows that this does not seem to be a general property of the 
language. As in the previous cases, I define y as x and change y. 


In [13]:

x = [1:5]

y = x

y = y*4

[x y]

Out[13]:

5x2 Array{Int64,2}:
 1   4
 2   8
 3  12
 4  16
 5  20



Certainly, I could use y = x[:] or simply change the original array. 
Nonetheless, the inconsistency seems undesirable from my point of view. Is this 
a bug? Any help would be appreciated. 

Re: [julia-users] Forming a structure made of complex and real numbers?

[Tom Breloff]

Also, it seems like what you really want is a conatiner for 2 Vectors. In
julia, Vector{T} is a typealias for Array{T,1}... The things in brackets
are the parameters. For Array{T,N}, the first parameter T is the type
inside the array, and N is the array dimension. So maybe you want:

type DataArray
  Y::Vector{Complex128}
  w::Vector{Float64}
end

On Saturday, July 25, 2015, Milan Bouchet-Valat  wrote:

> Le samedi 25 juillet 2015 à 06:55 -0700, Joe Tusek a écrit :
> > Hi, I am trying to convert some Matlab code where structured data
> > variables were used that were composed of complex and real data which
> > is passed to a function. The original Matlab call was [poles, L2] =
> > PSO("FLBF",lb,ub,poles,data)  and data is of the form data.Y and
> >  data.w, where Y is a complex number and w the frequency.
> >
> > In Julia I have defined the following structure
> >
> > type Data_array
> >   Y::Float64
> >   w::Float64
> > end
> >
> > but am not clear on how to get Y to be a complex Float64? I tried
> > Complex(Float64), and Array(Float64,1041) versions as well as
> > combinations of im but these were all rejected.
> >
> > If I comment out the non compliant lines of code so it will run, I
> > see that Y is of size (1041,1)  and w is of size (1, 1041). Trying to
> > form the data variable using
> > data = Data_array(Y, w)
> > suffers a conversion error.
> >
> > Can someone advise on how to make the needed structured variable?
> Complex(Float64) tries to build a complex holding the *value* Float64,
> which doesn't make sense. To specify a type parameter, use
> Complex{Float64}. There's also the alias Complex128, if you prefer.
>
> Regards
>

Re: [julia-users] Forming a structure made of complex and real numbers?

[Milan Bouchet-Valat]

Le samedi 25 juillet 2015 à 06:55 -0700, Joe Tusek a écrit :
> Hi, I am trying to convert some Matlab code where structured data 
> variables were used that were composed of complex and real data which 
> is passed to a function. The original Matlab call was [poles, L2] = 
> PSO("FLBF",lb,ub,poles,data)  and data is of the form data.Y and
>  data.w, where Y is a complex number and w the frequency.
> 
> In Julia I have defined the following structure
> 
> type Data_array
>   Y::Float64
>   w::Float64
> end
> 
> but am not clear on how to get Y to be a complex Float64? I tried 
> Complex(Float64), and Array(Float64,1041) versions as well as 
> combinations of im but these were all rejected.
> 
> If I comment out the non compliant lines of code so it will run, I 
> see that Y is of size (1041,1)  and w is of size (1, 1041). Trying to 
> form the data variable using
> data = Data_array(Y, w) 
> suffers a conversion error.
> 
> Can someone advise on how to make the needed structured variable?
Complex(Float64) tries to build a complex holding the *value* Float64,
which doesn't make sense. To specify a type parameter, use
Complex{Float64}. There's also the alias Complex128, if you prefer.

Regards

[julia-users] Re: John L. Gustafson's UNUMs

[Simon Danisch]

How cool!
I don't know much about this matter, but this looks very exciting! 
Julia seems to be a good fit to prototype this! 

Am Samstag, 25. Juli 2015 15:11:54 UTC+2 schrieb Job van der Zwan:
>
> So I came across the concept of UNUMs on the Pony language mailing list 
>  this 
> morning. I hadn't heard of them before, and a quick search doesn't show up 
> anything on this mailing list, so I guess most people here haven't either. 
> They're a proposed alternate encoding for numbers by John L. Gustafson. 
> This presentation by him sums it up nicely:
>
> http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf
>
> “Unums”(universal numbers) are to floating point what floating point is to 
>> fixed point.
>> Floating-point values self-describe their scale factor, but fix the 
>> exponent and fraction size. Unums self-describe the exponent size, fraction 
>> size, and inexact state, and include fixed point and IEEE floats as special 
>> cases.
>>
>
> The presentation can be seen here, provided you have the Silverlight 
> plugin:
>
>
> http://sites.ieee.org/scv-cs/archives/right-sizing-precision-to-save-energy-power-and-storage
>
> Now, I don't know enough about this topic to say if they're a good or bad 
> idea, but I figured the idea is interesting/relevant enough to share with 
> the Julia crowd.
>
> I'm also wondering if they could be implemented (relatively) easily within 
> Julia, given its flexible type system. If so, they might provide an 
> interesting advanced example, no?
>

[julia-users] Re: should using a pkg sub-module as the package loads work?

[Jeffrey Sarnoff]

src/SubModule.jl defines the SubModule
removing "using SubModule" and accessing subThing with SubModule.subThing 
does work (and I had not tried that)
so that helps -- thank you

On Saturday, July 25, 2015 at 10:00:29 AM UTC-4, Tero Frondelius wrote:
>
> Maybe it's otherwise ok, just remove "using SubModule". I assume that your 
> "src/file2.jl" defines the SubModule and when you include it you don't have 
> to write using SubModule at all. Or I just misunderstood your question. 
>
> On Saturday, July 25, 2015 at 4:45:29 PM UTC+3, Jeffrey Sarnoff wrote:
>>
>> above should read
>>
>> Package.jl
>>module Package
>>   include("src/file1.jl")
>>   include( "src/submodule.jl")
>>   using SubModule
>>   include( "src/file2.jl" ) # needs subThing
>>end 
>>
>> On Saturday, July 25, 2015 at 9:41:47 AM UTC-4, Jeffrey Sarnoff wrote:
>>>
>>> I have a package layed out something like this:
>>>
>>> Package
>>>Package.jl
>>>src
>>> file1.jl
>>> submodule.jl
>>>  module SubModule
>>>  export subThing
>>>  end
>>> file2.jl
>>>  ...use subThing...
>>>
>>> Package.jl
>>>include("src/file1.jl")
>>>include( "src/submodule.jl")
>>>using SubModule
>>>include( "src/file2.jl" )
>>>
>>> which causes (v0.4) ERROR: LoadError: ArgumentError: Sub not found in 
>>> path
>>>and so does
>>>... import SubModule: subThing
>>>   
>>> Is there a way to do this without making SubModule a separate package?
>>>
>>

[julia-users] Re: should using a pkg sub-module as the package loads work?

[Tero Frondelius]

Maybe it's otherwise ok, just remove "using SubModule". I assume that your 
"src/file2.jl" defines the SubModule and when you include it you don't have 
to write using SubModule at all. Or I just misunderstood your question. 

On Saturday, July 25, 2015 at 4:45:29 PM UTC+3, Jeffrey Sarnoff wrote:
>
> above should read
>
> Package.jl
>module Package
>   include("src/file1.jl")
>   include( "src/submodule.jl")
>   using SubModule
>   include( "src/file2.jl" ) # needs subThing
>end 
>
> On Saturday, July 25, 2015 at 9:41:47 AM UTC-4, Jeffrey Sarnoff wrote:
>>
>> I have a package layed out something like this:
>>
>> Package
>>Package.jl
>>src
>> file1.jl
>> submodule.jl
>>  module SubModule
>>  export subThing
>>  end
>> file2.jl
>>  ...use subThing...
>>
>> Package.jl
>>include("src/file1.jl")
>>include( "src/submodule.jl")
>>using SubModule
>>include( "src/file2.jl" )
>>
>> which causes (v0.4) ERROR: LoadError: ArgumentError: Sub not found in path
>>and so does
>>... import SubModule: subThing
>>   
>> Is there a way to do this without making SubModule a separate package?
>>
>

[julia-users] Forming a structure made of complex and real numbers?

[Joe Tusek]

Hi, I am trying to convert some Matlab code where structured data variables 
were used that were composed of complex and real data which is passed to 
a function. The original Matlab call was [poles, L2] = 
PSO("FLBF",lb,ub,poles,data)  and data is of the form data.Y and data.w, 
where Y is a complex number and w the frequency.

In Julia I have defined the following structure

type Data_array
  Y::Float64
  w::Float64
end

but am not clear on how to get Y to be a complex Float64? I tried 
Complex(Float64), and Array(Float64,1041) versions as well as combinations 
of im but these were all rejected.

If I comment out the non compliant lines of code so it will run, I see 
that Y is of size (1041,1)  and w is of size (1, 1041). Trying to form the 
data variable using
data = Data_array(Y, w)  
suffers a conversion error.

Can someone advise on how to make the needed structured variable? 

[julia-users] Re: should using a pkg sub-module as the package loads work?

[Jeffrey Sarnoff]

above should read

Package.jl
   module Package
  include("src/file1.jl")
  include( "src/submodule.jl")
  using SubModule
  include( "src/file2.jl" ) # needs subThing
   end 

On Saturday, July 25, 2015 at 9:41:47 AM UTC-4, Jeffrey Sarnoff wrote:
>
> I have a package layed out something like this:
>
> Package
>Package.jl
>src
> file1.jl
> submodule.jl
>  module SubModule
>  export subThing
>  end
> file2.jl
>  ...use subThing...
>
> Package.jl
>include("src/file1.jl")
>include( "src/submodule.jl")
>using SubModule
>include( "src/file2.jl" )
>
> which causes (v0.4) ERROR: LoadError: ArgumentError: Sub not found in path
>and so does
>... import SubModule: subThing
>   
> Is there a way to do this without making SubModule a separate package?
>

[julia-users] should using a pkg sub-module as the package loads work?

[Jeffrey Sarnoff]

I have a package layed out something like this:

Package
   Package.jl
   src
file1.jl
submodule.jl
 module SubModule
 export subThing
 end
file2.jl
 ...use subThing...

Package.jl
   include("src/file1.jl")
   include( "src/submodule.jl")
   using SubModule
   include( "src/file2.jl" )

which causes (v0.4) ERROR: LoadError: ArgumentError: Sub not found in path
   and so does
   ... import SubModule: subThing
  
Is there a way to do this without making SubModule a separate package?

[julia-users] John L. Gustafson's UNUMs

[Job van der Zwan]

So I came across the concept of UNUMs on the Pony language mailing list 
 this 
morning. I hadn't heard of them before, and a quick search doesn't show up 
anything on this mailing list, so I guess most people here haven't either. 
They're a proposed alternate encoding for numbers by John L. Gustafson. 
This presentation by him sums it up nicely:

http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf

“Unums”(universal numbers) are to floating point what floating point is to 
> fixed point.
> Floating-point values self-describe their scale factor, but fix the 
> exponent and fraction size. Unums self-describe the exponent size, fraction 
> size, and inexact state, and include fixed point and IEEE floats as special 
> cases.
>

The presentation can be seen here, provided you have the Silverlight plugin:

http://sites.ieee.org/scv-cs/archives/right-sizing-precision-to-save-energy-power-and-storage

Now, I don't know enough about this topic to say if they're a good or bad 
idea, but I figured the idea is interesting/relevant enough to share with 
the Julia crowd.

I'm also wondering if they could be implemented (relatively) easily within 
Julia, given its flexible type system. If so, they might provide an 
interesting advanced example, no?

Re: [julia-users] Re: complex results - why not automatic type conversion?

[Joe Tusek]

I guess I have a long way to go with Julia. Thanks everyone for taking an 
interest.

Re: [julia-users] Re: Environment reification and lazy evaluation

[Brandon Taylor]

Cool, workspace() seems very helpful. Yeah, I don't really understand 
exactly what that code would look like either, because I'm not the most 
familiar with time-series statistics. My point was that to work easily with 
flexible models that mix environmental variables with dataframe variables, 
it is convenient (though again not necessary) to have environment access.

On Saturday, July 25, 2015 at 7:34:44 AM UTC-4, Milan Bouchet-Valat wrote:
>
> Le samedi 25 juillet 2015 à 01:58 -0700, Brandon Taylor a écrit : 
> > Well a somewhat unique feature or R is automatic argument recycling, 
> > so that when doing operations on dataframes, it's a lot easier to 
> > incorporate data from outside of the dataframe into evaluation. Let's 
> > say you are doing a stepwise logisitic growth model, like dP/dt = 
> > r*P*(1 - P/K). Let's say that r a known single value in the global 
> > environment, K is going be predicted from some environmental 
> > variables within your dataframe, and P is going to be given as an 
> > initial condition and its evolution modeled. The R way of looking at 
> > this would be to set up an environment where the dataframe 
> > environment inherits from the global environment, and to evaluate 
> > within this environment regardless of calling environment. That means 
> > that within a sub sub function, you can use r to represent, maybe, a 
> > row number, and K, to represent, maybe, a column number, and that you 
> > can still evaluate an expression like r*P*(1 - P/K) with no problem. 
> > This is most useful when writing your own functions. For example, you 
> > could build some sort of time-series predictive package that could 
> > handle not only logisitic models, but other models, like the Lotka 
> > -Volterra models. Now, I'm not saying this is impossible to do in 
> > Julia: in fact, I'm quite sure it is. It's just less convenient. 
> Thanks for the example. I don't think I would use an environment for 
> that. Why not have the function take a data frame with the variables, a 
> nd constants as an argument? As I understand it, the only interest of 
> environments is that you don't have to make a difference between 
> variables in the data frame and variables in the global scope. But I 
> also find it confusing that you don't know where the data comes from, 
> and I've seen students make mistakes because of that. 
>
> That said, I don't understand exactly what the code you describe would 
> look like, so I might be missing something. If you can provide a few 
> lines to illustrate a toy example, it could help. 
>
> > The other nice things about environments are more trivial. For 
> > example, you might be doing a homework assignment with several 
> > problems. At the start of each problem, you could define a new 
> > environment. At the end of the problem, you could display the entire 
> > content of the problem's environment as a way to track down errors. 
> > When looking at an answer sheet, you could compare intermediate 
> > results and see where you went wrong. Again, not impossible to do 
> > with Julia; you would probably want to set up a dict for each 
> > problem, and do all operations within that dict. Which, I guess, is 
> > basically what is happening under the hood in a language with 
> > environments. 
> You should be able to do this by working inside modules in Julia. In 
> particular, workspace() looks exactly like what you're describing: once 
> you're done with one problem, call it to get a clean environment, 
> storing globals in the LastMain module. 
>
>
> Regards 
>
> > I'll just nod in agreement with the fexpr stuff and pretend I 
> > understand. 
> > 
> > On Friday, July 24, 2015 at 4:11:37 PM UTC-4, Scott Jones wrote: 
> > > I should give you a hard time about arguing from authority ;-), but 
> > > I was there at the same time and knew KMP, so I wouldn't want to 
> > > argue too much with him either, and I am in agreement with you 
> > > about fexprs vs. macros, and the equivalent issues in Julia. 
> > > 
> > > On Friday, July 24, 2015 at 2:31:54 PM UTC-4, Stefan Karpinski 
> > > wrote: 
> > > > Lisp has already been down this path – fexprs were special forms 
> > > > with behavior similar to R's functions, and they were deprecated 
> > > > in the 1980s in favor of macros, https://en.wikipedia.org/wiki/Fe 
> > > > xpr#Mainstream_use_and_deprecation: 
> > > > 
> > > > > His central objection was that, in a Lisp dialect that allows 
> > > > > fexprs, static analysis cannot determine generally whether an 
> > > > > operator represents an ordinary function or a fexpr — 
> > > > > therefore, static analysis cannot determine whether or not the 
> > > > > operands will be evaluated. In particular, the compiler cannot 
> > > > > tell whether a subexpression can be safely optimized, since the 
> > > > > subexpression might be treated as unevaluated data at run-time. 
> > > > If Lispers think a feature is too dynamic and hard to understand, 
> > > > that's a danger sign. In

Re: [julia-users] Re: Environment reification and lazy evaluation

[Milan Bouchet-Valat]

Le samedi 25 juillet 2015 à 01:58 -0700, Brandon Taylor a écrit :
> Well a somewhat unique feature or R is automatic argument recycling, 
> so that when doing operations on dataframes, it's a lot easier to 
> incorporate data from outside of the dataframe into evaluation. Let's 
> say you are doing a stepwise logisitic growth model, like dP/dt = 
> r*P*(1 - P/K). Let's say that r a known single value in the global 
> environment, K is going be predicted from some environmental 
> variables within your dataframe, and P is going to be given as an 
> initial condition and its evolution modeled. The R way of looking at 
> this would be to set up an environment where the dataframe 
> environment inherits from the global environment, and to evaluate 
> within this environment regardless of calling environment. That means 
> that within a sub sub function, you can use r to represent, maybe, a 
> row number, and K, to represent, maybe, a column number, and that you 
> can still evaluate an expression like r*P*(1 - P/K) with no problem. 
> This is most useful when writing your own functions. For example, you 
> could build some sort of time-series predictive package that could 
> handle not only logisitic models, but other models, like the Lotka
> -Volterra models. Now, I'm not saying this is impossible to do in 
> Julia: in fact, I'm quite sure it is. It's just less convenient.
Thanks for the example. I don't think I would use an environment for
that. Why not have the function take a data frame with the variables, a
nd constants as an argument? As I understand it, the only interest of
environments is that you don't have to make a difference between
variables in the data frame and variables in the global scope. But I
also find it confusing that you don't know where the data comes from,
and I've seen students make mistakes because of that.

That said, I don't understand exactly what the code you describe would
look like, so I might be missing something. If you can provide a few
lines to illustrate a toy example, it could help.

> The other nice things about environments are more trivial. For 
> example, you might be doing a homework assignment with several 
> problems. At the start of each problem, you could define a new 
> environment. At the end of the problem, you could display the entire 
> content of the problem's environment as a way to track down errors. 
> When looking at an answer sheet, you could compare intermediate 
> results and see where you went wrong. Again, not impossible to do 
> with Julia; you would probably want to set up a dict for each 
> problem, and do all operations within that dict. Which, I guess, is 
> basically what is happening under the hood in a language with 
> environments.
You should be able to do this by working inside modules in Julia. In
particular, workspace() looks exactly like what you're describing: once
you're done with one problem, call it to get a clean environment,
storing globals in the LastMain module.


Regards

> I'll just nod in agreement with the fexpr stuff and pretend I 
> understand.
> 
> On Friday, July 24, 2015 at 4:11:37 PM UTC-4, Scott Jones wrote:
> > I should give you a hard time about arguing from authority ;-), but 
> > I was there at the same time and knew KMP, so I wouldn't want to 
> > argue too much with him either, and I am in agreement with you 
> > about fexprs vs. macros, and the equivalent issues in Julia.
> > 
> > On Friday, July 24, 2015 at 2:31:54 PM UTC-4, Stefan Karpinski 
> > wrote:
> > > Lisp has already been down this path – fexprs were special forms 
> > > with behavior similar to R's functions, and they were deprecated 
> > > in the 1980s in favor of macros, https://en.wikipedia.org/wiki/Fe
> > > xpr#Mainstream_use_and_deprecation:
> > > 
> > > > His central objection was that, in a Lisp dialect that allows 
> > > > fexprs, static analysis cannot determine generally whether an 
> > > > operator represents an ordinary function or a fexpr — 
> > > > therefore, static analysis cannot determine whether or not the 
> > > > operands will be evaluated. In particular, the compiler cannot 
> > > > tell whether a subexpression can be safely optimized, since the 
> > > > subexpression might be treated as unevaluated data at run-time.
> > > If Lispers think a feature is too dynamic and hard to understand, 
> > > that's a danger sign. In general, I wouldn't want to argue too 
> > > much with Kent Pitman :-)
> > > 
> > > On the subject of Kent Pitman, here's a random bit of Lisp wisdom 
> > > from this interview with him:
> > > 
> > > > I like Lisp's willingness to represent itself. People often 
> > > > explain this as its ability to represent itself, but I think 
> > > > that's wrong. Most languages are capable of representing 
> > > > themselves, but they simply don't have the will to. Lisp 
> > > > programs are represented by lists and programmers are aware of 
> > > > that. It wouldn't matter if it had been arrays. It does matter 
> > > > that

Re: [julia-users] Re: Environment reification and lazy evaluation

[Brandon Taylor]

Well a somewhat unique feature or R is automatic argument recycling, so 
that when doing operations on dataframes, it's a lot easier to incorporate 
data from outside of the dataframe into evaluation. Let's say you are doing 
a stepwise logisitic growth model, like dP/dt = r*P*(1 - P/K). Let's say 
that r a known single value in the global environment, K is going be 
predicted from some environmental variables within your dataframe, and P is 
going to be given as an initial condition and its evolution modeled. The R 
way of looking at this would be to set up an environment where the 
dataframe environment inherits from the global environment, and to evaluate 
within this environment regardless of calling environment. That means that 
within a sub sub function, you can use r to represent, maybe, a row number, 
and K, to represent, maybe, a column number, and that you can still 
evaluate an expression like r*P*(1 - P/K) with no problem. This is most 
useful when writing your own functions. For example, you could build some 
sort of time-series predictive package that could handle not only logisitic 
models, but other models, like the Lotka-Volterra models. Now, I'm not 
saying this is impossible to do in Julia: in fact, I'm quite sure it is. 
It's just less convenient.

The other nice things about environments are more trivial. For example, you 
might be doing a homework assignment with several problems. At the start of 
each problem, you could define a new environment. At the end of the 
problem, you could display the entire content of the problem's environment 
as a way to track down errors. When looking at an answer sheet, you could 
compare intermediate results and see where you went wrong. Again, not 
impossible to do with Julia; you would probably want to set up a dict for 
each problem, and do all operations within that dict. Which, I guess, is 
basically what is happening under the hood in a language with environments.

I'll just nod in agreement with the fexpr stuff and pretend I understand.

On Friday, July 24, 2015 at 4:11:37 PM UTC-4, Scott Jones wrote:
>
> I should give you a hard time about arguing from authority ;-), but I was 
> there at the same time and knew KMP, so I wouldn't want to argue too much 
> with him either, and I am in agreement with you about fexprs vs. macros, 
> and the equivalent issues in Julia.
>
> On Friday, July 24, 2015 at 2:31:54 PM UTC-4, Stefan Karpinski wrote:
>>
>> Lisp has already been down this path – fexprs 
>>  were special forms with behavior 
>> similar to R's functions, and they were deprecated in the 1980s in favor of 
>> macros, 
>> https://en.wikipedia.org/wiki/Fexpr#Mainstream_use_and_deprecation:
>>
>> His central objection was that, in a Lisp dialect that allows fexprs, 
>>> static analysis cannot determine generally whether an operator represents 
>>> an ordinary function or a fexpr — therefore, static analysis cannot 
>>> determine whether or not the operands will be evaluated. In particular, the 
>>> compiler cannot tell whether a subexpression can be safely optimized, since 
>>> the subexpression might be treated as unevaluated data at run-time.
>>
>>
>> If Lispers think a feature is too dynamic and hard to understand, that's 
>> a danger sign. In general, I wouldn't want to argue too much with Kent 
>> Pitman :-)
>>
>> On the subject of Kent Pitman, here's a random bit of Lisp wisdom from this 
>> interview 
>> 
>>  
>> with him:
>>
>> I like Lisp's willingness to represent itself. People often explain this 
>>> as its ability to represent itself, but I think that's wrong. Most 
>>> languages are capable of representing themselves, but they simply don't 
>>> have the will to. Lisp programs are represented by lists and programmers 
>>> are aware of that. It wouldn't matter if it had been arrays. It does matter 
>>> that it's program structure that is represented, and not character syntax, 
>>> but beyond that the choice is pretty arbitrary. It's not important that the 
>>> representation be the Right® choice. It's just important that it be a 
>>> common, agreed-upon choice so that there can be a rich community of 
>>> program-manipulating programs that "do trade" in this common representation.
>>
>>
>> This is probably the best quote about homoiconicity I've read anywhere 
>> and explains why the term is tricky to pin down.
>>
>> On Fri, Jul 24, 2015 at 2:21 PM, Brandon Taylor  
>> wrote:
>>
>>> Macros seem to have a bunch of limitations. They can't be overloaded to 
>>> take advantage of Julia's typing system. Their functionality can somewhat 
>>> mimic evaluation within a function in its direct parent environment, but 
>>> what if you want to write functions within your macro, or macros inside 
>>> your macro, etc? Probably still possible to do many things, but it would 
>>> invovle passing expressions back in fo

Re: [julia-users] Re: complex results - why not automatic type conversion?

[Mauro]

> The lack of this specific issue appearing in say Python may be that the 
> relative speed penalty is not that large? It seems that one of the strong 
> features of Julia is its speed, having to deal with complex numbers in this 
> way means that people have to pay more attention  to coding than when using 
> other languages.

One of the reasons that Julia is as fast as it is, is because when there
is a choice between fast and convenient, Julia (usually) picks the fast
choice.  Another example is that Julia uses native integer arithmetic:
http://docs.julialang.org/en/release-0.3/manual/faq/#why-does-julia-use-native-machine-integer-arithmetic
see also
https://github.com/JuliaLang/julia/issues/855

(But this behavior is not without critique)

Python, R and Matlab often take the convenient choice, maybe as a small
speed penalty does not matter to them?

> I can imagine that if I wanted to have code running as fast as possible in 
> say a case where I don't know if eigen values will be real or complex, I 
> could code for both cases within the file and take branches according? Does 
> that approach even make any sense in the context of Julia?

You should try out Julia a bit more!  Julia's multiple dispatch makes it
super easy and natural to write code which works with several types:
just define methods for each type where it matters and generic ones
where it doesn't.  Voila!

Concerning the eigenvalues, if you don't know whether they are real or
not then you should default to complex.

[julia-users] Re: complex results - why not automatic type conversion?

[Joe Tusek]

The lack of this specific issue appearing in say Python may be that the 
relative speed penalty is not that large? It seems that one of the strong 
features of Julia is its speed, having to deal with complex numbers in this 
way means that people have to pay more attention  to coding than when using 
other languages.

I can imagine that if I wanted to have code running as fast as possible in 
say a case where I don't know if eigen values will be real or complex, I 
could code for both cases within the file and take branches according? Does 
that approach even make any sense in the context of Julia?