[julia-users] Meaty example of using singleton types

[milktrader]

Trying to wrap my mind around singleton types to see if they might be 
useful for something I'm working on, but running into some confusion. Here 
is an example that I started working with:

julia> type BadInt
   end

julia> import Base.+

julia> +(x::BadInt, y::Int64) = x - y
+ (generic function with 172 methods)

julia> BadInt() = 2
BadInt

julia> BadInt + 2
ERROR: MethodError: `+` has no method matching +(::Type{BadInt}, ::Int64)
Closest candidates are:
  +(::Any, ::Any, ::Any, ::Any...)
  +(::Int64, ::Int64)
  +(::Complex{Bool}, ::Real)
  ...

As I understand, a singleton type can only take on a single value. What's 
the utility in supporting this?

[julia-users] Re: Using DataFrames

[Andre Bieler]

Hi Vish,

there are two things I can spot.

1) You actually do have a header in the .csv file, so header=false is not a 
good option.

2) Something probably has gone wrong with the formatting of the second line 
in your .csv file.
It contains stuff like: *.1.739873170852661133e.00* which cannot be 
interpreted as a number
(note the dot in front of 1)

if I remove the second line of your .csv file I can read it in with

df = readtable("sample.csv")

So you might check the script producing your .csv file to get a nicely 
formatted
first line of the data.

Hope this helps.
Andre




On Tuesday, December 8, 2015 at 11:27:34 PM UTC-5, Vishnu Raj wrote:
>
> This is my sample CSV. It is an extract from UCI SUSY dataset, only first 
> few were saved using an R script.
>
>
> On Wednesday, December 9, 2015 at 3:26:19 AM UTC+5:30, Andre Bieler wrote:
>>
>> I cannot reproduce this.
>> Can you provide your data file?
>>
>> I attached a .cvs file and a .jl file to 
>> read out the data. Seems all good to me
>> and the values are stored as Float64.
>>
>>
>>
>>
>>
>> On Tuesday, December 8, 2015 at 7:24:26 AM UTC-5, Vishnu Raj wrote:
>>>
>>> Hi,
>>> I have a CSV file with values represented as 2.345 and 1.23e2 (say) and 
>>> no header
>>> When I try readtable( "file", header=false ), I'm getting all the cell 
>>> values as "UTF8String". How can I properly read it as Float64??
>>>
>>> - vish
>>>
>>

[julia-users] Re: Meaty example of using singleton types

[elextr]

On Wednesday, December 9, 2015 at 10:01:25 PM UTC+10, milktrader wrote:
>
> Trying to wrap my mind around singleton types to see if they might be 
> useful for something I'm working on, but running into some confusion. Here 
> is an example that I started working with:
>
> julia> type BadInt
>end
>
> julia> import Base.+
>
> julia> +(x::BadInt, y::Int64) = x - y
> + (generic function with 172 methods)
>
> julia> BadInt() = 2
> BadInt
>

Did not the above re-define BadInt() as a function returning 2 rather than 
the constructor for type BadInt?
 

>
> julia> BadInt + 2
>

As the error says, this is adding a type to an int, which isn't defined, 
not an instance of the singleton to the int as you intended.
 

> ERROR: MethodError: `+` has no method matching +(::Type{BadInt}, ::Int64)
> Closest candidates are:
>   +(::Any, ::Any, ::Any, ::Any...)
>   +(::Int64, ::Int64)
>   +(::Complex{Bool}, ::Real)
>   ...
>
> As I understand, a singleton type can only take on a single value. What's 
> the utility in supporting this?
>

Singletons take on no value, they have a size of zero (see 
http://docs.julialang.org/en/release-0.4/devdocs/object/?highlight=singleton#memory-layout-of-julia-objects).

There is only one instance of a singleton, no matter how often the 
constructor is called.  This is especially useful for parametric 
singletons, see Type{}

Re: [julia-users] The optimization strategy for fft didn't work

[Yichao Yu]

On Wed, Dec 9, 2015 at 5:57 AM, 博陈  wrote:

>
> 
> the optimization strategy for fft given by the official documentation
> seems to fail. Why?
>

You didn't mention exactly what optimization strategy you are trying so I
would need to guess.

1. You should expect the first one to be no faster than the last one since
it's basically doing the same thing and the first one does it all in global
scope
2. In place op doesn't make too much a difference here since the operation
you are doing is already very expensive. (most of the time are spent in
FFTW)
3. It doesn't really matter for this one (since FFTW determines the
performance here) but you should benchmark the loop in a function and hoist
the creation of the plan out of the loop. For your actual code, you might
want to make the plan a global constant or a parametrized field of a type
since it has not been not particularly type stable.
4. You can use `plan_fft(, flags=FFTW.MEASURE)` to let FFTW select the
best algorithm by actually measuring the time instead of guessing. It gives
me 20% to 30% speed up for your example and IIRC more speed up for small
problems.
5. You can use `FFTW.flops(p)` to figure out how much floating point
operations are needed to perform your transformation. On my computer, a
MEASURE'd plan takes 4.3s (100 times) and the naive estimation from
assuming one operation per clock cycle is 2s (100 times) so it's the right
order of magnitude.

Re: [julia-users] Understanding memory allocation output

[Tim Holy]

You have a mismatch between what's running and what's in the file. Have you 
edited the source code file but are still running in a session that loaded an 
older version of the file? Try doing this in a fresh session. Are you using a 
"userimg.jl" file? (If the latter, you need to rebuild julia to incorporate 
changes in packages you load.)

--Tim

On Tuesday, December 08, 2015 10:07:26 PM Júlio Hoffimann wrote:
> Hi,
> 
> I don't understand why some lines like 6, 16, 29, 33, 186 are allocating
> memory in the attached example. Can someone explain?
> 
> -Júlio

[julia-users] Re: Meaty example of using singleton types

[Eric Forgy]

Not sure I follow, but does this help?

julia> type BadInt
   end

julia> bi = BadInt()
BadInt()

julia> typeof(bi)
BadInt


On Wednesday, December 9, 2015 at 9:46:01 PM UTC+8, milktrader wrote:
>
> How do you create an instance of type BadInt then?
>
> On Wednesday, December 9, 2015 at 7:01:25 AM UTC-5, milktrader wrote:
>>
>> Trying to wrap my mind around singleton types to see if they might be 
>> useful for something I'm working on, but running into some confusion. Here 
>> is an example that I started working with:
>>
>> julia> type BadInt
>>end
>>
>> julia> import Base.+
>>
>> julia> +(x::BadInt, y::Int64) = x - y
>> + (generic function with 172 methods)
>>
>> julia> BadInt() = 2
>> BadInt
>>
>> julia> BadInt + 2
>> ERROR: MethodError: `+` has no method matching +(::Type{BadInt}, ::Int64)
>> Closest candidates are:
>>   +(::Any, ::Any, ::Any, ::Any...)
>>   +(::Int64, ::Int64)
>>   +(::Complex{Bool}, ::Real)
>>   ...
>>
>> As I understand, a singleton type can only take on a single value. What's 
>> the utility in supporting this?
>>
>

[julia-users] A non-breaking Julia control-flow change to separate the One language from mortal languages, doomed to die

[Dan]

*A non-breaking Julia control-flow change to separate the One language from 
mortal languages, doomed to die
*
>From a design patterns and DRY perspective it seems `for` loops together with 
>the `break` statement are serving
as a useful `try`/`catch` mechanism for non-error situations. A common pattern 
defines a variable before a `for` loop and tries to discern, using said 
variable, the circumstances of exiting the `for` loop. Leveraging the embedded 
mental construct of `try`/`catch` blocks, we can simplify this repeating 
pattern and make it easier and more readable.

The syntax can look as follows:


for ...(loop vars here)... 

...(local vars here)...

...

if ...

break 

end

...

catch 

...(access local/loop vars and  here)...



finally

...(access local/loop vars here)...



end 


Syntax changes worthy of consideration should be self-explanatory to many, as I 
hope this suggestion is.
But an example should help:

After change:


for line in eachline(f) 

fields = split(line) 

status = fileds[2] 

if status=="FAIL" 

break 

end 

catch 

println("Test $(fields[1]) failed with reason $(fields[3])") 

finally 

println("Test successful!") 

end 

Before change:
 

fields = [] 

didfail = false 

for line in eachline(f) 

fields = split(line) 

status = fields[2] 

if status=="FAIL" 

didfail = true 

break 

end 

end 

if didfail 

println("Test $(fields[1]) failed with reason $(fields[3])") 

else 

println("Test successful!") 

end 


The above example does not use the `break ` suggestion. With multiple 
`break` circumstances it should be useful to have separate code for each 
circumstance. One option is to replicate the `try`/`catch` form with a 
`` passed as ``, another would be to use `catch ` to run 
catch block if "`break  == catch `" (the `` can be a human 
readable symbol). A direct jump in the LLVM code to the appropriate `catch` 
block would be an easy optimization to implement.

Another issue to consider is the return value of a `for` block. The suggestion 
above adds the option to change the current default `nothing` return with 
`` in the new optional blocks.

Notice that the `catch` and `finally` blocks are completely optional and 
therefore backward compatibility is easy. Additionally there are no additional 
keywords and block nesting would not conflict with `try`/`catch`.

Hey, Julia is still < 0.9 so there is still time for some change.

Obligatory Disclaimerism:

1. This has already been considered before by **name**/**issue**.
2. Before suggesting I should have studied past discussions more.
3. Other langauges actually already have this... bla bla.
4. This post is what it is.


This suggestion is also readable in github markdown in the gist: 
https://gist.github.com/getzdan/75136f130c6f8ffeb60e


Feedback/Pointers/Gotchas welcome, of course.

Re: [julia-users] Re: Meaty example of using singleton types

[Tom Short]

I'm not sure what you want, either. How about this?

julia> type BadInt{X} end

julia> BadInt{3}()
BadInt{3}()

julia> f{X}(::Type{BadInt{X}}, y) = X - y
f (generic function with 1 method)

julia> f(BadInt{10}, 3)
7

julia> f{X}(::BadInt{X}, y) = X - y
f (generic function with 2 methods)

julia> f(BadInt{10}(), 3)
7


On Wed, Dec 9, 2015 at 8:56 AM, Eric Forgy  wrote:

> Not sure I follow, but does this help?
>
> julia> type BadInt
>end
>
> julia> bi = BadInt()
> BadInt()
>
> julia> typeof(bi)
> BadInt
>
>
> On Wednesday, December 9, 2015 at 9:46:01 PM UTC+8, milktrader wrote:
>>
>> How do you create an instance of type BadInt then?
>>
>> On Wednesday, December 9, 2015 at 7:01:25 AM UTC-5, milktrader wrote:
>>>
>>> Trying to wrap my mind around singleton types to see if they might be
>>> useful for something I'm working on, but running into some confusion. Here
>>> is an example that I started working with:
>>>
>>> julia> type BadInt
>>>end
>>>
>>> julia> import Base.+
>>>
>>> julia> +(x::BadInt, y::Int64) = x - y
>>> + (generic function with 172 methods)
>>>
>>> julia> BadInt() = 2
>>> BadInt
>>>
>>> julia> BadInt + 2
>>> ERROR: MethodError: `+` has no method matching +(::Type{BadInt}, ::Int64)
>>> Closest candidates are:
>>>   +(::Any, ::Any, ::Any, ::Any...)
>>>   +(::Int64, ::Int64)
>>>   +(::Complex{Bool}, ::Real)
>>>   ...
>>>
>>> As I understand, a singleton type can only take on a single value.
>>> What's the utility in supporting this?
>>>
>>

Re: [julia-users] Re: Meaty example of using singleton types

[Eric Forgy]

How about this?

https://github.com/JuliaLang/julia/blob/2d821670d2516cd38b51710b07b3eb18f191cd1b/base/multimedia.jl


On Wednesday, December 9, 2015 at 10:22:06 PM UTC+8, milktrader wrote:
>
> I'd like a somewhat clever example (or boring one for that matter) that 
> shows:
>
> 1. How to create an instance of a singleton type
>
> 2. How to write methods that use this type in a meaningful way.
>
> 3. How it's used in Base code (I seem to recall Void is a singleton type)
>
> On Wednesday, December 9, 2015 at 9:02:31 AM UTC-5, tshort wrote:
>>
>> I'm not sure what you want, either. How about this?
>>
>> julia> type BadInt{X} end
>>
>> julia> BadInt{3}()
>> BadInt{3}()
>>
>> julia> f{X}(::Type{BadInt{X}}, y) = X - y
>> f (generic function with 1 method)
>>
>> julia> f(BadInt{10}, 3)
>> 7
>>
>> julia> f{X}(::BadInt{X}, y) = X - y
>> f (generic function with 2 methods)
>>
>> julia> f(BadInt{10}(), 3)
>> 7
>>
>>
>> On Wed, Dec 9, 2015 at 8:56 AM, Eric Forgy  wrote:
>>
>>> Not sure I follow, but does this help?
>>>
>>> julia> type BadInt
>>>end
>>>
>>> julia> bi = BadInt()
>>> BadInt()
>>>
>>> julia> typeof(bi)
>>> BadInt
>>>
>>>
>>> On Wednesday, December 9, 2015 at 9:46:01 PM UTC+8, milktrader wrote:

 How do you create an instance of type BadInt then?

 On Wednesday, December 9, 2015 at 7:01:25 AM UTC-5, milktrader wrote:
>
> Trying to wrap my mind around singleton types to see if they might be 
> useful for something I'm working on, but running into some confusion. 
> Here 
> is an example that I started working with:
>
> julia> type BadInt
>end
>
> julia> import Base.+
>
> julia> +(x::BadInt, y::Int64) = x - y
> + (generic function with 172 methods)
>
> julia> BadInt() = 2
> BadInt
>
> julia> BadInt + 2
> ERROR: MethodError: `+` has no method matching +(::Type{BadInt}, 
> ::Int64)
> Closest candidates are:
>   +(::Any, ::Any, ::Any, ::Any...)
>   +(::Int64, ::Int64)
>   +(::Complex{Bool}, ::Real)
>   ...
>
> As I understand, a singleton type can only take on a single value. 
> What's the utility in supporting this?
>

>>

[julia-users] A non-breaking Julia control-flow change to separate the One language from mortal languages, doomed to die

[Dan]

*A non-breaking Julia control-flow change to separate the One language from *

*mortal languages, doomed to die
*
>From a design patterns and DRY perspective it seems `for` loops together with 
>the `break` statement 

are serving as a useful `try`/`catch` mechanism for non-error situations. A 
common pattern defines 

a variable before a `for` loop and tries to discern, using said variable, the 
circumstances of exiting 

the `for` loop. Leveraging the embedded mental construct of `try`/`catch` 
blocks, we can simplify 

this repeating pattern and make it easier and more readable.

The syntax can look as follows:

for ...(loop vars here)... 

...(local vars here)...

...

if ...

break 

end

...

catch 

...(access local/loop vars and  here)...



finally

...(access local/loop vars here)...



end 

Syntax changes worthy of consideration should be self-explanatory to 
many, as I hope this suggestion is.
But an example should help:

After change:

for line in eachline(f) 

fields = split(line) 

status = fileds[2] 

if status=="FAIL" 

break 

end 

catch 

println("Test $(fields[1]) failed with reason $(fields[3])") 

finally 

println("Test successful!") 

end 

Before change:

 

fields = [] 

didfail = false 

for line in eachline(f) 

fields = split(line) 

status = fields[2] 

if status=="FAIL" 

didfail = true 

break 

end 

end 

if didfail 

println("Test $(fields[1]) failed with reason $(fields[3])") 

else 

println("Test successful!") 

end 

The above example does not use the `break ` suggestion. 
With multiple `break` circumstances it should

be useful to have separate code for each circumstance. One option is to 
replicate the `try`/`catch` form 

with a `` passed as ``, another would be to use `catch ` 
to run catch block 

if "`break  == catch `" (the `` can be a human readable 
symbol). A direct jump in the 

LLVM code to the appropriate `catch` block would be an easy optimization to 
implement.

Another issue to consider is the return value of a `for` block. The suggestion 
above adds the option to change 

the current default `nothing` return with `` in the new optional 
blocks.

Notice that the `catch` and `finally` blocks are completely optional and 
therefore backward compatibility 

is easy. Additionally there are no additional keywords and block nesting would 
not conflict with `try`/`catch`.

Hey, Julia is still < 0.9 so there is still time for some change.

Obligatory Disclaimerism:

1. This has already been considered before by **name**/**issue**.
2. Before suggesting I should have studied past discussions more.
3. Other langauges actually already have this... bla bla.
4. This post is what it is.


This suggestion is also readable in github markdown in the gist: 
https://gist.github.com/getzdan/75136f130c6f8ffeb60e


Feedback/Pointers/Gotchas welcome, of course.

[julia-users] Re: using statement with for loop inside if statement

[Steven G. Johnson]

A using statement affects the global scope, so it doesn't make a lot of sense 
to evaluate it in local scope. That's why it's not allowed. The eval function 
evaluates in global scope, so it can execute a using statement. 

In general, though, if you are eval'ing a using statement, you should probably 
reorganize your code to do the using directly in global scope. For example, put 
your code into a module if you want to keep the using statement isolated from 
other code. 

[julia-users] A non-breaking Julia control-flow change to separate the One language from mortal languages, doomed to die

[Dan]

*A non-breaking Julia control-flow change to separate the One language from *

*mortal languages, doomed to die
*
>From a design patterns and DRY perspective it seems `for` loops together with 
>the `break` statement 

are serving as a useful `try`/`catch` mechanism for non-error situations. A 
common pattern defines 

a variable before a `for` loop and tries to discern, using said variable, the 
circumstances of exiting 

the `for` loop. Leveraging the embedded mental construct of `try`/`catch` 
blocks, we can simplify 

this repeating pattern and make it easier and more readable.

The syntax can look as follows:


for ...(loop vars here)... 

...(local vars here)...

...

if ...

break 

end

...

catch 

...(access local/loop vars and  here)...



finally

...(access local/loop vars here)...



end 


Syntax changes worthy of consideration should be self-explanatory to many, as I 
hope this suggestion is.
But an example should help:

After change:


for line in eachline(f) 

fields = split(line) 

status = fileds[2] 

if status=="FAIL" 

break 

end 

catch 

println("Test $(fields[1]) failed with reason $(fields[3])") 

finally 

println("Test successful!") 

end 

Before change:
 

fields = [] 

didfail = false 

for line in eachline(f) 

fields = split(line) 

status = fields[2] 

if status=="FAIL" 

didfail = true 

break 

end 

end 

if didfail 

println("Test $(fields[1]) failed with reason $(fields[3])") 

else 

println("Test successful!") 

end 


The above example does not use the `break ` suggestion. With multiple 
`break` circumstances it should

be useful to have separate code for each circumstance. One option is to 
replicate the `try`/`catch` form 

with a `` passed as ``, another would be to use `catch ` 
to run catch block 

if "`break  == catch `" (the `` can be a human readable 
symbol). A direct jump in the 

LLVM code to the appropriate `catch` block would be an easy optimization to 
implement.

Another issue to consider is the return value of a `for` block. The suggestion 
above adds the option to change 

the current default `nothing` return with `` in the new optional 
blocks.

Notice that the `catch` and `finally` blocks are completely optional and 
therefore backward compatibility 

is easy. Additionally there are no additional keywords and block nesting would 
not conflict with `try`/`catch`.

Hey, Julia is still < 0.9 so there is still time for some change.

Obligatory Disclaimerism:

1. This has already been considered before by **name**/**issue**.
2. Before suggesting I should have studied past discussions more.
3. Other langauges actually already have this... bla bla.
4. This post is what it is.


This suggestion is also readable in github markdown in the gist: 
https://gist.github.com/getzdan/75136f130c6f8ffeb60e


Feedback/Pointers/Gotchas welcome, of course.

Re: [julia-users] Re: Meaty example of using singleton types

[milktrader]

Thanks, that's something to look at.

On Wednesday, December 9, 2015 at 9:28:13 AM UTC-5, Eric Forgy wrote:
>
> How about this?
>
>
> https://github.com/JuliaLang/julia/blob/2d821670d2516cd38b51710b07b3eb18f191cd1b/base/multimedia.jl
>
>
> On Wednesday, December 9, 2015 at 10:22:06 PM UTC+8, milktrader wrote:
>>
>> I'd like a somewhat clever example (or boring one for that matter) that 
>> shows:
>>
>> 1. How to create an instance of a singleton type
>>
>> 2. How to write methods that use this type in a meaningful way.
>>
>> 3. How it's used in Base code (I seem to recall Void is a singleton type)
>>
>> On Wednesday, December 9, 2015 at 9:02:31 AM UTC-5, tshort wrote:
>>>
>>> I'm not sure what you want, either. How about this?
>>>
>>> julia> type BadInt{X} end
>>>
>>> julia> BadInt{3}()
>>> BadInt{3}()
>>>
>>> julia> f{X}(::Type{BadInt{X}}, y) = X - y
>>> f (generic function with 1 method)
>>>
>>> julia> f(BadInt{10}, 3)
>>> 7
>>>
>>> julia> f{X}(::BadInt{X}, y) = X - y
>>> f (generic function with 2 methods)
>>>
>>> julia> f(BadInt{10}(), 3)
>>> 7
>>>
>>>
>>> On Wed, Dec 9, 2015 at 8:56 AM, Eric Forgy  wrote:
>>>
 Not sure I follow, but does this help?

 julia> type BadInt
end

 julia> bi = BadInt()
 BadInt()

 julia> typeof(bi)
 BadInt


 On Wednesday, December 9, 2015 at 9:46:01 PM UTC+8, milktrader wrote:
>
> How do you create an instance of type BadInt then?
>
> On Wednesday, December 9, 2015 at 7:01:25 AM UTC-5, milktrader wrote:
>>
>> Trying to wrap my mind around singleton types to see if they might be 
>> useful for something I'm working on, but running into some confusion. 
>> Here 
>> is an example that I started working with:
>>
>> julia> type BadInt
>>end
>>
>> julia> import Base.+
>>
>> julia> +(x::BadInt, y::Int64) = x - y
>> + (generic function with 172 methods)
>>
>> julia> BadInt() = 2
>> BadInt
>>
>> julia> BadInt + 2
>> ERROR: MethodError: `+` has no method matching +(::Type{BadInt}, 
>> ::Int64)
>> Closest candidates are:
>>   +(::Any, ::Any, ::Any, ::Any...)
>>   +(::Int64, ::Int64)
>>   +(::Complex{Bool}, ::Real)
>>   ...
>>
>> As I understand, a singleton type can only take on a single value. 
>> What's the utility in supporting this?
>>
>
>>>

Re: [julia-users] Re: Meaty example of using singleton types

[milktrader]

I'd like a somewhat clever example (or boring one for that matter) that 
shows:

1. How to create an instance of a singleton type

2. How to write methods that use this type in a meaningful way.

3. How it's used in Base code (I seem to recall Void is a singleton type)

On Wednesday, December 9, 2015 at 9:02:31 AM UTC-5, tshort wrote:
>
> I'm not sure what you want, either. How about this?
>
> julia> type BadInt{X} end
>
> julia> BadInt{3}()
> BadInt{3}()
>
> julia> f{X}(::Type{BadInt{X}}, y) = X - y
> f (generic function with 1 method)
>
> julia> f(BadInt{10}, 3)
> 7
>
> julia> f{X}(::BadInt{X}, y) = X - y
> f (generic function with 2 methods)
>
> julia> f(BadInt{10}(), 3)
> 7
>
>
> On Wed, Dec 9, 2015 at 8:56 AM, Eric Forgy  > wrote:
>
>> Not sure I follow, but does this help?
>>
>> julia> type BadInt
>>end
>>
>> julia> bi = BadInt()
>> BadInt()
>>
>> julia> typeof(bi)
>> BadInt
>>
>>
>> On Wednesday, December 9, 2015 at 9:46:01 PM UTC+8, milktrader wrote:
>>>
>>> How do you create an instance of type BadInt then?
>>>
>>> On Wednesday, December 9, 2015 at 7:01:25 AM UTC-5, milktrader wrote:

 Trying to wrap my mind around singleton types to see if they might be 
 useful for something I'm working on, but running into some confusion. Here 
 is an example that I started working with:

 julia> type BadInt
end

 julia> import Base.+

 julia> +(x::BadInt, y::Int64) = x - y
 + (generic function with 172 methods)

 julia> BadInt() = 2
 BadInt

 julia> BadInt + 2
 ERROR: MethodError: `+` has no method matching +(::Type{BadInt}, 
 ::Int64)
 Closest candidates are:
   +(::Any, ::Any, ::Any, ::Any...)
   +(::Int64, ::Int64)
   +(::Complex{Bool}, ::Real)
   ...

 As I understand, a singleton type can only take on a single value. 
 What's the utility in supporting this?

>>>
>

[julia-users] Re: Expression Equality

[Fabian Gans]

Maybe this helps:

Expr(:call, Expr(:., :symbol, QuoteNode(:x)))==:(symbol.x()) --> TRUE

[julia-users] Re: Meaty example of using singleton types

[milktrader]

How do you create an instance of type BadInt then?

On Wednesday, December 9, 2015 at 7:01:25 AM UTC-5, milktrader wrote:
>
> Trying to wrap my mind around singleton types to see if they might be 
> useful for something I'm working on, but running into some confusion. Here 
> is an example that I started working with:
>
> julia> type BadInt
>end
>
> julia> import Base.+
>
> julia> +(x::BadInt, y::Int64) = x - y
> + (generic function with 172 methods)
>
> julia> BadInt() = 2
> BadInt
>
> julia> BadInt + 2
> ERROR: MethodError: `+` has no method matching +(::Type{BadInt}, ::Int64)
> Closest candidates are:
>   +(::Any, ::Any, ::Any, ::Any...)
>   +(::Int64, ::Int64)
>   +(::Complex{Bool}, ::Real)
>   ...
>
> As I understand, a singleton type can only take on a single value. What's 
> the utility in supporting this?
>

[julia-users] Re: Expression Equality

[STAR0SS]

You can also use dump() on your expressions to see how they differ exactly. 
The normal printing doesn't really show you much.

Re: [julia-users] Re: Meaty example of using singleton types

[Yichao Yu]

On Wed, Dec 9, 2015 at 9:22 AM, milktrader  wrote:
> I'd like a somewhat clever example (or boring one for that matter) that
> shows:
>
> 1. How to create an instance of a singleton type

Call the constructor just like any other types.

The only special thing about singleton type is that two instance of a
mutable singleton type are identical. Other than this, they are simply
types that doesn't have a field.

>
> 2. How to write methods that use this type in a meaningful way.

Just like any other types. As long as you are not comparing them, they
are exactly the same with everything else.

>
> 3. How it's used in Base code (I seem to recall Void is a singleton type)
>
> On Wednesday, December 9, 2015 at 9:02:31 AM UTC-5, tshort wrote:
>>
>> I'm not sure what you want, either. How about this?
>>
>> julia> type BadInt{X} end
>>
>> julia> BadInt{3}()
>> BadInt{3}()
>>
>> julia> f{X}(::Type{BadInt{X}}, y) = X - y
>> f (generic function with 1 method)
>>
>> julia> f(BadInt{10}, 3)
>> 7
>>
>> julia> f{X}(::BadInt{X}, y) = X - y
>> f (generic function with 2 methods)
>>
>> julia> f(BadInt{10}(), 3)
>> 7
>>
>>
>> On Wed, Dec 9, 2015 at 8:56 AM, Eric Forgy  wrote:
>>>
>>> Not sure I follow, but does this help?
>>>
>>> julia> type BadInt
>>>end
>>>
>>> julia> bi = BadInt()
>>> BadInt()
>>>
>>> julia> typeof(bi)
>>> BadInt
>>>
>>>
>>> On Wednesday, December 9, 2015 at 9:46:01 PM UTC+8, milktrader wrote:

 How do you create an instance of type BadInt then?

 On Wednesday, December 9, 2015 at 7:01:25 AM UTC-5, milktrader wrote:
>
> Trying to wrap my mind around singleton types to see if they might be
> useful for something I'm working on, but running into some confusion. Here
> is an example that I started working with:
>
> julia> type BadInt
>end
>
> julia> import Base.+
>
> julia> +(x::BadInt, y::Int64) = x - y
> + (generic function with 172 methods)
>
> julia> BadInt() = 2
> BadInt
>
> julia> BadInt + 2
> ERROR: MethodError: `+` has no method matching +(::Type{BadInt},
> ::Int64)
> Closest candidates are:
>   +(::Any, ::Any, ::Any, ::Any...)
>   +(::Int64, ::Int64)
>   +(::Complex{Bool}, ::Real)
>   ...
>
> As I understand, a singleton type can only take on a single value.
> What's the utility in supporting this?
>>
>>
>

Re: [julia-users] Re: using statement with for loop inside if statement

[Isaiah Norton]

>
> Something weird/unexpected does seem to be going on here:
>

There are some other edge cases like this where otherwise-top-level
expressions fail (essentially: the lowered code contains a `goto`, which
the interpreter doesn't support. so the thunk is sent to the JIT instead,
which can't yet handle `using`)

see e.g.
https://github.com/JuliaLang/julia/issues/2586
https://github.com/JuliaLang/julia/issues/4893

On Wed, Dec 9, 2015 at 10:50 AM, Josh Langsfeld  wrote:

> But an if statement does not introduce new scope, correct?
>
> Something weird/unexpected does seem to be going on here:
>
> julia> VERSION
> v"0.5.0-dev+1491"
>
> julia> if true
>  using Compat
>  println("Using")
>  foreach(println, 1:3)
>end
> Using
> 1
> 2
> 3
>
>
> julia> if true
>  using Compat
>  println("Using")
>  for i=1:3
>println(i)
>  end
>end
> ERROR: error compiling anonymous: unsupported or misplaced expression
> "using" in function anonymous
>  in eval at ./boot.jl:263
>
>
>
> On Wednesday, December 9, 2015 at 10:22:51 AM UTC-5, Steven G. Johnson
> wrote:
>>
>> A using statement affects the global scope, so it doesn't make a lot of
>> sense to evaluate it in local scope. That's why it's not allowed. The eval
>> function evaluates in global scope, so it can execute a using statement.
>>
>> In general, though, if you are eval'ing a using statement, you should
>> probably reorganize your code to do the using directly in global scope. For
>> example, put your code into a module if you want to keep the using
>> statement isolated from other code.
>>
>

[julia-users] Fun and games

[Tom Breloff]

Does anyone know of a Julia package which wraps the Arcade Learning 
Environment (http://www.arcadelearningenvironment.org/)?  I found @Andy-P's 
package https://github.com/Andy-P/DeepQLearning.jl, but this only has the 
learning algorithm, not the underlying framework.  My interest lies in 
novel approaches to AGI, and a Julia-wrapped ALE would enable some good 
benchmarks.  Also if anyone else shares these goals and is interested in 
collaboration, please reach out.

Thanks,
Tom

[julia-users] find source location for type definition

[Tamas Papp]

Is there an equivalent of

@edit function(arg1, ...)

for type definitions? @edit is so nice in Emacs. Currently I am using

M-x find-grep-dired RET \(type\|immutable\) Foo

but something built-in for Julia would be very convenient.

Best,

Tamas

[julia-users] Re: using statement with for loop inside if statement

[Brian Rogoff]

In what way doesn't it make sense to evaluate it in a local scope? It's 
true that Julia modules don't behave that way now, but other languages 
support local
modules; D and OCaml come to mind.

On Wednesday, December 9, 2015 at 7:22:51 AM UTC-8, Steven G. Johnson wrote:
>
> A using statement affects the global scope, so it doesn't make a lot of 
> sense to evaluate it in local scope. That's why it's not allowed. The eval 
> function evaluates in global scope, so it can execute a using statement. 
>
> In general, though, if you are eval'ing a using statement, you should 
> probably reorganize your code to do the using directly in global scope. For 
> example, put your code into a module if you want to keep the using 
> statement isolated from other code. 
>

Re: [julia-users] Reading from open()-ed process produces silence

[Miguel Bazdresch]

Do you get different results using readavailable()? Maybe there isn't a
newline on the stream and readline() blocks waiting for it.

On Tue, Dec 8, 2015 at 2:51 PM, Colin Beckingham 
wrote:

> I'm trying to launch a process from a Julia script. The process is a
> socket server.
> If I start the socket server outside Julia, then use Julia to connect to
> the socket, I can read from and write to the connected stream.
>
> Now if I use open() inside Julia to launch the socket server, wait a few
> seconds for it to set up and listen
> then connect() is good, the process starts, I give it some input and it
> acts on that input correctly, then my task
> is to collect text output from the socket server. But the readline()
> request waits and waits, hearing nothing.
>
> I guess I am confused by all the handles: stream and process are returned
> from open(), but I have the connect() handle as well.
> Perhaps something is blocking the output on open()?
>

Re: [julia-users] Understanding memory allocation output

[Júlio Hoffimann]

Thanks Tim, I'll double check it.

-Júlio

Re: [julia-users] Re: using statement with for loop inside if statement

[Josh Langsfeld]

Good to know. I also saw there's another related one where Steven reported 
an almost identical code 
sample: https://github.com/JuliaLang/julia/issues/6901

On Wednesday, December 9, 2015 at 11:03:45 AM UTC-5, Isaiah wrote:
>
> Something weird/unexpected does seem to be going on here:
>>
>
> There are some other edge cases like this where otherwise-top-level 
> expressions fail (essentially: the lowered code contains a `goto`, which 
> the interpreter doesn't support. so the thunk is sent to the JIT instead, 
> which can't yet handle `using`)
>
> see e.g.
> https://github.com/JuliaLang/julia/issues/2586
> https://github.com/JuliaLang/julia/issues/4893
>
> On Wed, Dec 9, 2015 at 10:50 AM, Josh Langsfeld  > wrote:
>
>> But an if statement does not introduce new scope, correct?
>>
>> Something weird/unexpected does seem to be going on here:
>>
>> julia> VERSION
>> v"0.5.0-dev+1491"
>>
>> julia> if true
>>  using Compat
>>  println("Using")  
>>  foreach(println, 1:3)
>>end
>> Using
>> 1
>> 2
>> 3
>>
>>
>> julia> if true
>>  using Compat
>>  println("Using")  
>>  for i=1:3
>>println(i)
>>  end
>>end
>> ERROR: error compiling anonymous: unsupported or misplaced expression 
>> "using" in function anonymous
>>  in eval at ./boot.jl:263
>>
>>
>>
>> On Wednesday, December 9, 2015 at 10:22:51 AM UTC-5, Steven G. Johnson 
>> wrote:
>>>
>>> A using statement affects the global scope, so it doesn't make a lot of 
>>> sense to evaluate it in local scope. That's why it's not allowed. The eval 
>>> function evaluates in global scope, so it can execute a using statement. 
>>>
>>> In general, though, if you are eval'ing a using statement, you should 
>>> probably reorganize your code to do the using directly in global scope. For 
>>> example, put your code into a module if you want to keep the using 
>>> statement isolated from other code. 
>>>
>>
>

Re: [julia-users] Re: A non-breaking Julia control-flow change to separate the One language from mortal languages, doomed to die

[Erik Schnetter]

One way to convince people that a new feature is worthwhile is to implement
an approximation of the feature, e.g. via a macro. If it then sees
widespread use, you have a strong argument in your favour.

Here's a possibility, using the customary "macro-in-front,
begin-end-around-everything" approach:

@loop begin for i in 1:10
...
if i==8 break end
end
finally
info("did not break")
end

I'm sure the syntax needs cleaning up.

-erik



On Wed, Dec 9, 2015 at 10:47 AM, Seth  wrote:

> Seems to me that this is just a more complex repeat...until or do...while
> bottom-conditional loop, which has already been discussed and rejected (to
> my disappointment).
>
>
> On Wednesday, December 9, 2015 at 7:05:43 AM UTC-8, Dan wrote:
>>
>> *A non-breaking Julia control-flow change to separate the One language from *
>>
>> *mortal languages, doomed to die
>> *
>> From a design patterns and DRY perspective it seems `for` loops together 
>> with the `break` statement
>>
>> are serving as a useful `try`/`catch` mechanism for non-error situations. A 
>> common pattern defines
>>
>> a variable before a `for` loop and tries to discern, using said variable, 
>> the circumstances of exiting
>>
>> the `for` loop. Leveraging the embedded mental construct of `try`/`catch` 
>> blocks, we can simplify
>>
>> this repeating pattern and make it easier and more readable.
>>
>> The syntax can look as follows:
>>
>> for ...(loop vars here)...
>>
>> ...(local vars here)...
>>
>> ...
>>
>> if ...
>>
>> break 
>>
>> end
>>
>> ...
>>
>> catch 
>>
>> ...(access local/loop vars and  here)...
>>
>> 
>>
>> finally
>>
>> ...(access local/loop vars here)...
>>
>> 
>>
>> end
>>
>>  Syntax changes worthy of consideration should be self-explanatory to 
>> many, as I hope this suggestion is.
>> But an example should help:
>>
>> After change:
>>
>> for line in eachline(f)
>>
>> fields = split(line)
>>
>> status = fileds[2]
>>
>> if status=="FAIL"
>>
>> break
>>
>> end
>>
>> catch
>>
>> println("Test $(fields[1]) failed with reason $(fields[3])")
>>
>> finally
>>
>> println("Test successful!")
>>
>> end
>>
>> Before change:
>>
>>
>>
>> fields = []
>>
>> didfail = false
>>
>> for line in eachline(f)
>>
>> fields = split(line)
>>
>> status = fields[2]
>>
>> if status=="FAIL"
>>
>> didfail = true
>>
>> break
>>
>> end
>>
>> end
>>
>> if didfail
>>
>> println("Test $(fields[1]) failed with reason $(fields[3])")
>>
>> else
>>
>> println("Test successful!")
>>
>> end
>>
>>  The above example does not use the `break ` suggestion. 
>> With multiple `break` circumstances it should
>>
>> be useful to have separate code for each circumstance. One option is to 
>> replicate the `try`/`catch` form
>>
>> with a `` passed as ``, another would be to use `catch 
>> ` to run catch block
>>
>> if "`break  == catch `" (the `` can be a human readable 
>> symbol). A direct jump in the
>>
>> LLVM code to the appropriate `catch` block would be an easy optimization to 
>> implement.
>>
>> Another issue to consider is the return value of a `for` block. The 
>> suggestion above adds the option to change
>>
>> the current default `nothing` return with `` in the new optional 
>> blocks.
>>
>> Notice that the `catch` and `finally` blocks are completely optional and 
>> therefore backward compatibility
>>
>> is easy. Additionally there are no additional keywords and block nesting 
>> would not conflict with `try`/`catch`.
>>
>> Hey, Julia is still < 0.9 so there is still time for some change.
>>
>> Obligatory Disclaimerism:
>>
>> 1. This has already been considered before by **name**/**issue**.
>> 2. Before suggesting I should have studied past discussions more.
>> 3. Other langauges actually already have this... bla bla.
>> 4. This post is what it is.
>>
>>
>> This suggestion is also readable in github markdown in the gist: 
>> https://gist.github.com/getzdan/75136f130c6f8ffeb60e
>>
>>
>> Feedback/Pointers/Gotchas welcome, of course.
>>
>>


-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

[julia-users] Re: A non-breaking Julia control-flow change to separate the One language from mortal languages, doomed to die

[Seth]

Seems to me that this is just a more complex repeat...until or do...while 
bottom-conditional loop, which has already been discussed and rejected (to 
my disappointment).

On Wednesday, December 9, 2015 at 7:05:43 AM UTC-8, Dan wrote:
>
> *A non-breaking Julia control-flow change to separate the One language from *
>
> *mortal languages, doomed to die
> *
> From a design patterns and DRY perspective it seems `for` loops together with 
> the `break` statement 
>
> are serving as a useful `try`/`catch` mechanism for non-error situations. A 
> common pattern defines 
>
> a variable before a `for` loop and tries to discern, using said variable, the 
> circumstances of exiting 
>
> the `for` loop. Leveraging the embedded mental construct of `try`/`catch` 
> blocks, we can simplify 
>
> this repeating pattern and make it easier and more readable.
>
> The syntax can look as follows:
>
> for ...(loop vars here)... 
>
> ...(local vars here)...
>
> ...
>
> if ...
>
> break 
>
> end
>
> ...
>
> catch 
>
> ...(access local/loop vars and  here)...
>
> 
>
> finally
>
> ...(access local/loop vars here)...
>
> 
>
> end 
>
>   Syntax changes worthy of consideration should be self-explanatory to 
> many, as I hope this suggestion is.
> But an example should help:
>
> After change:
>
> for line in eachline(f) 
>
> fields = split(line) 
>
> status = fileds[2] 
>
> if status=="FAIL" 
>
> break 
>
> end 
>
> catch 
>
> println("Test $(fields[1]) failed with reason $(fields[3])") 
>
> finally 
>
> println("Test successful!") 
>
> end 
>
> Before change:
>
>  
>
> fields = [] 
>
> didfail = false 
>
> for line in eachline(f) 
>
> fields = split(line) 
>
> status = fields[2] 
>
> if status=="FAIL" 
>
> didfail = true 
>
> break 
>
> end 
>
> end 
>
> if didfail 
>
> println("Test $(fields[1]) failed with reason $(fields[3])") 
>
> else 
>
> println("Test successful!") 
>
> end 
>
>   The above example does not use the `break ` suggestion. 
> With multiple `break` circumstances it should
>
> be useful to have separate code for each circumstance. One option is to 
> replicate the `try`/`catch` form 
>
> with a `` passed as ``, another would be to use `catch 
> ` to run catch block 
>
> if "`break  == catch `" (the `` can be a human readable 
> symbol). A direct jump in the 
>
> LLVM code to the appropriate `catch` block would be an easy optimization to 
> implement.
>
> Another issue to consider is the return value of a `for` block. The 
> suggestion above adds the option to change 
>
> the current default `nothing` return with `` in the new optional 
> blocks.
>
> Notice that the `catch` and `finally` blocks are completely optional and 
> therefore backward compatibility 
>
> is easy. Additionally there are no additional keywords and block nesting 
> would not conflict with `try`/`catch`.
>
> Hey, Julia is still < 0.9 so there is still time for some change.
>
> Obligatory Disclaimerism:
>
> 1. This has already been considered before by **name**/**issue**.
> 2. Before suggesting I should have studied past discussions more.
> 3. Other langauges actually already have this... bla bla.
> 4. This post is what it is.
>
>
> This suggestion is also readable in github markdown in the gist: 
> https://gist.github.com/getzdan/75136f130c6f8ffeb60e
>
>
> Feedback/Pointers/Gotchas welcome, of course.
>
>

[julia-users] Re: using statement with for loop inside if statement

[Josh Langsfeld]

But an if statement does not introduce new scope, correct?

Something weird/unexpected does seem to be going on here:

julia> VERSION
v"0.5.0-dev+1491"

julia> if true
 using Compat
 println("Using")  
 foreach(println, 1:3)
   end
Using
1
2
3


julia> if true
 using Compat
 println("Using")  
 for i=1:3
   println(i)
 end
   end
ERROR: error compiling anonymous: unsupported or misplaced expression 
"using" in function anonymous
 in eval at ./boot.jl:263



On Wednesday, December 9, 2015 at 10:22:51 AM UTC-5, Steven G. Johnson 
wrote:
>
> A using statement affects the global scope, so it doesn't make a lot of 
> sense to evaluate it in local scope. That's why it's not allowed. The eval 
> function evaluates in global scope, so it can execute a using statement. 
>
> In general, though, if you are eval'ing a using statement, you should 
> probably reorganize your code to do the using directly in global scope. For 
> example, put your code into a module if you want to keep the using 
> statement isolated from other code. 
>

Re: [julia-users] ERROR: ArgumentError: MyTest not found in path

[Yichao Yu]

On Wed, Dec 9, 2015 at 1:52 AM, Ajith Joseph  wrote:
> I am getting started with Julia - Version 0.4.2. I am not able to load a
> module in REPL
>
> ajoseph-osx:julia_test ajoseph$ cat /Users/ajoseph/julia_test/test.jl
>
> module MyTest
>
> end
>
>
> julia> push!(LOAD_PATH, "/Users/ajoseph/julia_test")
>
> 3-element Array{ByteString,1}:
>
>
> "/Applications/Julia-0.4.2.app/Contents/Resources/julia/local/share/julia/site/v0.4"
>
>
> "/Applications/Julia-0.4.2.app/Contents/Resources/julia/share/julia/site/v0.4"
>
>  "/Users/ajoseph/julia_test"
>
>
> julia> using MyTest
>
> ERROR: ArgumentError: MyTest not found in path
>
>  in require at
> /Applications/Julia-0.4.2.app/Contents/Resources/julia/lib/julia/sys.dylib
>
>
> What am I doing wrong here?

Rename your file to match the name of the module. Even though the
module name is not tied to file names in julia, the loader still need
to be able to figure out the file to know from the module name. If the
file it find (`ModuleName/src/ModuleName.jl` or `ModuleName.jl` in
load path) doesn't define the module, you will get a warning.

>
> Thanks

Re: [julia-users] Re: Meaty example of using singleton types

[Yichao Yu]

On Wed, Dec 9, 2015 at 12:50 PM, milktrader  wrote:
> Can you provide a Foo example of how this works, with both construction and
> method definition?

julia> type Foo
   end

julia> Base.(:+)(::Foo, x) = x
+ (generic function with 175 methods)

julia> Foo() + 1
1

julia> Foo() + "bar"
"bar"


>
> On Wednesday, December 9, 2015 at 9:32:36 AM UTC-5, Yichao Yu wrote:
>>
>> On Wed, Dec 9, 2015 at 9:22 AM, milktrader  wrote:
>> > I'd like a somewhat clever example (or boring one for that matter) that
>> > shows:
>> >
>> > 1. How to create an instance of a singleton type
>>
>> Call the constructor just like any other types.
>>
>> The only special thing about singleton type is that two instance of a
>> mutable singleton type are identical. Other than this, they are simply
>> types that doesn't have a field.
>>
>> >
>> > 2. How to write methods that use this type in a meaningful way.
>>
>> Just like any other types. As long as you are not comparing them, they
>> are exactly the same with everything else.
>>
>> >
>> > 3. How it's used in Base code (I seem to recall Void is a singleton
>> > type)
>> >
>> > On Wednesday, December 9, 2015 at 9:02:31 AM UTC-5, tshort wrote:
>> >>
>> >> I'm not sure what you want, either. How about this?
>> >>
>> >> julia> type BadInt{X} end
>> >>
>> >> julia> BadInt{3}()
>> >> BadInt{3}()
>> >>
>> >> julia> f{X}(::Type{BadInt{X}}, y) = X - y
>> >> f (generic function with 1 method)
>> >>
>> >> julia> f(BadInt{10}, 3)
>> >> 7
>> >>
>> >> julia> f{X}(::BadInt{X}, y) = X - y
>> >> f (generic function with 2 methods)
>> >>
>> >> julia> f(BadInt{10}(), 3)
>> >> 7
>> >>
>> >>
>> >> On Wed, Dec 9, 2015 at 8:56 AM, Eric Forgy  wrote:
>> >>>
>> >>> Not sure I follow, but does this help?
>> >>>
>> >>> julia> type BadInt
>> >>>end
>> >>>
>> >>> julia> bi = BadInt()
>> >>> BadInt()
>> >>>
>> >>> julia> typeof(bi)
>> >>> BadInt
>> >>>
>> >>>
>> >>> On Wednesday, December 9, 2015 at 9:46:01 PM UTC+8, milktrader wrote:
>> 
>>  How do you create an instance of type BadInt then?
>> 
>>  On Wednesday, December 9, 2015 at 7:01:25 AM UTC-5, milktrader wrote:
>> >
>> > Trying to wrap my mind around singleton types to see if they might
>> > be
>> > useful for something I'm working on, but running into some
>> > confusion. Here
>> > is an example that I started working with:
>> >
>> > julia> type BadInt
>> >end
>> >
>> > julia> import Base.+
>> >
>> > julia> +(x::BadInt, y::Int64) = x - y
>> > + (generic function with 172 methods)
>> >
>> > julia> BadInt() = 2
>> > BadInt
>> >
>> > julia> BadInt + 2
>> > ERROR: MethodError: `+` has no method matching +(::Type{BadInt},
>> > ::Int64)
>> > Closest candidates are:
>> >   +(::Any, ::Any, ::Any, ::Any...)
>> >   +(::Int64, ::Int64)
>> >   +(::Complex{Bool}, ::Real)
>> >   ...
>> >
>> > As I understand, a singleton type can only take on a single value.
>> > What's the utility in supporting this?
>> >>
>> >>
>> >

[julia-users] A Julia equivalent of destructors - is that a thing?

[Ben Ward]

Hi,

I'm not sure of the answer, but is there an equivalent of the concept of a 
class destructor in Julia? I can imagine a situation where there is some 
type where a field is something like - for example - a file stream, and you 
want to make sure if that variable gets deleted by the gc, then the stream 
that is one of those variables get's closed.

Best,
Ben.

Re: [julia-users] A Julia equivalent of destructors - is that a thing?

[Stefan Karpinski]

http://docs.julialang.org/en/release-0.4/stdlib/base/#Base.finalizer

On Wed, Dec 9, 2015 at 2:12 PM, Ben Ward  wrote:

> Hi,
>
> I'm not sure of the answer, but is there an equivalent of the concept of a
> class destructor in Julia? I can imagine a situation where there is some
> type where a field is something like - for example - a file stream, and you
> want to make sure if that variable gets deleted by the gc, then the stream
> that is one of those variables get's closed.
>
> Best,
> Ben.
>
>

Re: [julia-users] A Julia equivalent of destructors - is that a thing?

[Ben Ward]

Thanks Stefan,

After googling the method I noticed some github issues where Jeff said that 
finalizer is inefficient and that we should not use it so much #11207. 
Should I be concerned about this?

The reason I ask is I'm about to try and forge ahead with BioJulia's 
Dat.jl, and I guess stream work, or types associated with a stream field 
are a possibility.

On Wednesday, December 9, 2015 at 7:16:25 PM UTC, Stefan Karpinski wrote:
>
> http://docs.julialang.org/en/release-0.4/stdlib/base/#Base.finalizer
>
> On Wed, Dec 9, 2015 at 2:12 PM, Ben Ward  > wrote:
>
>> Hi,
>>
>> I'm not sure of the answer, but is there an equivalent of the concept of 
>> a class destructor in Julia? I can imagine a situation where there is some 
>> type where a field is something like - for example - a file stream, and you 
>> want to make sure if that variable gets deleted by the gc, then the stream 
>> that is one of those variables get's closed.
>>
>> Best,
>> Ben.
>>
>>
>

Re: [julia-users] Re: A non-breaking Julia control-flow change to separate the One language from mortal languages, doomed to die

[Dan]

Good idea regarding macro.

Not really trying to convince people, just to entice them and gauge the 
response. The traditional method of achieving the same results is OK, but 
I'm just thinking this could be better. Having said all of this, stability 
of a language has much merit as well.

On Wednesday, December 9, 2015 at 6:27:00 PM UTC+2, Erik Schnetter wrote:
>
> One way to convince people that a new feature is worthwhile is to 
> implement an approximation of the feature, e.g. via a macro. If it then 
> sees widespread use, you have a strong argument in your favour.
>
> Here's a possibility, using the customary "macro-in-front, 
> begin-end-around-everything" approach:
>
> @loop begin for i in 1:10
> ...
> if i==8 break end
> end
> finally
> info("did not break")
> end
>
> I'm sure the syntax needs cleaning up.
>
> -erik
>
>
>
> On Wed, Dec 9, 2015 at 10:47 AM, Seth  > wrote:
>
>> Seems to me that this is just a more complex repeat...until or do...while 
>> bottom-conditional loop, which has already been discussed and rejected (to 
>> my disappointment).
>>
>>
>> On Wednesday, December 9, 2015 at 7:05:43 AM UTC-8, Dan wrote:
>>>
>>> *A non-breaking Julia control-flow change to separate the One language from 
>>> *
>>>
>>> *mortal languages, doomed to die
>>> *
>>> From a design patterns and DRY perspective it seems `for` loops together 
>>> with the `break` statement 
>>>
>>> are serving as a useful `try`/`catch` mechanism for non-error situations. A 
>>> common pattern defines 
>>>
>>> a variable before a `for` loop and tries to discern, using said variable, 
>>> the circumstances of exiting 
>>>
>>> the `for` loop. Leveraging the embedded mental construct of `try`/`catch` 
>>> blocks, we can simplify 
>>>
>>> this repeating pattern and make it easier and more readable.
>>>
>>> The syntax can look as follows:
>>>
>>> for ...(loop vars here)... 
>>>
>>> ...(local vars here)...
>>>
>>> ...
>>>
>>> if ...
>>>
>>> break 
>>>
>>> end
>>>
>>> ...
>>>
>>> catch 
>>>
>>> ...(access local/loop vars and  here)...
>>>
>>> 
>>>
>>> finally
>>>
>>> ...(access local/loop vars here)...
>>>
>>> 
>>>
>>> end 
>>>
>>> Syntax changes worthy of consideration should be self-explanatory to 
>>> many, as I hope this suggestion is.
>>> But an example should help:
>>>
>>> After change:
>>>
>>> for line in eachline(f) 
>>>
>>> fields = split(line) 
>>>
>>> status = fileds[2] 
>>>
>>> if status=="FAIL" 
>>>
>>> break 
>>>
>>> end 
>>>
>>> catch 
>>>
>>> println("Test $(fields[1]) failed with reason $(fields[3])") 
>>>
>>> finally 
>>>
>>> println("Test successful!") 
>>>
>>> end 
>>>
>>> Before change:
>>>
>>>  
>>>
>>> fields = [] 
>>>
>>> didfail = false 
>>>
>>> for line in eachline(f) 
>>>
>>> fields = split(line) 
>>>
>>> status = fields[2] 
>>>
>>> if status=="FAIL" 
>>>
>>> didfail = true 
>>>
>>> break 
>>>
>>> end 
>>>
>>> end 
>>>
>>> if didfail 
>>>
>>> println("Test $(fields[1]) failed with reason $(fields[3])") 
>>>
>>> else 
>>>
>>> println("Test successful!") 
>>>
>>> end 
>>>
>>> The above example does not use the `break ` suggestion. 
>>> With multiple `break` circumstances it should
>>>
>>> be useful to have separate code for each circumstance. One option is to 
>>> replicate the `try`/`catch` form 
>>>
>>> with a `` passed as ``, another would be to use `catch 
>>> ` to run catch block 
>>>
>>> if "`break  == catch `" (the `` can be a human 
>>> readable symbol). A direct jump in the 
>>>
>>> LLVM code to the appropriate `catch` block would be an easy optimization to 
>>> implement.
>>>
>>> Another issue to consider is the return value of a `for` block. The 
>>> suggestion above adds the option to change 
>>>
>>> the current default `nothing` return with `` in the new optional 
>>> blocks.
>>>
>>> Notice that the `catch` and `finally` blocks are completely optional and 
>>> therefore backward compatibility 
>>>
>>> is easy. Additionally there are no additional keywords and block nesting 
>>> would not conflict with `try`/`catch`.
>>>
>>> Hey, Julia is still < 0.9 so there is still time for some change.
>>>
>>> Obligatory Disclaimerism:
>>>
>>> 1. This has already been considered before by **name**/**issue**.
>>> 2. Before suggesting I should have studied past discussions more.
>>> 3. Other langauges actually already have this... bla bla.
>>> 4. This post is what it is.
>>>
>>>
>>> This suggestion is also readable in github markdown in the gist: 
>>> https://gist.github.com/getzdan/75136f130c6f8ffeb60e
>>>
>>>
>>> Feedback/Pointers/Gotchas welcome, of course.
>>>
>>>
>
>
> -- 
> Erik Schnetter  
> http://www.perimeterinstitute.ca/personal/eschnetter/
>

Re: [julia-users] Re: Meaty example of using singleton types

[Yichao Yu]

On Wed, Dec 9, 2015 at 3:51 PM, milktrader  wrote:
> Ok, thanks. Can you do the following then?
>
> 1. restrict the value of Foo to an Int64?
> 2. assign the value of 6 to the singleton?

A singleton is not a variable and you can't change it's value or
assign to use. That's what variable or maybe global constants are for.

This is also what I mean by it's just a normal type. You can't assign
a Int64 value to a Float64 value.

>
>
>
> On Wednesday, December 9, 2015 at 1:09:08 PM UTC-5, Yichao Yu wrote:
>>
>> On Wed, Dec 9, 2015 at 12:50 PM, milktrader  wrote:
>> > Can you provide a Foo example of how this works, with both construction
>> > and
>> > method definition?
>>
>> julia> type Foo
>>end
>>
>> julia> Base.(:+)(::Foo, x) = x
>> + (generic function with 175 methods)
>>
>> julia> Foo() + 1
>> 1
>>
>> julia> Foo() + "bar"
>> "bar"
>>
>>
>> >
>> > On Wednesday, December 9, 2015 at 9:32:36 AM UTC-5, Yichao Yu wrote:
>> >>
>> >> On Wed, Dec 9, 2015 at 9:22 AM, milktrader  wrote:
>> >> > I'd like a somewhat clever example (or boring one for that matter)
>> >> > that
>> >> > shows:
>> >> >
>> >> > 1. How to create an instance of a singleton type
>> >>
>> >> Call the constructor just like any other types.
>> >>
>> >> The only special thing about singleton type is that two instance of a
>> >> mutable singleton type are identical. Other than this, they are simply
>> >> types that doesn't have a field.
>> >>
>> >> >
>> >> > 2. How to write methods that use this type in a meaningful way.
>> >>
>> >> Just like any other types. As long as you are not comparing them, they
>> >> are exactly the same with everything else.
>> >>
>> >> >
>> >> > 3. How it's used in Base code (I seem to recall Void is a singleton
>> >> > type)
>> >> >
>> >> > On Wednesday, December 9, 2015 at 9:02:31 AM UTC-5, tshort wrote:
>> >> >>
>> >> >> I'm not sure what you want, either. How about this?
>> >> >>
>> >> >> julia> type BadInt{X} end
>> >> >>
>> >> >> julia> BadInt{3}()
>> >> >> BadInt{3}()
>> >> >>
>> >> >> julia> f{X}(::Type{BadInt{X}}, y) = X - y
>> >> >> f (generic function with 1 method)
>> >> >>
>> >> >> julia> f(BadInt{10}, 3)
>> >> >> 7
>> >> >>
>> >> >> julia> f{X}(::BadInt{X}, y) = X - y
>> >> >> f (generic function with 2 methods)
>> >> >>
>> >> >> julia> f(BadInt{10}(), 3)
>> >> >> 7
>> >> >>
>> >> >>
>> >> >> On Wed, Dec 9, 2015 at 8:56 AM, Eric Forgy 
>> >> >> wrote:
>> >> >>>
>> >> >>> Not sure I follow, but does this help?
>> >> >>>
>> >> >>> julia> type BadInt
>> >> >>>end
>> >> >>>
>> >> >>> julia> bi = BadInt()
>> >> >>> BadInt()
>> >> >>>
>> >> >>> julia> typeof(bi)
>> >> >>> BadInt
>> >> >>>
>> >> >>>
>> >> >>> On Wednesday, December 9, 2015 at 9:46:01 PM UTC+8, milktrader
>> >> >>> wrote:
>> >> 
>> >>  How do you create an instance of type BadInt then?
>> >> 
>> >>  On Wednesday, December 9, 2015 at 7:01:25 AM UTC-5, milktrader
>> >>  wrote:
>> >> >
>> >> > Trying to wrap my mind around singleton types to see if they
>> >> > might
>> >> > be
>> >> > useful for something I'm working on, but running into some
>> >> > confusion. Here
>> >> > is an example that I started working with:
>> >> >
>> >> > julia> type BadInt
>> >> >end
>> >> >
>> >> > julia> import Base.+
>> >> >
>> >> > julia> +(x::BadInt, y::Int64) = x - y
>> >> > + (generic function with 172 methods)
>> >> >
>> >> > julia> BadInt() = 2
>> >> > BadInt
>> >> >
>> >> > julia> BadInt + 2
>> >> > ERROR: MethodError: `+` has no method matching +(::Type{BadInt},
>> >> > ::Int64)
>> >> > Closest candidates are:
>> >> >   +(::Any, ::Any, ::Any, ::Any...)
>> >> >   +(::Int64, ::Int64)
>> >> >   +(::Complex{Bool}, ::Real)
>> >> >   ...
>> >> >
>> >> > As I understand, a singleton type can only take on a single
>> >> > value.
>> >> > What's the utility in supporting this?
>> >> >>
>> >> >>
>> >> >

[julia-users] Re: Expression Equality

[vishesh]

sorry ok, I see - it's 
Expr.head
and 
Expr.args

Man, I really wish Julia had something like python's help(Expr) to see all 
the methods/fields of a class...

On Tuesday, December 8, 2015 at 8:26:35 PM UTC-8, vis...@stanford.edu wrote:
>
> Situations where the printed form of an expression (i.e, what you'd type 
> into julia REPL, for example) are equivalent aren't "equal" per julia's 
> standards:
>
> Expr(:call, :<, 1, 2) --> :(1 < 2)
> Meta.show_sexpr(:(1 < 2)) --> (:comparison, 1, :<, 2)
> Expr(:call, :<, 1, 2) == :(1 < 2) --> FALSE
>
> I figure that's expected because the s-expressions behind the scenes 
> aren't accurate.
> So the workaround is:
>
> Expr(:call, :<, 1, 2) == :(<(1,2)) --> TRUE
>
> This isn't ideal, but at least there's a way to express the Expr object I 
> want in terms of julia's syntax. 
> Is there another way to make these two semantically equivalent 
> representations actually be equal?
>
> Second - a much weirder problem:
>
> Meta.show_sexpr(:(symbol.x())) --> (:call, (:., :symbol, (:quote, :x)))
>
>
> Ok, so make an expression:
>
> Meta.show_sexpr(Expr(:call, Expr(:., :symbol, Expr(:quote, :x --> (:call, 
> (:., :symbol, (:quote, :x)))
>
>
> Cool. So this time the expression object and the actual julia 
> representation are the exact same.
>
> However:
>
> Expr(:call, Expr(:., :symbol, Expr(:quote, :x))) == :(symbol.x()) --> FALSE
>
>
> And stragely
>
>
> Meta.show_sexpr(Expr(:call, Expr(:., :symbol, Expr(:quote, :x == 
> Meta.show_sexpr(:(symbol.x())) --> TRUE
>
> What is going on!? And how do I get these expressions to agree?
>
>
> Vishesh
>
>
>
>
>
>

Re: [julia-users] Re: Meaty example of using singleton types

[milktrader]

Ok, thanks. Can you do the following then?

1. restrict the value of Foo to an Int64?
2. assign the value of 6 to the singleton?



On Wednesday, December 9, 2015 at 1:09:08 PM UTC-5, Yichao Yu wrote:
>
> On Wed, Dec 9, 2015 at 12:50 PM, milktrader  > wrote: 
> > Can you provide a Foo example of how this works, with both construction 
> and 
> > method definition? 
>
> julia> type Foo 
>end 
>
> julia> Base.(:+)(::Foo, x) = x 
> + (generic function with 175 methods) 
>
> julia> Foo() + 1 
> 1 
>
> julia> Foo() + "bar" 
> "bar" 
>
>
> > 
> > On Wednesday, December 9, 2015 at 9:32:36 AM UTC-5, Yichao Yu wrote: 
> >> 
> >> On Wed, Dec 9, 2015 at 9:22 AM, milktrader  wrote: 
> >> > I'd like a somewhat clever example (or boring one for that matter) 
> that 
> >> > shows: 
> >> > 
> >> > 1. How to create an instance of a singleton type 
> >> 
> >> Call the constructor just like any other types. 
> >> 
> >> The only special thing about singleton type is that two instance of a 
> >> mutable singleton type are identical. Other than this, they are simply 
> >> types that doesn't have a field. 
> >> 
> >> > 
> >> > 2. How to write methods that use this type in a meaningful way. 
> >> 
> >> Just like any other types. As long as you are not comparing them, they 
> >> are exactly the same with everything else. 
> >> 
> >> > 
> >> > 3. How it's used in Base code (I seem to recall Void is a singleton 
> >> > type) 
> >> > 
> >> > On Wednesday, December 9, 2015 at 9:02:31 AM UTC-5, tshort wrote: 
> >> >> 
> >> >> I'm not sure what you want, either. How about this? 
> >> >> 
> >> >> julia> type BadInt{X} end 
> >> >> 
> >> >> julia> BadInt{3}() 
> >> >> BadInt{3}() 
> >> >> 
> >> >> julia> f{X}(::Type{BadInt{X}}, y) = X - y 
> >> >> f (generic function with 1 method) 
> >> >> 
> >> >> julia> f(BadInt{10}, 3) 
> >> >> 7 
> >> >> 
> >> >> julia> f{X}(::BadInt{X}, y) = X - y 
> >> >> f (generic function with 2 methods) 
> >> >> 
> >> >> julia> f(BadInt{10}(), 3) 
> >> >> 7 
> >> >> 
> >> >> 
> >> >> On Wed, Dec 9, 2015 at 8:56 AM, Eric Forgy  
> wrote: 
> >> >>> 
> >> >>> Not sure I follow, but does this help? 
> >> >>> 
> >> >>> julia> type BadInt 
> >> >>>end 
> >> >>> 
> >> >>> julia> bi = BadInt() 
> >> >>> BadInt() 
> >> >>> 
> >> >>> julia> typeof(bi) 
> >> >>> BadInt 
> >> >>> 
> >> >>> 
> >> >>> On Wednesday, December 9, 2015 at 9:46:01 PM UTC+8, milktrader 
> wrote: 
> >>  
> >>  How do you create an instance of type BadInt then? 
> >>  
> >>  On Wednesday, December 9, 2015 at 7:01:25 AM UTC-5, milktrader 
> wrote: 
> >> > 
> >> > Trying to wrap my mind around singleton types to see if they 
> might 
> >> > be 
> >> > useful for something I'm working on, but running into some 
> >> > confusion. Here 
> >> > is an example that I started working with: 
> >> > 
> >> > julia> type BadInt 
> >> >end 
> >> > 
> >> > julia> import Base.+ 
> >> > 
> >> > julia> +(x::BadInt, y::Int64) = x - y 
> >> > + (generic function with 172 methods) 
> >> > 
> >> > julia> BadInt() = 2 
> >> > BadInt 
> >> > 
> >> > julia> BadInt + 2 
> >> > ERROR: MethodError: `+` has no method matching +(::Type{BadInt}, 
> >> > ::Int64) 
> >> > Closest candidates are: 
> >> >   +(::Any, ::Any, ::Any, ::Any...) 
> >> >   +(::Int64, ::Int64) 
> >> >   +(::Complex{Bool}, ::Real) 
> >> >   ... 
> >> > 
> >> > As I understand, a singleton type can only take on a single 
> value. 
> >> > What's the utility in supporting this? 
> >> >> 
> >> >> 
> >> > 
>

Re: [julia-users] Re: Expression Equality

[Erik Schnetter]

I want to test the expression

```
macroexpand(:@fastmath :+)
```

where `:+` is a symbol, not a function.

I wasn't able to determine the difference. I used both `info` and `dump`,
and my LHS (the result of the expression above) and what I constructed
manually looked identical, and in the REPL, the epression

```
macroexpand(:@fastmath :+) == :(:+)
```
yields `true`. In `test/fastmath.jl`, it didn't. (It works fine for five
other expressions that are currently being tested.)

Anyway -- my point being that it can be quite useful to compare
expressions, even if the exact value might change over time. Since Julia's
macros are all about manipulating expressions, having ways to output,
serialize, load, compare, and treat them like any other data makes totally
sense.

-erik



On Wed, Dec 9, 2015 at 4:05 PM, Yichao Yu  wrote:

> On Wed, Dec 9, 2015 at 3:57 PM, Erik Schnetter 
> wrote:
> > Comparing expressions is useful if you want to write a test case for a
> > function that transforms expressions, such as e.g. `@fastmath`. I
> recently
> > added some test cases, but was unable to test the result of
> >
> > macroexpand(:@fastmath :+)
> >
> > since I don't know how to explicitly construct the expected result. I
> know
> > how to do it in the REPL, but this doesn't work in test cases.
>
> What's the difference between REPL and test script?
>
> julia -f -e 'println(macroexpand(:(@fastmath +)) ==
> :(Base.FastMath.add_fast))'
> true
>
>
> >
> > -erik
> >
> >
> > On Wed, Dec 9, 2015 at 3:46 PM, Yichao Yu  wrote:
> >>
> >> On Wed, Dec 9, 2015 at 3:05 PM,   wrote:
> >> > Interesting. I didn't think to use dump to check differences.
> >> >
> >> > Another followup question. After using dump on some simple if
> >> > statements,
> >> > I've noticed that all blocks induce this LineNumberNode which is
> messing
> >> > up
> >> > the equality.
> >> > Is there a way to ignore these nodes in the equality check? They show
> up
> >> > in
> >> > any kind of block statement (function, if, etc)
> >> >
> >>
> >> May I ask what do you need the equality of expressions for? It doesn't
> >> sound like a too useful concept. There can be expressions that are
> >> equal but have different side effects due to the variables they
> >> capture (try constructing `Expr(:call, :push!, [1, 2], 1)` twice and
> >> eval/compare them). There can also be expressions that are equivalant
> >> but appears differently.
> >>
> >> In general, I never find `==` of expressions too useful. When
> >> processing it, you can just ignore the line number nodes if you don't
> >> care too much about debug info (also see base/docs/Docs.jl for some
> >> example of stripping unwanted part from a expression). There's also
> >> MacroTools.jl which provides a nice way to process expressions.
> >>
> >> > eg:
> >> >
> >> > dump(:(if true 1 else 0 end))
> >> >
> >> > Expr
> >> >
> >> >   head: Symbol if
> >> >
> >> >   args: Array(Any,(3,))
> >> >
> >> > 1: Bool true
> >> >
> >> > 2: Expr
> >> >
> >> >   head: Symbol block
> >> >
> >> >   args: Array(Any,(2,))
> >> >
> >> > 1: LineNumberNode
> >> >
> >> >   file: Symbol none
> >> >
> >> >   line: Int64 1
> >> >
> >> > 2: Int64 1
> >> >
> >> >   typ: Any
> >> >
> >> > 3: Expr
> >> >
> >> >   head: Symbol block
> >> >
> >> >   args: Array(Any,(2,))
> >> >
> >> > 1: LineNumberNode
> >> >
> >> >   file: Symbol none
> >> >
> >> >   line: Int64 1
> >> >
> >> > 2: Int64 0
> >> >
> >> >   typ: Any
> >> >
> >> >   typ: Any
> >> >
> >> >
> >> > dump(Expr(:if, true, Expr(:block, 0), Expr(:block,1)))
> >> >
> >> > Expr
> >> >
> >> >   head: Symbol if
> >> >
> >> >   args: Array(Any,(3,))
> >> >
> >> > 1: Bool true
> >> >
> >> > 2: Expr
> >> >
> >> >   head: Symbol block
> >> >
> >> >   args: Array(Any,(1,))
> >> >
> >> > 1: Int64 0
> >> >
> >> >   typ: Any
> >> >
> >> > 3: Expr
> >> >
> >> >   head: Symbol block
> >> >
> >> >   args: Array(Any,(1,))
> >> >
> >> > 1: Int64 1
> >> >
> >> >   typ: Any
> >> >
> >> >   typ: Any
> >> >
> >> >
> >> > They're the same minus LineNumberNodes, because block type expressions
> >> > always create those things.
> >> >
> >> >
> >> > On Wednesday, December 9, 2015 at 7:21:55 AM UTC-8, STAR0SS wrote:
> >> >>
> >> >> You can also use dump() on your expressions to see how they differ
> >> >> exactly. The normal printing doesn't really show you much.
> >
> >
> >
> >
> > --
> > Erik Schnetter 
> > http://www.perimeterinstitute.ca/personal/eschnetter/
>



-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

Re: [julia-users] Re: Expression Equality

[Yichao Yu]

On Wed, Dec 9, 2015 at 5:08 PM,   wrote:
> Indeed, my use case is also writing proper tests for macros using FactCheck.
> I have a more bizarre use case which involves writing a lisp using julia
> (learning purposes only), but it's more out there.
>
> In this case, it'd be nice to verify that the expression I get matches the
> one I expect.
> Is there a way process an Expression and ignore nodes (i.e, linenumbernode,
> which has absolutely nothing to do with expression equality, and represents
> internal julia metadata)? It'd be a tree traversal function, maybe, but I'm
> unable to find any documentation on how to manipulate Expression objects.
> Even something like cons/first/rest would be sufficient for my case.

Expr is just a normal object and you can access the head and args fields.

>
> On Wednesday, December 9, 2015 at 1:26:14 PM UTC-8, Erik Schnetter wrote:
>>
>> I want to test the expression
>>
>> ```
>> macroexpand(:@fastmath :+)
>> ```
>>
>> where `:+` is a symbol, not a function.
>>
>> I wasn't able to determine the difference. I used both `info` and `dump`,
>> and my LHS (the result of the expression above) and what I constructed
>> manually looked identical, and in the REPL, the epression
>>
>> ```
>> macroexpand(:@fastmath :+) == :(:+)
>> ```
>> yields `true`. In `test/fastmath.jl`, it didn't. (It works fine for five
>> other expressions that are currently being tested.)
>>
>> Anyway -- my point being that it can be quite useful to compare
>> expressions, even if the exact value might change over time. Since Julia's
>> macros are all about manipulating expressions, having ways to output,
>> serialize, load, compare, and treat them like any other data makes totally
>> sense.
>>
>> -erik
>>
>>
>>
>> On Wed, Dec 9, 2015 at 4:05 PM, Yichao Yu  wrote:
>>>
>>> On Wed, Dec 9, 2015 at 3:57 PM, Erik Schnetter  wrote:
>>> > Comparing expressions is useful if you want to write a test case for a
>>> > function that transforms expressions, such as e.g. `@fastmath`. I
>>> > recently
>>> > added some test cases, but was unable to test the result of
>>> >
>>> > macroexpand(:@fastmath :+)
>>> >
>>> > since I don't know how to explicitly construct the expected result. I
>>> > know
>>> > how to do it in the REPL, but this doesn't work in test cases.
>>>
>>> What's the difference between REPL and test script?
>>>
>>> julia -f -e 'println(macroexpand(:(@fastmath +)) ==
>>> :(Base.FastMath.add_fast))'
>>> true
>>>
>>>
>>> >
>>> > -erik
>>> >
>>> >
>>> > On Wed, Dec 9, 2015 at 3:46 PM, Yichao Yu  wrote:
>>>
>>> >>
>>> >> On Wed, Dec 9, 2015 at 3:05 PM,   wrote:
>>> >> > Interesting. I didn't think to use dump to check differences.
>>> >> >
>>> >> > Another followup question. After using dump on some simple if
>>> >> > statements,
>>> >> > I've noticed that all blocks induce this LineNumberNode which is
>>> >> > messing
>>> >> > up
>>> >> > the equality.
>>> >> > Is there a way to ignore these nodes in the equality check? They
>>> >> > show up
>>> >> > in
>>> >> > any kind of block statement (function, if, etc)
>>> >> >
>>> >>
>>> >> May I ask what do you need the equality of expressions for? It doesn't
>>> >> sound like a too useful concept. There can be expressions that are
>>> >> equal but have different side effects due to the variables they
>>> >> capture (try constructing `Expr(:call, :push!, [1, 2], 1)` twice and
>>> >> eval/compare them). There can also be expressions that are equivalant
>>> >> but appears differently.
>>> >>
>>> >> In general, I never find `==` of expressions too useful. When
>>> >> processing it, you can just ignore the line number nodes if you don't
>>> >> care too much about debug info (also see base/docs/Docs.jl for some
>>> >> example of stripping unwanted part from a expression). There's also
>>> >> MacroTools.jl which provides a nice way to process expressions.
>>> >>
>>> >> > eg:
>>> >> >
>>> >> > dump(:(if true 1 else 0 end))
>>> >> >
>>> >> > Expr
>>> >> >
>>> >> >   head: Symbol if
>>> >> >
>>> >> >   args: Array(Any,(3,))
>>> >> >
>>> >> > 1: Bool true
>>> >> >
>>> >> > 2: Expr
>>> >> >
>>> >> >   head: Symbol block
>>> >> >
>>> >> >   args: Array(Any,(2,))
>>> >> >
>>> >> > 1: LineNumberNode
>>> >> >
>>> >> >   file: Symbol none
>>> >> >
>>> >> >   line: Int64 1
>>> >> >
>>> >> > 2: Int64 1
>>> >> >
>>> >> >   typ: Any
>>> >> >
>>> >> > 3: Expr
>>> >> >
>>> >> >   head: Symbol block
>>> >> >
>>> >> >   args: Array(Any,(2,))
>>> >> >
>>> >> > 1: LineNumberNode
>>> >> >
>>> >> >   file: Symbol none
>>> >> >
>>> >> >   line: Int64 1
>>> >> >
>>> >> > 2: Int64 0
>>> >> >
>>> >> >   typ: Any
>>> >> >
>>> >> >   typ: Any
>>> >> >
>>> >> >
>>> >> > dump(Expr(:if, true, Expr(:block, 0), Expr(:block,1)))
>>> >> >
>>> >> > Expr
>>> >> >
>>> >> >   head: Symbol if
>>> >> >
>>> >> >   args: 

Re: [julia-users] Re: Expression Equality

[Yichao Yu]

On Wed, Dec 9, 2015 at 5:18 PM, Erik Schnetter  wrote:
> I didn't know about `methodswith(???, true)`. Could that be output by
> default when one is asking for help?

Not unless if there's some good way to filter it. Try
`methodswith(Vector, true)`

>
> -erik
>
> On Wed, Dec 9, 2015 at 5:17 PM, Yichao Yu  wrote:
>>
>> On Wed, Dec 9, 2015 at 5:15 PM, Yichao Yu  wrote:
>> > On Wed, Dec 9, 2015 at 5:12 PM,   wrote:
>> >> sorry ok, I see - it's
>> >> Expr.head
>> >> and
>> >> Expr.args
>> >>
>> >> Man, I really wish Julia had something like python's help(Expr) to see
>> >> all
>> >> the methods/fields of a class...
>>
>> And for methods, use methodswith
>>
>> ```
>> julia> methodswith(Expr, true)
>> 6-element Array{Method,1}:
>>  ==(x::Expr, y::Expr) at expr.jl:45
>>  copy(e::Expr) at expr.jl:34
>>  hash(x::Expr, h::UInt64) at hashing.jl:60
>>  print(io::IO,
>> ex::Union{Expr,GlobalRef,GotoNode,LabelNode,LineNumberNode,QuoteNode,SymbolNode,TopNode})
>> at show.jl:290
>>  serialize(s::SerializationState{I<:IO}, ex::Expr) at serialize.jl:227
>>  show(io::IO,
>> ex::Union{Expr,GlobalRef,GotoNode,LabelNode,LineNumberNode,QuoteNode,SymbolNode,TopNode})
>> at show.jl:291
>> ```
>>
>>
>> >>
>> >
>> > ```
>> > help?> Expr
>> > search: Expr export nextprod expanduser expm exp2 exp expm1 exp10
>> > expand exponent
>> >
>> >   No documentation found.
>> >
>> >   Summary:
>> >
>> >   type Expr <: Any
>> >
>> >   Fields:
>> >
>> >   head :: Symbol
>> >   args :: Array{Any,1}
>> >   typ  :: Any
>> > ```
>> >
>> >>
>> >> On Tuesday, December 8, 2015 at 8:26:35 PM UTC-8, vis...@stanford.edu
>> >> wrote:
>> >>>
>> >>> Situations where the printed form of an expression (i.e, what you'd
>> >>> type
>> >>> into julia REPL, for example) are equivalent aren't "equal" per
>> >>> julia's
>> >>> standards:
>> >>>
>> >>> Expr(:call, :<, 1, 2) --> :(1 < 2)
>> >>> Meta.show_sexpr(:(1 < 2)) --> (:comparison, 1, :<, 2)
>> >>> Expr(:call, :<, 1, 2) == :(1 < 2) --> FALSE
>> >>>
>> >>> I figure that's expected because the s-expressions behind the scenes
>> >>> aren't accurate.
>> >>> So the workaround is:
>> >>>
>> >>> Expr(:call, :<, 1, 2) == :(<(1,2)) --> TRUE
>> >>>
>> >>> This isn't ideal, but at least there's a way to express the Expr
>> >>> object I
>> >>> want in terms of julia's syntax.
>> >>> Is there another way to make these two semantically equivalent
>> >>> representations actually be equal?
>> >>>
>> >>> Second - a much weirder problem:
>> >>>
>> >>> Meta.show_sexpr(:(symbol.x())) --> (:call, (:., :symbol, (:quote,
>> >>> :x)))
>> >>>
>> >>>
>> >>> Ok, so make an expression:
>> >>>
>> >>> Meta.show_sexpr(Expr(:call, Expr(:., :symbol, Expr(:quote, :x -->
>> >>> (:call, (:., :symbol, (:quote, :x)))
>> >>>
>> >>>
>> >>> Cool. So this time the expression object and the actual julia
>> >>> representation are the exact same.
>> >>>
>> >>> However:
>> >>>
>> >>> Expr(:call, Expr(:., :symbol, Expr(:quote, :x))) == :(symbol.x()) -->
>> >>> FALSE
>> >>>
>> >>>
>> >>> And stragely
>> >>>
>> >>>
>> >>> Meta.show_sexpr(Expr(:call, Expr(:., :symbol, Expr(:quote, :x ==
>> >>> Meta.show_sexpr(:(symbol.x())) --> TRUE
>> >>>
>> >>>
>> >>> What is going on!? And how do I get these expressions to agree?
>> >>>
>> >>>
>> >>> Vishesh
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>
>
>
>
> --
> Erik Schnetter 
> http://www.perimeterinstitute.ca/personal/eschnetter/

Re: [julia-users] Re: Expression Equality

[Yichao Yu]

On Wed, Dec 9, 2015 at 3:57 PM, Erik Schnetter  wrote:
> Comparing expressions is useful if you want to write a test case for a
> function that transforms expressions, such as e.g. `@fastmath`. I recently
> added some test cases, but was unable to test the result of
>
> macroexpand(:@fastmath :+)
>
> since I don't know how to explicitly construct the expected result. I know
> how to do it in the REPL, but this doesn't work in test cases.

What's the difference between REPL and test script?

julia -f -e 'println(macroexpand(:(@fastmath +)) == :(Base.FastMath.add_fast))'
true


>
> -erik
>
>
> On Wed, Dec 9, 2015 at 3:46 PM, Yichao Yu  wrote:
>>
>> On Wed, Dec 9, 2015 at 3:05 PM,   wrote:
>> > Interesting. I didn't think to use dump to check differences.
>> >
>> > Another followup question. After using dump on some simple if
>> > statements,
>> > I've noticed that all blocks induce this LineNumberNode which is messing
>> > up
>> > the equality.
>> > Is there a way to ignore these nodes in the equality check? They show up
>> > in
>> > any kind of block statement (function, if, etc)
>> >
>>
>> May I ask what do you need the equality of expressions for? It doesn't
>> sound like a too useful concept. There can be expressions that are
>> equal but have different side effects due to the variables they
>> capture (try constructing `Expr(:call, :push!, [1, 2], 1)` twice and
>> eval/compare them). There can also be expressions that are equivalant
>> but appears differently.
>>
>> In general, I never find `==` of expressions too useful. When
>> processing it, you can just ignore the line number nodes if you don't
>> care too much about debug info (also see base/docs/Docs.jl for some
>> example of stripping unwanted part from a expression). There's also
>> MacroTools.jl which provides a nice way to process expressions.
>>
>> > eg:
>> >
>> > dump(:(if true 1 else 0 end))
>> >
>> > Expr
>> >
>> >   head: Symbol if
>> >
>> >   args: Array(Any,(3,))
>> >
>> > 1: Bool true
>> >
>> > 2: Expr
>> >
>> >   head: Symbol block
>> >
>> >   args: Array(Any,(2,))
>> >
>> > 1: LineNumberNode
>> >
>> >   file: Symbol none
>> >
>> >   line: Int64 1
>> >
>> > 2: Int64 1
>> >
>> >   typ: Any
>> >
>> > 3: Expr
>> >
>> >   head: Symbol block
>> >
>> >   args: Array(Any,(2,))
>> >
>> > 1: LineNumberNode
>> >
>> >   file: Symbol none
>> >
>> >   line: Int64 1
>> >
>> > 2: Int64 0
>> >
>> >   typ: Any
>> >
>> >   typ: Any
>> >
>> >
>> > dump(Expr(:if, true, Expr(:block, 0), Expr(:block,1)))
>> >
>> > Expr
>> >
>> >   head: Symbol if
>> >
>> >   args: Array(Any,(3,))
>> >
>> > 1: Bool true
>> >
>> > 2: Expr
>> >
>> >   head: Symbol block
>> >
>> >   args: Array(Any,(1,))
>> >
>> > 1: Int64 0
>> >
>> >   typ: Any
>> >
>> > 3: Expr
>> >
>> >   head: Symbol block
>> >
>> >   args: Array(Any,(1,))
>> >
>> > 1: Int64 1
>> >
>> >   typ: Any
>> >
>> >   typ: Any
>> >
>> >
>> > They're the same minus LineNumberNodes, because block type expressions
>> > always create those things.
>> >
>> >
>> > On Wednesday, December 9, 2015 at 7:21:55 AM UTC-8, STAR0SS wrote:
>> >>
>> >> You can also use dump() on your expressions to see how they differ
>> >> exactly. The normal printing doesn't really show you much.
>
>
>
>
> --
> Erik Schnetter 
> http://www.perimeterinstitute.ca/personal/eschnetter/

Re: [julia-users] Re: Expression Equality

[Erik Schnetter]

I didn't know about `methodswith(???, true)`. Could that be output by
default when one is asking for help?

-erik

On Wed, Dec 9, 2015 at 5:17 PM, Yichao Yu  wrote:

> On Wed, Dec 9, 2015 at 5:15 PM, Yichao Yu  wrote:
> > On Wed, Dec 9, 2015 at 5:12 PM,   wrote:
> >> sorry ok, I see - it's
> >> Expr.head
> >> and
> >> Expr.args
> >>
> >> Man, I really wish Julia had something like python's help(Expr) to see
> all
> >> the methods/fields of a class...
>
> And for methods, use methodswith
>
> ```
> julia> methodswith(Expr, true)
> 6-element Array{Method,1}:
>  ==(x::Expr, y::Expr) at expr.jl:45
>  copy(e::Expr) at expr.jl:34
>  hash(x::Expr, h::UInt64) at hashing.jl:60
>  print(io::IO,
> ex::Union{Expr,GlobalRef,GotoNode,LabelNode,LineNumberNode,QuoteNode,SymbolNode,TopNode})
> at show.jl:290
>  serialize(s::SerializationState{I<:IO}, ex::Expr) at serialize.jl:227
>  show(io::IO,
> ex::Union{Expr,GlobalRef,GotoNode,LabelNode,LineNumberNode,QuoteNode,SymbolNode,TopNode})
> at show.jl:291
> ```
>
>
> >>
> >
> > ```
> > help?> Expr
> > search: Expr export nextprod expanduser expm exp2 exp expm1 exp10
> > expand exponent
> >
> >   No documentation found.
> >
> >   Summary:
> >
> >   type Expr <: Any
> >
> >   Fields:
> >
> >   head :: Symbol
> >   args :: Array{Any,1}
> >   typ  :: Any
> > ```
> >
> >>
> >> On Tuesday, December 8, 2015 at 8:26:35 PM UTC-8, vis...@stanford.edu
> wrote:
> >>>
> >>> Situations where the printed form of an expression (i.e, what you'd
> type
> >>> into julia REPL, for example) are equivalent aren't "equal" per julia's
> >>> standards:
> >>>
> >>> Expr(:call, :<, 1, 2) --> :(1 < 2)
> >>> Meta.show_sexpr(:(1 < 2)) --> (:comparison, 1, :<, 2)
> >>> Expr(:call, :<, 1, 2) == :(1 < 2) --> FALSE
> >>>
> >>> I figure that's expected because the s-expressions behind the scenes
> >>> aren't accurate.
> >>> So the workaround is:
> >>>
> >>> Expr(:call, :<, 1, 2) == :(<(1,2)) --> TRUE
> >>>
> >>> This isn't ideal, but at least there's a way to express the Expr
> object I
> >>> want in terms of julia's syntax.
> >>> Is there another way to make these two semantically equivalent
> >>> representations actually be equal?
> >>>
> >>> Second - a much weirder problem:
> >>>
> >>> Meta.show_sexpr(:(symbol.x())) --> (:call, (:., :symbol, (:quote, :x)))
> >>>
> >>>
> >>> Ok, so make an expression:
> >>>
> >>> Meta.show_sexpr(Expr(:call, Expr(:., :symbol, Expr(:quote, :x -->
> >>> (:call, (:., :symbol, (:quote, :x)))
> >>>
> >>>
> >>> Cool. So this time the expression object and the actual julia
> >>> representation are the exact same.
> >>>
> >>> However:
> >>>
> >>> Expr(:call, Expr(:., :symbol, Expr(:quote, :x))) == :(symbol.x()) -->
> >>> FALSE
> >>>
> >>>
> >>> And stragely
> >>>
> >>>
> >>> Meta.show_sexpr(Expr(:call, Expr(:., :symbol, Expr(:quote, :x ==
> >>> Meta.show_sexpr(:(symbol.x())) --> TRUE
> >>>
> >>>
> >>> What is going on!? And how do I get these expressions to agree?
> >>>
> >>>
> >>> Vishesh
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
>



-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

Re: [julia-users] Re: Expression Equality

[Yichao Yu]

On Wed, Dec 9, 2015 at 3:05 PM,   wrote:
> Interesting. I didn't think to use dump to check differences.
>
> Another followup question. After using dump on some simple if statements,
> I've noticed that all blocks induce this LineNumberNode which is messing up
> the equality.
> Is there a way to ignore these nodes in the equality check? They show up in
> any kind of block statement (function, if, etc)
>

May I ask what do you need the equality of expressions for? It doesn't
sound like a too useful concept. There can be expressions that are
equal but have different side effects due to the variables they
capture (try constructing `Expr(:call, :push!, [1, 2], 1)` twice and
eval/compare them). There can also be expressions that are equivalant
but appears differently.

In general, I never find `==` of expressions too useful. When
processing it, you can just ignore the line number nodes if you don't
care too much about debug info (also see base/docs/Docs.jl for some
example of stripping unwanted part from a expression). There's also
MacroTools.jl which provides a nice way to process expressions.

> eg:
>
> dump(:(if true 1 else 0 end))
>
> Expr
>
>   head: Symbol if
>
>   args: Array(Any,(3,))
>
> 1: Bool true
>
> 2: Expr
>
>   head: Symbol block
>
>   args: Array(Any,(2,))
>
> 1: LineNumberNode
>
>   file: Symbol none
>
>   line: Int64 1
>
> 2: Int64 1
>
>   typ: Any
>
> 3: Expr
>
>   head: Symbol block
>
>   args: Array(Any,(2,))
>
> 1: LineNumberNode
>
>   file: Symbol none
>
>   line: Int64 1
>
> 2: Int64 0
>
>   typ: Any
>
>   typ: Any
>
>
> dump(Expr(:if, true, Expr(:block, 0), Expr(:block,1)))
>
> Expr
>
>   head: Symbol if
>
>   args: Array(Any,(3,))
>
> 1: Bool true
>
> 2: Expr
>
>   head: Symbol block
>
>   args: Array(Any,(1,))
>
> 1: Int64 0
>
>   typ: Any
>
> 3: Expr
>
>   head: Symbol block
>
>   args: Array(Any,(1,))
>
> 1: Int64 1
>
>   typ: Any
>
>   typ: Any
>
>
> They're the same minus LineNumberNodes, because block type expressions
> always create those things.
>
>
> On Wednesday, December 9, 2015 at 7:21:55 AM UTC-8, STAR0SS wrote:
>>
>> You can also use dump() on your expressions to see how they differ
>> exactly. The normal printing doesn't really show you much.

Re: [julia-users] Re: Expression Equality

[vishesh]

Indeed, my use case is also writing proper tests for macros using FactCheck.
I have a more bizarre use case which involves writing a lisp using julia 
(learning purposes only), but it's more out there.

In this case, it'd be nice to verify that the expression I get matches the 
one I expect.
Is there a way process an Expression and ignore nodes (i.e, linenumbernode, 
which has absolutely nothing to do with expression equality, and represents 
internal julia metadata)? It'd be a tree traversal function, maybe, but I'm 
unable to find any documentation on how to manipulate Expression objects.
Even something like cons/first/rest would be sufficient for my case.

On Wednesday, December 9, 2015 at 1:26:14 PM UTC-8, Erik Schnetter wrote:
>
> I want to test the expression
>
> ```
> macroexpand(:@fastmath :+)
> ```
>
> where `:+` is a symbol, not a function.
>
> I wasn't able to determine the difference. I used both `info` and `dump`, 
> and my LHS (the result of the expression above) and what I constructed 
> manually looked identical, and in the REPL, the epression
>
> ```
> macroexpand(:@fastmath :+) == :(:+)
> ```
> yields `true`. In `test/fastmath.jl`, it didn't. (It works fine for five 
> other expressions that are currently being tested.)
>
> Anyway -- my point being that it can be quite useful to compare 
> expressions, even if the exact value might change over time. Since Julia's 
> macros are all about manipulating expressions, having ways to output, 
> serialize, load, compare, and treat them like any other data makes totally 
> sense.
>
> -erik
>
>
>
> On Wed, Dec 9, 2015 at 4:05 PM, Yichao Yu  
> wrote:
>
>> On Wed, Dec 9, 2015 at 3:57 PM, Erik Schnetter > > wrote:
>> > Comparing expressions is useful if you want to write a test case for a
>> > function that transforms expressions, such as e.g. `@fastmath`. I 
>> recently
>> > added some test cases, but was unable to test the result of
>> >
>> > macroexpand(:@fastmath :+)
>> >
>> > since I don't know how to explicitly construct the expected result. I 
>> know
>> > how to do it in the REPL, but this doesn't work in test cases.
>>
>> What's the difference between REPL and test script?
>>
>> julia -f -e 'println(macroexpand(:(@fastmath +)) == 
>> :(Base.FastMath.add_fast))'
>> true
>>
>>
>> >
>> > -erik
>> >
>> >
>> > On Wed, Dec 9, 2015 at 3:46 PM, Yichao Yu > > wrote:
>> >>
>> >> On Wed, Dec 9, 2015 at 3:05 PM,   
>> wrote:
>> >> > Interesting. I didn't think to use dump to check differences.
>> >> >
>> >> > Another followup question. After using dump on some simple if
>> >> > statements,
>> >> > I've noticed that all blocks induce this LineNumberNode which is 
>> messing
>> >> > up
>> >> > the equality.
>> >> > Is there a way to ignore these nodes in the equality check? They 
>> show up
>> >> > in
>> >> > any kind of block statement (function, if, etc)
>> >> >
>> >>
>> >> May I ask what do you need the equality of expressions for? It doesn't
>> >> sound like a too useful concept. There can be expressions that are
>> >> equal but have different side effects due to the variables they
>> >> capture (try constructing `Expr(:call, :push!, [1, 2], 1)` twice and
>> >> eval/compare them). There can also be expressions that are equivalant
>> >> but appears differently.
>> >>
>> >> In general, I never find `==` of expressions too useful. When
>> >> processing it, you can just ignore the line number nodes if you don't
>> >> care too much about debug info (also see base/docs/Docs.jl for some
>> >> example of stripping unwanted part from a expression). There's also
>> >> MacroTools.jl which provides a nice way to process expressions.
>> >>
>> >> > eg:
>> >> >
>> >> > dump(:(if true 1 else 0 end))
>> >> >
>> >> > Expr
>> >> >
>> >> >   head: Symbol if
>> >> >
>> >> >   args: Array(Any,(3,))
>> >> >
>> >> > 1: Bool true
>> >> >
>> >> > 2: Expr
>> >> >
>> >> >   head: Symbol block
>> >> >
>> >> >   args: Array(Any,(2,))
>> >> >
>> >> > 1: LineNumberNode
>> >> >
>> >> >   file: Symbol none
>> >> >
>> >> >   line: Int64 1
>> >> >
>> >> > 2: Int64 1
>> >> >
>> >> >   typ: Any
>> >> >
>> >> > 3: Expr
>> >> >
>> >> >   head: Symbol block
>> >> >
>> >> >   args: Array(Any,(2,))
>> >> >
>> >> > 1: LineNumberNode
>> >> >
>> >> >   file: Symbol none
>> >> >
>> >> >   line: Int64 1
>> >> >
>> >> > 2: Int64 0
>> >> >
>> >> >   typ: Any
>> >> >
>> >> >   typ: Any
>> >> >
>> >> >
>> >> > dump(Expr(:if, true, Expr(:block, 0), Expr(:block,1)))
>> >> >
>> >> > Expr
>> >> >
>> >> >   head: Symbol if
>> >> >
>> >> >   args: Array(Any,(3,))
>> >> >
>> >> > 1: Bool true
>> >> >
>> >> > 2: Expr
>> >> >
>> >> >   head: Symbol block
>> >> >
>> >> >   args: Array(Any,(1,))
>> >> >
>> >> > 1: Int64 0
>> >> >
>> >> >   typ: Any
>> >> >
>> >> > 3: Expr
>> >> >
>> >> >   head: 

Re: [julia-users] Re: Expression Equality

[Yichao Yu]

On Wed, Dec 9, 2015 at 5:12 PM,   wrote:
> sorry ok, I see - it's
> Expr.head
> and
> Expr.args
>
> Man, I really wish Julia had something like python's help(Expr) to see all
> the methods/fields of a class...
>

```
help?> Expr
search: Expr export nextprod expanduser expm exp2 exp expm1 exp10
expand exponent

  No documentation found.

  Summary:

  type Expr <: Any

  Fields:

  head :: Symbol
  args :: Array{Any,1}
  typ  :: Any
```

>
> On Tuesday, December 8, 2015 at 8:26:35 PM UTC-8, vis...@stanford.edu wrote:
>>
>> Situations where the printed form of an expression (i.e, what you'd type
>> into julia REPL, for example) are equivalent aren't "equal" per julia's
>> standards:
>>
>> Expr(:call, :<, 1, 2) --> :(1 < 2)
>> Meta.show_sexpr(:(1 < 2)) --> (:comparison, 1, :<, 2)
>> Expr(:call, :<, 1, 2) == :(1 < 2) --> FALSE
>>
>> I figure that's expected because the s-expressions behind the scenes
>> aren't accurate.
>> So the workaround is:
>>
>> Expr(:call, :<, 1, 2) == :(<(1,2)) --> TRUE
>>
>> This isn't ideal, but at least there's a way to express the Expr object I
>> want in terms of julia's syntax.
>> Is there another way to make these two semantically equivalent
>> representations actually be equal?
>>
>> Second - a much weirder problem:
>>
>> Meta.show_sexpr(:(symbol.x())) --> (:call, (:., :symbol, (:quote, :x)))
>>
>>
>> Ok, so make an expression:
>>
>> Meta.show_sexpr(Expr(:call, Expr(:., :symbol, Expr(:quote, :x -->
>> (:call, (:., :symbol, (:quote, :x)))
>>
>>
>> Cool. So this time the expression object and the actual julia
>> representation are the exact same.
>>
>> However:
>>
>> Expr(:call, Expr(:., :symbol, Expr(:quote, :x))) == :(symbol.x()) -->
>> FALSE
>>
>>
>> And stragely
>>
>>
>> Meta.show_sexpr(Expr(:call, Expr(:., :symbol, Expr(:quote, :x ==
>> Meta.show_sexpr(:(symbol.x())) --> TRUE
>>
>>
>> What is going on!? And how do I get these expressions to agree?
>>
>>
>> Vishesh
>>
>>
>>
>>
>>
>

Re: [julia-users] Re: Expression Equality

[Erik Schnetter]

Comparing expressions is useful if you want to write a test case for a
function that transforms expressions, such as e.g. `@fastmath`. I recently
added some test cases, but was unable to test the result of

macroexpand(:@fastmath :+)

since I don't know how to explicitly construct the expected result. I know
how to do it in the REPL, but this doesn't work in test cases.

-erik


On Wed, Dec 9, 2015 at 3:46 PM, Yichao Yu  wrote:

> On Wed, Dec 9, 2015 at 3:05 PM,   wrote:
> > Interesting. I didn't think to use dump to check differences.
> >
> > Another followup question. After using dump on some simple if statements,
> > I've noticed that all blocks induce this LineNumberNode which is messing
> up
> > the equality.
> > Is there a way to ignore these nodes in the equality check? They show up
> in
> > any kind of block statement (function, if, etc)
> >
>
> May I ask what do you need the equality of expressions for? It doesn't
> sound like a too useful concept. There can be expressions that are
> equal but have different side effects due to the variables they
> capture (try constructing `Expr(:call, :push!, [1, 2], 1)` twice and
> eval/compare them). There can also be expressions that are equivalant
> but appears differently.
>
> In general, I never find `==` of expressions too useful. When
> processing it, you can just ignore the line number nodes if you don't
> care too much about debug info (also see base/docs/Docs.jl for some
> example of stripping unwanted part from a expression). There's also
> MacroTools.jl which provides a nice way to process expressions.
>
> > eg:
> >
> > dump(:(if true 1 else 0 end))
> >
> > Expr
> >
> >   head: Symbol if
> >
> >   args: Array(Any,(3,))
> >
> > 1: Bool true
> >
> > 2: Expr
> >
> >   head: Symbol block
> >
> >   args: Array(Any,(2,))
> >
> > 1: LineNumberNode
> >
> >   file: Symbol none
> >
> >   line: Int64 1
> >
> > 2: Int64 1
> >
> >   typ: Any
> >
> > 3: Expr
> >
> >   head: Symbol block
> >
> >   args: Array(Any,(2,))
> >
> > 1: LineNumberNode
> >
> >   file: Symbol none
> >
> >   line: Int64 1
> >
> > 2: Int64 0
> >
> >   typ: Any
> >
> >   typ: Any
> >
> >
> > dump(Expr(:if, true, Expr(:block, 0), Expr(:block,1)))
> >
> > Expr
> >
> >   head: Symbol if
> >
> >   args: Array(Any,(3,))
> >
> > 1: Bool true
> >
> > 2: Expr
> >
> >   head: Symbol block
> >
> >   args: Array(Any,(1,))
> >
> > 1: Int64 0
> >
> >   typ: Any
> >
> > 3: Expr
> >
> >   head: Symbol block
> >
> >   args: Array(Any,(1,))
> >
> > 1: Int64 1
> >
> >   typ: Any
> >
> >   typ: Any
> >
> >
> > They're the same minus LineNumberNodes, because block type expressions
> > always create those things.
> >
> >
> > On Wednesday, December 9, 2015 at 7:21:55 AM UTC-8, STAR0SS wrote:
> >>
> >> You can also use dump() on your expressions to see how they differ
> >> exactly. The normal printing doesn't really show you much.
>



-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

Re: [julia-users] Re: Expression Equality

[Yichao Yu]

On Wed, Dec 9, 2015 at 5:15 PM, Yichao Yu  wrote:
> On Wed, Dec 9, 2015 at 5:12 PM,   wrote:
>> sorry ok, I see - it's
>> Expr.head
>> and
>> Expr.args
>>
>> Man, I really wish Julia had something like python's help(Expr) to see all
>> the methods/fields of a class...

And for methods, use methodswith

```
julia> methodswith(Expr, true)
6-element Array{Method,1}:
 ==(x::Expr, y::Expr) at expr.jl:45
 copy(e::Expr) at expr.jl:34
 hash(x::Expr, h::UInt64) at hashing.jl:60
 print(io::IO, 
ex::Union{Expr,GlobalRef,GotoNode,LabelNode,LineNumberNode,QuoteNode,SymbolNode,TopNode})
at show.jl:290
 serialize(s::SerializationState{I<:IO}, ex::Expr) at serialize.jl:227
 show(io::IO, 
ex::Union{Expr,GlobalRef,GotoNode,LabelNode,LineNumberNode,QuoteNode,SymbolNode,TopNode})
at show.jl:291
```


>>
>
> ```
> help?> Expr
> search: Expr export nextprod expanduser expm exp2 exp expm1 exp10
> expand exponent
>
>   No documentation found.
>
>   Summary:
>
>   type Expr <: Any
>
>   Fields:
>
>   head :: Symbol
>   args :: Array{Any,1}
>   typ  :: Any
> ```
>
>>
>> On Tuesday, December 8, 2015 at 8:26:35 PM UTC-8, vis...@stanford.edu wrote:
>>>
>>> Situations where the printed form of an expression (i.e, what you'd type
>>> into julia REPL, for example) are equivalent aren't "equal" per julia's
>>> standards:
>>>
>>> Expr(:call, :<, 1, 2) --> :(1 < 2)
>>> Meta.show_sexpr(:(1 < 2)) --> (:comparison, 1, :<, 2)
>>> Expr(:call, :<, 1, 2) == :(1 < 2) --> FALSE
>>>
>>> I figure that's expected because the s-expressions behind the scenes
>>> aren't accurate.
>>> So the workaround is:
>>>
>>> Expr(:call, :<, 1, 2) == :(<(1,2)) --> TRUE
>>>
>>> This isn't ideal, but at least there's a way to express the Expr object I
>>> want in terms of julia's syntax.
>>> Is there another way to make these two semantically equivalent
>>> representations actually be equal?
>>>
>>> Second - a much weirder problem:
>>>
>>> Meta.show_sexpr(:(symbol.x())) --> (:call, (:., :symbol, (:quote, :x)))
>>>
>>>
>>> Ok, so make an expression:
>>>
>>> Meta.show_sexpr(Expr(:call, Expr(:., :symbol, Expr(:quote, :x -->
>>> (:call, (:., :symbol, (:quote, :x)))
>>>
>>>
>>> Cool. So this time the expression object and the actual julia
>>> representation are the exact same.
>>>
>>> However:
>>>
>>> Expr(:call, Expr(:., :symbol, Expr(:quote, :x))) == :(symbol.x()) -->
>>> FALSE
>>>
>>>
>>> And stragely
>>>
>>>
>>> Meta.show_sexpr(Expr(:call, Expr(:., :symbol, Expr(:quote, :x ==
>>> Meta.show_sexpr(:(symbol.x())) --> TRUE
>>>
>>>
>>> What is going on!? And how do I get these expressions to agree?
>>>
>>>
>>> Vishesh
>>>
>>>
>>>
>>>
>>>
>>

Re: [julia-users] Re: Expression Equality

[vishesh]

Oh cool, did not know! Thank you! (I'm very new to Julia, sorry)

For anyone else looking for this, here's a function that strips metadata 
(so far just LineNumberNodes) from Exprs so you can compare them.

function stripmeta(expr)
  println(typeof(expr))
  if isa(expr, Expr)
return Expr(expr.head, stripmeta(expr.args)...)
  elseif isa(expr, Array)
return map(stripmeta, filter(x -> !isa(x, LineNumberNode), expr))
  else
return expr
  end
end

All of the tests work as expected now:

Expr(:if, true, Expr(:block, 0), Expr(:block,1)) == :(if true 0 1) --> TRUE

:) Thanks!


On Wednesday, December 9, 2015 at 2:15:25 PM UTC-8, Yichao Yu wrote:
>
> On Wed, Dec 9, 2015 at 5:12 PM,   
> wrote: 
> > sorry ok, I see - it's 
> > Expr.head 
> > and 
> > Expr.args 
> > 
> > Man, I really wish Julia had something like python's help(Expr) to see 
> all 
> > the methods/fields of a class... 
> > 
>
> ``` 
> help?> Expr 
> search: Expr export nextprod expanduser expm exp2 exp expm1 exp10 
> expand exponent 
>
>   No documentation found. 
>
>   Summary: 
>
>   type Expr <: Any 
>
>   Fields: 
>
>   head :: Symbol 
>   args :: Array{Any,1} 
>   typ  :: Any 
> ``` 
>
> > 
> > On Tuesday, December 8, 2015 at 8:26:35 PM UTC-8, vis...@stanford.edu 
> wrote: 
> >> 
> >> Situations where the printed form of an expression (i.e, what you'd 
> type 
> >> into julia REPL, for example) are equivalent aren't "equal" per julia's 
> >> standards: 
> >> 
> >> Expr(:call, :<, 1, 2) --> :(1 < 2) 
> >> Meta.show_sexpr(:(1 < 2)) --> (:comparison, 1, :<, 2) 
> >> Expr(:call, :<, 1, 2) == :(1 < 2) --> FALSE 
> >> 
> >> I figure that's expected because the s-expressions behind the scenes 
> >> aren't accurate. 
> >> So the workaround is: 
> >> 
> >> Expr(:call, :<, 1, 2) == :(<(1,2)) --> TRUE 
> >> 
> >> This isn't ideal, but at least there's a way to express the Expr object 
> I 
> >> want in terms of julia's syntax. 
> >> Is there another way to make these two semantically equivalent 
> >> representations actually be equal? 
> >> 
> >> Second - a much weirder problem: 
> >> 
> >> Meta.show_sexpr(:(symbol.x())) --> (:call, (:., :symbol, (:quote, :x))) 
> >> 
> >> 
> >> Ok, so make an expression: 
> >> 
> >> Meta.show_sexpr(Expr(:call, Expr(:., :symbol, Expr(:quote, :x --> 
> >> (:call, (:., :symbol, (:quote, :x))) 
> >> 
> >> 
> >> Cool. So this time the expression object and the actual julia 
> >> representation are the exact same. 
> >> 
> >> However: 
> >> 
> >> Expr(:call, Expr(:., :symbol, Expr(:quote, :x))) == :(symbol.x()) --> 
> >> FALSE 
> >> 
> >> 
> >> And stragely 
> >> 
> >> 
> >> Meta.show_sexpr(Expr(:call, Expr(:., :symbol, Expr(:quote, :x == 
> >> Meta.show_sexpr(:(symbol.x())) --> TRUE 
> >> 
> >> 
> >> What is going on!? And how do I get these expressions to agree? 
> >> 
> >> 
> >> Vishesh 
> >> 
> >> 
> >> 
> >> 
> >> 
> > 
>

Re: [julia-users] Re: Expression Equality

[Erik Schnetter]

We should introduce `map` and `filter` implementations for `Expr` that
traverse the expression tree. It would be quite convenient if `Expr` was a
full-scale collection.

Or maybe there should be a generic (parameterized) tree data structure, and
`Expr` is then an instance of it.

-erik

On Wed, Dec 9, 2015 at 5:24 PM,  wrote:

> Oh cool, did not know! Thank you! (I'm very new to Julia, sorry)
>
> For anyone else looking for this, here's a function that strips metadata
> (so far just LineNumberNodes) from Exprs so you can compare them.
>
> function stripmeta(expr)
>   println(typeof(expr))
>   if isa(expr, Expr)
> return Expr(expr.head, stripmeta(expr.args)...)
>   elseif isa(expr, Array)
> return map(stripmeta, filter(x -> !isa(x, LineNumberNode), expr))
>   else
> return expr
>   end
> end
>
> All of the tests work as expected now:
>
> Expr(:if, true, Expr(:block, 0), Expr(:block,1)) == :(if true 0 1) --> TRUE
>
> :) Thanks!
>
>
> On Wednesday, December 9, 2015 at 2:15:25 PM UTC-8, Yichao Yu wrote:
>>
>> On Wed, Dec 9, 2015 at 5:12 PM,   wrote:
>> > sorry ok, I see - it's
>> > Expr.head
>> > and
>> > Expr.args
>> >
>> > Man, I really wish Julia had something like python's help(Expr) to see
>> all
>> > the methods/fields of a class...
>> >
>>
>> ```
>> help?> Expr
>> search: Expr export nextprod expanduser expm exp2 exp expm1 exp10
>> expand exponent
>>
>>   No documentation found.
>>
>>   Summary:
>>
>>   type Expr <: Any
>>
>>   Fields:
>>
>>   head :: Symbol
>>   args :: Array{Any,1}
>>   typ  :: Any
>> ```
>>
>> >
>> > On Tuesday, December 8, 2015 at 8:26:35 PM UTC-8, vis...@stanford.edu
>> wrote:
>> >>
>> >> Situations where the printed form of an expression (i.e, what you'd
>> type
>> >> into julia REPL, for example) are equivalent aren't "equal" per
>> julia's
>> >> standards:
>> >>
>> >> Expr(:call, :<, 1, 2) --> :(1 < 2)
>> >> Meta.show_sexpr(:(1 < 2)) --> (:comparison, 1, :<, 2)
>> >> Expr(:call, :<, 1, 2) == :(1 < 2) --> FALSE
>> >>
>> >> I figure that's expected because the s-expressions behind the scenes
>> >> aren't accurate.
>> >> So the workaround is:
>> >>
>> >> Expr(:call, :<, 1, 2) == :(<(1,2)) --> TRUE
>> >>
>> >> This isn't ideal, but at least there's a way to express the Expr
>> object I
>> >> want in terms of julia's syntax.
>> >> Is there another way to make these two semantically equivalent
>> >> representations actually be equal?
>> >>
>> >> Second - a much weirder problem:
>> >>
>> >> Meta.show_sexpr(:(symbol.x())) --> (:call, (:., :symbol, (:quote,
>> :x)))
>> >>
>> >>
>> >> Ok, so make an expression:
>> >>
>> >> Meta.show_sexpr(Expr(:call, Expr(:., :symbol, Expr(:quote, :x -->
>> >> (:call, (:., :symbol, (:quote, :x)))
>> >>
>> >>
>> >> Cool. So this time the expression object and the actual julia
>> >> representation are the exact same.
>> >>
>> >> However:
>> >>
>> >> Expr(:call, Expr(:., :symbol, Expr(:quote, :x))) == :(symbol.x()) -->
>> >> FALSE
>> >>
>> >>
>> >> And stragely
>> >>
>> >>
>> >> Meta.show_sexpr(Expr(:call, Expr(:., :symbol, Expr(:quote, :x ==
>> >> Meta.show_sexpr(:(symbol.x())) --> TRUE
>> >>
>> >>
>> >> What is going on!? And how do I get these expressions to agree?
>> >>
>> >>
>> >> Vishesh
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>>
>


-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

Re: [julia-users] The optimization strategy for fft didn't work

[博陈]

Thanks a lot for your help. I am just starting to code with julia, and I 
surprisedly found that my julia code is about 2.5 times slower than the 
matlab one, they just do the same things. I learn from  
http://docs.julialang.org/en/release-0.4/stdlib/math/?highlight=fft#Base.fft  
about the fft optimization strategies. The optimization strategies are 
1. use plan_fft!() instead of plan_fft() or fft() to decrease the memory to 
be allocated and preallocate the fft operation.
2. use flags like FFTW.MEASURE or FFEW.EXHAUSTIVE. In my project, I have 
involved that flags, and it surely make a difference. But I'm just confused 
why the fft! and plan_fft strategy didn't work, which was clearly explained 
by you.





在 2015年12月9日星期三 UTC+8下午9:09:07，Yichao Yu写道：
>
>
>
> On Wed, Dec 9, 2015 at 5:57 AM, 博陈  
> wrote:
>
>>
>> 
>> the optimization strategy for fft given by the official documentation 
>> seems to fail. Why?
>>
>
> You didn't mention exactly what optimization strategy you are trying so I 
> would need to guess.
>
> 1. You should expect the first one to be no faster than the last one since 
> it's basically doing the same thing and the first one does it all in global 
> scope
> 2. In place op doesn't make too much a difference here since the operation 
> you are doing is already very expensive. (most of the time are spent in 
> FFTW)
> 3. It doesn't really matter for this one (since FFTW determines the 
> performance here) but you should benchmark the loop in a function and hoist 
> the creation of the plan out of the loop. For your actual code, you might 
> want to make the plan a global constant or a parametrized field of a type 
> since it has not been not particularly type stable.
> 4. You can use `plan_fft(, flags=FFTW.MEASURE)` to let FFTW select the 
> best algorithm by actually measuring the time instead of guessing. It gives 
> me 20% to 30% speed up for your example and IIRC more speed up for small 
> problems.
> 5. You can use `FFTW.flops(p)` to figure out how much floating point 
> operations are needed to perform your transformation. On my computer, a 
> MEASURE'd plan takes 4.3s (100 times) and the naive estimation from 
> assuming one operation per clock cycle is 2s (100 times) so it's the right 
> order of magnitude.
>
>

[julia-users] Possible bug with SharedArray and pmap?

[John Brock]

To replicate, be sure to start julia with more than one process (e.g., 
`julia -p 2`):

julia> foo = convert(SharedArray, [1,2,3,4]);

julia> @async pmap(i->println(foo), 1:2) 

Task (waiting) @0x00010cd8f730 

julia> From worker 2: [1,2,3,4] 

 From worker 3: [1,2,3,4] 

julia> pmap(i->println(foo), 1:2) 

2-element Array{Any,1}: 

 RemoteException(2,CapturedException(UndefVarError(:foo),Any[(:anonymous,:
none,1,symbol(""),-1,1),(:anonymous,symbol("multi.jl"),907,symbol(""),-1,1
),(:run_work_thunk,symbol("multi.jl"),645,symbol(""),-1,1),(:anonymous,
symbol("multi.jl"),907,symbol("task.jl"),63,1)])) 

 RemoteException(3,CapturedException(UndefVarError(:foo),Any[(:anonymous,:
none,1,symbol(""),-1,1),(:anonymous,symbol("multi.jl"),907,symbol(""),-1,1
),(:run_work_thunk,symbol("multi.jl"),645,symbol(""),-1,1),(:anonymous,
symbol("multi.jl"),907,symbol("task.jl"),63,1)]))

[julia-users] Functions inside pmap call can't see SharedArrays unless preceded by @async

[John Brock]

I don't know if this is a feature or a bug. Functions used inside a pmap 
call can only see SharedArrays when the pmap call is preceded by @async. To 
replicate, be sure to start julia with more than one process (e.g., `julia 
-p 2`):

julia> foo = convert(SharedArray, [1,2,3,4]);

julia> @async pmap(i->println(foo), 1:2) 
Task (waiting) @0x00010cd8f730 

julia> From worker 2: [1,2,3,4] 
   From worker 3: [1,2,3,4] 

julia> pmap(i->println(foo), 1:2) 
2-element Array{Any,1}: 
 RemoteException(2,CapturedException(UndefVarError(:foo),Any[(:anonymous,:
none,1,symbol(""),-1,1),(:anonymous,symbol("multi.jl"),907,symbol(""),-1,1
),(:run_work_thunk,symbol("multi.jl"),645,symbol(""),-1,1),(:anonymous,
symbol("multi.jl"),907,symbol("task.jl"),63,1)])) 
 RemoteException(3,CapturedException(UndefVarError(:foo),Any[(:anonymous,:
none,1,symbol(""),-1,1),(:anonymous,symbol("multi.jl"),907,symbol(""),-1,1
),(:run_work_thunk,symbol("multi.jl"),645,symbol(""),-1,1),(:anonymous,
symbol("multi.jl"),907,symbol("task.jl"),63,1)]))



julia> versioninfo()
Julia Version 0.4.2
Commit bb73f34 (2015-12-06 21:47 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin15.0.0)
  CPU: Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.3



I can also replicate this on Julia v0.3.9.

Re: [julia-users] Re: Meaty example of using singleton types

[Cristóvão Duarte Sousa]

Maybe this:

type BadInt end
const badint = BadInt()
const _badint_val = 6

Base.(:+)(::BadInt, x) = _badint_val - x 

badint + 5   # -5

On Wednesday, December 9, 2015 at 8:51:47 PM UTC, milktrader wrote:
>
> Ok, thanks. Can you do the following then?
>
> 1. restrict the value of Foo to an Int64?
> 2. assign the value of 6 to the singleton?
>
>
>
> On Wednesday, December 9, 2015 at 1:09:08 PM UTC-5, Yichao Yu wrote:
>>
>> On Wed, Dec 9, 2015 at 12:50 PM, milktrader  wrote: 
>> > Can you provide a Foo example of how this works, with both construction 
>> and 
>> > method definition? 
>>
>> julia> type Foo 
>>end 
>>
>> julia> Base.(:+)(::Foo, x) = x 
>> + (generic function with 175 methods) 
>>
>> julia> Foo() + 1 
>> 1 
>>
>> julia> Foo() + "bar" 
>> "bar" 
>>
>>
>> > 
>> > On Wednesday, December 9, 2015 at 9:32:36 AM UTC-5, Yichao Yu wrote: 
>> >> 
>> >> On Wed, Dec 9, 2015 at 9:22 AM, milktrader  
>> wrote: 
>> >> > I'd like a somewhat clever example (or boring one for that matter) 
>> that 
>> >> > shows: 
>> >> > 
>> >> > 1. How to create an instance of a singleton type 
>> >> 
>> >> Call the constructor just like any other types. 
>> >> 
>> >> The only special thing about singleton type is that two instance of a 
>> >> mutable singleton type are identical. Other than this, they are simply 
>> >> types that doesn't have a field. 
>> >> 
>> >> > 
>> >> > 2. How to write methods that use this type in a meaningful way. 
>> >> 
>> >> Just like any other types. As long as you are not comparing them, they 
>> >> are exactly the same with everything else. 
>> >> 
>> >> > 
>> >> > 3. How it's used in Base code (I seem to recall Void is a singleton 
>> >> > type) 
>> >> > 
>> >> > On Wednesday, December 9, 2015 at 9:02:31 AM UTC-5, tshort wrote: 
>> >> >> 
>> >> >> I'm not sure what you want, either. How about this? 
>> >> >> 
>> >> >> julia> type BadInt{X} end 
>> >> >> 
>> >> >> julia> BadInt{3}() 
>> >> >> BadInt{3}() 
>> >> >> 
>> >> >> julia> f{X}(::Type{BadInt{X}}, y) = X - y 
>> >> >> f (generic function with 1 method) 
>> >> >> 
>> >> >> julia> f(BadInt{10}, 3) 
>> >> >> 7 
>> >> >> 
>> >> >> julia> f{X}(::BadInt{X}, y) = X - y 
>> >> >> f (generic function with 2 methods) 
>> >> >> 
>> >> >> julia> f(BadInt{10}(), 3) 
>> >> >> 7 
>> >> >> 
>> >> >> 
>> >> >> On Wed, Dec 9, 2015 at 8:56 AM, Eric Forgy  
>> wrote: 
>> >> >>> 
>> >> >>> Not sure I follow, but does this help? 
>> >> >>> 
>> >> >>> julia> type BadInt 
>> >> >>>end 
>> >> >>> 
>> >> >>> julia> bi = BadInt() 
>> >> >>> BadInt() 
>> >> >>> 
>> >> >>> julia> typeof(bi) 
>> >> >>> BadInt 
>> >> >>> 
>> >> >>> 
>> >> >>> On Wednesday, December 9, 2015 at 9:46:01 PM UTC+8, milktrader 
>> wrote: 
>> >>  
>> >>  How do you create an instance of type BadInt then? 
>> >>  
>> >>  On Wednesday, December 9, 2015 at 7:01:25 AM UTC-5, milktrader 
>> wrote: 
>> >> > 
>> >> > Trying to wrap my mind around singleton types to see if they 
>> might 
>> >> > be 
>> >> > useful for something I'm working on, but running into some 
>> >> > confusion. Here 
>> >> > is an example that I started working with: 
>> >> > 
>> >> > julia> type BadInt 
>> >> >end 
>> >> > 
>> >> > julia> import Base.+ 
>> >> > 
>> >> > julia> +(x::BadInt, y::Int64) = x - y 
>> >> > + (generic function with 172 methods) 
>> >> > 
>> >> > julia> BadInt() = 2 
>> >> > BadInt 
>> >> > 
>> >> > julia> BadInt + 2 
>> >> > ERROR: MethodError: `+` has no method matching +(::Type{BadInt}, 
>> >> > ::Int64) 
>> >> > Closest candidates are: 
>> >> >   +(::Any, ::Any, ::Any, ::Any...) 
>> >> >   +(::Int64, ::Int64) 
>> >> >   +(::Complex{Bool}, ::Real) 
>> >> >   ... 
>> >> > 
>> >> > As I understand, a singleton type can only take on a single 
>> value. 
>> >> > What's the utility in supporting this? 
>> >> >> 
>> >> >> 
>> >> > 
>>
>

Re: [julia-users] Re: Meaty example of using singleton types

[Erik Schnetter]

Singleton types can, by definition, not hold any data. They are just empty
objects. They are "singletons" because all objects of such a type are not
only equal (==), but also egal (===), as if they were immutable.

To hold data for a singleton, you'd use a global variable.

-erik

On Wed, Dec 9, 2015 at 6:26 PM, Cristóvão Duarte Sousa 
wrote:

> Maybe this:
>
> type BadInt end
> const badint = BadInt()
> const _badint_val = 6
>
> Base.(:+)(::BadInt, x) = _badint_val - x
>
> badint + 5   # -5
>
> On Wednesday, December 9, 2015 at 8:51:47 PM UTC, milktrader wrote:
>>
>> Ok, thanks. Can you do the following then?
>>
>> 1. restrict the value of Foo to an Int64?
>> 2. assign the value of 6 to the singleton?
>>
>>
>>
>> On Wednesday, December 9, 2015 at 1:09:08 PM UTC-5, Yichao Yu wrote:
>>>
>>> On Wed, Dec 9, 2015 at 12:50 PM, milktrader  wrote:
>>> > Can you provide a Foo example of how this works, with both
>>> construction and
>>> > method definition?
>>>
>>> julia> type Foo
>>>end
>>>
>>> julia> Base.(:+)(::Foo, x) = x
>>> + (generic function with 175 methods)
>>>
>>> julia> Foo() + 1
>>> 1
>>>
>>> julia> Foo() + "bar"
>>> "bar"
>>>
>>>
>>> >
>>> > On Wednesday, December 9, 2015 at 9:32:36 AM UTC-5, Yichao Yu wrote:
>>> >>
>>> >> On Wed, Dec 9, 2015 at 9:22 AM, milktrader 
>>> wrote:
>>> >> > I'd like a somewhat clever example (or boring one for that matter)
>>> that
>>> >> > shows:
>>> >> >
>>> >> > 1. How to create an instance of a singleton type
>>> >>
>>> >> Call the constructor just like any other types.
>>> >>
>>> >> The only special thing about singleton type is that two instance of a
>>> >> mutable singleton type are identical. Other than this, they are
>>> simply
>>> >> types that doesn't have a field.
>>> >>
>>> >> >
>>> >> > 2. How to write methods that use this type in a meaningful way.
>>> >>
>>> >> Just like any other types. As long as you are not comparing them,
>>> they
>>> >> are exactly the same with everything else.
>>> >>
>>> >> >
>>> >> > 3. How it's used in Base code (I seem to recall Void is a singleton
>>> >> > type)
>>> >> >
>>> >> > On Wednesday, December 9, 2015 at 9:02:31 AM UTC-5, tshort wrote:
>>> >> >>
>>> >> >> I'm not sure what you want, either. How about this?
>>> >> >>
>>> >> >> julia> type BadInt{X} end
>>> >> >>
>>> >> >> julia> BadInt{3}()
>>> >> >> BadInt{3}()
>>> >> >>
>>> >> >> julia> f{X}(::Type{BadInt{X}}, y) = X - y
>>> >> >> f (generic function with 1 method)
>>> >> >>
>>> >> >> julia> f(BadInt{10}, 3)
>>> >> >> 7
>>> >> >>
>>> >> >> julia> f{X}(::BadInt{X}, y) = X - y
>>> >> >> f (generic function with 2 methods)
>>> >> >>
>>> >> >> julia> f(BadInt{10}(), 3)
>>> >> >> 7
>>> >> >>
>>> >> >>
>>> >> >> On Wed, Dec 9, 2015 at 8:56 AM, Eric Forgy 
>>> wrote:
>>> >> >>>
>>> >> >>> Not sure I follow, but does this help?
>>> >> >>>
>>> >> >>> julia> type BadInt
>>> >> >>>end
>>> >> >>>
>>> >> >>> julia> bi = BadInt()
>>> >> >>> BadInt()
>>> >> >>>
>>> >> >>> julia> typeof(bi)
>>> >> >>> BadInt
>>> >> >>>
>>> >> >>>
>>> >> >>> On Wednesday, December 9, 2015 at 9:46:01 PM UTC+8, milktrader
>>> wrote:
>>> >> 
>>> >>  How do you create an instance of type BadInt then?
>>> >> 
>>> >>  On Wednesday, December 9, 2015 at 7:01:25 AM UTC-5, milktrader
>>> wrote:
>>> >> >
>>> >> > Trying to wrap my mind around singleton types to see if they
>>> might
>>> >> > be
>>> >> > useful for something I'm working on, but running into some
>>> >> > confusion. Here
>>> >> > is an example that I started working with:
>>> >> >
>>> >> > julia> type BadInt
>>> >> >end
>>> >> >
>>> >> > julia> import Base.+
>>> >> >
>>> >> > julia> +(x::BadInt, y::Int64) = x - y
>>> >> > + (generic function with 172 methods)
>>> >> >
>>> >> > julia> BadInt() = 2
>>> >> > BadInt
>>> >> >
>>> >> > julia> BadInt + 2
>>> >> > ERROR: MethodError: `+` has no method matching
>>> +(::Type{BadInt},
>>> >> > ::Int64)
>>> >> > Closest candidates are:
>>> >> >   +(::Any, ::Any, ::Any, ::Any...)
>>> >> >   +(::Int64, ::Int64)
>>> >> >   +(::Complex{Bool}, ::Real)
>>> >> >   ...
>>> >> >
>>> >> > As I understand, a singleton type can only take on a single
>>> value.
>>> >> > What's the utility in supporting this?
>>> >> >>
>>> >> >>
>>> >> >
>>>
>>


-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

[julia-users] Microsoft: Power BI - Custom Visuals

[Eric Forgy]

Just throwing this out there...

I am interested in getting Julia to interact with Power BI either directly 
or indirectly. I find it interesting (mind boggling?) Microsoft is going 
open source with all this stuff. It's like an entirely new company from the 
one I know. MIT License too...

https://github.com/Microsoft/PowerBI-visuals

And it uses d3 **drool**

Anyone else interested?

Re: [julia-users] Understanding memory allocation output

[Júlio Hoffimann]

Hi Tim,

I recompiled Julia, reinstalled all the packages and the *.mem file is
still showing those strange counts. Any idea?

-Júlio

2015-12-09 8:44 GMT-08:00 Júlio Hoffimann :

> Thanks Tim, I'll double check it.
>
> -Júlio
>

[julia-users] Re: ERROR: ArgumentError: MyTest not found in path

[Ajith Joseph]

Thanks! That worked for me.

On Wednesday, December 9, 2015 at 9:34:03 AM UTC-8, Ajith Joseph wrote:
>
> I am getting started with Julia - Version 0.4.2. I am not able to load a 
> module in REPL
>
> ajoseph-osx:julia_test ajoseph$* cat /Users/ajoseph/julia_test/test.jl *
>
> *module MyTest*
>
> *end*
>
>
> *julia> **push!(LOAD_PATH, "/Users/ajoseph/julia_test")*
>
> *3-element Array{ByteString,1}:*
>
>
> * 
> "/Applications/Julia-0.4.2.app/Contents/Resources/julia/local/share/julia/site/v0.4"*
>
> * 
> "/Applications/Julia-0.4.2.app/Contents/Resources/julia/share/julia/site/v0.4"
>  
>  *
>
> * "/Users/ajoseph/julia_test"*
>
>
> *julia> **using MyTest*
>
> *ERROR: ArgumentError: MyTest not found in path*
>
> * in require at 
> /Applications/Julia-0.4.2.app/Contents/Resources/julia/lib/julia/sys.dylib*
>
>
> What am I doing wrong here?
>
> Thanks
>

Re: [julia-users] Re: Embedding Julia

['Bill Hart' via julia-users]

One mystery is solved. Elliot Saba pointed out that I was issuing the wrong
command to look for symbols in libjulia.so. And in fact libjulia.so is
expected to be in the "odd" location that I reported, on Ubuntu.

And linking against it does in fact work.

So that leaves one remaining issue, namely that there is a hard coded
relative path for sys.so somewhere so that embedding doesn't work unless
the compiled binary is in a specific location relative to sys.so.

This means that a user trying to do embedding with say an Ubuntu installed
libjulia.so would need sudo privileges to put the binary in the right
location. I'm not sure where exactly Julia looks for its sys.so, but on
Ubuntu at least, it looks in the wrong place.

Bill.

On 9 December 2015 at 05:00, Bill Hart  wrote:

>
>
> On 9 December 2015 at 04:47, Tony Kelman  wrote:
>
>> I'd think a simple shell script, install-julia.sh or something, would be
>> better than a Makefile - you don't always have build-essential installed.
>> Putting something in contrib (along with a corresponding uninstall-julia.sh
>> script?) and adding it to the `make binary-dist` tarball generation rules
>> for Linux would be okay by me.
>>
>
> Yes a shell script ought to do it. I'll add it to my todo list (which is
> quite long).
>
> Bill.
>
>

Re: [julia-users] A Julia equivalent of destructors - is that a thing?

[Yichao Yu]

On Wed, Dec 9, 2015 at 2:27 PM, Ben Ward  wrote:
> Thanks Stefan,
>
> After googling the method I noticed some github issues where Jeff said that
> finalizer is inefficient and that we should not use it so much #11207.
> Should I be concerned about this?

You can use finalizers but you should generally explicitly free
external resources or don't get upset when the GC doesn't free it for
a long time, (even after manually calling gc)

>
> The reason I ask is I'm about to try and forge ahead with BioJulia's Dat.jl,
> and I guess stream work, or types associated with a stream field are a
> possibility.
>
> On Wednesday, December 9, 2015 at 7:16:25 PM UTC, Stefan Karpinski wrote:
>>
>> http://docs.julialang.org/en/release-0.4/stdlib/base/#Base.finalizer
>>
>> On Wed, Dec 9, 2015 at 2:12 PM, Ben Ward  wrote:
>>>
>>> Hi,
>>>
>>> I'm not sure of the answer, but is there an equivalent of the concept of
>>> a class destructor in Julia? I can imagine a situation where there is some
>>> type where a field is something like - for example - a file stream, and you
>>> want to make sure if that variable gets deleted by the gc, then the stream
>>> that is one of those variables get's closed.
>>>
>>> Best,
>>> Ben.
>>>
>>
>

[julia-users] ERROR: ArgumentError: MyTest not found in path

[Ajith Joseph]

I am getting started with Julia - Version 0.4.2. I am not able to load a 
module in REPL

ajoseph-osx:julia_test ajoseph$* cat /Users/ajoseph/julia_test/test.jl *

*module MyTest*

*end*


*julia> **push!(LOAD_PATH, "/Users/ajoseph/julia_test")*

*3-element Array{ByteString,1}:*

* 
"/Applications/Julia-0.4.2.app/Contents/Resources/julia/local/share/julia/site/v0.4"*

* 
"/Applications/Julia-0.4.2.app/Contents/Resources/julia/share/julia/site/v0.4" 
 *

* "/Users/ajoseph/julia_test"*


*julia> **using MyTest*

*ERROR: ArgumentError: MyTest not found in path*

* in require at 
/Applications/Julia-0.4.2.app/Contents/Resources/julia/lib/julia/sys.dylib*


What am I doing wrong here?

Thanks

Re: [julia-users] Re: Meaty example of using singleton types

[milktrader]

Can you provide a Foo example of how this works, with both construction and 
method definition?

On Wednesday, December 9, 2015 at 9:32:36 AM UTC-5, Yichao Yu wrote:
>
> On Wed, Dec 9, 2015 at 9:22 AM, milktrader  > wrote: 
> > I'd like a somewhat clever example (or boring one for that matter) that 
> > shows: 
> > 
> > 1. How to create an instance of a singleton type 
>
> Call the constructor just like any other types. 
>
> The only special thing about singleton type is that two instance of a 
> mutable singleton type are identical. Other than this, they are simply 
> types that doesn't have a field. 
>
> > 
> > 2. How to write methods that use this type in a meaningful way. 
>
> Just like any other types. As long as you are not comparing them, they 
> are exactly the same with everything else. 
>
> > 
> > 3. How it's used in Base code (I seem to recall Void is a singleton 
> type) 
> > 
> > On Wednesday, December 9, 2015 at 9:02:31 AM UTC-5, tshort wrote: 
> >> 
> >> I'm not sure what you want, either. How about this? 
> >> 
> >> julia> type BadInt{X} end 
> >> 
> >> julia> BadInt{3}() 
> >> BadInt{3}() 
> >> 
> >> julia> f{X}(::Type{BadInt{X}}, y) = X - y 
> >> f (generic function with 1 method) 
> >> 
> >> julia> f(BadInt{10}, 3) 
> >> 7 
> >> 
> >> julia> f{X}(::BadInt{X}, y) = X - y 
> >> f (generic function with 2 methods) 
> >> 
> >> julia> f(BadInt{10}(), 3) 
> >> 7 
> >> 
> >> 
> >> On Wed, Dec 9, 2015 at 8:56 AM, Eric Forgy  wrote: 
> >>> 
> >>> Not sure I follow, but does this help? 
> >>> 
> >>> julia> type BadInt 
> >>>end 
> >>> 
> >>> julia> bi = BadInt() 
> >>> BadInt() 
> >>> 
> >>> julia> typeof(bi) 
> >>> BadInt 
> >>> 
> >>> 
> >>> On Wednesday, December 9, 2015 at 9:46:01 PM UTC+8, milktrader wrote: 
>  
>  How do you create an instance of type BadInt then? 
>  
>  On Wednesday, December 9, 2015 at 7:01:25 AM UTC-5, milktrader wrote: 
> > 
> > Trying to wrap my mind around singleton types to see if they might 
> be 
> > useful for something I'm working on, but running into some 
> confusion. Here 
> > is an example that I started working with: 
> > 
> > julia> type BadInt 
> >end 
> > 
> > julia> import Base.+ 
> > 
> > julia> +(x::BadInt, y::Int64) = x - y 
> > + (generic function with 172 methods) 
> > 
> > julia> BadInt() = 2 
> > BadInt 
> > 
> > julia> BadInt + 2 
> > ERROR: MethodError: `+` has no method matching +(::Type{BadInt}, 
> > ::Int64) 
> > Closest candidates are: 
> >   +(::Any, ::Any, ::Any, ::Any...) 
> >   +(::Int64, ::Int64) 
> >   +(::Complex{Bool}, ::Real) 
> >   ... 
> > 
> > As I understand, a singleton type can only take on a single value. 
> > What's the utility in supporting this? 
> >> 
> >> 
> > 
>