[julia-users] Re: How to vonvet Char to Float64, what wrong ?

[Jeffrey Sarnoff]

what is `a` and `typeof(a)` where `a = sort(unique(dane[:,4]))[3])`



On Friday, November 25, 2016 at 3:35:21 AM UTC-5, program...@gmail.com wrote:
> How to convert Char  to Float? What wrong ?
> 
> julia> eltype(sort(unique(dane[:,4]))[3])
> Char
> 
> julia> (sort(unique(dane[:,4]))[3])
> "-.097"
> 
> julia> convert(Float64(sort(unique(dane[:,4]))[3]))
> ERROR: MethodError: `convert` has no method matching convert(::Type{Float64}, 
> ::UTF8String)
> This may have arisen from a call to the constructor Float64(...),
> since type constructors fall back to convert methods.
> Closest candidates are:
>   call{T}(::Type{T}, ::Any)
>   convert(::Type{Float64}, ::Int8)
>   convert(::Type{Float64}, ::Int16)
>   ...
>  in call at essentials.jl:56
> 
> paul

[julia-users] Re: How to vonvet Char to Float64, what wrong ?

[Jeffrey Sarnoff]

if `a = sort(unique(dane[:,4])[3])`, what is `(a, typeof(a))`?

On Friday, November 25, 2016 at 3:35:21 AM UTC-5, program...@gmail.com wrote:
> How to convert Char  to Float? What wrong ?
> 
> julia> eltype(sort(unique(dane[:,4]))[3])
> Char
> 
> julia> (sort(unique(dane[:,4]))[3])
> "-.097"
> 
> julia> convert(Float64(sort(unique(dane[:,4]))[3]))
> ERROR: MethodError: `convert` has no method matching convert(::Type{Float64}, 
> ::UTF8String)
> This may have arisen from a call to the constructor Float64(...),
> since type constructors fall back to convert methods.
> Closest candidates are:
>   call{T}(::Type{T}, ::Any)
>   convert(::Type{Float64}, ::Int8)
>   convert(::Type{Float64}, ::Int16)
>   ...
>  in call at essentials.jl:56
> 
> paul

[julia-users] Re: What is the value of time_ns() before it wraps?

[Jeffrey Sarnoff]

On Thursday, November 24, 2016 at 11:30:36 PM UTC-5, Jeffrey Sarnoff wrote:
> The help says "Get the time in nanoseconds. The time corresponding to 0 is 
> undefined, and wraps every 5.8 years." I want to know the largest UInt64 
> value that time_ns() can return: the (nonzero) value which would be followed 
> by 0x01%UInt64.

Doing the math results in 0x028a4486a830c000 (5.8 years of nanoseconds).  That 
seems an unlikely max value -- which prompts this question.

[julia-users] What is the value of time_ns() before it wraps?

[Jeffrey Sarnoff]

The help says "Get the time in nanoseconds. The time corresponding to 0 is 
undefined, and wraps every 5.8 years." I want to know the largest UInt64 value 
that time_ns() can return: the (nonzero) value which would be followed by 
0x01%UInt64.

[julia-users] Re: Indexing problem

[Jeffrey Sarnoff]

good things to know about how indexing works


The indices for a Vector, or a column or row of a Matrix start at *1*

```
length(avector)   # gets the number of elements in avector

avector[1]# gets the first item in avector
avector[end]  # gets the final item in avector 
avector[1:end]# gets all elements of avector

int_column_vector = [10, 20, 30]
 10
 20
 30

int_column_vector[1]
 10
# do not use zero as an index
int_column_vector[ 0 ]
ERROR: BoundsError:
# do not use false, true as indices because avec[ false ] means avec[ 0 ]

```

in ` w[1,(w[1].-(z))] = 0 `, the second index can simplify to 
`false`   (consider this)
```
avec = [ 10, 20, 30 ]
avec1 = avec[ 1 ] 
avec1 == avec[ 1 + false ]
avec2 = avec[  2 ]
avec2 == avec[ 1 + true ] 
```

As a start, recheck indexing expressions, be more sure they do what you 
want them to do.


On Wednesday, November 16, 2016 at 1:36:57 PM UTC-5, Patrik Waldmann wrote:
>
> Hi,
>
> I'm an R user trying to learn Julia. I got hold of some code from the Knet 
> package that I was playing around with. My goal is to set values to zero in 
> a loop based on a logical expression, but I cannot figure out how the 
> indexing works. Any help would be appreciated (the problem lies in 
> w[1,(w[1].-(z))] = 0):
>
> using Knet
> predict(w,x) = w[1]*x .+ w[2]
> lambda = 2
> z = Array{Float64}(1,13)
> loss(w,x,y) = sumabs2(y - predict(w,x)) / size(y,2)
> lossgradient = grad(loss)
> function train(w, data; lr=.1)
> for (x,y) in data
> dw = lossgradient(w, x, y)
> z[:] = lr * lambda
> w[1] -= lr * dw[1]
> w[2] -= lr * dw[2]
> w[1,(w[1].-(z))] = 0
> end
> return w
> end
> url = "
> https://archive.ics.uci.edu/ml/machine-learning-databases/housing/housing.data
> "
> rawdata = readdlm(download(url))
> x = rawdata[:,1:13]'
> x = (x .- mean(x,2)) ./ std(x,2)
> y = rawdata[:,14:14]'
> w = Any[ 0.1*randn(1,13), 0 ]
> niter = 25
> lossest = zeros(niter)
> for i=1:niter; train(w, [(x,y)]); lossest[i]=loss(w,x,y); end
>
>
> Best regards,
>
> Patrik
>

[julia-users] Re: Why construction of Dict via generator is not type-stable?

[Jeffrey Sarnoff]

(afaik requires @generated functions to take everything to a type stable 
post-precompilation state)

assuming
(a1) If `typeof(x)  == typeof(y)` then `typeof( t(x) )` is the same as 
`typeof( t(y) )`.
(a2) If `typeof(x) != typeof(y)` then `typeof( t(x) )` might differ from 
`typeof( t(y) )`.
(a3) There are relatively few (dozens not millions) possible types that x 
may have when `t(x)` is called.  

(b1) If `typeof(x)  == typeof(y)` then  `typeof( f2(x) )` is the same as 
`typeof( t(y) )`.
(b2) If `T is the typeof(x) and T != typeof(y)`, `typeof( f2(t, 
a::Vector{typeof(x)}) )` may differ from `typeof( f2(t, 
a::Vector{typeof(y)}) )`.
(b2) There are relatively few (dozens not millions) possible types that T 
may have when `f2{T}(t, a::Vector{T})` is called.  

Given (a123), If you write one version of the function `t` for each 
[abstract] type of x that is to be processed,   
you could annotate each of them with the correct return type.   If you can 
do that, then you could create an   
ObjectIdDict, t_oid, that maps the type of `x` to the return type of `t`. 
 Given (b123) and t_oid, you can create an   
ObjectIdDict, f2_oid, that maps the type `T` in `f2` to the return type of 
`f2`.   
Using t_oid and f2_oid the return type for each call of `t` and each call 
of `f2` is determinate and available.  


On Monday, November 14, 2016 at 5:32:51 PM UTC-5, bogumil@gmail.com 
wrote:
>
> Actually I could do:
>
> function f2{T}(t, a::Vector{T})
> Dict{T, code_typed(t, (T,))[1].rettype}((x, t(x)) for x in a)
> end
>
> but this does not solve the problem as the compiler still is unable to 
> determine the exact return type of f2.
>
> On Monday, November 14, 2016 at 4:06:20 PM UTC+1, Lutfullah Tomak wrote:
>>
>> You could find `ta=t.(a)` first and then construct a 
>> `Dict{eltype(a),eltype(ta)}` but it is just a workaround and wastes some 
>> memory.
>
>

Re: [julia-users] Re: [Announcement] Moving to Discourse (Statement of Intent)

[Jeffrey Sarnoff]

+1 move ["don't think twice, its alright" -- Bob Dylan]

On Thursday, November 10, 2016 at 3:26:59 AM UTC-5, Patrick Kofod Mogensen 
wrote:
>
> My take: make the move or don't.
>
> Stuff like forwarding posts only creates confusion, and people start 
> answering things that aren't seen by the person asking, because of the 
> one-way-street-thing.
>
> On Wednesday, November 9, 2016 at 2:24:18 AM UTC+1, Valentin Churavy wrote:
>>
>> `julia-dev` has now moved to discourse. 
>>
>> One possibility would be to start forwarding posts for `julia-users` from 
>> Google Groups to Discourse, but that is a one way street. So before I 
>> enable that I would like to hear what everybody thinks about it.
>>
>> On Wed, 9 Nov 2016 at 02:01 Tom Breloff  wrote:
>>
>>> +1... can we move already?  Discourse is a huge improvement.  I 
>>> specifically don't answer some questions here because of the difficulty in 
>>> writing answers with code.
>>>
>>> On Sun, Nov 6, 2016 at 3:16 PM, Stefan Karpinski  
>>> wrote:
>>>
 - Selectively subscribe to certain topics/categories of discussion and 
 not others.
 - Selectively see threads that reach certain quality/interest 
 thresholds.
 - Take links directly from where one reads messages
 (I really dislike the Google groups interface, so I use Gmail for 
 reading messages, but then getting a link to a post is a real pain; the 
 Discourse interface is much better).
 - Real tools for moderation, management and administration.
 - Active, open development
 Google Groups is not only proprietary, but it's also effectively 
 abandonware.

 On Sun, Nov 6, 2016 at 8:33 AM, Simon Byrne  wrote:

> Personally, I find the following an improvement over google groups:
> - code blocks (copying and pasting code into the google groups 
> interface always tends to look bad)
> - the ability to edit posts
> - the ability to move threads to different categories (i.e. posts to 
> julia-dev which should have gone to julia-users, etc)
>
>
> On Sunday, 6 November 2016 10:33:20 UTC, Milan Bouchet-Valat wrote:
>>
>> Le dimanche 06 novembre 2016 à 01:49 -0800, Andreas Lobinger a 
>> écrit : 
>> > Hello colleague, 
>> > 
>> > > The Julia community has been growing rapidly over the last few 
>> > > years and discussions are happening at many different places: 
>> there 
>> > > are several Google Groups (julia-users, julia-dev, ...), IRC, 
>> > > Gitter, and a few other places. Sometimes packages or 
>> organisations 
>> > > also have their own forums and chat rooms. 
>> > > 
>> > > In the past, Discourse has been brought up as an alternative 
>> > > platform that we could use instead of Google Groups and that 
>> would 
>> > > allow us to invite the entire Julia community into one space. 
>> > > 
>> > 
>> > What problem with the julia-users mailing-list and the google 
>> groups 
>> > web interface is solved by using discourse? 
>> You can have a look at the previous thread about this: 
>> https://groups.google.com/d/msg/julia-users/4oDqW-QxyVA/lw71uqNGBQAJ 
>>
>> I also encourage you to give a try to Discourse (this can be done 
>> without even creating an account on their test instance). 
>>
>> > Why do you think (can you prove?) more centralisation will happen 
>> > with discourse? 
>> Centralization will be made possible by allowing for sub-forums 
>> dedicated to each topic (stats, optimization, data...) inside 
>> Discourse 
>> itself, instead of creating totally separate mailing lists as is 
>> currently done. Of course people will still be free to use something 
>> else, but that's quite unlikely. 
>>
>> > > We would like to solicit feedback from the broader Julia 
>> community 
>> > > about moving julia-users to Discourse as well, and potentially 
>> > > other mailing lists like julia-stats. 
>> > > 
>> > 
>> > Please define 'We'.  
>> "We" meant "Julia core developers". 
>>
>> > > If you have feedback or comments, please post them 
>> > > at 
>> http://discourse.julialang.org/t/migration-of-google-groups-to- 
>> > > discourse or in this thread. 
>> > > 
>> > 
>> > In some parts of the world, asking for feedback on a topic via a 
>> > different medium is seen as unfriendly act ... but still there is 
>> > this thread. 
>> The idea was that we would like to see how well it works by having 
>> people use Discourse for this discussion. But as you noted there's 
>> this 
>> thread for people who don't want to to that. 
>>
>>
>> Regards 
>>
>> > Wishing a happy day, 
>> >  Andreas 
>>
>
> On Sunday, 6 November 2016 10:33:20 UTC, Milan Bouchet-Valat wrote:
>>
>> Le 

[julia-users] Re: entering an unicode symbol ?

[Jeffrey Sarnoff]

```julia


u4DC0 = '\u4DC0' 
u4DC0 = '\U4DC0' 

```

On Friday, November 4, 2016 at 8:01:57 AM UTC-4, Henri Girard wrote:
>
> Hi, 
> I want to enter a list of unicode like this one : 
>
> U+4DC0 how to do it ? 
> regards 
> Henri 
>
>
>
>
>

Re: [julia-users] Re: how to report errors with context

[Jeffrey Sarnoff]

The error model for Microsoft's Midori project (2009-2013) 
<http://joeduffyblog.com/2016/02/07/the-error-model/>  is  a Nice Link

On Friday, November 4, 2016 at 5:45:39 AM UTC-4, Tamas Papp wrote:
>
> I figured it out (posting the solution for the archives, and possibly 
> for comments). Reading the Julia issues about exceptions, I came across 
> a blog post about the Midori error model [1], and also some discussions 
> on how exceptions are not the way to handle errors which are not 
> bugs. So I realized I need a version of parse that returns a 
> Nullable, then found it that it already exists (tryparse). 
>
> So here is my solution (for the self-contained stylized example, the 
> actual code is much more complex): 
>
> parsefield{T <: Real}(::Type{T}, string) = tryparse(T, string) 
>
> function parsefile(io, schema) 
> line = 1 
> while !eof(io) 
> strings = split(chomp(readline(io)), ';') 
> values = parsefield.(schema, strings) 
> function checked(column, value) 
> if isnull(value) 
> error("could not parse \"$(strings[column])\" as " * 
>   "$(schema[column]) in line $(line), column 
> $(column)") 
> else 
> value 
> end 
> end 
> # do something with this 
> [checked(column,value) for (column, value) in enumerate(values)] 
> line += 1 
> end 
> end 
>
> test_file = """ 
> 1;2;3 
> 4;5;6 
> 7;error;9 
> """ 
>
> parsefile(IOBuffer(test_file), fill(Int, 3)) 
>
> I still need to figure out type stability etc, but I think I am on the 
> right track. 
>
> [1] http://joeduffyblog.com/2016/02/07/the-error-model/ 
>
> On Thu, Nov 03 2016, Tamas Papp wrote: 
>
> > Unfortunately, the data is too large to fit in memory -- I must process 
> > it in a stream. 
> > 
> > I will look at some libraries, hoping to find an idiomatic solution. I 
> > am sure that I am not the first one encountering this pattern. 
> > 
> > On Thu, Nov 03 2016, Jeffrey Sarnoff wrote: 
> > 
> >> or split the string into rows of strings and rows into individual 
> >> value-keeper strings and put that into a matrix of strings and process 
> the 
> >> matrix, tracking row and col and checking for "error" 
> >> 
> >> On Thursday, November 3, 2016 at 5:15:06 AM UTC-4, Jeffrey Sarnoff 
> wrote: 
> >>> 
> >>> Or, redefine the question :> 
> >>> 
> >>> If you are not tied to string processing, reading the test_file  as a 
> >>> string (if it is) and then splitting the string 
> >>> ```julia 
> >>>rowstrings = map(String, split(test_file, '\n')) # need the map to 
> >>> avoid SubString results, if it matters 
> >>># then split the rows on ';' and convert to ?Float64 with NaN for 
> error 
> >>> or ?Nullable Ints 
> >>># and put the values in a matrix, processing the matrix you have 
> the 
> >>> rows and cols 
> >>> ``` 
> >>> 
> >>> 
> >>> On Thursday, November 3, 2016 at 4:34:53 AM UTC-4, Tamas Papp wrote: 
> >>>> 
> >>>> Jeffrey, 
> >>>> 
> >>>> Thanks, but my question was about how to have line and column in the 
> >>>> error message. So I would like to have an error message like this: 
> >>>> 
> >>>> ERROR: Failed to parse "error" as type Int64 in column 2, line 3. 
> >>>> 
> >>>> My best idea so far: catch the error at each level, and add i and 
> line 
> >>>> number. But this requires two try-catch-end blocks with rethrow. 
> >>>> 
> >>>> Extremely convoluted mess with rethrow here: 
> >>>> https://gist.github.com/tpapp/6f67ff36a228f47a1792e011d9b0fc13 
> >>>> 
> >>>> It does what I want, but it is ugly. A simpler solution would be 
> >>>> appreciated. I am sure I am missing something. 
> >>>> 
> >>>> Best, 
> >>>> 
> >>>> Tamas 
> >>>> 
> >>>> On Thu, Nov 03 2016, Jeffrey Sarnoff wrote: 
> >>>> 
> >>>> > Tamas, 
> >>>> > 
> >>>> > running this 
> >>>> > 
> >>>> > 
> >>>> > 
> >>>> > typealias AkoString Union{String, SubString{String}} 
> >>>> > 
> >

Re: [julia-users] Re: how to report errors with context

[Jeffrey Sarnoff]

or split the string into rows of strings and rows into individual 
value-keeper strings and put that into a matrix of strings and process the 
matrix, tracking row and col and checking for "error"

On Thursday, November 3, 2016 at 5:15:06 AM UTC-4, Jeffrey Sarnoff wrote:
>
> Or, redefine the question :>
>
> If you are not tied to string processing, reading the test_file  as a 
> string (if it is) and then splitting the string
> ```julia
>rowstrings = map(String, split(test_file, '\n')) # need the map to 
> avoid SubString results, if it matters
># then split the rows on ';' and convert to ?Float64 with NaN for error 
> or ?Nullable Ints
># and put the values in a matrix, processing the matrix you have the 
> rows and cols
> ```
>
>
> On Thursday, November 3, 2016 at 4:34:53 AM UTC-4, Tamas Papp wrote:
>>
>> Jeffrey, 
>>
>> Thanks, but my question was about how to have line and column in the 
>> error message. So I would like to have an error message like this: 
>>
>> ERROR: Failed to parse "error" as type Int64 in column 2, line 3. 
>>
>> My best idea so far: catch the error at each level, and add i and line 
>> number. But this requires two try-catch-end blocks with rethrow. 
>>
>> Extremely convoluted mess with rethrow here: 
>> https://gist.github.com/tpapp/6f67ff36a228f47a1792e011d9b0fc13 
>>
>> It does what I want, but it is ugly. A simpler solution would be 
>> appreciated. I am sure I am missing something. 
>>
>> Best, 
>>
>> Tamas 
>>
>> On Thu, Nov 03 2016, Jeffrey Sarnoff wrote: 
>>
>> > Tamas, 
>> > 
>> > running this 
>> > 
>> > 
>> > 
>> > typealias AkoString Union{String, SubString{String}} 
>> > 
>> > function parsefield{T <: Real, S <: AkoString}(::Type{T}, str::S) 
>> > result = T(0) 
>> > try 
>> > result = parse(T, str) 
>> > catch ArgumentError 
>> > errormsg = string("Failed to parse \"",str,"\" as type ", T) 
>> > throw(ErrorException(errormsg)) 
>> > end 
>> > return result 
>> > end 
>> > 
>> > function parserow(schema, strings) 
>> > # keep i for reporting column, currently not used 
>> > [parsefield(T, string) for (i, (T, string)) in 
>> enumerate(zip(schema, 
>> > strings))] 
>> > end 
>> > 
>> > function parsefile(io, schema) 
>> > line = 1 
>> > while !eof(io) 
>> > strings = split(chomp(readline(io)), ';') 
>> > parserow(schema, strings) 
>> > line += 1 # currently not used, use for error reporting 
>> > end 
>> > end 
>> > 
>> > test_file = """ 
>> > 1;2;3 
>> > 4;5;6 
>> > 7;8;error 
>> > """ 
>> > 
>> > parsefile(IOBuffer(test_file), fill(Int, 3)) 
>> > 
>> > 
>> > 
>> > 
>> > by evaluating parsefile(...), results in 
>> > 
>> > 
>> > 
>> > julia> parsefile(IOBuffer(test_file), fill(Int, 3)) 
>> > ERROR: Failed to parse "error" as type Int64 
>> >  in parsefield(::Type{Int64}, ::SubString{String}) at ./REPL[2]:7 
>> >  in (::##1#2)(::Tuple{Int64,Tuple{DataType,SubString{String}}}) at 
>> > ./:0 
>> >  in collect_to!(::Array{Int64,1}, 
>> > 
>> ::Base.Generator{Enumerate{Base.Zip2{Array{DataType,1},Array{SubString{String},1}}},##1#2},
>>  
>>
>> > ::Int64, ::Tuple{Int64,Tuple{Int64,Int64}}) at ./array.jl:340 
>> >  in 
>> > 
>> collect(::Base.Generator{Enumerate{Base.Zip2{Array{DataType,1},Array{SubString{String},1}}},##1#2})
>>  
>>
>> > at ./array.jl:308 
>> >  in parsefile(::Base.AbstractIOBuffer{Array{UInt8,1}}, 
>> ::Array{DataType,1}) 
>> > at ./REPL[4]:5 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > On Wednesday, November 2, 2016 at 1:01:30 PM UTC-4, Tamas Papp wrote: 
>> >> 
>> >> This is a conceptual question. Consider the following (extremely 
>> >> stylized, but self-contained) code 
>> >> 
>> >> parsefield{T <: Real}(::Type{T}, string) = parse(T, string) 
>> >> 
>> >> function parserow(schema, strings) 
>> >> # keep i for reporting column, currently not used 
>> >> [parsefield(T, string) for (i, (T, string)) in 
>> 

Re: [julia-users] Re: how to report errors with context

[Jeffrey Sarnoff]

Or, redefine the question :>

If you are not tied to string processing, reading the test_file  as a 
string (if it is) and then splitting the string
```julia
   rowstrings = map(String, split(test_file, '\n')) # need the map to avoid 
SubString results, if it matters
   # then split the rows on ';' and convert to ?Float64 with NaN for error 
or ?Nullable Ints
   # and put the values in a matrix, processing the matrix you have the 
rows and cols
```


On Thursday, November 3, 2016 at 4:34:53 AM UTC-4, Tamas Papp wrote:
>
> Jeffrey, 
>
> Thanks, but my question was about how to have line and column in the 
> error message. So I would like to have an error message like this: 
>
> ERROR: Failed to parse "error" as type Int64 in column 2, line 3. 
>
> My best idea so far: catch the error at each level, and add i and line 
> number. But this requires two try-catch-end blocks with rethrow. 
>
> Extremely convoluted mess with rethrow here: 
> https://gist.github.com/tpapp/6f67ff36a228f47a1792e011d9b0fc13 
>
> It does what I want, but it is ugly. A simpler solution would be 
> appreciated. I am sure I am missing something. 
>
> Best, 
>
> Tamas 
>
> On Thu, Nov 03 2016, Jeffrey Sarnoff wrote: 
>
> > Tamas, 
> > 
> > running this 
> > 
> > 
> > 
> > typealias AkoString Union{String, SubString{String}} 
> > 
> > function parsefield{T <: Real, S <: AkoString}(::Type{T}, str::S) 
> > result = T(0) 
> > try 
> > result = parse(T, str) 
> > catch ArgumentError 
> > errormsg = string("Failed to parse \"",str,"\" as type ", T) 
> > throw(ErrorException(errormsg)) 
> > end 
> > return result 
> > end 
> > 
> > function parserow(schema, strings) 
> > # keep i for reporting column, currently not used 
> > [parsefield(T, string) for (i, (T, string)) in enumerate(zip(schema, 
> > strings))] 
> > end 
> > 
> > function parsefile(io, schema) 
> > line = 1 
> > while !eof(io) 
> > strings = split(chomp(readline(io)), ';') 
> > parserow(schema, strings) 
> > line += 1 # currently not used, use for error reporting 
> > end 
> > end 
> > 
> > test_file = """ 
> > 1;2;3 
> > 4;5;6 
> > 7;8;error 
> > """ 
> > 
> > parsefile(IOBuffer(test_file), fill(Int, 3)) 
> > 
> > 
> > 
> > 
> > by evaluating parsefile(...), results in 
> > 
> > 
> > 
> > julia> parsefile(IOBuffer(test_file), fill(Int, 3)) 
> > ERROR: Failed to parse "error" as type Int64 
> >  in parsefield(::Type{Int64}, ::SubString{String}) at ./REPL[2]:7 
> >  in (::##1#2)(::Tuple{Int64,Tuple{DataType,SubString{String}}}) at 
> > ./:0 
> >  in collect_to!(::Array{Int64,1}, 
> > 
> ::Base.Generator{Enumerate{Base.Zip2{Array{DataType,1},Array{SubString{String},1}}},##1#2},
>  
>
> > ::Int64, ::Tuple{Int64,Tuple{Int64,Int64}}) at ./array.jl:340 
> >  in 
> > 
> collect(::Base.Generator{Enumerate{Base.Zip2{Array{DataType,1},Array{SubString{String},1}}},##1#2})
>  
>
> > at ./array.jl:308 
> >  in parsefile(::Base.AbstractIOBuffer{Array{UInt8,1}}, 
> ::Array{DataType,1}) 
> > at ./REPL[4]:5 
> > 
> > 
> > 
> > 
> > 
> > On Wednesday, November 2, 2016 at 1:01:30 PM UTC-4, Tamas Papp wrote: 
> >> 
> >> This is a conceptual question. Consider the following (extremely 
> >> stylized, but self-contained) code 
> >> 
> >> parsefield{T <: Real}(::Type{T}, string) = parse(T, string) 
> >> 
> >> function parserow(schema, strings) 
> >> # keep i for reporting column, currently not used 
> >> [parsefield(T, string) for (i, (T, string)) in 
> enumerate(zip(schema, 
> >> strings))] 
> >> end 
> >> 
> >> function parsefile(io, schema) 
> >> line = 1 
> >> while !eof(io) 
> >> strings = split(chomp(readline(io)), ';') 
> >> parserow(schema, strings) 
> >> line += 1 # currently not used, use for error reporting 
> >> end 
> >> end 
> >> 
> >> test_file = """ 
> >> 1;2;3 
> >> 4;5;6 
> >> 7;8;error 
> >> """ 
> >> 
> >> parsefile(IOBuffer(test_file), fill(Int, 3)) 
> >> 
> >> This will fail with an error message 
> >> 
> >> ERROR: ArgumentError: invalid base 10 digit 'e'

Re: [julia-users] Parsing complex numbers

[Jeffrey Sarnoff]

+1 (imo) It would be a real contribution to Julia's way of just working 
well with this as with that   
  for one with the requisite skill to make quick work of 
implementing
  parse(Complex, complex) and parse(Rational, rational) into 
v0.6  


On Friday, October 28, 2016 at 6:25:47 PM UTC-4, Jérémy Béjanin wrote:
>
> How easy would it be to make one assuming the standard julia notation 
> 3+4im?
>
> On Friday, October 28, 2016 at 3:58:08 PM UTC-4, Yichao Yu wrote:
>>
>> On Fri, Oct 28, 2016 at 3:53 PM, Jérémy Béjanin 
>>  wrote: 
>> > I've noticed that parsing a string representing a real number yields a 
>> real 
>> > number, but parsing a string representing a complex number yields an 
>> > expression that must subsequently be evaluated. Is there a reason for 
>> that 
>> > behaviour? I'd like to avoid that behaviour considering I am reading 
>> > user-inputted data. 
>> > 
>> > ```julia 
>> > julia> typeof(parse("1.60254+3im")) 
>> > Expr 
>> > 
>> > julia> typeof(parse("1.60254")) 
>> > Float64 
>> > ``` 
>>
>> Do no use `parse(::String)` to parse numbers. It is for parsing 
>> generic julia code. Use `parse(Float64, str)` to parse a floating 
>> point number. 
>>
>> I don't think we have a parsing function for complex number likely 
>> because there isn't a universal standard. 
>>
>

[julia-users] Re: How do I use Guide.yticks() with a log scale?

[Jeffrey Sarnoff]

Try posting your question/concern here:  discussing Plots.jl 



On Monday, October 24, 2016 at 4:14:45 PM UTC-4, Dean Schulze wrote:
>
>
> When I plot the DataFrame below using Scale.y_log10 the y-axis has ticks 
> for half powers of 10 (e.g. 10^5.5).  The plot is correct, but it's weird 
> seeing half powers of 10 on a log plot.
>
> If I add Guide.yticks(ticks=ymarks) with the following values
>
> ymarks=[10^4,10^5,10^6,10^7]
>
>
> I get a plot with the y-axis running up to 10^1000.
>
> How can I get rid of the half powers of 10 on the y-axis ticks?
>
>
>
> 9×2 DataFrames.DataFrame
> │ Row │ x │ y   │
> ├─┼───┼─┤
> │ 1   │ 5000  │ 35950   │
> │ 2   │ 1 │ 71961   │
> │ 3   │ 15000 │ 108145  │
> │ 4   │ 2 │ 154528  │
> │ 5   │ 24000 │ 395218  │
> │ 6   │ 28000 │ 689465  │
> │ 7   │ 32000 │ 2646407 │
> │ 8   │ 36000 │ 3138533 │
> │ 9   │ 4 │ 8648694 │
>
>
> ymarks=[10^4,10^5,10^6,10^7]
> plot(df, x="x",y="y",Scale.y_log10, Guide.yticks(ticks=ymarks) )
>
>
>

[julia-users] Re: how to report errors with context

[Jeffrey Sarnoff]

Tamas,

running this



typealias AkoString Union{String, SubString{String}}

function parsefield{T <: Real, S <: AkoString}(::Type{T}, str::S)
result = T(0)
try
result = parse(T, str)
catch ArgumentError
errormsg = string("Failed to parse \"",str,"\" as type ", T)
throw(ErrorException(errormsg))
end
return result
end

function parserow(schema, strings)
# keep i for reporting column, currently not used
[parsefield(T, string) for (i, (T, string)) in enumerate(zip(schema, 
strings))]
end

function parsefile(io, schema)
line = 1
while !eof(io)
strings = split(chomp(readline(io)), ';')
parserow(schema, strings)
line += 1 # currently not used, use for error reporting
end
end

test_file = """
1;2;3
4;5;6
7;8;error
"""

parsefile(IOBuffer(test_file), fill(Int, 3))




by evaluating parsefile(...), results in



julia> parsefile(IOBuffer(test_file), fill(Int, 3))
ERROR: Failed to parse "error" as type Int64
 in parsefield(::Type{Int64}, ::SubString{String}) at ./REPL[2]:7
 in (::##1#2)(::Tuple{Int64,Tuple{DataType,SubString{String}}}) at 
./:0
 in collect_to!(::Array{Int64,1}, 
::Base.Generator{Enumerate{Base.Zip2{Array{DataType,1},Array{SubString{String},1}}},##1#2},
 
::Int64, ::Tuple{Int64,Tuple{Int64,Int64}}) at ./array.jl:340
 in 
collect(::Base.Generator{Enumerate{Base.Zip2{Array{DataType,1},Array{SubString{String},1}}},##1#2})
 
at ./array.jl:308
 in parsefile(::Base.AbstractIOBuffer{Array{UInt8,1}}, ::Array{DataType,1}) 
at ./REPL[4]:5





On Wednesday, November 2, 2016 at 1:01:30 PM UTC-4, Tamas Papp wrote:
>
> This is a conceptual question. Consider the following (extremely 
> stylized, but self-contained) code 
>
> parsefield{T <: Real}(::Type{T}, string) = parse(T, string) 
>
> function parserow(schema, strings) 
> # keep i for reporting column, currently not used 
> [parsefield(T, string) for (i, (T, string)) in enumerate(zip(schema, 
> strings))] 
> end 
>
> function parsefile(io, schema) 
> line = 1 
> while !eof(io) 
> strings = split(chomp(readline(io)), ';') 
> parserow(schema, strings) 
> line += 1 # currently not used, use for error reporting 
> end 
> end 
>
> test_file = """ 
> 1;2;3 
> 4;5;6 
> 7;8;error 
> """ 
>
> parsefile(IOBuffer(test_file), fill(Int, 3)) 
>
> This will fail with an error message 
>
> ERROR: ArgumentError: invalid base 10 digit 'e' in "error" 
>  in tryparse_internal(::Type{Int64}, ::SubString{String}, ::Int64, 
> ::Int64, ::Int64 
> , ::Bool) at ./parse.jl:88 
>  in parse(::Type{Int64}, ::SubString{String}) at ./parse.jl:152 
>  in parsefield(::Type{Int64}, ::SubString{String}) at ./REPL[152]:1 
>  in (::##5#6)(::Tuple{Int64,Tuple{DataType,SubString{String}}}) at 
> ./:0 
>  in collect_to!(::Array{Int64,1}, 
> ::Base.Generator{Enumerate{Base.Zip2{Array{DataTy 
> pe,1},Array{SubString{String},1}}},##5#6}, ::Int64, 
> ::Tuple{Int64,Tuple{Int64,Int64 
> }}) at ./array.jl:340 
>  in 
> collect(::Base.Generator{Enumerate{Base.Zip2{Array{DataType,1},Array{SubString{
>  
>
> String},1}}},##5#6}) at ./array.jl:308 
>  in parsefile(::Base.AbstractIOBuffer{Array{UInt8,1}}, 
> ::Array{DataType,1}) at ./RE 
> PL[154]:5 
>
> Instead, I would like to report something like this: 
>
> ERROR: Failed to parse "error" as Int on line 3, column 3. 
>
> What's the idiomatic way of doing this in Julia? My problem is that 
> parsefield fails without knowing line or column (i in parserow). I could 
> catch and rethrow, constructing an error object gradually. Or I could 
> pass line and column numbers to parserow and parsefield for error 
> reporting, but that seems somehow inelegant (I have seen it in code 
> though). 
>
> Best, 
>
> Tamas 
>

[julia-users] Re: Sys.CPU_CORES

[Jeffrey Sarnoff]

It works for me on Linux and Windows.

On Wednesday, November 2, 2016 at 9:29:28 PM UTC-4, Júlio Hoffimann wrote:
>
> Hi,
>
> Sys.CPU_CORES returns the number of physical cores or processing units? Is 
> it portable across different OS?
>
> -Júlio
>

Re: [julia-users] building julia 0.5.0 on FreeBSD 11

[Jeffrey Sarnoff]

Kostas,

Please post the location of those patches for others' reference.

Thanks

On Wednesday, November 2, 2016 at 6:29:40 PM UTC-4, Kostas Oikonomou wrote:
>
> Thanks, I found an entire set of patches.
>
> On Sunday, October 30, 2016 at 10:28:40 PM UTC-4, Isaiah wrote:
>>
>> Just guessing here from some quick poking around: try adding `#include 
>> ` to that file (`OPENBLAS_SRC/driver/others/blas_server.c`).
>>
>> On Sat, Oct 29, 2016 at 4:50 PM, Kostas Oikonomou > > wrote:
>>
>>> Hi, I'm following the instructions in the README, trying to build 0.5.0 
>>> from source on an amd64 machine.   
>>>
>>> However, I'm stuck at errors  in the OpenBlas build:
>>>
>>>
>>> blas_server.c:569:16: error: variable has incomplete type 'struct rlimit'
>>> struct rlimit rlim;
>>>   ^
>>> blas_server.c:569:9: note: forward declaration of 'struct rlimit'
>>> struct rlimit rlim;
>>>^
>>> blas_server.c:578:17: warning: implicit declaration of function 'raise' 
>>> is invalid in C99
>>>   [-Wimplicit-function-declaration]
>>> if(0 != raise(SIGINT)) {
>>> ^
>>> blas_server.c:578:23: error: use of undeclared identifier 'SIGINT'
>>> if(0 != raise(SIGINT)) {
>>>   ^
>>> 1 warning and 2 errors generated.
>>> gmake[3]: *** [Makefile:101: blas_server.o] Error 1
>>>
>>>
>>> I also tried using FreeBSD's OpenBlas port, but that apparently creates 
>>> a conflict between gcc 4.8.4 and the recommended gcc6.
>>>
>>> Here is my Make.user file:
>>>
>>> # libunwind needs a small patch to its tests to compile.
>>> FC=gfortran6
>>> # gfortran can't link binaries:
>>> FFLAGS=-Wl,-rpath,/usr/local/lib/gcc6
>>> # System libraries installed by pkg are not on the compiler path by 
>>> default:
>>> LDFLAGS=/usr/local/lib
>>> CPPFLAGS=/usr/local/include
>>> # Problems with OpenBLAS 
>>> OPENBLAS_TARGET_ARCH=BARCELONA
>>> OPENBLAS_DYNAMIC_ARCH=0 
>>> # Installation
>>> prefix=/opt/julia
>>>
>>> Thanks for any help.
>>>
>>> Kostas
>>>
>>
>>

[julia-users] Re: Calling Julia code from Python

[Jeffrey Sarnoff]

Alexi,

While you may want it to be otherwise, Steven is right.  There have been a 
few programming languages that were designed to be useful with very little 
instruction.  Julia, Python, Java, and most other modern languages are not 
that way.  And while it would be great if there really were a forthcoming 
interlingua .. there is not, not today anyway.  The best advice any of us 
could give you is to revisit the reason that you find a need to do this 
that way, and find an alternative way to satisfy that expectation.  No 
reasonable teacher or manager would expect you to make that happen without 
much more experience.  And once you have the experience, you would probably 
still want to choose a different way to work this.

*with some simpatico*


On Wednesday, November 2, 2016 at 6:21:20 PM UTC-4, Steven G. Johnson wrote:
>
>
>
> On Wednesday, November 2, 2016 at 2:43:27 PM UTC-4, Alexei Serdiuk wrote:
>>
>> I'm new to Julia and, unfortunately, I'm almost zero to Python. 
>>
>
> An unfortunate combination — better to learn one programming language 
> before you deal with inter-language calling.
>  
>
>> I need to call Julia code from Python. This code must do some operations 
>> and then return it back to Python.
>>
>
> Google "pyjulia"
>  
>
>> I have an example for calling Java:
>>
>
> That code is calling Java by piping the input and output through files and 
> popen.  You can do the exact same thing with Julia too, of course, but 
> pyjulia is far more efficient: it calls Julia as a library, within the same 
> process, and can even pass large arrays without making copies. 
>

Re: [julia-users] Recursive data structures with Julia

[Jeffrey Sarnoff]

John,

Currently (v0.5) :
Which uses of non-concrete types are performance friendly?
What ways of using abstract types are a drag on performance?

Regards, Jeffrey


On Sunday, October 30, 2016 at 9:38:15 PM UTC-4, John Myles White wrote:
>
> Working with non-concrete types is often a problem for performance, so 
> this approach may not be very efficient compared with alternatives that are 
> more careful about the use of concrete types.
>
>  --John
>
> On Sunday, October 30, 2016 at 6:27:47 PM UTC-7, Ralph Smith wrote:
>>
>> Conversion is done by methods listed in base/nullable.jl
>>
>> I would like to know if there is any drawback to an alternative like
>>
>> abstract Bst
>>
>> immutable NullNode <: Bst end
>>
>> type BstNode <: Bst
>> val::Int
>> left::Bst
>> right::Bst
>> end
>>
>> isnull(t::Bst) = isa(t,NullNode)
>>
>> BstNode(key::Int) = BstNode(key, NullNode(), NullNode())
>>
>> which appears to be good for type-safety, and is (sometimes) slightly 
>> faster and less cumbersome than Nullables.
>>
>> On Sunday, October 30, 2016 at 6:24:42 PM UTC-4, Ángel de Vicente wrote:
>>>
>>> Hi, 
>>>
>>> by searching in the web I found 
>>> (
>>> http://stackoverflow.com/questions/36383517/how-to-implement-bst-in-julia) 
>>>
>>> a way to make my BST code much cleaner (as posted below). Nevertheless, 
>>> I don't find this very ellegant, since the head node is of type Bst, 
>>> while the children are of type Nullable{Bst} (is this the 'canonical' 
>>> way 
>>> of building recursive data structures with Julia?). 
>>>
>>> But when I first read the code in SO, I thought that it was probably 
>>> wrong, since it does: 
>>>
>>> node.left = BST(key) 
>>> where node.left is of type Nullable{BST}. 
>>>
>>> Then I realized that automatic conversion from BST to Nullable{BST} is 
>>> done when assigning to node.left, so all is good. Coming from Fortran, 
>>> this is a bit odd for me... what are the rules for automatic conversion? 
>>>   
>>>
>>>
>>> Thanks a lot, 
>>> Ángel de Vicente 
>>>
>>>
>>>
>>>
>>>
>>> , 
>>> | module b 
>>> | 
>>> | type Bst 
>>> | val::Int 
>>> | left::Nullable{Bst} 
>>> | right::Nullable{Bst} 
>>> | end 
>>> | Bst(key::Int) = Bst(key, Nullable{Bst}(), Nullable{Bst}())   
>>> | 
>>> | "Given an array of Ints, it will create a BST tree, type: Bst" 
>>> | function build_bst(list::Array{Int,1}) 
>>> | head = list[1] 
>>> | tree = Bst(head) 
>>> | for e in list[2:end] 
>>> | place_bst(tree,e) 
>>> | end 
>>> | return tree 
>>> | end 
>>> | 
>>> | function place_bst(tree::Bst,e::Int) 
>>> | if e == tree.val 
>>> | println("Dropping $(e). No repeated values allowed") 
>>> | elseif e < tree.val 
>>> | if (isnull(tree.left)) 
>>> | tree.left = Bst(e) 
>>> | else 
>>> | place_bst(tree.left.value,e) 
>>> | end 
>>> | else 
>>> | if (isnull(tree.right)) 
>>> | tree.right = Bst(e) 
>>> | else 
>>> | place_bst(tree.right.value,e) 
>>> | end 
>>> | end 
>>> | end 
>>> | 
>>> | function print_bst(tree::Bst) 
>>> | if !isnull(tree.left) print_bst(tree.left.value) end 
>>> | println(tree.val) 
>>> | if !isnull(tree.right) print_bst(tree.right.value) end 
>>> | end 
>>> | 
>>> | end 
>>> ` 
>>>
>>> , 
>>> | julia> include("bst.jl") 
>>> | 
>>> | julia> b.print_bst( b.build_bst([4,5,10,3,20,-1,10])) 
>>> | Dropping 10. No repeated values allowed 
>>> | -1 
>>> | 3 
>>> | 4 
>>> | 5 
>>> | 10 
>>> | 20 
>>> | 
>>> | julia> 
>>> ` 
>>>
>>>
>>> -- 
>>> Ángel de Vicente 
>>> http://www.iac.es/galeria/angelv/   
>>>
>>

[julia-users] Re: Error calculating eigs of pentadiagonal matrix.

[Jeffrey Sarnoff]

I have one suggestion: see if Andreas' LinearAlgebra.jl does any better.


Pkg.clone(""https://github.com/andreasnoack/LinearAlgebra.jl;)
using LinearAlgebra
# ...



If there is still difficulty, you may look at eigenGeneral.jl 

 and eigenSelfAdjoint.jl 

 to 
find which more specific versions of eigvals/eigvals! is appropriate for 
your scenario.


On Wednesday, November 2, 2016 at 6:43:48 AM UTC-4, Alejandro Castellanos 
wrote:
>
> Hello.
>
> I am working with a pentadiagonal sparse matrix that represents a 2D 
> Schrodinger's time-independent equation. I first work the laplacian 
> expressed in Finite Differences form and then I apply the potential on the 
> same matrix.
>
> So far I've been able to validate my results for both an electron in a box 
> as well as a harmonic oscillator, but when I change to the following 
> potential of a dipole, Julia pretty much quits on me when I try to obtain 
> the eigenvalues and eigenvectors:
>
>   O = [round(L/2)-hx round(L/2)-hy]# --el ORIGEN (centro -- x,y) 
> del potencial.
>   Eps_o  = 8.854187817e10-12# --F*m^-1
>   C = 1/(4*pi*Eps_o)
>   D = 1e-21#C*m^2/s# --Debyes)
>   pe= 1.8*D 
>   *P(X,Y)  = -(C)*pe*(Y/X)*(1/( (X)^2 + (Y)^2)   )*# --How the 
> potential gets described.
>  
> #--I'm aware there's singularities in the potential.
> #--and here's how I apply the potential to my sparse matrix.
>
>   Vi  = Float64[]# --container for the potential.
>   for j=Y  for i=X  push!(Vi,P(i,j))   end  end@ --applying the potential.
>
>
> I use this command: *l, v = eigs(M,nev=15,which = :SM ,ritzvec=true)*
>
> My problem seems to be that there's an error that I can't get past:
>
> ERROR: LoadError: ArgumentError: matrix has one or more zero pivots
>>>
>>>  in #ldltfact!#10(::Float64, ::Function, 
 ::Base.SparseArrays.CHOLMOD.Factor{Float64}, 
 ::Base.SparseArrays.CHOLMOD.Sparse{Float64}) at ./sparse/cholmod.jl:1350
>>>
>>>  in (::Base.LinAlg.#kw##ldltfact!)(::Array{Any,1}, 
 ::Base.LinAlg.#ldltfact!, ::Base.SparseArrays.CHOLMOD.Factor{Float64}, 
 ::Base.SparseArrays.CHOLMOD.Sparse{Float64}) at ./:0
>>>
>>>  in #ldltfact#12(::Float64, ::Array{Int64,1}, ::Function, 
 ::Base.SparseArrays.CHOLMOD.Sparse{Float64}) at ./sparse/cholmod.jl:1386
>>>
>>>  in #ldltfact#13(::Array{Any,1}, ::Function, 
 ::Hermitian{Float64,SparseMatrixCSC{Float64,Int64}}) at 
 ./sparse/cholmod.jl:1426
>>>
>>>  in factorize(::SparseMatrixCSC{Float64,Int64}) at ./sparse/linalg.jl:897
>>>
>>>  in #_eigs#62(::Int64, ::Int64, ::Symbol, ::Float64, ::Int64, ::Void, 
 ::Array{Float64,1}, ::Bool, ::Base.LinAlg.#_eigs, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at 
 ./linalg/arnoldi.jl:251
>>>
>>>  in (::Base.LinAlg.#kw##_eigs)(::Array{Any,1}, ::Base.LinAlg.#_eigs, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at ./:0
>>>
>>>  in #eigs#55(::Array{Any,1}, ::Function, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at 
 ./linalg/arnoldi.jl:78
>>>
>>>  in (::Base.LinAlg.#kw##eigs)(::Array{Any,1}, ::Base.LinAlg.#eigs, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at ./:0
>>>
>>>  in #eigs#54(::Array{Any,1}, ::Function, 
 ::SparseMatrixCSC{Float64,Int64}) at ./linalg/arnoldi.jl:77
>>>
>>>  in (::Base.LinAlg.#kw##eigs)(::Array{Any,1}, ::Base.LinAlg.#eigs, 
 ::SparseMatrixCSC{Float64,Int64}) at ./:0
>>>
>>>  in include_from_node1(::String) at ./loading.jl:488
>>>
>>> while loading /home/alejandro/Desktop/ACAD/PROG/ACADEMIC_PROGRAMMING/FDM 
 (Finite_Difference_Method)/2D/SCHROD_DIP_2D/SCRATCH-2D-SI-DIPOLO2.jl, in 
 expression starting on line 106
>>>
>>>
>>> My question is, is there a way to work around it, or, am I completely 
> screwed?
>
> Thanks so much in advance.
>

[julia-users] Re: jl_stat_ctime

[Jeffrey Sarnoff]

If you are working with file information, use e.g. `file_stats=stat(); 
file_creation_time = file_stats.ctime; file_modification_time = 
file_stat.mtime;` 
You will get Float64 values, to make FineComputerTimes from those, 

function FineComputerTime(stat_time::Float64)
   nanosecs = round(UInt64, stat_time * 1.0e9)
   return FineComputerTime(nanosecs)
end




On Tuesday, November 1, 2016 at 3:44:07 PM UTC-4, Jeffrey Sarnoff wrote:
>
> Look at the help for tic() and toc().
> Do you care about interfacing directly with jl_ routines?  If not, and you 
> are trying to make your own harness ... perhaps this would help:
> #=
>Using immutable rather than type with fields that are 
>simple and immediate values keeps information directly
>available (rather than indirectly available, like arrays).
>
>Use Int64 because nanosecond timing uses 64 bits (UInt64).
>
>time_ns() "Get the time in nanoseconds. 
>   The time corresponding to 0 is undefined,
>   and wraps every 5.8 years."
>
>time_zero because the timer is given as a UInt64 value, and 
> there are more of those than positive Int64s.
> =#
>
> const time_zero = [time_ns()]
> get_time_zero() = time_zero[1]
> function set_time_zero(nanoseconds::UInt64)
> time_zero[1] = nanoseconds
> return nanoseconds
> end
>
> immutable FineComputerTime
> seconds::Int64
> nanoseconds::Int64
> end
>
> function FineComputerTime(nanosecs::UInt64)
> nanosecs -= get_time_zero()
> secs, nsecs = fldmod( nanosecs, 1_000_000_000%UInt64 ) # value%UInt64 
> is a fast way to force the type
> return FineComputerTime( Int64(secs), Int64(nsecs) )
> end
>
> FineComputerTime() = FineComputerTime(time_ns())
>
>
>
>
>
>
>
>
> On Friday, October 28, 2016 at 10:07:42 AM UTC-4, Brandon Taylor wrote:
>>
>> Right now in base jl_stat_ctime looks like this:
>>
>> JL_DLLEXPORT double jl_stat_ctime(char *statbuf)
>> {
>> uv_stat_t *s;
>> s = (uv_stat_t*)statbuf;
>> return (double)s->st_ctim.tv_sec + (double)s->st_ctim.tv_nsec * 1e-9;
>> }
>>
>> And it's called with
>>
>> ccall(:jl_stat_ctime,   Float64, (Ptr{UInt8},), buf)
>>
>> I'd like to simplify this.
>>
>> I'd like a type
>>
>> type FineComputerTime
>> seconds::Int
>> nanoseconds::Int
>> end
>>
>> And a way to fill it in using the stat buffer.
>>
>> Can anyone offer some tips? The c code keeps confusing me.
>>
>>
>>
>>
>> I
>>
>

[julia-users] Re: jl_stat_ctime

[Jeffrey Sarnoff]

Look at the help for tic() and toc().
Do you care about interfacing directly with jl_ routines?  If not, and you 
are trying to make your own harness ... perhaps this would help:
#=
   Using immutable rather than type with fields that are 
   simple and immediate values keeps information directly
   available (rather than indirectly available, like arrays).

   Use Int64 because nanosecond timing uses 64 bits (UInt64).

   time_ns() "Get the time in nanoseconds. 
  The time corresponding to 0 is undefined,
  and wraps every 5.8 years."

   time_zero because the timer is given as a UInt64 value, and 
there are more of those than positive Int64s.
=#

const time_zero = [time_ns()]
get_time_zero() = time_zero[1]
function set_time_zero(nanoseconds::UInt64)
time_zero[1] = nanoseconds
return nanoseconds
end

immutable FineComputerTime
seconds::Int64
nanoseconds::Int64
end

function FineComputerTime(nanosecs::UInt64)
nanosecs -= get_time_zero()
secs, nsecs = fldmod( nanosecs, 1_000_000_000%UInt64 ) # value%UInt64 
is a fast way to force the type
return FineComputerTime( Int64(secs), Int64(nsecs) )
end

FineComputerTime() = FineComputerTime(time_ns())








On Friday, October 28, 2016 at 10:07:42 AM UTC-4, Brandon Taylor wrote:
>
> Right now in base jl_stat_ctime looks like this:
>
> JL_DLLEXPORT double jl_stat_ctime(char *statbuf)
> {
> uv_stat_t *s;
> s = (uv_stat_t*)statbuf;
> return (double)s->st_ctim.tv_sec + (double)s->st_ctim.tv_nsec * 1e-9;
> }
>
> And it's called with
>
> ccall(:jl_stat_ctime,   Float64, (Ptr{UInt8},), buf)
>
> I'd like to simplify this.
>
> I'd like a type
>
> type FineComputerTime
> seconds::Int
> nanoseconds::Int
> end
>
> And a way to fill it in using the stat buffer.
>
> Can anyone offer some tips? The c code keeps confusing me.
>
>
>
>
> I
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

Bill, 
Consider distributing windows_build.txt ready to use with 64-bit machines 
and giving the changes to be made for 32-bit machines in comments.  That 
reverses the current orientation, and fits more of the likely user base.  I 
think that change gives you this:


Note that windows_build.txt is preset for 32-bit Windows;
for 64-bit machines, windows_build.txt should be this:

# This is set for use with 64-bit Windows installations
#
#   To use this with  32-bit Windows installations,
#   replace x86_64 with i686 throughout
#   replace ABI=64 with ABI=32


wget http://mpir.org/mpir-2.7.2.tar.bz2
tar -xvf mpir-2.7.2.tar.bz2
cd mpir-2.7.2
./configure --enable-shared --disable-static --enable-gmpcompat 
--build=core2-w64-mingw64 LDFLAGS=-static-libgcc ABI=64
make -j
cd ..
wget http://www.mpfr.org/mpfr-current/mpfr-3.1.4.tar.bz2
tar -xvf mpfr-3.1.4.tar.bz2
cd mpfr-3.1.4
./configure --with-gmp-build=/home/User/mpir-2.7.2 --enable-shared 
--disable-static
make -j
cd ..
git clone https://github.com/wbhart/flint2
https://github.com/wbhart/antic
cd flint2
./configure --enable-shared --disable-static 
--with-mpir=/home/user/mpir-2.7.2 --with-mpfr=/home/user/mpfr-3.1.4 
--extensions=/home/user/antic
# edit Makefile
# in CLFAGS replace -ansi -pedantic with -std=c99
# add -mtune=core2 -march=core2 to CFLAGS
# add -I/home/User/flint2 to INCS
# ensure EXTRA_SHARED_FLAGS contains -static-libgcc -shared 
-Wl,--export-all-symbols
make -j
cd ..
wget http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.7.6.tar.gz
tar -xvf pari-2.7.6.tar.gz
cd pari-2.7.6
export PATH=/home/user/mpir-2.7.2/.libs:$PATH
LDFLAGS=-static-libgcc CFLAGS="-mtune=core2 -march=core2" ./Configure 
--with-gmp-include=/home/user/mpir-2.7.2 
--with-gmp-lib=/home/user/mpir-2.7.2/.libs --host=x86_64-pc-mingw
cd Omingw-x86_64-pc
make gp
cd ../..




On Friday, October 28, 2016 at 4:54:06 AM UTC-4, Bill Hart wrote:
>
> 64 bit Windows will run 32 bit Windows binaries, yes. Of course we 
> recommend the 64 bit ones.
>
> On 28 October 2016 at 10:52, digxx  
> wrote:
>
>> Yes but when I do not manually change i686 and ABI=32 to the x64 it is 
>>> running the 32bit version, right?
>>> You mean windows 64 can still cope with 32bit stuff? 
>>>
>>
>>
>> I mean changing in the windows_build.txt
>> By Pkg.build("Nemo") I do not run any executable, right? 
>>
>
>

Re: [julia-users] Re: Input a data from the console

[Jeffrey Sarnoff]

or, the more specific

function read_integer(prompt::String="")::Int
print(prompt)
str = chomp(readline())
   return parse(Int, str)
end

On Friday, October 28, 2016 at 1:17:54 AM UTC-4, Jeffrey Sarnoff wrote:
>
> with Yichao's help,
>
>
>
> typealias ParseableNumber Union{Float64, Float32, Signed, Unsigned, Bool} 
>
> """
> `input{T<:ParseableNumber}(::Type{T}, prompt::String="")::T`
>
> Read an integer or a floating point value from STDIN.
>
>
> The prompt string, if given, is printed to standard output without a
> trailing newline before reading the input.
>
> days = input(Int, "How many days? ")
>
> """
> function input{T<:ParseableNumber}(::Type{T}, prompt::String = "")::T
> print(prompt)
> str = chomp(readline())
>return parse(T, str)
> end
>
>
>
>
>
>
>
> On Friday, October 28, 2016 at 12:48:33 AM UTC-4, Jeffrey Sarnoff wrote:
>>
>> Thank you, that is helpful.
>>
>> On Friday, October 28, 2016 at 12:22:37 AM UTC-4, Yichao Yu wrote:
>>>
>>> On Fri, Oct 28, 2016 at 12:01 AM, Jeffrey Sarnoff 
>>> <jeffrey...@gmail.com> wrote: 
>>> > And although readline() yields a String, if you are asking for, say, a 
>>> Int 
>>> > or a Float64 value, you can add a second version of `input`: 
>>> > 
>>> > ``` 
>>> > typealias ParseableNumber Union{Float64, Float32, Signed, Unsigned, 
>>> Bool} 
>>> > 
>>> > """ 
>>> > `input{T<:ParseableNumber}(::Type{T}, prompt::String="")::T` 
>>> > 
>>> > Read an integer or a floating point value from STDIN. 
>>> > 
>>> > The prompt string, if given, is printed to standard output without a 
>>> > trailing newline before reading the input. 
>>> > 
>>> > days = input(Int, "How many days? ") 
>>> > 
>>> > """ 
>>> > function input{T<:ParseableNumber}(::Type{T}, prompt::String = "")::T 
>>> > print(prompt) 
>>> > str = chomp(readline()) 
>>> > return parse(str) 
>>>
>>> Don't use `parse(::String)` for this. It is for parsing julia code, 
>>> not for parsing numbers. Use sth like `parse(Int, str)` intead. 
>>>
>>> > end 
>>> > ``` 
>>> > 
>>> > 
>>> > On Thursday, October 27, 2016 at 1:47:27 PM UTC-4, Ismael Venegas 
>>> Castelló 
>>> > wrote: 
>>> >> 
>>> >> """ 
>>> >> `input(prompt::String="")::String` 
>>> >> 
>>> >> Read a string from STDIN. The trailing newline is stripped. 
>>> >> 
>>> >> The prompt string, if given, is printed to standard output without a 
>>> >> trailing newline before reading input. 
>>> >> """ 
>>> >> function input(prompt::String = "")::String 
>>> >> print(prompt) 
>>> >> return chomp(readline()) 
>>> >> end 
>>> >> 
>>> >> 
>>> >> 
>>> >> 
>>> >> El jueves, 27 de octubre de 2016, 10:16:25 (UTC-5), Aleksandr Mikheev 
>>> >> escribió: 
>>> >>> 
>>> >>> Hello, 
>>> >>> 
>>> >>> How could I input a data from the console? For instance, I would 
>>> like to 
>>> >>> make such that user is able to input the value of x. Is there any 
>>> way to do 
>>> >>> it like in Fortran or something? I can't find anything in 
>>> documentation. 
>>> >>> 
>>> >>> P.S. Also, I believe there is a way to input a string using 
>>> readline() 
>>> >>> function. However, if I do something like: 
>>> >>> 
>>> >>> a = readline() 
>>> >>> "asd" 
>>> >>> 
>>> >>> then I will get "\"asd\"\r\n". 
>>> >>> 
>>> >>> How to avoid these excess symbols? 
>>> >>> 
>>> >>> Thank you in advance! 
>>>
>>

Re: [julia-users] Re: Input a data from the console

[Jeffrey Sarnoff]

with Yichao's help,



typealias ParseableNumber Union{Float64, Float32, Signed, Unsigned, Bool} 

"""
`input{T<:ParseableNumber}(::Type{T}, prompt::String="")::T`

Read an integer or a floating point value from STDIN.


The prompt string, if given, is printed to standard output without a
trailing newline before reading the input.

days = input(Int, "How many days? ")

"""
function input{T<:ParseableNumber}(::Type{T}, prompt::String = "")::T
print(prompt)
str = chomp(readline())
   return parse(T, str)
end







On Friday, October 28, 2016 at 12:48:33 AM UTC-4, Jeffrey Sarnoff wrote:
>
> Thank you, that is helpful.
>
> On Friday, October 28, 2016 at 12:22:37 AM UTC-4, Yichao Yu wrote:
>>
>> On Fri, Oct 28, 2016 at 12:01 AM, Jeffrey Sarnoff 
>> <jeffrey...@gmail.com> wrote: 
>> > And although readline() yields a String, if you are asking for, say, a 
>> Int 
>> > or a Float64 value, you can add a second version of `input`: 
>> > 
>> > ``` 
>> > typealias ParseableNumber Union{Float64, Float32, Signed, Unsigned, 
>> Bool} 
>> > 
>> > """ 
>> > `input{T<:ParseableNumber}(::Type{T}, prompt::String="")::T` 
>> > 
>> > Read an integer or a floating point value from STDIN. 
>> > 
>> > The prompt string, if given, is printed to standard output without a 
>> > trailing newline before reading the input. 
>> > 
>> > days = input(Int, "How many days? ") 
>> > 
>> > """ 
>> > function input{T<:ParseableNumber}(::Type{T}, prompt::String = "")::T 
>> > print(prompt) 
>> > str = chomp(readline()) 
>> > return parse(str) 
>>
>> Don't use `parse(::String)` for this. It is for parsing julia code, 
>> not for parsing numbers. Use sth like `parse(Int, str)` intead. 
>>
>> > end 
>> > ``` 
>> > 
>> > 
>> > On Thursday, October 27, 2016 at 1:47:27 PM UTC-4, Ismael Venegas 
>> Castelló 
>> > wrote: 
>> >> 
>> >> """ 
>> >> `input(prompt::String="")::String` 
>> >> 
>> >> Read a string from STDIN. The trailing newline is stripped. 
>> >> 
>> >> The prompt string, if given, is printed to standard output without a 
>> >> trailing newline before reading input. 
>> >> """ 
>> >> function input(prompt::String = "")::String 
>> >> print(prompt) 
>> >> return chomp(readline()) 
>> >> end 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> El jueves, 27 de octubre de 2016, 10:16:25 (UTC-5), Aleksandr Mikheev 
>> >> escribió: 
>> >>> 
>> >>> Hello, 
>> >>> 
>> >>> How could I input a data from the console? For instance, I would like 
>> to 
>> >>> make such that user is able to input the value of x. Is there any way 
>> to do 
>> >>> it like in Fortran or something? I can't find anything in 
>> documentation. 
>> >>> 
>> >>> P.S. Also, I believe there is a way to input a string using 
>> readline() 
>> >>> function. However, if I do something like: 
>> >>> 
>> >>> a = readline() 
>> >>> "asd" 
>> >>> 
>> >>> then I will get "\"asd\"\r\n". 
>> >>> 
>> >>> How to avoid these excess symbols? 
>> >>> 
>> >>> Thank you in advance! 
>>
>

Re: [julia-users] Re: Input a data from the console

[Jeffrey Sarnoff]

Thank you, that is helpful.

On Friday, October 28, 2016 at 12:22:37 AM UTC-4, Yichao Yu wrote:
>
> On Fri, Oct 28, 2016 at 12:01 AM, Jeffrey Sarnoff 
> <jeffrey...@gmail.com > wrote: 
> > And although readline() yields a String, if you are asking for, say, a 
> Int 
> > or a Float64 value, you can add a second version of `input`: 
> > 
> > ``` 
> > typealias ParseableNumber Union{Float64, Float32, Signed, Unsigned, 
> Bool} 
> > 
> > """ 
> > `input{T<:ParseableNumber}(::Type{T}, prompt::String="")::T` 
> > 
> > Read an integer or a floating point value from STDIN. 
> > 
> > The prompt string, if given, is printed to standard output without a 
> > trailing newline before reading the input. 
> > 
> > days = input(Int, "How many days? ") 
> > 
> > """ 
> > function input{T<:ParseableNumber}(::Type{T}, prompt::String = "")::T 
> > print(prompt) 
> > str = chomp(readline()) 
> > return parse(str) 
>
> Don't use `parse(::String)` for this. It is for parsing julia code, 
> not for parsing numbers. Use sth like `parse(Int, str)` intead. 
>
> > end 
> > ``` 
> > 
> > 
> > On Thursday, October 27, 2016 at 1:47:27 PM UTC-4, Ismael Venegas 
> Castelló 
> > wrote: 
> >> 
> >> """ 
> >> `input(prompt::String="")::String` 
> >> 
> >> Read a string from STDIN. The trailing newline is stripped. 
> >> 
> >> The prompt string, if given, is printed to standard output without a 
> >> trailing newline before reading input. 
> >> """ 
> >> function input(prompt::String = "")::String 
> >> print(prompt) 
> >> return chomp(readline()) 
> >> end 
> >> 
> >> 
> >> 
> >> 
> >> El jueves, 27 de octubre de 2016, 10:16:25 (UTC-5), Aleksandr Mikheev 
> >> escribió: 
> >>> 
> >>> Hello, 
> >>> 
> >>> How could I input a data from the console? For instance, I would like 
> to 
> >>> make such that user is able to input the value of x. Is there any way 
> to do 
> >>> it like in Fortran or something? I can't find anything in 
> documentation. 
> >>> 
> >>> P.S. Also, I believe there is a way to input a string using readline() 
> >>> function. However, if I do something like: 
> >>> 
> >>> a = readline() 
> >>> "asd" 
> >>> 
> >>> then I will get "\"asd\"\r\n". 
> >>> 
> >>> How to avoid these excess symbols? 
> >>> 
> >>> Thank you in advance! 
>

[julia-users] Re: Input a data from the console

[Jeffrey Sarnoff]

And although readline() yields a String, if you are asking for, say, a Int 
or a Float64 value, you can add a second version of `input`:

```
typealias ParseableNumber Union{Float64, Float32, Signed, Unsigned, Bool} 

"""
`input{T<:ParseableNumber}(::Type{T}, prompt::String="")::T`

Read an integer or a floating point value from STDIN.

The prompt string, if given, is printed to standard output without a
trailing newline before reading the input.

days = input(Int, "How many days? ")

"""
function input{T<:ParseableNumber}(::Type{T}, prompt::String = "")::T
print(prompt)
str = chomp(readline())
return parse(str)
end
```


On Thursday, October 27, 2016 at 1:47:27 PM UTC-4, Ismael Venegas Castelló 
wrote:
>
> """
> `input(prompt::String="")::String`
>
> Read a string from STDIN. The trailing newline is stripped.
>
> The prompt string, if given, is printed to standard output without a
> trailing newline before reading input.
> """
> function input(prompt::String = "")::String
> print(prompt)
> return chomp(readline())
> end
>
>
>
>
> El jueves, 27 de octubre de 2016, 10:16:25 (UTC-5), Aleksandr Mikheev 
> escribió:
>>
>> Hello,
>>
>> How could I input a data from the console? For instance, I would like to 
>> make such that user is able to input the value of x. Is there any way to do 
>> it like in Fortran or something? I can't find anything in documentation.
>>
>> P.S. Also, I believe there is a way to input a string using readline() 
>> function. However, if I do something like:
>>
>> a = readline()
>> "asd"
>>
>> then I will get "\"asd\"\r\n".
>>
>> How to avoid these excess symbols?
>>
>> Thank you in advance!
>>
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

*Home Free: no longer is getting Nemo's usefulness somewhere else and
costing you time.*

On Thu, Oct 27, 2016 at 4:27 PM, 'Bill Hart' via julia-users <
julia-users@googlegroups.com> wrote:

> Yes, we'll eventually get rid of the warnings. Technically we only fully
> support Julia-0.4 at the moment. However, Nemo is known to work with
> Julia-0.5 with some warnings.
>
> Thanks for persisting with it. I'm glad it is working for you now.
>
> We'll try to figure out how to stop this happening in future, so you don't
> have to go through this again!
>
> Bill.
>
> On 27 October 2016 at 21:39, digxx <diger_d...@hotmail.com> wrote:
>
>>
>>
>> Am Donnerstag, 27. Oktober 2016 21:25:54 UTC+2 schrieb Jeffrey Sarnoff:
>>>
>>> You are home free!  Try arbfield(1) twice ..
>>>
>>
>> Yes I know the warning is gone I'm just wondering why it always shows up
>> the first time...
>>
>>
>> home free? in terms of homedir() or what you mean?
>>
>
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

You are home free!  Try arbfield(1) twice ..

On Thursday, October 27, 2016 at 3:22:39 PM UTC-4, digxx wrote:
>
>
>
> Am Donnerstag, 27. Oktober 2016 20:24:19 UTC+2 schrieb Bill Hart:
>>
>> It could well be libflint-13.dll is the problem. It's just a copy of the 
>> other flint dll, so you can make that any way you like. Just copy the file 
>> and rename the copy.
>>
>> As for the dll DependencyWalker claims is missing, I don't know what it 
>> does and it might not be relevant. We are mainly looking for dlls in the 
>> left hand pane that it says are missing that appear related to gcc, 
>> pthreads, arb, flint, gmp, mpfr, pari, arb, msys, etc. Anything that looks 
>> like an MS dll can probably be ignored.
>>
>> Bill.
>>
>
> I haven't tried the wget.exe proposal of jeffrey yet but it seems that the 
> libflint-13 (for whatever reason is the issue)
> now I get:
>
> julia> arbfield( 1 )
> WARNING: bytestring(p::Union{Ptr{Int8},Ptr{UInt8}}) is deprecated, use 
> unsafe_string(p) instead.
>  in depwarn(::String, ::Symbol) at .\deprecated.jl:64
>  in bytestring(::Ptr{UInt8}) at .\deprecated.jl:50
>  in show(::IOContext{Base.Terminals.TTYTerminal}, ::Nemo.arb) at 
> D:\Julia\v0.5\Nemo\src\arb\arb.jl:118
>  in display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, 
> ::MIME{Symbol("text/plain")}, ::Nemo.arb) at .\REPL.jl:132
>  in display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, ::Nemo.arb) 
> at .\REPL.jl:135
>  in display(::Nemo.arb) at .\multimedia.jl:143
>  in print_response(::Base.Terminals.TTYTerminal, ::Any, ::Void, ::Bool, 
> ::Bool, ::Void) at .\REPL.jl:154
>  in print_response(::Base.REPL.LineEditREPL, ::Any, ::Void, ::Bool, 
> ::Bool) at .\REPL.jl:139
>  in 
> (::Base.REPL.##22#23{Bool,Base.REPL.##33#42{Base.REPL.LineEditREPL,Base.REPL.REPLHistoryProvider},Base.REPL.LineEditREPL,Base.LineEdit.Prompt})(::Base.LineEdit.MIState,
>  
> ::Base.AbstractIOBuffer{Array{UInt8,1}}, ::Bool) at .\REPL.jl:652
>  in run_interface(::Base.Terminals.TTYTerminal, 
> ::Base.LineEdit.ModalInterface) at .\LineEdit.jl:1579
>  in run_frontend(::Base.REPL.LineEditREPL, ::Base.REPL.REPLBackendRef) at 
> .\REPL.jl:903
>  in run_repl(::Base.REPL.LineEditREPL, ::Base.##932#933) at .\REPL.jl:188
>  in _start() at .\client.jl:360
> while loading no file, in expression starting on line 0
> 1.000 
>
>
> will the deprecated usage be changed in the future?
>
> @jeffrey: if I remove the libflint-13 again the error is back...try it 
> yourself. BTW is the wget.exe stuff u wrote still advisable to do or what 
> other advantages do I get out of it?
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

To see your path, open the terminal and type: Path
move the file wget64.exe, now given the name wget.exe to one of the 
directories in your path.

and maybe this will take: start Julia
Pkg.rm("Nemo")
Pkg.rm("Nemo")
Pkg.update()
Pkg.add("Nemo")
quit()
start Julia
Pkg.build("Nemo")
# let it finish correctly or otherwise
quit()
start Julia
Pkg.build("Nemo")
quit()
start Julia
using Nemo
arbfield64 = ArbField(64)
a = arbfield64( 1 )

if not, remove all of the Nemo package directory
then Pkg.update() and repeat


On Thursday, October 27, 2016 at 1:51:31 PM UTC-4, digxx wrote:
>
>
>
> Am Donnerstag, 27. Oktober 2016 19:33:22 UTC+2 schrieb Jeffrey Sarnoff:
>>
>> libflint-13.dll appears to be a copy of libflint.dll with a different 
>> name and you can try copying libflint.dll to libflint-13.dll
>> The .git\ is not there because you have not tried to add then build Nemo 
>> with git becoming engaged, and that too is worthwhile doing.  
>> Double check that you have libgmp-16.dll and not some other version in 
>> that directory.
>>
>
> Well, how do I do that?
> I presume it's not just adding git to the Nemo directory ;)
>
>  
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

It may be helpful to download 
https://eternallybored.org/misc/wget/current/wget64.exe and copy it 
`wget.exe` then put that file somewhere in your Path (not in the Nemo 
subdirectories).



On Thursday, October 27, 2016 at 1:33:22 PM UTC-4, Jeffrey Sarnoff wrote:
>
> libflint-13.dll appears to be a copy of libflint.dll with a different name 
> and you can try copying libflint.dll to libflint-13.dll
> The .git\ is not there because you have not tried to add then build Nemo 
> with git becoming engaged, and that too is worthwhile doing.  
> Double check that you have libgmp-16.dll and not some other version in 
> that directory.
>
>
>
> On Thursday, October 27, 2016 at 12:57:57 PM UTC-4, digxx wrote:
>>
>> Actually:
>> libflint-13.dll  14,156 KB
>> is missing for me
>>
>> also is .git\
>> under Nemo
>>
>> Am Donnerstag, 27. Oktober 2016 18:32:48 UTC+2 schrieb Jeffrey Sarnoff:
>>>
>>> With 64-bit Win7, in my directory for Julia packages
>>>
>>> under Nemo:
>>> .git\
>>> benchmarks\
>>> deps\
>>> doc\
>>> local\
>>> src\
>>> test\
>>> .gitignore
>>> .travis.yml
>>> appveyor.yml
>>> LICENSE.md
>>> README.md
>>> REQUIRE
>>> todo.txt
>>> windows_build.txt
>>>
>>> in deps:
>>> antic\
>>> arb\
>>> flint2\
>>> build.jl
>>> mpfr-3.1.3.tar.bz2
>>> mpir-2.7.2.tar.bz2
>>> pari-2.7.4.tar.gz
>>> patch-alloc-2.7.4
>>>
>>>
>>> under local:
>>> lib\
>>>
>>> in lib:
>>> libarb.dll   22,350 KB
>>> libflint.dll 14,156 KB
>>> libflint-13.dll  14,156 KB
>>> libpari.dll   6,067 KB
>>> libgmp-16.dll   673 KB
>>> libmpfr-4.dll   451 KB
>>> libwinpthread-1.dll  84 KB
>>>
>>>
>>>
>>>
>>> Note that windows_build.txt is preset for 32-bit Windows;
>>> for 64-bit machines, windows_build.txt should be this:
>>>
>>> # start of file
>>> # For Windows 64
>>>
>>> wget http://mpir.org/mpir-2.7.2.tar.bz2
>>> tar -xvf mpir-2.7.2.tar.bz2
>>> cd mpir-2.7.2
>>> ./configure --enable-shared --disable-static --enable-gmpcompat 
>>> --build=core2-w64-mingw64 LDFLAGS=-static-libgcc ABI=64
>>> make -j
>>> cd ..
>>> wget http://www.mpfr.org/mpfr-current/mpfr-3.1.4.tar.bz2
>>> tar -xvf mpfr-3.1.4.tar.bz2
>>> cd mpfr-3.1.4
>>> ./configure --with-gmp-build=/home/User/mpir-2.7.2 --enable-shared 
>>> --disable-static
>>> make -j
>>> cd ..
>>> git clone https://github.com/wbhart/flint2
>>> https://github.com/wbhart/antic
>>> cd flint2
>>> ./configure --enable-shared --disable-static 
>>> --with-mpir=/home/user/mpir-2.7.2 --with-mpfr=/home/user/mpfr-3.1.4 
>>> --extensions=/home/user/antic
>>> # edit Makefile
>>> # in CLFAGS replace -ansi -pedantic with -std=c99
>>> # add -mtune=core2 -march=core2 to CFLAGS
>>> # add -I/home/User/flint2 to INCS
>>> # ensure EXTRA_SHARED_FLAGS contains -static-libgcc -shared 
>>> -Wl,--export-all-symbols
>>> make -j
>>> cd ..
>>> wget http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.7.6.tar.gz
>>> tar -xvf pari-2.7.6.tar.gz
>>> cd pari-2.7.6
>>> export PATH=/home/user/mpir-2.7.2/.libs:$PATH
>>> LDFLAGS=-static-libgcc CFLAGS="-mtune=core2 -march=core2" ./Configure 
>>> --with-gmp-include=/home/user/mpir-2.7.2 
>>> --with-gmp-lib=/home/user/mpir-2.7.2/.libs --host=x86_64-pc-mingw
>>> cd Omingw-x86_64-pc
>>> make gp
>>> cd ../..
>>>
>>> # For Windows 32:
>>>
>>> # replace x86_64 with i686 throughout
>>> # replace ABI=64 with ABI=32
>>>
>>> # end of file
>>>
>>>
>>> On Wednesday, October 26, 2016 at 8:09:33 PM UTC-4, Bill Hart wrote:
>>>>
>>>> Actually, there is one more thing you could do. Download 
>>>> DependencyWalker [1] and run it on libarb.dll in place where it currently 
>>>> is in your Nemo/local/lib directory. It's bound to complain a lot, and 
>>>> there will be lots of yellow flags. But what we are looking for is missing 
>>>> dependencies that we are responsible for.
>>>>
>>>> Bill.
>>>>
>>>> [1] http://www.dependencywalker.com/
>>>>
>>>>
>>>> On 27 October 2016 at 02:04, Bill Hart <goodwi...@googlemail.com> 
>>>> wrote:
>>>>
>>>>> The only thing I can think of to suggest is try it again from scratch 
>>>>> in Julia-0.4 so we can rule out the dlls being corrupted on our website 
>>>>> somehow.
>>>>>
>>>>> I can't think what else could be wrong, unless something else changed 
>>>>> in Julia itself on Windows, between versions 0.4 and 0.5.
>>>>>
>>>>> Jeffrey, are you using 64 bit Windows with Julia 0.5?
>>>>>
>>>>> Bill.
>>>>>
>>>>> On 26 October 2016 at 23:02, digxx <diger...@hotmail.com> wrote:
>>>>>
>>>>>> It's weird coz in julia 0.4.x it was running without any problems...
>>>>>>
>>>>>
>>>>>
>>>>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

libflint-13.dll appears to be a copy of libflint.dll with a different name 
and you can try copying libflint.dll to libflint-13.dll
The .git\ is not there because you have not tried to add then build Nemo 
with git becoming engaged, and that too is worthwhile doing.  
Double check that you have libgmp-16.dll and not some other version in that 
directory.



On Thursday, October 27, 2016 at 12:57:57 PM UTC-4, digxx wrote:
>
> Actually:
> libflint-13.dll  14,156 KB
> is missing for me
>
> also is .git\
> under Nemo
>
> Am Donnerstag, 27. Oktober 2016 18:32:48 UTC+2 schrieb Jeffrey Sarnoff:
>>
>> With 64-bit Win7, in my directory for Julia packages
>>
>> under Nemo:
>> .git\
>> benchmarks\
>> deps\
>> doc\
>> local\
>> src\
>> test\
>> .gitignore
>> .travis.yml
>> appveyor.yml
>> LICENSE.md
>> README.md
>> REQUIRE
>> todo.txt
>> windows_build.txt
>>
>> in deps:
>> antic\
>> arb\
>> flint2\
>> build.jl
>> mpfr-3.1.3.tar.bz2
>> mpir-2.7.2.tar.bz2
>> pari-2.7.4.tar.gz
>> patch-alloc-2.7.4
>>
>>
>> under local:
>> lib\
>>
>> in lib:
>> libarb.dll   22,350 KB
>> libflint.dll 14,156 KB
>> libflint-13.dll  14,156 KB
>> libpari.dll   6,067 KB
>> libgmp-16.dll   673 KB
>> libmpfr-4.dll   451 KB
>> libwinpthread-1.dll  84 KB
>>
>>
>>
>>
>> Note that windows_build.txt is preset for 32-bit Windows;
>> for 64-bit machines, windows_build.txt should be this:
>>
>> # start of file
>> # For Windows 64
>>
>> wget http://mpir.org/mpir-2.7.2.tar.bz2
>> tar -xvf mpir-2.7.2.tar.bz2
>> cd mpir-2.7.2
>> ./configure --enable-shared --disable-static --enable-gmpcompat 
>> --build=core2-w64-mingw64 LDFLAGS=-static-libgcc ABI=64
>> make -j
>> cd ..
>> wget http://www.mpfr.org/mpfr-current/mpfr-3.1.4.tar.bz2
>> tar -xvf mpfr-3.1.4.tar.bz2
>> cd mpfr-3.1.4
>> ./configure --with-gmp-build=/home/User/mpir-2.7.2 --enable-shared 
>> --disable-static
>> make -j
>> cd ..
>> git clone https://github.com/wbhart/flint2
>> https://github.com/wbhart/antic
>> cd flint2
>> ./configure --enable-shared --disable-static 
>> --with-mpir=/home/user/mpir-2.7.2 --with-mpfr=/home/user/mpfr-3.1.4 
>> --extensions=/home/user/antic
>> # edit Makefile
>> # in CLFAGS replace -ansi -pedantic with -std=c99
>> # add -mtune=core2 -march=core2 to CFLAGS
>> # add -I/home/User/flint2 to INCS
>> # ensure EXTRA_SHARED_FLAGS contains -static-libgcc -shared 
>> -Wl,--export-all-symbols
>> make -j
>> cd ..
>> wget http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.7.6.tar.gz
>> tar -xvf pari-2.7.6.tar.gz
>> cd pari-2.7.6
>> export PATH=/home/user/mpir-2.7.2/.libs:$PATH
>> LDFLAGS=-static-libgcc CFLAGS="-mtune=core2 -march=core2" ./Configure 
>> --with-gmp-include=/home/user/mpir-2.7.2 
>> --with-gmp-lib=/home/user/mpir-2.7.2/.libs --host=x86_64-pc-mingw
>> cd Omingw-x86_64-pc
>> make gp
>> cd ../..
>>
>> # For Windows 32:
>>
>> # replace x86_64 with i686 throughout
>> # replace ABI=64 with ABI=32
>>
>> # end of file
>>
>>
>> On Wednesday, October 26, 2016 at 8:09:33 PM UTC-4, Bill Hart wrote:
>>>
>>> Actually, there is one more thing you could do. Download 
>>> DependencyWalker [1] and run it on libarb.dll in place where it currently 
>>> is in your Nemo/local/lib directory. It's bound to complain a lot, and 
>>> there will be lots of yellow flags. But what we are looking for is missing 
>>> dependencies that we are responsible for.
>>>
>>> Bill.
>>>
>>> [1] http://www.dependencywalker.com/
>>>
>>>
>>> On 27 October 2016 at 02:04, Bill Hart <goodwi...@googlemail.com> wrote:
>>>
>>>> The only thing I can think of to suggest is try it again from scratch 
>>>> in Julia-0.4 so we can rule out the dlls being corrupted on our website 
>>>> somehow.
>>>>
>>>> I can't think what else could be wrong, unless something else changed 
>>>> in Julia itself on Windows, between versions 0.4 and 0.5.
>>>>
>>>> Jeffrey, are you using 64 bit Windows with Julia 0.5?
>>>>
>>>> Bill.
>>>>
>>>> On 26 October 2016 at 23:02, digxx <diger...@hotmail.com> wrote:
>>>>
>>>>> It's weird coz in julia 0.4.x it was running without any problems...
>>>>>
>>>>
>>>>
>>>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

With 64-bit Win7, in my directory for Julia packages

under Nemo:
.git\
benchmarks\
deps\
doc\
local\
src\
test\
.gitignore
.travis.yml
appveyor.yml
LICENSE.md
README.md
REQUIRE
todo.txt
windows_build.txt

in deps:
antic\
arb\
flint2\
build.jl
mpfr-3.1.3.tar.bz2
mpir-2.7.2.tar.bz2
pari-2.7.4.tar.gz
patch-alloc-2.7.4


under local:
lib\

in lib:
libarb.dll   22,350 KB
libflint.dll 14,156 KB
libflint-13.dll  14,156 KB
libpari.dll   6,067 KB
libgmp-16.dll   673 KB
libmpfr-4.dll   451 KB
libwinpthread-1.dll  84 KB




Note that windows_build.txt is preset for 32-bit Windows;
for 64-bit machines, windows_build.txt should be this:

# start of file
# For Windows 64

wget http://mpir.org/mpir-2.7.2.tar.bz2
tar -xvf mpir-2.7.2.tar.bz2
cd mpir-2.7.2
./configure --enable-shared --disable-static --enable-gmpcompat 
--build=core2-w64-mingw64 LDFLAGS=-static-libgcc ABI=64
make -j
cd ..
wget http://www.mpfr.org/mpfr-current/mpfr-3.1.4.tar.bz2
tar -xvf mpfr-3.1.4.tar.bz2
cd mpfr-3.1.4
./configure --with-gmp-build=/home/User/mpir-2.7.2 --enable-shared 
--disable-static
make -j
cd ..
git clone https://github.com/wbhart/flint2
https://github.com/wbhart/antic
cd flint2
./configure --enable-shared --disable-static 
--with-mpir=/home/user/mpir-2.7.2 --with-mpfr=/home/user/mpfr-3.1.4 
--extensions=/home/user/antic
# edit Makefile
# in CLFAGS replace -ansi -pedantic with -std=c99
# add -mtune=core2 -march=core2 to CFLAGS
# add -I/home/User/flint2 to INCS
# ensure EXTRA_SHARED_FLAGS contains -static-libgcc -shared 
-Wl,--export-all-symbols
make -j
cd ..
wget http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.7.6.tar.gz
tar -xvf pari-2.7.6.tar.gz
cd pari-2.7.6
export PATH=/home/user/mpir-2.7.2/.libs:$PATH
LDFLAGS=-static-libgcc CFLAGS="-mtune=core2 -march=core2" ./Configure 
--with-gmp-include=/home/user/mpir-2.7.2 
--with-gmp-lib=/home/user/mpir-2.7.2/.libs --host=x86_64-pc-mingw
cd Omingw-x86_64-pc
make gp
cd ../..

# For Windows 32:

# replace x86_64 with i686 throughout
# replace ABI=64 with ABI=32

# end of file


On Wednesday, October 26, 2016 at 8:09:33 PM UTC-4, Bill Hart wrote:
>
> Actually, there is one more thing you could do. Download DependencyWalker 
> [1] and run it on libarb.dll in place where it currently is in your 
> Nemo/local/lib directory. It's bound to complain a lot, and there will be 
> lots of yellow flags. But what we are looking for is missing dependencies 
> that we are responsible for.
>
> Bill.
>
> [1] http://www.dependencywalker.com/
>
>
> On 27 October 2016 at 02:04, Bill Hart  > wrote:
>
>> The only thing I can think of to suggest is try it again from scratch in 
>> Julia-0.4 so we can rule out the dlls being corrupted on our website 
>> somehow.
>>
>> I can't think what else could be wrong, unless something else changed in 
>> Julia itself on Windows, between versions 0.4 and 0.5.
>>
>> Jeffrey, are you using 64 bit Windows with Julia 0.5?
>>
>> Bill.
>>
>> On 26 October 2016 at 23:02, digxx  
>> wrote:
>>
>>> It's weird coz in julia 0.4.x it was running without any problems...
>>>
>>
>>
>

[julia-users] Re: promote_op seems flakey (in a pure context)

[Jeffrey Sarnoff]

Do you have a minimal example?

On Tuesday, October 25, 2016 at 8:26:46 PM UTC-4, Andy Ferris wrote:
>
> I seem to be getting non-deterministic behaviour from `promote_op`, e.g. 
> where the output of the function is different at the REPL, in a function 
> and in a generated function.
>
> Inside the function generator it sometimes works to give the correct 
> result and sometimes returns `Any`. I haven't seen it fail at the REPL, but 
> I'm getting test failures in StaticArrays master because of this.
>
> I'm not sure if this is one of those "not valid in a pure context" (i.e. 
> `@pure` or `@generated`) functions as it's implementation seems to involve 
> inference and `Generator`s and so on. Or maybe it's a bug and I should file 
> a report?
>
> Thanks for any feedback,
> Andy
>

[julia-users] Re: ANN: ParallelAccelerator v0.2 for Julia 0.5 released.

[Jeffrey Sarnoff]

With appreciation for Intel Labs' commitment, our thanks to the people who 
landed v0.2 of the ParallelAccelerator project.

On Wednesday, October 26, 2016 at 8:13:38 PM UTC-4, Todd Anderson wrote:
>
> Okay, METADATA with ParallelAccelerator verison 0.2 has been merged so if 
> you do a standard Pkg.add() or update() you should get the latest version.
>
> For native threads, please note that we've identified some issues with 
> reductions and stencils that have been fixed and we will shortly be 
> released in version 0.2.1.  I will post here again when that release takes 
> place.
>
> Again, please give it a try and report back with experiences or file bugs.
>
> thanks!
>
> Todd
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

Yes.

Jeffrey Sarnoff


> On Oct 26, 2016, at 8:04 PM, 'Bill Hart' via julia-users 
> <julia-users@googlegroups.com> wrote:
> 
> The only thing I can think of to suggest is try it again from scratch in 
> Julia-0.4 so we can rule out the dlls being corrupted on our website somehow.
> 
> I can't think what else could be wrong, unless something else changed in 
> Julia itself on Windows, between versions 0.4 and 0.5.
> 
> Jeffrey, are you using 64 bit Windows with Julia 0.5?
> 
> Bill.
> 
>> On 26 October 2016 at 23:02, digxx <diger_d...@hotmail.com> wrote:
>> It's weird coz in julia 0.4.x it was running without any problems...
> 

[julia-users] One more effort

[Jeffrey Sarnoff]

I can compare my dirs and dll names with yours and we can replay the cold 
startup -- tomorrow.  I am away.

Jeffrey Sarnoff

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

you commented out too much -- try the other way
uncomment the Nemo build file and remove the old git-bash and install the
new git -- etc.


On Wed, Oct 26, 2016 at 3:17 PM, digxx  wrote:

>
>
> Am Mittwoch, 26. Oktober 2016 20:51:48 UTC+2 schrieb Bill Hart:
>>
>> I mean as an environment variable, specifically PATH. Alternatively you
>> can just remove the lines from Nemo/deps/build.jl that run git. The source
>> code is not needed on Windows. We only download it for you to keep in the
>> spirit of the LGPL license, i.e. to supply you the source code for the
>> software you are using.
>>
>> Bill.
>>
>
> Hey,
> So I just removed the lines:
>
> #=
> try
>   run(`git clone https://github.com/wbhart/antic.git`
> )
> catch
>   cd(joinpath("$wdir", "antic"))
>   run(`git pull`)
> end
>
> cd(wdir)
>
> # install FLINT
> try
>   run(`git clone https://github.com/wbhart/flint2.git`
> )
> catch
>   cd(joinpath("$wdir", "flint2"))
>   run(`git pull`)
> end
> =#
>
> #=
> try
>   run(`git clone https://github.com/fredrik-johansson/arb.git`
> )
> catch
>   cd(joinpath("$wdir", "arb"))
>   run(`git pull`)
>   cd(wdir)
> end
> =#
>
> So u mean these are not needed for the installation of Nemo on windows???
> But the last one runs some arb sth...Dont I need it?
> The building works now and I can run Nemo but I ask about the arb sth bcoz
> now on the new Julia version I again get the error:
>
> julia> using Nemo
>
> Welcome to Nemo version 0.5.1
>
> Nemo comes with absolutely no warranty whatsoever
>
>
> julia> r=ArbField(64)
> Real Field with 64 bits of precision and error bounds
>
> julia> r(1)
> ERROR: error compiling ArbField: error compiling Type: could not load
> library "libarb"
> t
>
>

[julia-users] Re: How do the file name / module name mapping rules work?

[Jeffrey Sarnoff]

A cleaner tack, for the moment is follow this general approach

package name: MyPackagedModule.jl  
package content on github  

repositiory: https://github.com//MyPackagedModule.jl  

files/directories  
at the top level of the repository the files  
LICENSE  
README.md  

at the top level of the repository the directories  
`src`  
`test`  


in `test`, a file named runtests.jl with the lines:   
using Base.test  
using MyPackagedModule  
# and eventually some actual tests  

in `src`, a file with the same name as the package:  
MyPackagedModule.jl  

that looks like this:  

```julia
module MyPackagedModule

# possibly
# capabilities you need to use or you need to specialize for your use
import Base: *function_name, function_name *

# and make what you create available outside of the package's inside
export MyPackgedType, MyPackagedFunction

# include your code, software that exists in separate files
# keeping this source file clean and neat
include("mytype,jl")
include("myfunction.jl")
# or better yet, but them in a subdirectory of `src`
# if that subdirectory is named `implementation`
include("implemention/mytype,jl")
include("implementation/myfunction.jl")


end # module MyPackagedModule
```

On Wednesday, October 26, 2016 at 1:44:34 PM UTC-4, ma...@maasha.dk wrote:
>
> Using the example package https://github.com/JuliaLang/Example.jl/ I am 
> wondering:
>
>
> the root level name ~/Example.jl is case-insensitive and the .jl suffix 
> is optional i.e. if I rename ~/Example.jl to ~/example it still works.
>
>
> Changing ~/Example.jl to ~/fobar and it breaks.
>
>
> However, ~/Example.jl/src/Example.jl is not case-insensitive and the .jl 
> suffix 
> is mandatory ...
>
>
> And how is the source tree searched? - the docs are a bit patchy ...
>
>
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

Your question is not at all silly.  Forget about the gitbash installation 
-- *remove it*.   
Download the new git installer from : this web page 
 and when it has downloaded, run it.
Then open a terminal window and type `git --version`.  If you see something 
meaningful, try rebuilding Nemo.  
Otherwise, add the location of git.exe to your path. (if you need help with 
that, ask).
And let us know what happens.

On Wednesday, October 26, 2016 at 2:40:48 PM UTC-4, digxx wrote:
>
> I do have Gitbash installed for some reason, but I never used it and it's 
> in c:\programs
> Sorry for that stupid question but u mean put the folder with git-cmd.exe 
> or git-bash.exe as an environment variable
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

Get git here: download git installer for windows 
<https://git-scm.com/download/win>

On Wednesday, October 26, 2016 at 3:23:36 AM UTC-4, Bill Hart wrote:
>
> This is probably because Git is not in your path. We still haven't 
> switched to libgit, which means the build script for Nemo still relies on 
> Git being available on your machine.
>
> Bill.
>
> On 26 October 2016 at 01:43, Jeffrey Sarnoff <jeffrey...@gmail.com 
> > wrote:
>
>> send me all the messages output, please
>>
>> On Tue, Oct 25, 2016 at 7:41 PM, Jeffrey Sarnoff <jeffrey...@gmail.com 
>> > wrote:
>>
>>> What happens if you restart that Julia from the windows menu (if that 
>>> does not launch cygwin terminal)
>>> and  do >Pkg.build("Nemo") again?
>>>
>>> On Tue, Oct 25, 2016 at 7:37 PM, digxx <diger...@hotmail.com 
>>> > wrote:
>>>
>>>> Sry but I followed precisely ur steps i.e.:
>>>> I installed a completely new version in D:\Julia\Julia-0.5.0 and added 
>>>> an environment variable JULIA_PKGDIR within D:\Julia because I didn't like 
>>>> the default one.
>>>> I then initialized by Pkg.init()
>>>> I ran Pkg.update()  (prob not needed here coz its new)
>>>> I ran: Pkg.clone("https://github.com/Nemocas/Nemo.jl;)
>>>> I exitted and restarted julia
>>>> I ran: Pkg.build("Nemo") and stumbled across:
>>>>
>>>> julia> Pkg.build("Nemo")
>>>> INFO: Building Nemo
>>>> WARNING: `@windows` is deprecated, use `@static is_windows()` instead
>>>>  in depwarn(::String, ::Symbol) at .\deprecated.jl:64
>>>>  in @windows(::Any, ::Any) at .\deprecated.jl:472
>>>>  in include_from_node1(::String) at .\loading.jl:488
>>>>  in evalfile(::String, ::Array{String,1}) at .\loading.jl:504 (repeats 
>>>> 2 times)
>>>>  in cd(::##2#4, ::String) at .\file.jl:48
>>>>  in (::##1#3)(::IOStream) at .\none:13
>>>>  in open(::##1#3, ::String, ::String) at .\iostream.jl:113
>>>>  in eval(::Module, ::Any) at .\boot.jl:234
>>>>  in process_options(::Base.JLOptions) at .\client.jl:239
>>>>  in _start() at .\client.jl:318
>>>> while loading D:\Julia\v0.5\Nemo\deps\build.jl, in expression starting 
>>>> on line 1
>>>> ===[
>>>>  
>>>> ERROR: Nemo 
>>>> ]===
>>>>
>>>> LoadError: chdir D:\Julia\v0.5\Nemo\deps\antic: no such file or 
>>>> directory (ENOENT)
>>>> while loading D:\Julia\v0.5\Nemo\deps\build.jl, in expression starting 
>>>> on line 121
>>>>
>>>>
>>>> =
>>>>
>>>> ==[
>>>>  
>>>> BUILD ERRORS 
>>>> ]===
>>>>
>>>> WARNING: Nemo had build errors.
>>>>
>>>>  - packages with build errors remain installed in D:\Julia\v0.5
>>>>  - build the package(s) and all dependencies with `Pkg.build("Nemo")`
>>>>  - build a single package by running its `deps/build.jl` script
>>>>
>>>>
>>>> =
>>>>
>>>>
>>>
>>
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

send me all the messages output, please

On Tue, Oct 25, 2016 at 7:41 PM, Jeffrey Sarnoff <jeffrey.sarn...@gmail.com>
wrote:

> What happens if you restart that Julia from the windows menu (if that does
> not launch cygwin terminal)
> and  do >Pkg.build("Nemo") again?
>
> On Tue, Oct 25, 2016 at 7:37 PM, digxx <diger_d...@hotmail.com> wrote:
>
>> Sry but I followed precisely ur steps i.e.:
>> I installed a completely new version in D:\Julia\Julia-0.5.0 and added an
>> environment variable JULIA_PKGDIR within D:\Julia because I didn't like the
>> default one.
>> I then initialized by Pkg.init()
>> I ran Pkg.update()  (prob not needed here coz its new)
>> I ran: Pkg.clone("https://github.com/Nemocas/Nemo.jl;)
>> I exitted and restarted julia
>> I ran: Pkg.build("Nemo") and stumbled across:
>>
>> julia> Pkg.build("Nemo")
>> INFO: Building Nemo
>> WARNING: `@windows` is deprecated, use `@static is_windows()` instead
>>  in depwarn(::String, ::Symbol) at .\deprecated.jl:64
>>  in @windows(::Any, ::Any) at .\deprecated.jl:472
>>  in include_from_node1(::String) at .\loading.jl:488
>>  in evalfile(::String, ::Array{String,1}) at .\loading.jl:504 (repeats 2
>> times)
>>  in cd(::##2#4, ::String) at .\file.jl:48
>>  in (::##1#3)(::IOStream) at .\none:13
>>  in open(::##1#3, ::String, ::String) at .\iostream.jl:113
>>  in eval(::Module, ::Any) at .\boot.jl:234
>>  in process_options(::Base.JLOptions) at .\client.jl:239
>>  in _start() at .\client.jl:318
>> while loading D:\Julia\v0.5\Nemo\deps\build.jl, in expression starting
>> on line 1
>> 
>> ===[ ERROR: Nemo
>> ]===
>> 
>>
>> LoadError: chdir D:\Julia\v0.5\Nemo\deps\antic: no such file or directory
>> (ENOENT)
>> while loading D:\Julia\v0.5\Nemo\deps\build.jl, in expression starting
>> on line 121
>>
>> 
>> 
>> 
>> =
>>
>> 
>> ==[ BUILD ERRORS
>> ]===
>> 
>>
>> WARNING: Nemo had build errors.
>>
>>  - packages with build errors remain installed in D:\Julia\v0.5
>>  - build the package(s) and all dependencies with `Pkg.build("Nemo")`
>>  - build a single package by running its `deps/build.jl` script
>>
>> 
>> 
>> 
>> =
>>
>>
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

What happens if you restart that Julia from the windows menu (if that does
not launch cygwin terminal)
and  do >Pkg.build("Nemo") again?

On Tue, Oct 25, 2016 at 7:37 PM, digxx  wrote:

> Sry but I followed precisely ur steps i.e.:
> I installed a completely new version in D:\Julia\Julia-0.5.0 and added an
> environment variable JULIA_PKGDIR within D:\Julia because I didn't like the
> default one.
> I then initialized by Pkg.init()
> I ran Pkg.update()  (prob not needed here coz its new)
> I ran: Pkg.clone("https://github.com/Nemocas/Nemo.jl;)
> I exitted and restarted julia
> I ran: Pkg.build("Nemo") and stumbled across:
>
> julia> Pkg.build("Nemo")
> INFO: Building Nemo
> WARNING: `@windows` is deprecated, use `@static is_windows()` instead
>  in depwarn(::String, ::Symbol) at .\deprecated.jl:64
>  in @windows(::Any, ::Any) at .\deprecated.jl:472
>  in include_from_node1(::String) at .\loading.jl:488
>  in evalfile(::String, ::Array{String,1}) at .\loading.jl:504 (repeats 2
> times)
>  in cd(::##2#4, ::String) at .\file.jl:48
>  in (::##1#3)(::IOStream) at .\none:13
>  in open(::##1#3, ::String, ::String) at .\iostream.jl:113
>  in eval(::Module, ::Any) at .\boot.jl:234
>  in process_options(::Base.JLOptions) at .\client.jl:239
>  in _start() at .\client.jl:318
> while loading D:\Julia\v0.5\Nemo\deps\build.jl, in expression starting on
> line 1
> 
> ===[ ERROR: Nemo
> ]===
> 
>
> LoadError: chdir D:\Julia\v0.5\Nemo\deps\antic: no such file or directory
> (ENOENT)
> while loading D:\Julia\v0.5\Nemo\deps\build.jl, in expression starting on
> line 121
>
> 
> 
> 
> =
>
> 
> ==[ BUILD ERRORS
> ]===
> 
>
> WARNING: Nemo had build errors.
>
>  - packages with build errors remain installed in D:\Julia\v0.5
>  - build the package(s) and all dependencies with `Pkg.build("Nemo")`
>  - build a single package by running its `deps/build.jl` script
>
> 
> 
> 
> =
>
>

[julia-users] ANN: best practices choosing and using names

[Jeffrey Sarnoff]

from the introduction:

It is easier to understand what `facial_recognition` does than it is to 
> understand what `facer` does.  

These brief guides collect information on best practices and sound 
> approaches using names with Julia.

   

The material is available here .

[julia-users] ANN: best practices choosing and using names

[Jeffrey Sarnoff]

from the introduction:

It is easier to understand what `facial_recognition` does than it is to 
> understand what `facer` does.  

These brief guides collect information on best practices and sound 
> approaches using names with Julia.

   

The material is available [here](https://github.com/JuliaPraxis/Naming).

[julia-users] Re: Comprehension (generator) with statement IF and the number of true

[Jeffrey Sarnoff]

this change saves some space: `count_zeros = length( find(x->x==0.0, 
actuals) )`


On Tuesday, October 25, 2016 at 4:48:29 AM UTC-4, Jeffrey Sarnoff wrote:
>
> As given above, the time is in sum_reldiffs, the space is in the 
> count_zeros.
>
> On Tuesday, October 25, 2016 at 4:42:02 AM UTC-4, Jeffrey Sarnoff wrote:
>>
>> (you may like that visual noise if the code finds more than 1 year's use)
>> Which matters more to you saving time or saving space?
>>
>> On Tuesday, October 25, 2016 at 4:39:33 AM UTC-4, Martin Florek wrote:
>>>
>>> Thnaks, It is true, but when I apply @benchmark v3 is 6 times slower as 
>>> v1, also has a large allocation and I do not want it. For me speed is 
>>> important and v3 is not without visual noise, too. Any more thoughts?
>>>
>>> ben1 = @benchmark mapeBase_v1(a,f)
>>> BenchmarkTools.Trial: 
>>>   samples:  848
>>>   evals/sample: 1
>>>   time tolerance:   5.00%
>>>   memory tolerance: 1.00%
>>>   memory estimate:  32.00 bytes
>>>   allocs estimate:  1
>>>   minimum time: 4.35 ms (0.00% GC)
>>>   median time:  5.87 ms (0.00% GC)
>>>   mean time:5.89 ms (0.00% GC)
>>>   maximum time: 7.57 ms (0.00% GC)
>>>
>>> ben2 = @benchmark mapeBase_v3(a,f)
>>> BenchmarkTools.Trial: 
>>>   samples:  145
>>>   evals/sample: 1
>>>   time tolerance:   5.00%
>>>   memory tolerance: 1.00%
>>>   memory estimate:  977.03 kb
>>>   allocs estimate:  14
>>>   minimum time: 32.69 ms (0.00% GC)
>>>   median time:  33.91 ms (0.00% GC)
>>>   mean time:34.55 ms (0.10% GC)
>>>   maximum time: 49.03 ms (3.25% GC)
>>>
>>>
>>>
>>>
>>> On Tuesday, 25 October 2016 09:43:20 UTC+2, Jeffrey Sarnoff wrote:
>>>>
>>>> This may do what you want.
>>>>
>>>> function mapeBase_v3(actuals::Vector{Float64}, forecasts::Vector{Float64})
>>>> # actuals - actual target values
>>>> # forecasts - forecasts (model estimations)
>>>>
>>>>   sum_reldiffs = sumabs((x - y) / x for (x, y) in zip(actuals, forecasts) 
>>>> if x != 0.0)  # Generator
>>>>
>>>>   count_zeros = sum( map(x->(x==0.0), actuals) )
>>>>   count_nonzeros = length(actuals) - count_zeros
>>>>   sum_reldiffs, count_nonzeros
>>>> end
>>>>
>>>>
>>>>
>>>>
>>>> On Tuesday, October 25, 2016 at 3:15:54 AM UTC-4, Martin Florek wrote:
>>>>>
>>>>> Hi all,
>>>>> I'm new in Julia and I'm doing refactoring. I have the following 
>>>>> function:
>>>>>
>>>>> function mapeBase_v1(A::Vector{Float64}, F::Vector{Float64})
>>>>>   s = 0.0
>>>>>   count = 0
>>>>>   for i in 1:length(A)
>>>>> if(A[i] != 0.0)
>>>>>   s += abs( (A[i] - F[i]) / A[i])
>>>>>   count += 1
>>>>> end
>>>>>   end
>>>>>
>>>>>   s, count 
>>>>>
>>>>> end   
>>>>>
>>>>> I'm looking for a simpler variant which is as follows:
>>>>>
>>>>> function mapeBase_v2(A::Vector{Float64}, F::Vector{Float64})
>>>>> # A - actual target values
>>>>> # F - forecasts (model estimations)
>>>>>
>>>>>   s = sumabs((x - y) / x for (x, y) in zip(A, F) if x != 0) # Generator
>>>>>
>>>>>   count = length(A) # ???
>>>>>   s, countend
>>>>>
>>>>>
>>>>> However with this variant can not determine the number of non-zero 
>>>>> elements. I found option with length(A[A .!= 0.0]), but it has a large 
>>>>> allocation. Please, someone knows a solution with generator, or variant 
>>>>> v1 is very good choice?
>>>>>
>>>>>
>>>>> Thanks in advance,
>>>>> Martin
>>>>>
>>>>>

[julia-users] Re: parse Unicode string to Float64

[Jeffrey Sarnoff]

I got this log file:
Circuit: * C:\Users\Jeff\Documents\LTspiceXVII\examples\test.asc

Direct Newton iteration for .op point succeeded.

current: i(r1)=2.5


Date: Tue Oct 25 03:55:44 2016
Total elapsed time: 0.134 seconds.

tnom = 27
temp = 27
method = modified trap
totiter = 2091
traniter = 2088
tranpoints = 1045
accept = 1045
rejected = 0
matrix size = 2
fillins = 0
solver = Normal
Matrix Compiler1: 36 bytes object code size  0.0/0.0/[0.0]
Matrix Compiler2: off  [0.0]/0.1/0.1


Are you trying to get a vector of all the rhs names and all the lhs values? 
It is easier to help if you tell me the goal (in detail).

On Tuesday, October 25, 2016 at 3:31:43 AM UTC-4, Chris Stook wrote:
>
> The circuit file is test1.asc (
> https://github.com/cstook/LTspice.jl/blob/master/test/test1.asc).  You 
> should be able to open it with LTspice and run the simulation to produce 
> the log file.
>
> The log file is a human readable text file, which I am parsing to get the 
> measurements.  LTspiceIV used ASCII for the log file and everything was 
> fine.  You can look at the documentation for my module LTspice.jl (
> http://www.chrisstook.com/LTspice.jl/) to see what I'm trying to do.
>

[julia-users] Re: Comprehension (generator) with statement IF and the number of true

[Jeffrey Sarnoff]

This may do what you want.

function mapeBase_v3(actuals::Vector{Float64}, forecasts::Vector{Float64})
# actuals - actual target values
# forecasts - forecasts (model estimations)

  sum_reldiffs = sumabs((x - y) / x for (x, y) in zip(actuals, forecasts) if x 
!= 0.0)  # Generator

  count_zeros = sum( map(x->(x==0.0), actuals) )
  count_nonzeros = length(actuals) - count_zeros
  sum_reldiffs, count_nonzeros
end




On Tuesday, October 25, 2016 at 3:15:54 AM UTC-4, Martin Florek wrote:
>
> Hi all,
> I'm new in Julia and I'm doing refactoring. I have the following function:
>
> function mapeBase_v1(A::Vector{Float64}, F::Vector{Float64})
>   s = 0.0
>   count = 0
>   for i in 1:length(A)
> if(A[i] != 0.0)
>   s += abs( (A[i] - F[i]) / A[i])
>   count += 1
> end
>   end
>
>   s, count 
>
> end   
>
> I'm looking for a simpler variant which is as follows:
>
> function mapeBase_v2(A::Vector{Float64}, F::Vector{Float64})
> # A - actual target values
> # F - forecasts (model estimations)
>
>   s = sumabs((x - y) / x for (x, y) in zip(A, F) if x != 0) # Generator
>
>   count = length(A) # ???
>   s, countend
>
>
> However with this variant can not determine the number of non-zero elements. 
> I found option with length(A[A .!= 0.0]), but it has a large allocation. 
> Please, someone knows a solution with generator, or variant v1 is very good 
> choice?
>
>
> Thanks in advance,
> Martin
>
>

[julia-users] Re: parse Unicode string to Float64

[Jeffrey Sarnoff]

I downloaded that software, did you create that log file? If so, how?

It is likely that what is being stored in the log file is not a sequence of 
numbers in a vanilla format.  So parsing it as a sequence of strings is not 
going to work.

from their help:   

OK, that works for bitmaps, but can I get the data itself to an application 
> like Excel?
> There is an export utility(Waveform Menu: File=>Export) that allows data 
> to be exported to an ASCII file. There is also a 3rd party free utility 
> written by Helmut Sennewald. It is available from the independent users' 
> group http://groups.yahoo.com/group/LTspice. This utility allows various 
> forms of manipulation of the data including the ability to merge waveforms 
> from different simulation runs.



>
On Tuesday, October 25, 2016 at 3:08:23 AM UTC-4, Chris Stook wrote:
>
> The file (
> https://github.com/cstook/LTspice.jl/blob/LTspiceXVII_compat/test/test1.log) 
> is a .log file produced by LTspiceXVII (
> http://www.linear.com/designtools/software/).  I'm using regular 
> expressions to parse the file.  The code below shows the problem.
>
> io = open("test1.log","r")
> for line in readlines(io)
>   m = match(r".*",line)
>   print(line)
>   println(m)
> end
>
> Circuit: * C:\Users\Chris\.julia\v0.5\LTspice\test\test1.asc
> RegexMatch("C\0i\0r\0c\0u\0i\0t\0:\0 \0*\0 
> \0C\0:\0\\\0U\0s\0e\0r\0s\0\\\0C\0h\0r\0i\0s\0\\\0.\0j\0u\0l\0i\0a\0\\\0v\x000\0.\x005\0\\\0L\0T\0s\0p\0i\0c\0e\0\\\0t\0e\0s\0t\0\\\0t\0e\0s\0t\x001\0.\0a\0s\0c\0")
>
> RegexMatch("\0")
> Direct Newton iteration for .op point succeeded.
> RegexMatch("\0D\0i\0r\0e\0c\0t\0 \0N\0e\0w\0t\0o\0n\0 
> \0i\0t\0e\0r\0a\0t\0i\0o\0n\0 \0f\0o\0r\0 \0.\0o\0p\0 \0p\0o\0i\0n\0t\0 
> \0s\0u\0c\0c\0e\0e\0d\0e\0d\0.\0")
>
> RegexMatch("\0")
> current: i(r1)=2.5
> RegexMatch("\0c\0u\0r\0r\0e\0n\0t\0:\0 
> \0i\0(\0r\x001\0)\0=\x002\0.\x005\0")
>
> RegexMatch("\0")
>
> RegexMatch("\0")
> Date: Mon Oct 24 20:11:13 2016
> RegexMatch("\0D\0a\0t\0e\0:\0 \0M\0o\0n\0 \0O\0c\0t\0 \x002\x004\0 
> \x002\x000\0:\x001\x001\0:\x001\x003\0 \x002\x000\x001\x006\0")
> Total elapsed time: 0.024 seconds.
> RegexMatch("\0T\0o\0t\0a\0l\0 \0e\0l\0a\0p\0s\0e\0d\0 \0t\0i\0m\0e\0:\0 
> \x000\0.\x000\x002\x004\0 \0s\0e\0c\0o\0n\0d\0s\0.\0")
>
> RegexMatch("\0")
> tnom = 27
> RegexMatch("\0t\0n\0o\0m\0 \0=\0 \x002\x007\0")
> temp = 27
> RegexMatch("\0t\0e\0m\0p\0 \0=\0 \x002\x007\0")
> method = modified trap
> RegexMatch("\0m\0e\0t\0h\0o\0d\0 \0=\0 \0m\0o\0d\0i\0f\0i\0e\0d\0 
> \0t\0r\0a\0p\0")
> totiter = 2091
> RegexMatch("\0t\0o\0t\0i\0t\0e\0r\0 \0=\0 \x002\x000\09\x001\0")
> traniter = 2088
> RegexMatch("\0t\0r\0a\0n\0i\0t\0e\0r\0 \0=\0 \x002\x000\08\08\0")
> tranpoints = 1045
> RegexMatch("\0t\0r\0a\0n\0p\0o\0i\0n\0t\0s\0 \0=\0 \x001\x000\x004\x005\0")
> accept = 1045
> RegexMatch("\0a\0c\0c\0e\0p\0t\0 \0=\0 \x001\x000\x004\x005\0")
> rejected = 0
> RegexMatch("\0r\0e\0j\0e\0c\0t\0e\0d\0 \0=\0 \x000\0")
> matrix size = 2
> RegexMatch("\0m\0a\0t\0r\0i\0x\0 \0s\0i\0z\0e\0 \0=\0 \x002\0")
> fillins = 0
> RegexMatch("\0f\0i\0l\0l\0i\0n\0s\0 \0=\0 \x000\0")
> solver = Normal
> RegexMatch("\0s\0o\0l\0v\0e\0r\0 \0=\0 \0N\0o\0r\0m\0a\0l\0")
> Matrix Compiler1: off  [0.0]/0.0/0.0
> RegexMatch("\0M\0a\0t\0r\0i\0x\0 \0C\0o\0m\0p\0i\0l\0e\0r\x001\0:\0 
> \0o\0f\0f\0 \0 \0[\x000\0.\x000\0]\0/\x000\0.\x000\0/\x000\0.\x000\0")
> Matrix Compiler2: 96 bytes object code size  0.0/0.0/[0.0]
> RegexMatch("\0M\0a\0t\0r\0i\0x\0 \0C\0o\0m\0p\0i\0l\0e\0r\x002\0:\0 
> \09\x006\0 \0b\0y\0t\0e\0s\0 \0o\0b\0j\0e\0c\0t\0 \0c\0o\0d\0e\0 
> \0s\0i\0z\0e\0 \0 \x000\0.\x000\0/\x000\0.\x000\0/\0[\x000\0.\x000\0]\0")
>
> RegexMatch("\0")
>
> RegexMatch("\0")
> RegexMatch("\0")
>
>

[julia-users] Re: parse Unicode string to Float64

[Jeffrey Sarnoff]

This is rather odd, your character codes are control codes (0x02 STX, start 
of text; 0x05 ENQ, enquiry) and really do not belong in a numeric string.
Do all the entries use that pattern "\x002\anumber.\x005\bnumber"?  If so, 
and the intended number is anumber.bnumber, there would be a way.
What is the file extension on the input file, and do you know what program 
generated it?

On Tuesday, October 25, 2016 at 12:44:34 AM UTC-4, Chris Stook wrote:
>
> I'm trying to parse a text file which contains some floating point 
> numbers.  The number 2.5 is represented by the string "\x002\0.\x005\0". 
>  Parse will not convert this to a Float64.  Print works (prints "2.5") in 
> Atom and Jupyter, but not in the REPL.
>
> _
> _   _ _(_)_ |  A fresh approach to technical computing
> (_) | (_) (_)|  Documentation: http://docs.julialang.org
> _ _   _| |_  __ _   |  Type "?help" for help.
> | | | | | | |/ _` |  |
> | | |_| | | | (_| |  |  Version 0.5.0 (2016-09-19 18:14 UTC)
> _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
> |__/   |  x86_64-w64-mingw32
>
> julia> print("\x002\0.\x005\0")
> �2�.�5�
> julia> parse(Float64,"\x002\0.\x005\0")
> ERROR: ArgumentError: invalid number format "\x002\0.\x005\0" for Float64
> in parse(::Type{Float64}, ::String) at .\parse.jl:167
>
> julia>
>
> I am not familiar with Unicode.  Is the Unicode valid?  How should I 
> convert this to a Float?  I do not have control over the input file.
>
> Thanks,
> Chris
>
>

[julia-users] Re: Julia and the Tower of Babel

[Jeffrey Sarnoff]

Actually, all is good.  The current docs do not take a stand on the use of 
case following an acronym.  


On Monday, October 24, 2016 at 1:38:39 PM UTC-4, Jeffrey Sarnoff wrote:
>
> update on package names that begin with an acronym .. following much 
> discussion, the rule which a strong preponderance of participants favor:
>the acronym is to be uppercased and the following words camelcased, no 
> separator.
>so: CSSscripts, HTMLlinks, XMLparser.
>
> This does not match the current docs:
>  the acronym is to be uppercased and the second word is to be 
> capitalized, no separator.  
>  so: CSSScripts, HTMLLinks, XMLParser  
>
> The reasoning I found most persuasive is that the current docs' rule
> undermines Julia's developing reputation for expressive clarity. 
>
> On Friday, October 14, 2016 at 3:15:44 PM UTC-4, Jeffrey Sarnoff wrote:
>>
>> Just clarifying: For a two part package name that begins with an acronym 
>> and ends in a word   
>>   
>> the present guidance:   
>>  the acronym is to be uppercased and the second word is to be 
>> capitalized, no separator.  
>>  so: CSSScripts, HTMLLinks  
>>
>> the desired guidance (from 24hrs of feedback):   
>>  the acronym is to be titlecased and the second word is to be 
>> capitalized, no separator.   
>>  so: CssScripts, HtmlLinks
>>
>> What is behind the present guidance?
>>
>>
>> On Saturday, October 8, 2016 at 8:42:05 AM UTC-4, Jeffrey Sarnoff wrote:
>>>
>>> I have created a new Organization on github: *JuliaPraxis.*
>>> Everyone who has added to this thread will get an invitation to join, 
>>> and so contribute.
>>> I will set up the site and let you know how do include your wor(l)d 
>>> views.
>>>
>>> Anyone else is welcome to post to this thread, and I will send an 
>>> invitation.
>>>
>>>
>>>
>>> On Saturday, October 8, 2016 at 6:59:51 AM UTC-4, Chris Rackauckas wrote:
>>>>
>>>> Conventions would have to be arrived at before this is possible.
>>>>
>>>> On Saturday, October 8, 2016 at 3:39:55 AM UTC-7, Traktor Toni wrote:
>>>>>
>>>>> In my opinion the solutions to this are very clear, or would be:
>>>>>
>>>>> 1. make a mandatory linter for all julia code
>>>>> 2. julia IDEs should offer good intellisense
>>>>>
>>>>> Am Freitag, 7. Oktober 2016 17:35:46 UTC+2 schrieb Gabriel Gellner:
>>>>>>
>>>>>> Something that I have been noticing, as I convert more of my research 
>>>>>> code over to Julia, is how the super easy to use package manager (which 
>>>>>> I 
>>>>>> love), coupled with the talent base of the Julia community seems to have 
>>>>>> a 
>>>>>> detrimental effect on the API consistency of the many “micro” packages 
>>>>>> that 
>>>>>> cover what I would consider the de-facto standard library.
>>>>>>
>>>>>> What I mean is that whereas a commercial package like 
>>>>>> Matlab/Mathematica etc., being written under one large umbrella, will 
>>>>>> largely (clearly not always) choose consistent names for similar API 
>>>>>> keyword arguments, and have similar calling conventions for master 
>>>>>> function 
>>>>>> like tools (`optimize` versus `lbfgs`, etc), which I am starting to 
>>>>>> realize 
>>>>>> is one of the great selling points of these packages as an end user. I 
>>>>>> can 
>>>>>> usually guess what a keyword will be in Mathematica, whereas even after 
>>>>>> a 
>>>>>> year of using Julia almost exclusively I find I have to look at the 
>>>>>> documentation (or the source code depending on the documentation ...) to 
>>>>>> figure out the keyword names in many common packages.
>>>>>>
>>>>>> Similarly, in my experience with open source tools, due to the 
>>>>>> complexity of the package management, we get large “batteries included” 
>>>>>> distributions that cover a lot of the standard stuff for doing science, 
>>>>>> like python’s numpy + scipy combination. Whereas in Julia the equivalent 
>>>>>> of 
>>>>>> scipy is split over many, separately developed packages (Base, Optim.jl, 
>>>>>> NLopt.jl, Roots.jl, NLsolve.jl

[julia-users] Re: Trait for exactness of numbers

[Jeffrey Sarnoff]

for values, something like this may do:

function isexact(x)
if isa(x, Integer) || isa(x, Rational)
true
elseif isa(x, Complex)
isExact(x.re)
else
false
end
 end




On Monday, October 24, 2016 at 2:09:09 PM UTC-4, jw3126 wrote:
>
> A couple of times I was in a situation, where I had two algorithms solving 
> the same problem, one which was faster and one which was more numerically 
> stable. Now for some types of numbers (FloatingPoint, Complex{Float64}...) 
> numerical stability is important while for others it does not matter (e.g. 
> Integer, Complex{Int64}...) etc. 
> In such situations it would be handy to have a mechanism (a trait) which 
> decides whether a type is exact or prone to rounding.
> Maybe there is already such a thing somewhere?
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

and just run julia from the terminal, not cygwin

On Monday, October 24, 2016 at 4:08:26 PM UTC-4, Jeffrey Sarnoff wrote:
>
> It is not clear to me what the difference is in your install and what I 
> did.  I can do r=ArbField(64); r(1) .. there is a warning the first time, 
> but it works.
>
> If you want, go back to the new installation and do
> > Pkg.build("Nemo")
> then (a) show us what it says [everything]
> and then  try
> > r=ArbField(64)
> > r(1)
> and show us what it says [everything]
>
>
> On Monday, October 24, 2016 at 3:22:47 PM UTC-4, digxx wrote:
>>
>> Maybe to point out: the installation in the part where I tried to do it 
>> directly via the repl command window was in a completely new .julia path 
>> (to try it fresh from the beginning) with no influence of already existing 
>> stuff...
>>
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

It is not clear to me what the difference is in your install and what I 
did.  I can do r=ArbField(64); r(1) .. there is a warning the first time, 
but it works.

If you want, go back to the new installation and do
> Pkg.build("Nemo")
then (a) show us what it says [everything]
and then  try
> r=ArbField(64)
> r(1)
and show us what it says [everything]


On Monday, October 24, 2016 at 3:22:47 PM UTC-4, digxx wrote:
>
> Maybe to point out: the installation in the part where I tried to do it 
> directly via the repl command window was in a completely new .julia path 
> (to try it fresh from the beginning) with no influence of already existing 
> stuff...
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

Here are the usual Windows versions for 32-bit Windows 
<https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-win32.exe>
 and for 64-bit Windows 
<https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-win64.exe>

On Monday, October 24, 2016 at 2:23:24 PM UTC-4, Bill Hart wrote:
>
> We don't support Cygwin. The Nemo binaries are native Windows binaries.
>
> I was unaware there was a Cygwin version of Julia.
>
> Bill.
>
> On 24 October 2016 at 19:48, Jeffrey Sarnoff <jeffrey...@gmail.com 
> > wrote:
>
>> I tried this on windows, it worked:
>> delete the directory Nemo (found with Pkg.dir() subdir Nemo))
>> delete the corresponding directory METADATA/Nemo (Pkg.dir("METADATA") 
>> subdir Nemo)
>> and if they exist, .cache/Nemo, METADATA/.cache/Nemo
>> restart Julia, do Pkg.update()
>> > Pkg.clone("https://github.com/Nemocas/Nemo.jl;)
>> when its done, quit and restart Julia
>> > Pkg.build("Nemo")
>> when its done, restart Julia
>> > using Nemo
>> # a bunch of warnings, then Welcome to Nemo ...
>> restart Julia
>> > using  Nemo 
>> Welcome to Nemo ... (without the warnings)
>>
>>
>> On Monday, October 24, 2016 at 1:24:30 PM UTC-4, digxx wrote:
>>>
>>> Hey,
>>> Thx for ur reply. I tried both deleting all the files and run Pkg.build 
>>> again...
>>> It however did not work as are all the files present too :-(
>>> Julia in cygwin is correct...
>>>
>>
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

I tried this on windows, it worked:
delete the directory Nemo (found with Pkg.dir() subdir Nemo))
delete the corresponding directory METADATA/Nemo (Pkg.dir("METADATA") 
subdir Nemo)
and if they exist, .cache/Nemo, METADATA/.cache/Nemo
restart Julia, do Pkg.update()
> Pkg.clone("https://github.com/Nemocas/Nemo.jl;)
when its done, quit and restart Julia
> Pkg.build("Nemo")
when its done, restart Julia
> using Nemo
# a bunch of warnings, then Welcome to Nemo ...
restart Julia
> using  Nemo 
Welcome to Nemo ... (without the warnings)


On Monday, October 24, 2016 at 1:24:30 PM UTC-4, digxx wrote:
>
> Hey,
> Thx for ur reply. I tried both deleting all the files and run Pkg.build 
> again...
> It however did not work as are all the files present too :-(
> Julia in cygwin is correct...
>

[julia-users] Re: Julia and the Tower of Babel

[Jeffrey Sarnoff]

update on package names that begin with an acronym .. following much 
discussion, the rule which a strong preponderance of participants favor:
   the acronym is to be uppercased and the following words camelcased, no 
separator.
   so: CSSscripts, HTMLlinks, XMLparser.

This does not match the current docs:
 the acronym is to be uppercased and the second word is to be 
capitalized, no separator.  
 so: CSSScripts, HTMLLinks, XMLParser  

The reasoning I found most persuasive is that the current docs' rule
undermines Julia's developing reputation for expressive clarity. 

On Friday, October 14, 2016 at 3:15:44 PM UTC-4, Jeffrey Sarnoff wrote:
>
> Just clarifying: For a two part package name that begins with an acronym 
> and ends in a word   
>   
> the present guidance:   
>  the acronym is to be uppercased and the second word is to be 
> capitalized, no separator.  
>  so: CSSScripts, HTMLLinks  
>
> the desired guidance (from 24hrs of feedback):   
>  the acronym is to be titlecased and the second word is to be 
> capitalized, no separator.   
>  so: CssScripts, HtmlLinks
>
> What is behind the present guidance?
>
>
> On Saturday, October 8, 2016 at 8:42:05 AM UTC-4, Jeffrey Sarnoff wrote:
>>
>> I have created a new Organization on github: *JuliaPraxis.*
>> Everyone who has added to this thread will get an invitation to join, and 
>> so contribute.
>> I will set up the site and let you know how do include your wor(l)d views.
>>
>> Anyone else is welcome to post to this thread, and I will send an 
>> invitation.
>>
>>
>>
>> On Saturday, October 8, 2016 at 6:59:51 AM UTC-4, Chris Rackauckas wrote:
>>>
>>> Conventions would have to be arrived at before this is possible.
>>>
>>> On Saturday, October 8, 2016 at 3:39:55 AM UTC-7, Traktor Toni wrote:
>>>>
>>>> In my opinion the solutions to this are very clear, or would be:
>>>>
>>>> 1. make a mandatory linter for all julia code
>>>> 2. julia IDEs should offer good intellisense
>>>>
>>>> Am Freitag, 7. Oktober 2016 17:35:46 UTC+2 schrieb Gabriel Gellner:
>>>>>
>>>>> Something that I have been noticing, as I convert more of my research 
>>>>> code over to Julia, is how the super easy to use package manager (which I 
>>>>> love), coupled with the talent base of the Julia community seems to have 
>>>>> a 
>>>>> detrimental effect on the API consistency of the many “micro” packages 
>>>>> that 
>>>>> cover what I would consider the de-facto standard library.
>>>>>
>>>>> What I mean is that whereas a commercial package like 
>>>>> Matlab/Mathematica etc., being written under one large umbrella, will 
>>>>> largely (clearly not always) choose consistent names for similar API 
>>>>> keyword arguments, and have similar calling conventions for master 
>>>>> function 
>>>>> like tools (`optimize` versus `lbfgs`, etc), which I am starting to 
>>>>> realize 
>>>>> is one of the great selling points of these packages as an end user. I 
>>>>> can 
>>>>> usually guess what a keyword will be in Mathematica, whereas even after a 
>>>>> year of using Julia almost exclusively I find I have to look at the 
>>>>> documentation (or the source code depending on the documentation ...) to 
>>>>> figure out the keyword names in many common packages.
>>>>>
>>>>> Similarly, in my experience with open source tools, due to the 
>>>>> complexity of the package management, we get large “batteries included” 
>>>>> distributions that cover a lot of the standard stuff for doing science, 
>>>>> like python’s numpy + scipy combination. Whereas in Julia the equivalent 
>>>>> of 
>>>>> scipy is split over many, separately developed packages (Base, Optim.jl, 
>>>>> NLopt.jl, Roots.jl, NLsolve.jl, ODE.jl/DifferentialEquations.jl). Many of 
>>>>> these packages are stupid awesome, but they can have dramatically 
>>>>> different 
>>>>> naming conventions and calling behavior, for essential equivalent 
>>>>> behavior. 
>>>>> Recently I noticed that tolerances, for example, are named as `atol/rtol` 
>>>>> versus `abstol/reltol` versus `abs_tol/rel_tol`, which means is extremely 
>>>>> easy to have a piece of scientific code that will need to use all three 
>>>>> conve

[julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

I do not get that error.  Are you using the current versions of Julia nd 
Nemo?  You may see a warning message with the first use each session.

Here is a transcript:. Let me see yours, and  the output of versioninfo().


> using Nemo
> c = AcbField(64)
Complex Field with 64 bits of precision and error bounds

> c(1,1)
..warning...
1.000 + i*1.000
> c(1,1)
1.000 + i*1.000
> f = ArbField(64)
Real Field with 64 bits of precision and error bounds

julia> f(1)

1.000





On Tuesday, October 18, 2016 at 6:27:28 PM UTC-4, digxx wrote:
>
> Hey, Sorry but I also get this error when I write
>
> r=AcbField(64)
> r(1,1)
>
> Likewise
>
> r=ArbField(64)
> r(1) 
>
> gives me the same error...
>

[julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

The exported logic requires both the real and the imaginary parts  be given.

ComplexField = AcbField(64)
complexValue = ComplexField(1, 0)





On Monday, October 17, 2016 at 8:08:40 AM UTC-4, digxx wrote:
>
> push...

[julia-users] Re: What is really "big data" for Julia (or otherwise), 1D or multi-dimensional?

[Jeffrey Sarnoff]

One fact about big data is it keeps getting bigger.

On Friday, October 14, 2016 at 1:00:35 PM UTC-4, Páll Haraldsson wrote:
>
> On Thursday, October 13, 2016 at 7:49:51 PM UTC, cdm wrote:
>>
>> from CloudArray.jl:
>>
>> "If you are dealing with big data, i.e., your RAM memory is not enough 
>> to store your data, you can create a CloudArray from a file."
>>
>>
>> https://github.com/gsd-ufal/CloudArray.jl#creating-a-cloudarray-from-a-file
>>
>
> Good to know, and seems cool.. (like CatViews.jl) indexes could need to be 
> bigger than 32-bit this way.. even for 2D.
>
> But has anyone worked with more than 70 terabyte arrays, that would 
> otherwise have been a limitation?
>
> Anyone know biggest (or just big over 2 GB) one-dimensional array people 
> are working with?
>

[julia-users] gathering advice on types

[Jeffrey Sarnoff]

Do you have words of wisdom, style, technique, efficiency or pragmatism 
regarding types in any of their forms (concrete, abstract, aliased, bits 
and parameters).

We are gathering advice on types on gitter at JuliaPraxis 
.   

[julia-users] Re: redefining Base method for `show`

[Jeffrey Sarnoff]

module Rationality

abstract SymbolicMathematics

export SymbolicRational

import Base: STDOUT, string, show, Rational

type SymbolicRational <: SymbolicMathematics
num::Int128
den::Int128

SymbolicRational{I<:Signed}(num::I, den::I) = new(Int128(num), 
Int128(den))
SymbolicRational{I<:Signed}(q::Rational{I}) = SymbolicRational(q.num, 
q.den)
end

function string(x::SymbolicRational)
return string(x.num, "/", x.den)
end

function string{I}(x::Rational{I})
return string(x.num, "//", x.den)
end

function show(io::IO, x::SymbolicRational)
s = string(x)
print(io, s)
end
show(x::SymbolicRational) = show(STDOUT, x)

function show{I}(io::IO, x::Rational{I})
s = string(x)
print(io, s)
end
show{I}(x::Rational{I}) = show(STDOUT, x)

end # module Rationality


using Rationality

p = 3//5

q = SymbolicRational(p)

pstr = string(p);

qstr = string(q);

p_q = string(pstr, "   ", qstr)

println(p_q)

show([p, q])








On Friday, October 14, 2016 at 9:52:51 AM UTC-4, lapeyre@gmail.com 
wrote:
>
> I'm thinking of symbolic mathematics (Symata.jl). Another example is 
> `SymPy.jl`, which prints rationals the same way I want to, like this: 
> "2/3". But in SymPy.jl, rationals are not `Rational`'s, but rather wrapped 
> python objects, so the problem with printing does not arise. If I wrapped 
> `Rational`'s it would introduce a lot of complexity.
>
> So far, walking expression trees to wrap objects of certain types just 
> before printing seems to be working well.
>
> On Friday, October 14, 2016 at 4:23:27 AM UTC+2, Jeffrey Sarnoff wrote:
>>
>> I assume you meant x::T in type A{T}.  Why do you want to do this:
>>
>>> Every time a Rational or Symbol or Bool is encountered on any level, I 
>>> want it to print differently than Base.show does it.
>>>
>> Do you want to adorn it (like "3//5" -> "{3//5}") or alter it (like 
>> "3//5" -> "2//5")?
>>
>> Also, I think you are approaching solving your problem in way more suited 
>> to another language.  But I really have no idea what your motivation is.
>>
>> On Tuesday, October 11, 2016 at 7:21:35 PM UTC-4, lapeyre@gmail.com 
>> wrote:
>>>
>>> To make it concrete, I have
>>>
>>> type A{T}
>>>x
>>>a::Array{Any,1}
>>> end
>>>
>>> The elements of the array a are numbers, Symbols, strings, etc., as well 
>>> as more instances of type A{T}.  They
>>> may be nested to arbitrary depth. If I call show on an instance of A{T}, 
>>> then show will be called recursively
>>> on all parts of the tree. Every time a Rational or Symbol or Bool is 
>>> encountered on any level, I want it to print differently than Base.show 
>>> does it.
>>>
>>>
>>> On Tuesday, October 11, 2016 at 11:48:46 PM UTC+2, Jeffrey Sarnoff wrote:
>>>>
>>>> Are you saying  a and b and c and d?
>>>>
>>>> (a) that you have a outer type which has a Rational field and has 
>>>> another field of a type that has a field which is typed Rational or is 
>>>> typed e.g. Vector{Rational}   
>>>>
>>>> (b) and displaying a value of the outer type includes displaying the 
>>>> Rationals from withiin the field of the inner type
>>>>
>>>> (c) and when displaying that value, you want to present the outer 
>>>> type's Rational field a special way
>>>>
>>>> (d) and when displaying that value, you want to present the Rational 
>>>> fields of the inner type in the usual way
>>>>
>>>>
>>>> On Tuesday, October 11, 2016 at 1:23:37 PM UTC-4, lapeyre@gmail.com 
>>>> wrote:
>>>>>
>>>>> I think I understand what you are saying (not sure).  A problem that 
>>>>> arises is that if I call show or print on an object, then show or print 
>>>>> may 
>>>>> be called many times on fields and fields of fields, etc., including from 
>>>>> within Base code before the call returns. I don't know how to tell the 
>>>>> builtin julia code my preference for printing rationals. The only way I 
>>>>> know to get a redefinition of show eg M.show to work in all situations, 
>>>>> is 
>>>>> to copy all the code that might be called. Maybe I'm missing something, 
>>>>> but 
>>>>> I can't see a way around this.
>>>>>
>>>>> I'm not familiar with the idea of a fencing module.
>>>>>
&

[julia-users] Re: Julia and the Tower of Babel

[Jeffrey Sarnoff]

Just clarifying: For a two part package name that begins with an acronym 
and ends in a word   
  
the present guidance:   
 the acronym is to be uppercased and the second word is to be 
capitalized, no separator.  
 so: CSSScripts, HTMLLinks  

the desired guidance (from 24hrs of feedback):   
 the acronym is to be titlecased and the second word is to be 
capitalized, no separator.   
 so: CssScripts, HtmlLinks

What is behind the present guidance?


On Saturday, October 8, 2016 at 8:42:05 AM UTC-4, Jeffrey Sarnoff wrote:
>
> I have created a new Organization on github: *JuliaPraxis.*
> Everyone who has added to this thread will get an invitation to join, and 
> so contribute.
> I will set up the site and let you know how do include your wor(l)d views.
>
> Anyone else is welcome to post to this thread, and I will send an 
> invitation.
>
>
>
> On Saturday, October 8, 2016 at 6:59:51 AM UTC-4, Chris Rackauckas wrote:
>>
>> Conventions would have to be arrived at before this is possible.
>>
>> On Saturday, October 8, 2016 at 3:39:55 AM UTC-7, Traktor Toni wrote:
>>>
>>> In my opinion the solutions to this are very clear, or would be:
>>>
>>> 1. make a mandatory linter for all julia code
>>> 2. julia IDEs should offer good intellisense
>>>
>>> Am Freitag, 7. Oktober 2016 17:35:46 UTC+2 schrieb Gabriel Gellner:
>>>>
>>>> Something that I have been noticing, as I convert more of my research 
>>>> code over to Julia, is how the super easy to use package manager (which I 
>>>> love), coupled with the talent base of the Julia community seems to have a 
>>>> detrimental effect on the API consistency of the many “micro” packages 
>>>> that 
>>>> cover what I would consider the de-facto standard library.
>>>>
>>>> What I mean is that whereas a commercial package like 
>>>> Matlab/Mathematica etc., being written under one large umbrella, will 
>>>> largely (clearly not always) choose consistent names for similar API 
>>>> keyword arguments, and have similar calling conventions for master 
>>>> function 
>>>> like tools (`optimize` versus `lbfgs`, etc), which I am starting to 
>>>> realize 
>>>> is one of the great selling points of these packages as an end user. I can 
>>>> usually guess what a keyword will be in Mathematica, whereas even after a 
>>>> year of using Julia almost exclusively I find I have to look at the 
>>>> documentation (or the source code depending on the documentation ...) to 
>>>> figure out the keyword names in many common packages.
>>>>
>>>> Similarly, in my experience with open source tools, due to the 
>>>> complexity of the package management, we get large “batteries included” 
>>>> distributions that cover a lot of the standard stuff for doing science, 
>>>> like python’s numpy + scipy combination. Whereas in Julia the equivalent 
>>>> of 
>>>> scipy is split over many, separately developed packages (Base, Optim.jl, 
>>>> NLopt.jl, Roots.jl, NLsolve.jl, ODE.jl/DifferentialEquations.jl). Many of 
>>>> these packages are stupid awesome, but they can have dramatically 
>>>> different 
>>>> naming conventions and calling behavior, for essential equivalent 
>>>> behavior. 
>>>> Recently I noticed that tolerances, for example, are named as `atol/rtol` 
>>>> versus `abstol/reltol` versus `abs_tol/rel_tol`, which means is extremely 
>>>> easy to have a piece of scientific code that will need to use all three 
>>>> conventions across different calls to seemingly similar libraries. 
>>>>
>>>> Having brought this up I find that the community is largely sympathetic 
>>>> and, in general, would support a common convention, the issue I have 
>>>> slowly 
>>>> realized is that it is rarely that straightforward. In the above example 
>>>> the abstol/reltol versus abs_tol/rel_tol seems like an easy example of 
>>>> what 
>>>> can be tidied up, but the latter underscored name is consistent with 
>>>> similar naming conventions from Optim.jl for other tolerances, so that 
>>>> community is reluctant to change the convention. Similarly, I think there 
>>>> would be little interest in changing abstol/reltol to the underscored 
>>>> version in packages like Base, ODE.jl etc as this feels consistent with 
>>>> each of these code bases. Hence I have started to think that the problem 
>>>

Re: [julia-users] Re: Julia and the Tower of Babel

[Jeffrey Sarnoff]

first pass at naming guidelines https://github.com/JuliaPraxis/Naming

On Thursday, October 13, 2016 at 8:07:18 AM UTC-4, Páll Haraldsson wrote:
>
> On Sunday, October 9, 2016 at 9:59:12 AM UTC, Michael Borregaard wrote:
>>
>>
>> So when I came to julia I was struck by how structured the package 
>> ecosystem appears to be, yet, in spite of the micropackaging. [..] I think 
>> there are a number of reasons for this difference, but I also believe that 
>> a primary reason is the reliance on github for developing the package 
>> ecosystem from the bottom up, and the use of organizations.
>>
>
> Could be; my feeling is that Julia allows for better
>
> https://en.wikipedia.org/wiki/Separation_of_concerns [term "was probably 
> coined by Edsger W. Dijkstra 
>  in his 1974 paper "On 
> the role of scientific thought" "; synonym for "modularity"?]
>
> that other languages, OO (and information hiding) has been credited as 
> helping, but my feeling is that multiple dispatch is even better, for it.
>
>
> That is, leads to low:
>
> https://en.wikipedia.org/wiki/Coupling_(computer_programming)
> "Coupling is usually contrasted with cohesion. Low coupling 
>  often correlates with high 
> cohesion, and vice versa. Low coupling is often a sign of a well-structured 
> computer 
> system  and a good design"
>
>
> https://en.wikipedia.org/wiki/Cohesion_(computer_science)
>
> Now, as an outsider looking in, e.g. on:
>
> https://en.wikipedia.org/wiki/Automatic_differentiation
>
> There seems to be lots of redundant packages with e.g.
>
> https://github.com/denizyuret/AutoGrad.jl
>
>
> Maybe it's just my limited math skills showing, are there subtle 
> differences, explaining are requiring all these packages?
>
> Do you expect some/many packages to just die?
>
> One solution to many similar packages is a:
>
> https://en.wikipedia.org/wiki/Facade_pattern
>
> e.g. Plots.jl and then backends (you may care less about(?)).
>
>
> Not sure when you use all these similar (or complementary?) packages 
> together.. if it applies.
>
>
> In my other answer I misquoted (making clear original user's comment is 
> quoting
>
> Style Insensitive?
> https://github.com/nim-lang/Nim/issues/521
> >Nimrod is a style-insensitive language. This means that it is not 
> case-sensitive and even underscores are ignored: type is a reserved word, 
> and so is TYPE or T_Y_P_E. The idea behind this is that this allows 
> programmers to use their own preferred spelling style and libraries written 
> by different programmers cannot use incompatible conventions. [..]
>
> Please *rethink* about that or at least give us an option to disable 
> both: case insensitive and also underscore ignored
>
> [another user]:
>
> Also a consistent style for code bases is VASTLY overrated, in fact I 
> almost never had the luxury of it and yet it was never a problem."
>

[julia-users] Re: redefining Base method for `show`

[Jeffrey Sarnoff]

I assume you meant x::T in type A{T}.  Why do you want to do this:

> Every time a Rational or Symbol or Bool is encountered on any level, I 
> want it to print differently than Base.show does it.
>
Do you want to adorn it (like "3//5" -> "{3//5}") or alter it (like "3//5" 
-> "2//5")?

Also, I think you are approaching solving your problem in way more suited 
to another language.  But I really have no idea what your motivation is.

On Tuesday, October 11, 2016 at 7:21:35 PM UTC-4, lapeyre@gmail.com 
wrote:
>
> To make it concrete, I have
>
> type A{T}
>x
>a::Array{Any,1}
> end
>
> The elements of the array a are numbers, Symbols, strings, etc., as well 
> as more instances of type A{T}.  They
> may be nested to arbitrary depth. If I call show on an instance of A{T}, 
> then show will be called recursively
> on all parts of the tree. Every time a Rational or Symbol or Bool is 
> encountered on any level, I want it to print differently than Base.show 
> does it.
>
>
> On Tuesday, October 11, 2016 at 11:48:46 PM UTC+2, Jeffrey Sarnoff wrote:
>>
>> Are you saying  a and b and c and d?
>>
>> (a) that you have a outer type which has a Rational field and has another 
>> field of a type that has a field which is typed Rational or is typed e.g. 
>> Vector{Rational}   
>>
>> (b) and displaying a value of the outer type includes displaying the 
>> Rationals from withiin the field of the inner type
>>
>> (c) and when displaying that value, you want to present the outer type's 
>> Rational field a special way
>>
>> (d) and when displaying that value, you want to present the Rational 
>> fields of the inner type in the usual way
>>
>>
>> On Tuesday, October 11, 2016 at 1:23:37 PM UTC-4, lapeyre@gmail.com 
>> wrote:
>>>
>>> I think I understand what you are saying (not sure).  A problem that 
>>> arises is that if I call show or print on an object, then show or print may 
>>> be called many times on fields and fields of fields, etc., including from 
>>> within Base code before the call returns. I don't know how to tell the 
>>> builtin julia code my preference for printing rationals. The only way I 
>>> know to get a redefinition of show eg M.show to work in all situations, is 
>>> to copy all the code that might be called. Maybe I'm missing something, but 
>>> I can't see a way around this.
>>>
>>> I'm not familiar with the idea of a fencing module.
>>>
>>> On Monday, October 10, 2016 at 11:30:18 PM UTC+2, Jeffrey Sarnoff wrote:
>>>>
>>>> You could wrap your redefinitions in a module M without exporting show 
>>>> explicitly.   
>>>> `using M`  and accessing the your variation as `M.show` may give the 
>>>> localization you want.
>>>> Should it not, then doing that within some outer working context, a 
>>>> fencing module, may add enough flexibility.
>>>>
>>>>
>>>> On Monday, October 10, 2016 at 4:18:52 PM UTC-4, lapeyre@gmail.com 
>>>> wrote:
>>>>>
>>>>> For the record, a workable solution, at least for this particular 
>>>>> code: I pass all output through wrapout() at the outermost output call. 
>>>>> The 
>>>>> object to be printed is traversed recursively. All types fall through 
>>>>> except for the handful that I want to change. Each of these is each 
>>>>> wrapped 
>>>>> in a new type. I extend Base.show for each of these wrapper types. This 
>>>>> seems pretty economical and  robust and works across versions. The 
>>>>> wrapper 
>>>>> types are only introduced upon output, the rest of the code never sees 
>>>>> them.
>>>>>
>>>>> This works because the code uses a customization of the REPL, and 
>>>>> several instances of print, warn, string, etc. I make a new top-level 
>>>>> output function for the REPL that uses `wrapout`. I also  generate 
>>>>> wrappers 
>>>>> for each of print, etc. that map `wrapout` over all arguments. A 
>>>>> developer 
>>>>> is expected to use the interface provided rather than `print` etc. 
>>>>> directly.  The user doesn't even have a choice. There are very few types 
>>>>> in 
>>>>> the package, but a lot of nested instances. So there is very little code 
>>>>> needed to traverse these instances.  This might be more difficult in a 

Re: [julia-users] how to do push! on a fieldname?

[Jeffrey Sarnoff]

Jeff's approach should be included in the performance hints doc

On Tuesday, October 11, 2016 at 1:04:43 PM UTC-4, Jeff Bezanson wrote:
>
> If the performance of this matters, it will probably be faster to 
> iterate over `1:nfields(myt)`, as that will avoid (1) constructing the 
> array of symbols, (2) looking up the index within the type for that 
> field. 
>
> On Mon, Oct 10, 2016 at 7:20 PM, K leo  
> wrote: 
> > Thanks so much Mauro.  That does it. 
> > 
> > On Monday, October 10, 2016 at 10:58:30 PM UTC+8, Mauro wrote: 
> >> 
> >> Try 
> >> 
> >> for fl in fieldnames(myt) 
> >>push!(getfield(myt,fl), 0.) 
> >> end 
> >> 
> >> `fieldnames` returns the name of the field as a symbol, thus your 
> error. 
> >> 
> >> On Mon, 2016-10-10 at 16:41, K leo  wrote: 
> >> > I hope to expand all arrays in a type using something like the 
> >> > following: 
> >> > 
> >> > fields=fieldnames(myType) 
> >> >> for i=1:length(fields) 
> >> >> push!(fields[i], 0.) 
> >> >> end 
> >> > 
> >> > 
> >> > But I get error saying no method matching push!(::Symbol, ::Float64) 
> >> > 
> >> > What else can I do for my purpose? 
>

[julia-users] Re: redefining Base method for `show`

[Jeffrey Sarnoff]

Are you saying  a and b and c and d?

(a) that you have a outer type which has a Rational field and has another 
field of a type that has a field which is typed Rational or is typed e.g. 
Vector{Rational}   

(b) and displaying a value of the outer type includes displaying the 
Rationals from withiin the field of the inner type

(c) and when displaying that value, you want to present the outer type's 
Rational field a special way

(d) and when displaying that value, you want to present the Rational fields 
of the inner type in the usual way


On Tuesday, October 11, 2016 at 1:23:37 PM UTC-4, lapeyre@gmail.com 
wrote:
>
> I think I understand what you are saying (not sure).  A problem that 
> arises is that if I call show or print on an object, then show or print may 
> be called many times on fields and fields of fields, etc., including from 
> within Base code before the call returns. I don't know how to tell the 
> builtin julia code my preference for printing rationals. The only way I 
> know to get a redefinition of show eg M.show to work in all situations, is 
> to copy all the code that might be called. Maybe I'm missing something, but 
> I can't see a way around this.
>
> I'm not familiar with the idea of a fencing module.
>
> On Monday, October 10, 2016 at 11:30:18 PM UTC+2, Jeffrey Sarnoff wrote:
>>
>> You could wrap your redefinitions in a module M without exporting show 
>> explicitly.   
>> `using M`  and accessing the your variation as `M.show` may give the 
>> localization you want.
>> Should it not, then doing that within some outer working context, a 
>> fencing module, may add enough flexibility.
>>
>>
>> On Monday, October 10, 2016 at 4:18:52 PM UTC-4, lapeyre@gmail.com 
>> wrote:
>>>
>>> For the record, a workable solution, at least for this particular code: 
>>> I pass all output through wrapout() at the outermost output call. The 
>>> object to be printed is traversed recursively. All types fall through 
>>> except for the handful that I want to change. Each of these is each wrapped 
>>> in a new type. I extend Base.show for each of these wrapper types. This 
>>> seems pretty economical and  robust and works across versions. The wrapper 
>>> types are only introduced upon output, the rest of the code never sees them.
>>>
>>> This works because the code uses a customization of the REPL, and 
>>> several instances of print, warn, string, etc. I make a new top-level 
>>> output function for the REPL that uses `wrapout`. I also  generate wrappers 
>>> for each of print, etc. that map `wrapout` over all arguments. A developer 
>>> is expected to use the interface provided rather than `print` etc. 
>>> directly.  The user doesn't even have a choice. There are very few types in 
>>> the package, but a lot of nested instances. So there is very little code 
>>> needed to traverse these instances.  This might be more difficult in a 
>>> different situation if many methods for wrapout() were required.
>>>
>>> On Monday, October 10, 2016 at 12:20:50 AM UTC+2, lapeyre@gmail.com 
>>> wrote:
>>>>
>>>> I want to change show for Symbol, Rational, and Bool. Till now, I 
>>>> simply overwrote the existing methods. This works great. I get what I 
>>>> want, 
>>>> even in warn and error and string interpolation, etc. It works flawlessly 
>>>> on v0.4, v0.5, and v0.6. But, this changes the behavior for everyone. So, 
>>>> I 
>>>> want to get the same effect through different means that do not affect 
>>>> other code. Any idea about how to do this ?
>>>>
>>>> One solution is to copy a large amount of  base code that uses print, 
>>>> write, show, etc. renaming these functions. Other than changing 15 or 20 
>>>> lines for Symbol, etc., the code is unchanged. This is works more or less, 
>>>> but is obviously a fragile, bad solution.
>>>>
>>>> Another idea is to make a subtype of IO that wraps subtypes of IO. I am 
>>>> allowed to write methods for show for this new type. This is turning out 
>>>> to 
>>>> be complicated and unworkable.
>>>>
>>>> Another vague idea is to make a new mime type. Another is to copy 
>>>> IOStream as another type, so that I only have to write methods for Symbol, 
>>>> Rational and Bool again.
>>>>
>>>>  
>>>>
>>>

[julia-users] Re: redefining Base method for `show`

[Jeffrey Sarnoff]

You could wrap your redefinitions in a module M without exporting show 
explicitly.   
`using M`  and accessing the your variation as `M.show` may give the 
localization you want.
Should it not, then doing that within some outer working context, a fencing 
module, may add enough flexibility.


On Monday, October 10, 2016 at 4:18:52 PM UTC-4, lapeyre@gmail.com 
wrote:
>
> For the record, a workable solution, at least for this particular code: I 
> pass all output through wrapout() at the outermost output call. The object 
> to be printed is traversed recursively. All types fall through except for 
> the handful that I want to change. Each of these is each wrapped in a new 
> type. I extend Base.show for each of these wrapper types. This seems pretty 
> economical and  robust and works across versions. The wrapper types are 
> only introduced upon output, the rest of the code never sees them.
>
> This works because the code uses a customization of the REPL, and several 
> instances of print, warn, string, etc. I make a new top-level output 
> function for the REPL that uses `wrapout`. I also  generate wrappers for 
> each of print, etc. that map `wrapout` over all arguments. A developer is 
> expected to use the interface provided rather than `print` etc. directly.  
> The user doesn't even have a choice. There are very few types in the 
> package, but a lot of nested instances. So there is very little code needed 
> to traverse these instances.  This might be more difficult in a different 
> situation if many methods for wrapout() were required.
>
> On Monday, October 10, 2016 at 12:20:50 AM UTC+2, lapeyre@gmail.com 
> wrote:
>>
>> I want to change show for Symbol, Rational, and Bool. Till now, I simply 
>> overwrote the existing methods. This works great. I get what I want, even 
>> in warn and error and string interpolation, etc. It works flawlessly on 
>> v0.4, v0.5, and v0.6. But, this changes the behavior for everyone. So, I 
>> want to get the same effect through different means that do not affect 
>> other code. Any idea about how to do this ?
>>
>> One solution is to copy a large amount of  base code that uses print, 
>> write, show, etc. renaming these functions. Other than changing 15 or 20 
>> lines for Symbol, etc., the code is unchanged. This is works more or less, 
>> but is obviously a fragile, bad solution.
>>
>> Another idea is to make a subtype of IO that wraps subtypes of IO. I am 
>> allowed to write methods for show for this new type. This is turning out to 
>> be complicated and unworkable.
>>
>> Another vague idea is to make a new mime type. Another is to copy 
>> IOStream as another type, so that I only have to write methods for Symbol, 
>> Rational and Bool again.
>>
>>  
>>
>

[julia-users] Re: Julia and the Tower of Babel

[Jeffrey Sarnoff]

JuliaPraxis is on  github <https://github.com/JuliaPraxis> and gitter 
<https://gitter.im/JuliaPraxis/Lobby> ... bring our praxes. 


On Saturday, October 8, 2016 at 8:42:05 AM UTC-4, Jeffrey Sarnoff wrote:
>
> I have created a new Organization on github: *JuliaPraxis.*
> Everyone who has added to this thread will get an invitation to join, and 
> so contribute.
> I will set up the site and let you know how do include your wor(l)d views.
>
> Anyone else is welcome to post to this thread, and I will send an 
> invitation.
>
>
>
> On Saturday, October 8, 2016 at 6:59:51 AM UTC-4, Chris Rackauckas wrote:
>>
>> Conventions would have to be arrived at before this is possible.
>>
>> On Saturday, October 8, 2016 at 3:39:55 AM UTC-7, Traktor Toni wrote:
>>>
>>> In my opinion the solutions to this are very clear, or would be:
>>>
>>> 1. make a mandatory linter for all julia code
>>> 2. julia IDEs should offer good intellisense
>>>
>>> Am Freitag, 7. Oktober 2016 17:35:46 UTC+2 schrieb Gabriel Gellner:
>>>>
>>>> Something that I have been noticing, as I convert more of my research 
>>>> code over to Julia, is how the super easy to use package manager (which I 
>>>> love), coupled with the talent base of the Julia community seems to have a 
>>>> detrimental effect on the API consistency of the many “micro” packages 
>>>> that 
>>>> cover what I would consider the de-facto standard library.
>>>>
>>>> What I mean is that whereas a commercial package like 
>>>> Matlab/Mathematica etc., being written under one large umbrella, will 
>>>> largely (clearly not always) choose consistent names for similar API 
>>>> keyword arguments, and have similar calling conventions for master 
>>>> function 
>>>> like tools (`optimize` versus `lbfgs`, etc), which I am starting to 
>>>> realize 
>>>> is one of the great selling points of these packages as an end user. I can 
>>>> usually guess what a keyword will be in Mathematica, whereas even after a 
>>>> year of using Julia almost exclusively I find I have to look at the 
>>>> documentation (or the source code depending on the documentation ...) to 
>>>> figure out the keyword names in many common packages.
>>>>
>>>> Similarly, in my experience with open source tools, due to the 
>>>> complexity of the package management, we get large “batteries included” 
>>>> distributions that cover a lot of the standard stuff for doing science, 
>>>> like python’s numpy + scipy combination. Whereas in Julia the equivalent 
>>>> of 
>>>> scipy is split over many, separately developed packages (Base, Optim.jl, 
>>>> NLopt.jl, Roots.jl, NLsolve.jl, ODE.jl/DifferentialEquations.jl). Many of 
>>>> these packages are stupid awesome, but they can have dramatically 
>>>> different 
>>>> naming conventions and calling behavior, for essential equivalent 
>>>> behavior. 
>>>> Recently I noticed that tolerances, for example, are named as `atol/rtol` 
>>>> versus `abstol/reltol` versus `abs_tol/rel_tol`, which means is extremely 
>>>> easy to have a piece of scientific code that will need to use all three 
>>>> conventions across different calls to seemingly similar libraries. 
>>>>
>>>> Having brought this up I find that the community is largely sympathetic 
>>>> and, in general, would support a common convention, the issue I have 
>>>> slowly 
>>>> realized is that it is rarely that straightforward. In the above example 
>>>> the abstol/reltol versus abs_tol/rel_tol seems like an easy example of 
>>>> what 
>>>> can be tidied up, but the latter underscored name is consistent with 
>>>> similar naming conventions from Optim.jl for other tolerances, so that 
>>>> community is reluctant to change the convention. Similarly, I think there 
>>>> would be little interest in changing abstol/reltol to the underscored 
>>>> version in packages like Base, ODE.jl etc as this feels consistent with 
>>>> each of these code bases. Hence I have started to think that the problem 
>>>> is 
>>>> the micro-packaging. It is much easier to look for consistency within a 
>>>> package then across similar packages, and since Julia seems to distribute 
>>>> so many of the essential tools in very narrow boundaries of functionality 
>>>> I 
>>>>

Re: [julia-users] Re: Julia and the Tower of Babel

[Jeffrey Sarnoff]

__JuliaPraxis__ is on [github](https://github.com/JuliaPraxis) and 
[gitter](https://gitter.im/JuliaPraxis/Lobby), 
welcoming growth.

[julia-users] Re: Julia and the Tower of Babel

[Jeffrey Sarnoff]

I have created a new Organization on github: *JuliaPraxis.*
Everyone who has added to this thread will get an invitation to join, and 
so contribute.
I will set up the site and let you know how do include your wor(l)d views.

Anyone else is welcome to post to this thread, and I will send an 
invitation.



On Saturday, October 8, 2016 at 6:59:51 AM UTC-4, Chris Rackauckas wrote:
>
> Conventions would have to be arrived at before this is possible.
>
> On Saturday, October 8, 2016 at 3:39:55 AM UTC-7, Traktor Toni wrote:
>>
>> In my opinion the solutions to this are very clear, or would be:
>>
>> 1. make a mandatory linter for all julia code
>> 2. julia IDEs should offer good intellisense
>>
>> Am Freitag, 7. Oktober 2016 17:35:46 UTC+2 schrieb Gabriel Gellner:
>>>
>>> Something that I have been noticing, as I convert more of my research 
>>> code over to Julia, is how the super easy to use package manager (which I 
>>> love), coupled with the talent base of the Julia community seems to have a 
>>> detrimental effect on the API consistency of the many “micro” packages that 
>>> cover what I would consider the de-facto standard library.
>>>
>>> What I mean is that whereas a commercial package like Matlab/Mathematica 
>>> etc., being written under one large umbrella, will largely (clearly not 
>>> always) choose consistent names for similar API keyword arguments, and have 
>>> similar calling conventions for master function like tools (`optimize` 
>>> versus `lbfgs`, etc), which I am starting to realize is one of the great 
>>> selling points of these packages as an end user. I can usually guess what a 
>>> keyword will be in Mathematica, whereas even after a year of using Julia 
>>> almost exclusively I find I have to look at the documentation (or the 
>>> source code depending on the documentation ...) to figure out the keyword 
>>> names in many common packages.
>>>
>>> Similarly, in my experience with open source tools, due to the 
>>> complexity of the package management, we get large “batteries included” 
>>> distributions that cover a lot of the standard stuff for doing science, 
>>> like python’s numpy + scipy combination. Whereas in Julia the equivalent of 
>>> scipy is split over many, separately developed packages (Base, Optim.jl, 
>>> NLopt.jl, Roots.jl, NLsolve.jl, ODE.jl/DifferentialEquations.jl). Many of 
>>> these packages are stupid awesome, but they can have dramatically different 
>>> naming conventions and calling behavior, for essential equivalent behavior. 
>>> Recently I noticed that tolerances, for example, are named as `atol/rtol` 
>>> versus `abstol/reltol` versus `abs_tol/rel_tol`, which means is extremely 
>>> easy to have a piece of scientific code that will need to use all three 
>>> conventions across different calls to seemingly similar libraries. 
>>>
>>> Having brought this up I find that the community is largely sympathetic 
>>> and, in general, would support a common convention, the issue I have slowly 
>>> realized is that it is rarely that straightforward. In the above example 
>>> the abstol/reltol versus abs_tol/rel_tol seems like an easy example of what 
>>> can be tidied up, but the latter underscored name is consistent with 
>>> similar naming conventions from Optim.jl for other tolerances, so that 
>>> community is reluctant to change the convention. Similarly, I think there 
>>> would be little interest in changing abstol/reltol to the underscored 
>>> version in packages like Base, ODE.jl etc as this feels consistent with 
>>> each of these code bases. Hence I have started to think that the problem is 
>>> the micro-packaging. It is much easier to look for consistency within a 
>>> package then across similar packages, and since Julia seems to distribute 
>>> so many of the essential tools in very narrow boundaries of functionality I 
>>> am not sure that this kind of naming convention will ever be able to reach 
>>> something like a Scipy, or the even higher standard of commercial packages 
>>> like Matlab/Mathematica. (I am sure there are many more examples like using 
>>> maxiter, versus iterations for describing stopping criteria in iterative 
>>> solvers ...)
>>>
>>> Even further I have noticed that even when packages try to find 
>>> consistency across packages, for example Optim.jl <-> Roots.jl <-> 
>>> NLsolve.jl, when one package changes how they do things (Optim.jl moving to 
>>> delegation on types for method choice) then again the consistency fractures 
>>> quickly, where we now have a common divide of using either Typed dispatch 
>>> keywords versus :method symbol names across the previous packages (not to 
>>> mention the whole inplace versus not-inplace for function arguments …)
>>>
>>> Do people, with more experience in scientific packages ecosystems, feel 
>>> this is solvable? Or do micro distributions just lead to many, many varying 
>>> degrees of API conventions that need to be learned by end users? Is this 
>>> common in communities that use 

[julia-users] Re: multiple dispatch for operators

[Jeffrey Sarnoff]

Is there a way around the nonjuliance of Python  

within Python?


Regards, Jeffrey



On Friday, October 7, 2016 at 5:51:11 AM UTC-4, Sisyphuss wrote:
>
> In Julia, we can do multiple dispatch for operators, that is the 
> interpreter can identify:
> float + integer
> integer + integer
> integer + float
> float + float
> as well as *user-defined* data structure.
>
> Recently, I am working on Python (I have no choice because Spark hasn't 
> yet a Julia binding). I intended to do the same thing -- multiplication -- 
> between a Numpy matrix and self-defined Low-rank matrix. Of course, I 
> defined the `__rmul__ ` method for Low-rank matrix. However, it seems to me 
> that the Numpy matrix intercepts the `*` operator as its `__mul__` method, 
> which expects the argument on the right side of `*` to be a scalar.
>
> I would like to know if there is anyway around?
>
>

[julia-users] Re: Representation of a material conditional (implication)

[Jeffrey Sarnoff]

Peter Norvig's book+site is a very good learning tool.

by the way: if you are using OSX or Linux and have your terminal using a 
font with decent unicode coverage,   
`\Rightarrow` followed by TAB turns into `⇒`, which is the generally 
accepted symbol for material implication.

⇒(p::Bool, q::Bool) = ifelse(p, q, true)

true  ⇒  true, false  ⇒  true,  false  ⇒  false
# (true, true, true)

true  ⇒ false
# false






On Thursday, October 6, 2016 at 4:34:11 PM UTC-4, Kevin Liu wrote:
>
> Thanks for the distinction, Jeffrey.
>
> Also, look what I found https://github.com/aimacode. Julia is empty :-). 
> Can we hire some Martians to fill it up as we have ran out of Julians on 
> Earth? I'm happy I found this though. 
>
> On Thursday, October 6, 2016 at 5:26:43 PM UTC-3, Jeffrey Sarnoff wrote:
>>
>> you are welcome to use
>> implies(p::Bool, q::Bool) = !p | q
>> { !p, ~p likely compile to the same instructions -- they do for me; you 
>> might prefer to use of !p here as that means 'logical_not(p)' where ~p 
>> means 'flip_the_bits_of(p)' }
>>
>> I find that this form is also 40% slower than the ifelse form.
>>
>>
>>
>> On Thursday, October 6, 2016 at 4:11:55 PM UTC-4, Kevin Liu wrote:
>>>
>>> Is this why I couldn't find implication in Julia? 
>>>
>>> Maybe it was considered redundant because (1) it is less primitive than 
>>>> "^", "v", "~", (2) it saves very little typing since "A => B" is 
>>>> equivalent 
>>>> to "~A v B". – Giorgio 
>>>> <http://programmers.stackexchange.com/users/29020/giorgio> Jan 18 '13 
>>>> at 14:50 
>>>> <http://programmers.stackexchange.com/questions/184089/why-dont-languages-include-implication-as-a-logical-operator#comment353607_184089>
>>>
>>>
>>> Wikipedia also says the implication table is identical to that of ~p | 
>>> q. So instead just the below?
>>>
>>> julia> ~p | q 
>>>
>>> false
>>>
>>>
>>> I'll take that.
>>>
>>> On Thursday, October 6, 2016 at 4:08:00 PM UTC-3, Jeffrey Sarnoff wrote:
>>>>
>>>> (the version using ifelse benchmarks faster on my system)
>>>>
>>>> On Thursday, October 6, 2016 at 3:05:50 PM UTC-4, Jeffrey Sarnoff wrote:
>>>>>
>>>>> here are two ways
>>>>>
>>>>> implies(p::Bool, q::Bool) = !(p & !q)
>>>>>
>>>>> implies(p::Bool, q::Bool) = ifelse(p, q, true)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thursday, October 6, 2016 at 12:10:51 PM UTC-4, Kevin Liu wrote:
>>>>>>
>>>>>> How is an implication represented in Julia? 
>>>>>>
>>>>>>
>>>>>> https://en.wikipedia.org/wiki/Material_conditional#Definitions_of_the_material_conditional
>>>>>>
>>>>>

[julia-users] Re: Representation of a material conditional (implication)

[Jeffrey Sarnoff]

you are welcome to use
implies(p::Bool, q::Bool) = !p | q
{ !p, ~p likely compile to the same instructions -- they do for me; you 
might prefer to use of !p here as that means 'logical_not(p)' where ~p 
means 'flip_the_bits_of(p)' }

I find that this form is also 40% slower than the ifelse form.



On Thursday, October 6, 2016 at 4:11:55 PM UTC-4, Kevin Liu wrote:
>
> Is this why I couldn't find implication in Julia? 
>
> Maybe it was considered redundant because (1) it is less primitive than 
>> "^", "v", "~", (2) it saves very little typing since "A => B" is equivalent 
>> to "~A v B". – Giorgio 
>> <http://programmers.stackexchange.com/users/29020/giorgio> Jan 18 '13 at 
>> 14:50 
>> <http://programmers.stackexchange.com/questions/184089/why-dont-languages-include-implication-as-a-logical-operator#comment353607_184089>
>
>
> Wikipedia also says the implication table is identical to that of ~p | q. 
> So instead just the below?
>
> julia> ~p | q 
>
> false
>
>
> I'll take that.
>
> On Thursday, October 6, 2016 at 4:08:00 PM UTC-3, Jeffrey Sarnoff wrote:
>>
>> (the version using ifelse benchmarks faster on my system)
>>
>> On Thursday, October 6, 2016 at 3:05:50 PM UTC-4, Jeffrey Sarnoff wrote:
>>>
>>> here are two ways
>>>
>>> implies(p::Bool, q::Bool) = !(p & !q)
>>>
>>> implies(p::Bool, q::Bool) = ifelse(p, q, true)
>>>
>>>
>>>
>>>
>>> On Thursday, October 6, 2016 at 12:10:51 PM UTC-4, Kevin Liu wrote:
>>>>
>>>> How is an implication represented in Julia? 
>>>>
>>>>
>>>> https://en.wikipedia.org/wiki/Material_conditional#Definitions_of_the_material_conditional
>>>>
>>>

[julia-users] Re: Representation of a material conditional (implication)

[Jeffrey Sarnoff]

(the version using ifelse benchmarks faster on my system)

On Thursday, October 6, 2016 at 3:05:50 PM UTC-4, Jeffrey Sarnoff wrote:
>
> here are two ways
>
> implies(p::Bool, q::Bool) = !(p & !q)
>
> implies(p::Bool, q::Bool) = ifelse(p, q, true)
>
>
>
>
> On Thursday, October 6, 2016 at 12:10:51 PM UTC-4, Kevin Liu wrote:
>>
>> How is an implication represented in Julia? 
>>
>>
>> https://en.wikipedia.org/wiki/Material_conditional#Definitions_of_the_material_conditional
>>
>

[julia-users] Re: Representation of a material conditional (implication)

[Jeffrey Sarnoff]

here are two ways

implies(p::Bool, q::Bool) = !(p & !q)

implies(p::Bool, q::Bool) = ifelse(p, q, true)




On Thursday, October 6, 2016 at 12:10:51 PM UTC-4, Kevin Liu wrote:
>
> How is an implication represented in Julia? 
>
>
> https://en.wikipedia.org/wiki/Material_conditional#Definitions_of_the_material_conditional
>

[julia-users] Re: What is best practice for determining if a URL exists?

[Jeffrey Sarnoff]

good suggestion, should someone else need this:

using Requests
function urlExists(url)
try
   Requests.head(url)
   true
catch
   false
end
end





On Thursday, October 6, 2016 at 8:09:01 AM UTC-4, Andreas Lobinger wrote:
>
> I haven't used it, but https://github.com/JuliaWeb/Requests.jl looks 
> reasonable
>
> On Thursday, October 6, 2016 at 2:01:54 PM UTC+2, Jeffrey Sarnoff wrote:
>>
>> ok, how (within Julia)?
>>
>> On Thursday, October 6, 2016 at 6:19:00 AM UTC-4, Johan Sigfrids wrote:
>>>
>>> I would probably do a HTTP HEAD request. It would return the headers 
>>> allowing you to tell what, if anything, is there without having to download 
>>> it.
>>>
>>> On Thursday, October 6, 2016 at 7:54:13 AM UTC+3, Jeffrey Sarnoff wrote:
>>>>
>>>> What is best practice for determining if a URL exists (known, 
>>>> retrievable, and not 404)?
>>>>
>>>

[julia-users] Re: What is best practice for determining if a URL exists?

[Jeffrey Sarnoff]

ok, how (within Julia)?

On Thursday, October 6, 2016 at 6:19:00 AM UTC-4, Johan Sigfrids wrote:
>
> I would probably do a HTTP HEAD request. It would return the headers 
> allowing you to tell what, if anything, is there without having to download 
> it.
>
> On Thursday, October 6, 2016 at 7:54:13 AM UTC+3, Jeffrey Sarnoff wrote:
>>
>> What is best practice for determining if a URL exists (known, 
>> retrievable, and not 404)?
>>
>

[julia-users] What is best practice for determining if a URL exists?

[Jeffrey Sarnoff]

What is best practice for determining if a URL exists (known, retrievable, 
and not 404)?

[julia-users] [ANN] TypedDelegation.jl

[Jeffrey Sarnoff]

When you want to use the fields of a type as arguments to a function or 
where you want to apply a type-wrapped version an imported operator, 
TypedDelegation is  available.

Eight macros are exported.  Four are for use where one field within a type 
is needed, and four where two fields within a type are needed.  Each group 
supports functions over one or two variables of a given type:. 
signbit(x), !=(x,y).  Each group supports operations on a given type that 
return results of that type:  abs(x), +(x,y).
See the README  for 
examples of their use.

# apply functions through a given Type T, using one field as a 
parameter
#
#   evaluates as the type that the function returns
@delegate_oneField,   #  fn(x::T)
@delegate_oneField_fromTwoVars,   #  fn(x::T, y::T)
#
#   evaluates as the type that is used in delegation
@delegate_oneField_asType,#  op(x::T)::T
@delegate_oneField_fromTwoVars_asType,#  op(x::T, y::T)::T
  #
# apply functions through a given Type, using two fields as 
parameters
#
#   evaluates as the type that the function returns
@delegate_twoFields,  #  fn(x::T)
@delegate_twoFields_fromTwoVars,  #  fn(x::T, y::T)
#
#   evaluates as the type that is used in delegation
@delegate_twoFields_asType,   #  op(x::T)::T
@delegate_twoFields_fromTwoVars_asType#  op(x::T, y::T)::T

[julia-users] Re: ANN: Julia v0.5.0 released!

[Jeffrey Sarnoff]

whoo-hoo!

On Tuesday, September 20, 2016 at 5:08:44 AM UTC-4, Tony Kelman wrote:
>
> At long last, we can announce the final release of Julia 0.5.0! See the 
> release notes at 
> https://github.com/JuliaLang/julia/blob/release-0.5/NEWS.md for more 
> details, and expect a blog post with some highlights within the next few 
> days. Binaries are available from the usual place 
> , and please report all issues to either 
> the issue tracker  or email 
> the julia-users list. Don't CC julia-news, which is intended to be 
> low-volume, if you reply to this message.
>
> Many thanks to all the contributors, package authors, users and reporters 
> of issues who helped us get here. We'll be releasing regular monthly bugfix 
> backports from the 0.5.x line, while major feature work is ongoing on 
> master for 0.6-dev. Enjoy!
>
>
> We haven't made the change just yet, but to package authors: please be 
> aware that `release` on Travis CI for `language: julia` will change meaning 
> to 0.5 shortly. So if you want to continue supporting Julia 0.4 in your 
> package, please update your .travis.yml file to have an "- 0.4" entry under 
> `julia:` versions. When you want to drop support for Julia 0.4, update your 
> REQUIRE file to list `julia 0.5` as a lower bound, and the next time you 
> tag the package be sure to increment the minor or major version number via 
> `PkgDev.tag(pkgname, :minor)`.
>
>

[julia-users] Re: julia installation broken

[Jeffrey Sarnoff]

I have had this happen, too.  My suggestion is  grounded in persistence 
rather than deep mastery of Julia's structural and file relationships.
So someone else may have a more studied approach with some explaining. 
 Until then,

quit() Julia.
To have an new install be really clean, first cd  to /.julia/ 
and delete the directory `v0.5` -- if that is overkill because you do not 
want to redo many Pkg.add()s then cd v0.5 and delete the METADATA directory 
the REQUIRE file and the META_BRANCH file and the entry for whatever 
packages you had added just before this difficulty (including those that 
have hiccuped on precompile).   
now delete and then reget the most current binary for your system 
julia-0.5.0-rc4-osx10.7+.dmg 

install
Then start julia and quit().  Then start Julia and do Pkg.update() then 
quit().
Then start julia and do Pkg.add() for 1 package you want then quit(). then 
start julia and do using  (so it precompiles) and quit().
now try using that package.






On Friday, September 16, 2016 at 4:43:06 AM UTC-4, Michael Borregaard wrote:
>
> Hi, Is this the right forum for troubleshooting / issues with my julia 
> install?
>
> I have kept having problems with packages giving error on precompile, 
> rendering julia unusable. I then reinstalled julia-0.5-rc4, and removed my 
> .julia folder from my home dir to do a fresh install. Now, Julia fails with 
> an error message when I do Pkg.update():
>
> julia> Pkg.update()
> INFO: Initializing package repository /Users/michael/.julia/v0.5
> INFO: Cloning METADATA from https://github.com/JuliaLang/METADATA.jl
> ERROR: SystemError (with /Users/michael/.julia/v0.5/METADATA): rmdir: 
> Directory not empty
>  in #systemerror#51 at ./error.jl:34 [inlined]
>  in (::Base.#kw##systemerror)(::Array{Any,1}, ::Base.#systemerror, 
> ::Symbol, ::Bool) at ./:0
>  in #rm#7(::Bool, ::Bool, ::Function, ::String) at ./file.jl:125
>  in #rm#7(::Bool, ::Bool, ::Function, ::String) at 
> /Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib:?
>  in (::Base.Filesystem.#kw##rm)(::Array{Any,1}, ::Base.Filesystem.#rm, 
> ::String) at ./:0
>  in init(::String, ::String) at ./pkg/dir.jl:62
>  in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, 
> ::Vararg{Any,N}) at ./pkg/dir.jl:28
>  in update() at ./pkg/pkg.jl:210
>
> I assums that a completely clean install should work. Are there keys to 
> delete etc that will give me a properly clean install? I am on Mac OS X 
> (newest version).
> Thanks!
>

[julia-users] TIOBE Headline: Julia enters top 50 for the first time

[Jeffrey Sarnoff]

> It was a matter of time until Julia would hit the top 50. This month it 
> did so. The Julia programming language is meant for numerical computing. It 
> combines functional programming paradigms with high speed. In other words, 
> readable and stable code that performs. Chances are high that Julia will 
> gain even more popularity the next few months.


 The TIOBE Programming Community index is an indicator 
of the popularity of programming languages. 


 (thanks to Bill Hart for posting the link at nemo-dev)

Re: [julia-users] code design question – best ideomatic way to define nested types?

[Jeffrey Sarnoff]

Tom, the coarseness encountered when trying splatfields with type 
parameters: is it endemic and likely to persist or does this grow better in 
v0.6+?

On Thursday, September 15, 2016 at 11:20:35 PM UTC-4, Tom Breloff wrote:
>
> I like splatfields but I think it's hard to make work with type parameters 
> (which is normally a deal breaker for me)
>
> On Thursday, September 15, 2016, 'Greg Plowman' via julia-users <
> julia...@googlegroups.com > wrote:
>
>>
>> Another variation on Chris's @commonfields and Tom's @base & @extend:
>>
>> This is somewhere between example 2 and 3, 
>> Avoids copy and paste of example 2
>> Avoids delegating to Foo of example 3 
>>
>> abstract AbstractFoo
>>
>> type Foo <: AbstractFoo
>> bar
>> baz
>> end
>>
>> type Foobar <: AbstractFoo
>> @splatfields Foo
>> barbaz
>> bazbaz
>> end
>>
>> Also allows for "multiple" composition/inheritance.
>>
>>  
>>
>

[julia-users] Re: Tracking down type instability

[Jeffrey Sarnoff]

Removing the @inlines may be useful while investigating.

On Thursday, September 15, 2016 at 10:08:16 AM UTC-4, Ben Ward wrote:
>
> Hi I have two functions and a function which calls them:
>
> @inline function expected_distance(::Type{JukesCantor69}, p::Float64)
> return -0.75 * log(1 - 4 * p / 3)
> end
>
> @inline function variance(::Type{JukesCantor69}, p::Float64, l::Int64)
> return p * (1 - p) / (((1 - 4 * p / 3) ^ 2) * l)
> end
>
> function distance{A<:NucleotideAlphabet}(::Type{JukesCantor69}, 
> seqs::Vector{BioSequence{A}})
> p, l = distance(Proportion{AnyMutation}, seqs)
> D = Vector{Float64}(length(p))
> V = Vector{Float64}(length(p))
> @inbounds for i in 1:length(p)
> D[i] = expected_distance(JukesCantor69, p[i])
> V[i] = variance(JukesCantor69, p[i], l[i])
> end
> return D, V
> end
>
> But I'm seeing type uncertainty:
>
> *@code_warntype distance(JukesCantor69, dnas)*
>
> Variables:
>
>   #self#::Bio.Var.#distance
>
>   #unused#::Type{Bio.Var.JukesCantor69}
>
>   seqs::Array{Bio.Seq.BioSequence{Bio.Seq.DNAAlphabet{4}},1}
>
>   p::Array{Float64,1}
>
>   l::Array{Int64,1}
>
>   #temp#@_6::Int64
>
>   D::Array{Float64,1}
>
>   V::Array{Float64,1}
>
>   #temp#@_9::Int64
>
>   i::Int64
>
>
> Body:
>
>   begin 
>
>   SSAValue(0) = $(Expr(:invoke, LambdaInfo for 
> distance(::Type{Bio.Var.Proportion{Bio.Var.AnyMutation}}, 
> ::Array{Bio.Seq.BioSequence{Bio.Seq.DNAAlphabet{4}},1}), 
> :(Bio.Var.distance), Bio.Var.Proportion{Bio.Var.AnyMutation}, :(seqs)))
>
>   #temp#@_6::Int64 = $(QuoteNode(1))
>
>   SSAValue(15) = (Base.getfield)(SSAValue(0),1)
> *::Union{Array{Float64,1},Array{Int64,1}}*
>
>   SSAValue(16) = (Base.box)(Int64,(Base.add_int)(1,1))
>
>   p::Array{Float64,1} = SSAValue(15)
>
>   #temp#@_6::Int64 = SSAValue(16)
>
>   SSAValue(17) = (Base.getfield)(SSAValue(0),2)
> *::Union{Array{Float64,1},Array{Int64,1}}*
>
>   SSAValue(18) = (Base.box)(Int64,(Base.add_int)(2,1))
>
>   l::Array{Int64,1} = SSAValue(17)
>
>   #temp#@_6::Int64 = SSAValue(18) # line 314:
>
>   SSAValue(7) = (Base.arraylen)(p::Array{Float64,1})::Int64
>
>   D::Array{Float64,1} = 
> (Core.ccall)(:jl_alloc_array_1d,(Core.apply_type)(Core.Array,Float64,1)::Type{Array{Float64,1}},(Core.svec)(Core.Any,Core.Int)::SimpleVector,Array{Float64,1},0,SSAValue(7),0)::Array{Float64,1}
>  
> # line 315:
>
>   SSAValue(9) = (Base.arraylen)(p::Array{Float64,1})::Int64
>
>   V::Array{Float64,1} = 
> (Core.ccall)(:jl_alloc_array_1d,(Core.apply_type)(Core.Array,Float64,1)::Type{Array{Float64,1}},(Core.svec)(Core.Any,Core.Int)::SimpleVector,Array{Float64,1},0,SSAValue(9),0)::Array{Float64,1}
>  
> # line 316:
>
>   $(Expr(:inbounds, true))
>
>   SSAValue(11) = (Base.arraylen)(p::Array{Float64,1})::Int64
>
>   SSAValue(19) = 
> (Base.select_value)((Base.sle_int)(1,SSAValue(11))::Bool,SSAValue(11),(Base.box)(Int64,(Base.sub_int)(1,1)))::Int64
>
>   #temp#@_9::Int64 = 1
>
>   22: 
>
>   unless (Base.box)(Base.Bool,(Base.not_int)((#temp#@_9::Int64 === 
> (Base.box)(Int64,(Base.add_int)(SSAValue(19),1)))::Bool)) goto 43
>
>   SSAValue(20) = #temp#@_9::Int64
>
>   SSAValue(21) = (Base.box)(Int64,(Base.add_int)(#temp#@_9::Int64,1))
>
>   i::Int64 = SSAValue(20)
>
>   #temp#@_9::Int64 = SSAValue(21) # line 317:
>
>   SSAValue(12) = (Base.arrayref)(p::Array{Float64,1},i::Int64)::Float64
>
>   $(Expr(:inbounds, false))
>
>   # meta: location /Users/bward/.julia/v0.5/Bio/src/var/distances.jl 
> expected_distance 69
>
>   SSAValue(13) = $(Expr(:invoke, LambdaInfo for log(::Float64), 
> :(Bio.Var.log), 
> :((Base.box)(Base.Float64,(Base.sub_float)((Base.box)(Float64,(Base.sitofp)(Float64,1)),(Base.box)(Base.Float64,(Base.div_float)((Base.box)(Base.Float64,(Base.mul_float)((Base.box)(Float64,(Base.sitofp)(Float64,4)),SSAValue(12))),(Base.box)(Float64,(Base.sitofp)(Float64,3)
>
>   # meta: pop location
>
>   $(Expr(:inbounds, :pop))
>
>   SSAValue(5) = 
> (Base.box)(Base.Float64,(Base.mul_float)(-0.75,SSAValue(13)))
>
>   
> (Base.arrayset)(D::Array{Float64,1},SSAValue(5),i::Int64)::Array{Float64,1} 
> # line 318:
>
>   SSAValue(14) = (Base.arrayref)(p::Array{Float64,1},i::Int64)::Float64
>
>   SSAValue(6) = 
> 

[julia-users] Brown Data Science blog: Register a Pkg, Why Concrete Types

[Jeffrey Sarnoff]

here are the links to Julia posts in Brown's Data Science blog:

performance-and-type-stable-functions-in-julia 



registering-a-julia-package 
 
(best 
read in concert with the pkg dev docs 
) 

 

[julia-users] Re: Re: dependent types in julia?

[Jeffrey Sarnoff]

and if you're pretty happy, that's all!

On Thursday, September 15, 2016 at 10:43:09 AM UTC-4, Neal Becker wrote:
>
> After some iterations, I'm pretty happy with this form, which doesn't need 
> any magic: 
>
> https://gist.github.com/nbecker/58f79e449400159e4762f6c8eedd9f65 
>
> The type var is parameterized by 2 parameters, and the constructors take 
> care of the type computations, similar to Dan's suggestion. The invariant 
> checking you suggest could be added (but in my case would be a bit more 
> complicated) 
>
> Jeffrey Sarnoff wrote: 
>
> > Hi Neal, 
> > 
> > It is not good practice to leave out parts of the template that Dan 
> > offers. 
> >  While it may work with some test data, it is very likely to fail in 
> > general use (particularly by/with use from other packages) and it may 
> > become incompatible in some specific manner with future releases. 
> > 
> > If I get your drift, something like this may serve 
> > 
> > underlyingtype{T}(::Type{Complex{T}}) = T 
> > 
> > type ComplexOf{S,T} 
> > sum::S 
> > sumsqr::T 
> > function ComplexOf{S,T}(s::S,ss::T) 
> > realtype = underlyingtype(S) 
> > if typeof(ss) != realtype 
> > throw( 
> >   TypeError( :ComplexOf, "ComplexOf($s,$ss)\n\t\t", 
> realtype, 
> >   T 
> > )) 
> > end 
> > new(s,ss) 
> >  end 
> > end 
> > 
> > ComplexOf{S,T}(x::S, y::T) = ComplexOf{S,T}(x,y) 
> > 
> > ComplexOf(1.5+2.0im, 1.0) 
> > 
> > ComplexOf(5+2im, 3) 
> > 
> > # force a type error by mixing the kinds of underlying types 
> > ComplexOf(5.0+1.5im, 2.0f0) 
> > 
> > # presumably, you want to add 
> > function ComplexOf{T}(x::Vector{Complex{T}}) 
> > s = sum(x) 
> > ss = abs2(s) 
> > return ComplexOf(s,ss) 
> > end 
> > 
> > 
> > test = ComplexOf([3.0+1.0im, 2.0-1.0im]); 
> > test.sum, test.sumsqr 
> > 
> > 
> > 
> > If you have questions about why something is present, do ask. 
> > Also, in this case, you can use `immutable ComplexOf` rather than `type 
> > ComplexOf`, which helps if there are very many of them. 
> > 
> > On Thursday, September 15, 2016 at 8:44:28 AM UTC-4, Neal Becker wrote: 
> >> 
> >> OK, I think I got it: 
> >> 
> >> decomplexify{T}(::Type{Complex{T}}) = T 
> >> 
> >> type var2{T,S} 
> >> sum::S 
> >> sumsqr::T 
> >> nobjs::Int64 
> >> var2() = new(0,0,0) 
> >> end 
> >> 
> >> (::Type{var2{T}}){T}() = var2{T,decomplexify((T))}()   << magic? 
> >> var2() = var2{Complex{Float64},Float64}() << default 
> >> 
> >> This seems to work 
> >> Problem is I have no idea what this line marked "magic" means. 
> >> 
> >> Isaiah Norton wrote: 
> >> 
> >> > See 
> >> https://github.com/JuliaLang/julia/issues/18466#issuecomment-246713799 
> >> > 
> >> > On Wed, Sep 14, 2016 at 6:13 PM, Dan 
> >> > <get...@gmail.com > wrote: 
> >> > 
> >> >> Maybe the following is the form you are looking for: 
> >> >> 
> >> >> julia> decomplexify{T}(::Type{Complex{T}}) = T 
> >> >> decomplexify (generic function with 1 method) 
> >> >> 
> >> >> 
> >> >> julia> type bar{S,T} 
> >> >>sum::S 
> >> >>sumsqr::T 
> >> >>function bar(s,ss) 
> >> >>if typeof(ss) != decomplexify(typeof(s)) 
> >> >>error("Yaiks") 
> >> >>end 
> >> >>new(s,ss) 
> >> >>end 
> >> >>end 
> >> >> 
> >> >> 
> >> >> julia> bar{Complex{Float64},Float64}(1.5+2.0im,1.0) 
> >> >> bar{Complex{Float64},Float64}(1.5 + 2.0im,1.0) 
> >> >> 
> >> >> 
> >> >> julia> bar{S,T}(x::S,y::T) = bar{S,T}(x,y) 
> >> >> bar{S,T} 
> >> >> 
> >> >> 
> >> >> julia> bar(1.5+2.0im,1.0) 
> >> >> bar{Complex{Float64},Float64}(1.5 + 2.0im,1.0) 
> >> >> 
> >> >> 
> >> >> The outer constructor is necessary to get the last line working. The 
> >> >> inner constructor basically maintains the constraint between S and T 
> >> of: 
> >> >> T == Complex{S}. 
> >> >> 
> >> >> On Wednesday, September 14, 2016 at 3:38:53 PM UTC-4, Neal Becker 
> >> wrote: 
> >> >>> 
> >> >>> Evan Fields wrote: 
> >> >>> 
> >> >>> > How about something like the following? 
> >> >>> > 
> >> >>> > type CT{T} 
> >> >>> > ctsum::Complex{T} 
> >> >>> > ctsumsq::T 
> >> >>> > end 
> >> >>> > 
> >> >>> 
> >> >>> I'm aware that it's easier to make the type parameter the scalar 
> >> >>> type, allowing writing as you show, but as a learning exercise I'd 
> >> >>> like to know how Julia would go the other way. 
> >> >>> 
> >> >>> In c++ this would be done with template metaprogramming, but as 
> Julia 
> >> >>> claims 
> >> >>> to have types as 1st class objects, I thought there should be some 
> >> >>> elegant 
> >> >>> way to do this. 
> >> >>> 
> >> >>> That is, given T is Complex{U}, I need the type U so I can write 
> >> >>> ctsumsq::U 
> >> >>> 
> >> >>> 
> >> 
> >> 
> >> 
>
>
>

[julia-users] Re: Re: dependent types in julia?

[Jeffrey Sarnoff]

Hi Neal,

It is not good practice to leave out parts of the template that Dan offers. 
 While it may work with some test data, it is very likely to fail in 
general use (particularly by/with use from other packages) and it may 
become incompatible in some specific manner with future releases.

If I get your drift, something like this may serve

underlyingtype{T}(::Type{Complex{T}}) = T

type ComplexOf{S,T} 
sum::S 
sumsqr::T
function ComplexOf{S,T}(s::S,ss::T)
realtype = underlyingtype(S)
if typeof(ss) != realtype
throw(
  TypeError( :ComplexOf, "ComplexOf($s,$ss)\n\t\t", realtype, T 
))
end
new(s,ss)
 end
end

ComplexOf{S,T}(x::S, y::T) = ComplexOf{S,T}(x,y)

ComplexOf(1.5+2.0im, 1.0)

ComplexOf(5+2im, 3)

# force a type error by mixing the kinds of underlying types
ComplexOf(5.0+1.5im, 2.0f0)

# presumably, you want to add
function ComplexOf{T}(x::Vector{Complex{T}})
s = sum(x)
ss = abs2(s)
return ComplexOf(s,ss)
end


test = ComplexOf([3.0+1.0im, 2.0-1.0im]);
test.sum, test.sumsqr



If you have questions about why something is present, do ask.
Also, in this case, you can use `immutable ComplexOf` rather than `type 
ComplexOf`, which helps if there are very many of them.

On Thursday, September 15, 2016 at 8:44:28 AM UTC-4, Neal Becker wrote:
>
> OK, I think I got it: 
>
> decomplexify{T}(::Type{Complex{T}}) = T 
>
> type var2{T,S} 
> sum::S 
> sumsqr::T 
> nobjs::Int64 
> var2() = new(0,0,0) 
> end 
>
> (::Type{var2{T}}){T}() = var2{T,decomplexify((T))}()   << magic? 
> var2() = var2{Complex{Float64},Float64}() << default 
>
> This seems to work 
> Problem is I have no idea what this line marked "magic" means. 
>
> Isaiah Norton wrote: 
>
> > See 
> https://github.com/JuliaLang/julia/issues/18466#issuecomment-246713799 
> > 
> > On Wed, Sep 14, 2016 at 6:13 PM, Dan 
> >  wrote: 
> > 
> >> Maybe the following is the form you are looking for: 
> >> 
> >> julia> decomplexify{T}(::Type{Complex{T}}) = T 
> >> decomplexify (generic function with 1 method) 
> >> 
> >> 
> >> julia> type bar{S,T} 
> >>sum::S 
> >>sumsqr::T 
> >>function bar(s,ss) 
> >>if typeof(ss) != decomplexify(typeof(s)) 
> >>error("Yaiks") 
> >>end 
> >>new(s,ss) 
> >>end 
> >>end 
> >> 
> >> 
> >> julia> bar{Complex{Float64},Float64}(1.5+2.0im,1.0) 
> >> bar{Complex{Float64},Float64}(1.5 + 2.0im,1.0) 
> >> 
> >> 
> >> julia> bar{S,T}(x::S,y::T) = bar{S,T}(x,y) 
> >> bar{S,T} 
> >> 
> >> 
> >> julia> bar(1.5+2.0im,1.0) 
> >> bar{Complex{Float64},Float64}(1.5 + 2.0im,1.0) 
> >> 
> >> 
> >> The outer constructor is necessary to get the last line working. The 
> >> inner constructor basically maintains the constraint between S and T 
> of: 
> >> T == Complex{S}. 
> >> 
> >> On Wednesday, September 14, 2016 at 3:38:53 PM UTC-4, Neal Becker 
> wrote: 
> >>> 
> >>> Evan Fields wrote: 
> >>> 
> >>> > How about something like the following? 
> >>> > 
> >>> > type CT{T} 
> >>> > ctsum::Complex{T} 
> >>> > ctsumsq::T 
> >>> > end 
> >>> > 
> >>> 
> >>> I'm aware that it's easier to make the type parameter the scalar type, 
> >>> allowing writing as you show, but as a learning exercise I'd like to 
> >>> know how Julia would go the other way. 
> >>> 
> >>> In c++ this would be done with template metaprogramming, but as Julia 
> >>> claims 
> >>> to have types as 1st class objects, I thought there should be some 
> >>> elegant 
> >>> way to do this. 
> >>> 
> >>> That is, given T is Complex{U}, I need the type U so I can write 
> >>> ctsumsq::U 
> >>> 
> >>> 
>
>
>

[julia-users] building a package without rebuilding a REQUIRES pkg

[Jeffrey Sarnoff]

If I have a package MainPkg with a  REQUIRE file that holds "HelperPkg", 
and I do
Pkg.add("HelperPkg");Pkg.build("HelperPkg");
is there a way to 
Pkg.add("MainPkg")
without automatically rebuilding (the already current) HelperPkg?

[julia-users] Re: ANN: SimpleTraits.jl

[Jeffrey Sarnoff]

Thanks for updating your work.
If there is a form that allows a function to be defined that has 
multidispatch over trait and also over type, please provide an example.
(If it is already there, please direct me to that example).

On Wednesday, September 14, 2016 at 6:04:04 AM UTC-4, Mauro wrote:
>
> There is --at times-- some interest on this list about traits, enough 
> that I thought the noise to announce the registration of this traits 
> package is warranted.  In brief, traits group types into sets 
> independent of the type hierarchy and let functions dispatch on those 
> traits instead of on types. 
>
> The package can be found here: 
>   https://github.com/mauro3/SimpleTraits.jl 
>
> SimpleTraits.jl provides macros to automate *Tim's trait trick*.  A 
> brief example (more can be found in the README): 
>
>   using SimpleTraits 
>   # define a trait: 
>   @traitdef IsNice{X} 
>
>   # add some types to the trait: 
>   @traitimpl IsNice{Int} 
>   @traitimpl IsNice{String} 
>
>   # define a function dispatching on this trait and its negation: 
>   @traitfn f{X;  IsNice{X}}(x::X) = "Very nice!" 
>   @traitfn f{X; !IsNice{X}}(x::X) = "Not so nice!" 
>
>   # use that function like any other function 
>   f(5) # => "Very nice!" 
>   f("a") # => "Very nice!" 
>   f(6.0) # => "Not so nice!" 
>
>
> Tim Holy, indeed the inventor of the trick named after him, uses 
> SimpleTraits in the overhaul of his Images.jl package [1,2] (and was who 
> prodded me to register SimpleTraits.jl).  The "blurb" in my README is: 
>
>   Tim Holy endorses SimpleTraits, a bit: "I'd say that compared to 
>   manually writing out the trait-dispatch, the "win" is not enormous, 
>   but it is a little nicer." I suspect that — if you don't write 
>   Holy-traits before breakfast — your "win" should be greater ;-) 
>
> [1] https://github.com/timholy/Images.jl/issues/542 
> [2] https://github.com/JuliaImages/ImageAxes.jl 
>

[julia-users] Re: macro: with

[Jeffrey Sarnoff]

It is a good example for others who are looking to understand how to write 
a macro that facilitates field qualified access.

On Wednesday, September 7, 2016 at 10:23:47 AM UTC-4, Tom Breloff wrote:
>
> Hey all... I just threw together a quick macro to save some typing when 
> working with the fields of an object.  Disclaimer: this should not be used 
> in library code, or in anything that will stick around longer than a REPL 
> session.  Hopefully it's self explanatory with this example.  Is there a 
> good home for this?  Does anyone want to use it?
>
> julia> type T; a; b; end; t = T(0,0)
> T(0,0)
>
> julia> macroexpand(:(
>@with t::T begin
>a = 1
>b = 2
>c = a + b - 4
>d = c - b
>a = d / c
>end
>))
> quote  # REPL[3], line 3:
> t.a = 1 # REPL[3], line 4:
> t.b = 2 # REPL[3], line 5:
> c = (t.a + t.b) - 4 # REPL[3], line 6:
> d = c - t.b # REPL[3], line 7:
> t.a = d / c
> end
>
> julia> @with t::T begin
>a = 1
>b = 2
>c = a + b - 4
>d = c - b
>a = d / c
>end
> 3.0
>
> julia> t
> T(3.0,2)
>
>

[julia-users] Re: ANN: DelegationMacros v0.0.3

[Jeffrey Sarnoff]

Hi Lyndon,

The kind words are much welcome.
This, DelegationMacros, is the nicer -- more humanly -- phrasing of some of 
the macros in the earlier version.  
I expect to port some more of that version to the nicer style.  Please let 
me know if you need some combination of
number of fields to delegate into/through and count of variables to operate 
over.  I'd be happy to supply that with this.

-- Jeffrey


On Tuesday, September 6, 2016 at 9:56:31 PM UTC-4, Lyndon White wrote:
>
> Nice work.
> I spotted https://github.com/Jeffrey-Sarnoff/Delegate.jl
> last week and was pretty keen on it.
> Yet to use it but really looks like it will
> solve a lot of my irritation with Composition as a Inheritance.
>
> What is the relationship between Delegate.jl and DelegateMacros.jl?
> Is Delegate.jl deprecated?
> Is there non-overlapping features
>
>
> On Wednesday, 7 September 2016 06:14:22 UTC+8, Jeffrey Sarnoff wrote:
>>
>> This offers updated macros to assist with delegating into/through fields 
>> of a defined type.  
>>
>> Two macros apply a function to field value(s) yielding the functional 
>> result; 
>> and two others do that and then rewrap the result in the source type.
>>
>> The exports are:
>>@delegate_oneField, 
>>@delegate_oneField_fromTwoVars,
>>@delegate_oneField_asType, 
>>@delegate_oneField_fromTwoVars_asType
>>
>> They work so:
>>
>> import Base:string, show, (<), (<=), abs, (-), (+), (*)
>>
>> immutable MyInt16
>>value::Int16
>> end
>>
>> three = MyInt16(3)
>> seven = MyInt16(7)
>>
>>
>> @delegate_oneField( MyInt16, value, [string, show])
>>
>> string(three) == "3"  # true
>> show(seven)   # 7
>>
>>
>> @delegate_oneField_fromTwoVars( MyInt16, value, [ (<), (<=) ] )
>>
>> three <  seven# true
>> seven <= seven# true
>>
>>
>> @delegate_oneField_asType( MyInt16, value, [abs, (-)])
>>
>> abs(three) == three   # true
>> -seven == MyInt16(-7) # true
>>
>>
>> @delegate_oneField_fromTwoVars_asType( MyInt16, value, [ (+), (*) ] )
>>
>> three + seven == MyInt16(3+7) # true
>> three * seven == MyInt16(3*7) # true
>>
>>
>>
>>
>>
>>

[julia-users] Any Julia pkgs using Polymer web components?

[Jeffrey Sarnoff]

If you know of work with Julia and Polymer, please share that information.

[julia-users] Re: ANN: DelegationMacros v0.0.3

[Jeffrey Sarnoff]

to get the package, clone this 
git://github.com/JuliaArbTypes/DelegationMacros.jl.git 
<https://github.com/JuliaArbTypes/DelegationMacros.jl>


On Tuesday, September 6, 2016 at 6:14:22 PM UTC-4, Jeffrey Sarnoff wrote:
>
> This offers updated macros to assist with delegating into/through fields 
> of a defined type.  
>
> Two macros apply a function to field value(s) yielding the functional 
> result; 
> and two others do that and then rewrap the result in the source type.
>
> The exports are:
>@delegate_oneField, 
>@delegate_oneField_fromTwoVars,
>@delegate_oneField_asType, 
>@delegate_oneField_fromTwoVars_asType
>
> They work so:
>
> import Base:string, show, (<), (<=), abs, (-), (+), (*)
>
> immutable MyInt16
>value::Int16
> end
>
> three = MyInt16(3)
> seven = MyInt16(7)
>
>
> @delegate_oneField( MyInt16, value, [string, show])
>
> string(three) == "3"  # true
> show(seven)   # 7
>
>
> @delegate_oneField_fromTwoVars( MyInt16, value, [ (<), (<=) ] )
>
> three <  seven# true
> seven <= seven# true
>
>
> @delegate_oneField_asType( MyInt16, value, [abs, (-)])
>
> abs(three) == three   # true
> -seven == MyInt16(-7) # true
>
>
> @delegate_oneField_fromTwoVars_asType( MyInt16, value, [ (+), (*) ] )
>
> three + seven == MyInt16(3+7) # true
> three * seven == MyInt16(3*7) # true
>
>
>
>
>
>

[julia-users] ANN: DelegationMacros v0.0.3

[Jeffrey Sarnoff]

This offers updated macros to assist with delegating into/through fields of 
a defined type.  

Two macros apply a function to field value(s) yielding the functional 
result; 
and two others do that and then rewrap the result in the source type.

The exports are:
   @delegate_oneField, 
   @delegate_oneField_fromTwoVars,
   @delegate_oneField_asType, 
   @delegate_oneField_fromTwoVars_asType

They work so:

import Base:string, show, (<), (<=), abs, (-), (+), (*)

immutable MyInt16
   value::Int16
end

three = MyInt16(3)
seven = MyInt16(7)


@delegate_oneField( MyInt16, value, [string, show])

string(three) == "3"  # true
show(seven)   # 7


@delegate_oneField_fromTwoVars( MyInt16, value, [ (<), (<=) ] )

three <  seven# true
seven <= seven# true


@delegate_oneField_asType( MyInt16, value, [abs, (-)])

abs(three) == three   # true
-seven == MyInt16(-7) # true


@delegate_oneField_fromTwoVars_asType( MyInt16, value, [ (+), (*) ] )

three + seven == MyInt16(3+7) # true
three * seven == MyInt16(3*7) # true

Re: [julia-users] METADATA madness (my fault)

[Jeffrey Sarnoff]

fabulous!

On Tuesday, September 6, 2016 at 3:20:57 AM UTC-4, Shashi Gowda wrote:
>
> It looks like some changes left behind by a half-done Pkg.tag are causing 
> this problem. These steps should get things back to normal, and publish 
> the new tag.
>
> 1. rm METADATA/ArbFloats -rf
>
> 2. git checkout METADATA/ArbFloats # if this directory did exist before 
> you tried to tag
>
> 3. I also suggest you then make sure you're on the latest commit on 
> JuliaLang/METADATA.jl repository:
> git fetch origin
> git checkout -b arb-floats origin/metadata-v2
> this is required if your previous failed attempt left behind a commit.
>
> 4. Note that if you tried PkgDev.tag previously, you will have a tag in 
> your ArbFloats repository. You will need to remove that with git tag 
> --delete vX.Y.Z before performing PkgDev.tag(...) to get you the correct 
> new tag.
>
> 5. You're good to do PkgDev.tag("ArbFloats", :minor)
>
> 6. Finally push your new tag to your ArbFloats repository -- git push 
> origin vX.Y.Z
>
> 7. make a METADATA PR from your fork of METADATA.jl
>
>
> On Tue, Sep 6, 2016 at 12:03 PM, Jeffrey Sarnoff <jeffrey...@gmail.com 
> > wrote:
>
>> I have yet to enter my package into the Julia ecosystem by publishing it 
>> or manually forking METADATA etc.
>> As I was about to do that, I managed to destroy my local METADATA for the 
>> package. I can, by erasing the entry in METADATA (& cache & lib)
>> use PkgDev to re-register the package, but when  I try to tag it, it gets 
>> all upset 
>>
>> julia> PkgDev.tag("ArbFloats") # or julia> PkgDev.tag("ArbFloats",:minor)
>>
>> ERROR: METADATA/ArbFloats is dirty – commit or stash changes to tag
>>  in #36 at /home/jas/.julia/v0.5/PkgDev/src/entry.jl:223 [inlined]
>>  in with(::PkgDev.Entry.##36#44{String}, ::Base.LibGit2.GitRepo) at 
>> ./libgit2/types.jl:638
>>  in tag(::String, ::Symbol, ::Bool, ::String) at 
>> /home/jas/.julia/v0.5/PkgDev/src/entry.jl:222
>>  in 
>> (::Base.Pkg.Dir.##2#3{Array{Any,1},PkgDev.Entry.#tag,Tuple{String,Symbol}})()
>>  
>> at ./pkg/dir.jl:31
>>  in 
>> cd(::Base.Pkg.Dir.##2#3{Array{Any,1},PkgDev.Entry.#tag,Tuple{String,Symbol}},
>>  
>> ::String) at ./file.jl:59
>>  in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, 
>> ::Vararg{Any,N}) at ./pkg/dir.jl:31
>>  in tag(::String, ::Symbol) at 
>> /home/jas/.julia/v0.5/PkgDev/src/PkgDev.jl:47
>>
>>
>>
>> What is the remedy?
>>
>>
>>
>

[julia-users] METADATA madness (my fault)

[Jeffrey Sarnoff]

I have yet to enter my package into the Julia ecosystem by publishing it or 
manually forking METADATA etc.
As I was about to do that, I managed to destroy my local METADATA for the 
package. I can, by erasing the entry in METADATA (& cache & lib)
use PkgDev to re-register the package, but when  I try to tag it, it gets 
all upset 

julia> PkgDev.tag("ArbFloats") # or julia> PkgDev.tag("ArbFloats",:minor)

ERROR: METADATA/ArbFloats is dirty – commit or stash changes to tag
 in #36 at /home/jas/.julia/v0.5/PkgDev/src/entry.jl:223 [inlined]
 in with(::PkgDev.Entry.##36#44{String}, ::Base.LibGit2.GitRepo) at 
./libgit2/types.jl:638
 in tag(::String, ::Symbol, ::Bool, ::String) at 
/home/jas/.julia/v0.5/PkgDev/src/entry.jl:222
 in 
(::Base.Pkg.Dir.##2#3{Array{Any,1},PkgDev.Entry.#tag,Tuple{String,Symbol}})() 
at ./pkg/dir.jl:31
 in 
cd(::Base.Pkg.Dir.##2#3{Array{Any,1},PkgDev.Entry.#tag,Tuple{String,Symbol}}, 
::String) at ./file.jl:59
 in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, 
::Vararg{Any,N}) at ./pkg/dir.jl:31
 in tag(::String, ::Symbol) at /home/jas/.julia/v0.5/PkgDev/src/PkgDev.jl:47



What is the remedy?

Re: [julia-users] New to Julia - Need some basic help

[Jeffrey Sarnoff]

and before all that, start with `julia> Pkg.update()`

On Monday, September 5, 2016 at 5:47:10 PM UTC-4, Jeffrey Sarnoff wrote:
>
> Not easy to know what's happening there.
> You might try:
>
> julia> quit()
> julia> Pkg.rm("Cairo");Pkg.rm("Cairo");
> julia> Pkg.add("Cairo")
> julia> Pkg.build("Cairo")
> julia> quit()
> julia> using Cairo
>
>
> if there are error messages, post 'em
> otherwise do the same substituting "Tk" for "Cairo"
> if there are error messages, post 'em
>
>
> On Saturday, September 3, 2016 at 2:13:28 PM UTC-4, Pigskin Ablanket wrote:
>>
>> meh - errors running the Pkg.
>>
>> On Saturday, September 3, 2016 at 1:53:01 PM UTC-4, Chris Rackauckas 
>> wrote:
>>>
>>> Pkg.build("Package") will build the binaries for the package. You should 
>>> run it since the package is saying it needs you to do it. Generally, 
>>> packages which have a lot of binary dependencies (i.e. ones that link to 
>>> C/C++ libraries) will require some form of building.
>>>
>>> On Saturday, September 3, 2016 at 10:49:36 AM UTC-7, Pigskin Ablanket 
>>> wrote:
>>>>
>>>> Haha - good question.  Didnt know what Pkg.Build("Cairo") meant - so I 
>>>> havent run that yet.  Should I do that?
>>>>
>>>> On Saturday, September 3, 2016 at 12:33:47 PM UTC-4, Chris Rackauckas 
>>>> wrote:
>>>>>
>>>>> Did it build correctly after using Pkg.build("Cairo")?
>>>>>
>>>>> On Saturday, September 3, 2016 at 8:33:16 AM UTC-7, Pigskin Ablanket 
>>>>> wrote:
>>>>>>
>>>>>> So I tried all of this, but it looks like there was an error loading 
>>>>>> the TK package.  When I went to use Tk I got the following error message:
>>>>>>
>>>>>> ERROR: LoadError: Cairo Package not properly installed. Please run 
>>>>>> Pkg.build("Cairo") in error at error jl:22 while loading.  
>>>>>>
>>>>>> On Thursday, August 25, 2016 at 1:06:49 AM UTC-4, Jeffrey Sarnoff 
>>>>>> wrote:
>>>>>>>
>>>>>>> (before all that, rename the file to something simple like 
>>>>>>> "everyday.jl")
>>>>>>>
>>>>>>> On Thursday, August 25, 2016 at 1:05:20 AM UTC-4, Jeffrey Sarnoff 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> on an empty area of the windows desktop, RIGHT-CLICK and select new 
>>>>>>>> > shortcut.
>>>>>>>>   where it says type the location of the item, type
>>>>>>>> C:\\Users\\JHerron\\Documents\\Documents\\
>>>>>>>> Personal\\DFS\\NHL\\Julia\\code_for_Github.jl
>>>>>>>>  then click on next
>>>>>>>>
>>>>>>>> start Julia
>>>>>>>> julia> Pkg.update() # ignore everything, let it finish
>>>>>>>> julia> Pkg.add("Tk") # ignore everything, let it finish
>>>>>>>> julia> quit()
>>>>>>>>
>>>>>>>> start Julia
>>>>>>>> julia> using Tk
>>>>>>>> julia> include(GetOpenFile())   
>>>>>>>> # go to the desktop, select the shortcut you made
>>>>>>>> # that code file should load and run
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wednesday, August 24, 2016 at 7:57:30 AM UTC-4, j verzani wrote:
>>>>>>>>>
>>>>>>>>> I haven't tested it on Windows, but the `Tk` package has 
>>>>>>>>> `GetOpenFile()` that should allow for a dialog to navigate the file 
>>>>>>>>> system. 
>>>>>>>>> Something like `include(GetOpenFile())` should work.
>>>>>>>>>
>>>>>>>>> On Wednesday, August 24, 2016 at 7:40:10 AM UTC-4, Pigskin 
>>>>>>>>> Ablanket wrote:
>>>>>>>>>>
>>>>>>>>>> Looks like his comment got deleted.  Will try it today and follow 
>>>>>>>>>> up.  Thanks again for all the help
>>>>>>>>>>
>>>>>>>>>> On Tuesday, August 23, 2016 a

Re: [julia-users] New to Julia - Need some basic help

[Jeffrey Sarnoff]

Not easy to know what's happening there.
You might try:

julia> quit()
julia> Pkg.rm("Cairo");Pkg.rm("Cairo");
julia> Pkg.add("Cairo")
julia> Pkg.build("Cairo")
julia> quit()
julia> using Cairo


if there are error messages, post 'em
otherwise do the same substituting "Tk" for "Cairo"
if there are error messages, post 'em


On Saturday, September 3, 2016 at 2:13:28 PM UTC-4, Pigskin Ablanket wrote:
>
> meh - errors running the Pkg.
>
> On Saturday, September 3, 2016 at 1:53:01 PM UTC-4, Chris Rackauckas wrote:
>>
>> Pkg.build("Package") will build the binaries for the package. You should 
>> run it since the package is saying it needs you to do it. Generally, 
>> packages which have a lot of binary dependencies (i.e. ones that link to 
>> C/C++ libraries) will require some form of building.
>>
>> On Saturday, September 3, 2016 at 10:49:36 AM UTC-7, Pigskin Ablanket 
>> wrote:
>>>
>>> Haha - good question.  Didnt know what Pkg.Build("Cairo") meant - so I 
>>> havent run that yet.  Should I do that?
>>>
>>> On Saturday, September 3, 2016 at 12:33:47 PM UTC-4, Chris Rackauckas 
>>> wrote:
>>>>
>>>> Did it build correctly after using Pkg.build("Cairo")?
>>>>
>>>> On Saturday, September 3, 2016 at 8:33:16 AM UTC-7, Pigskin Ablanket 
>>>> wrote:
>>>>>
>>>>> So I tried all of this, but it looks like there was an error loading 
>>>>> the TK package.  When I went to use Tk I got the following error message:
>>>>>
>>>>> ERROR: LoadError: Cairo Package not properly installed. Please run 
>>>>> Pkg.build("Cairo") in error at error jl:22 while loading.  
>>>>>
>>>>> On Thursday, August 25, 2016 at 1:06:49 AM UTC-4, Jeffrey Sarnoff 
>>>>> wrote:
>>>>>>
>>>>>> (before all that, rename the file to something simple like 
>>>>>> "everyday.jl")
>>>>>>
>>>>>> On Thursday, August 25, 2016 at 1:05:20 AM UTC-4, Jeffrey Sarnoff 
>>>>>> wrote:
>>>>>>>
>>>>>>> on an empty area of the windows desktop, RIGHT-CLICK and select new 
>>>>>>> > shortcut.
>>>>>>>   where it says type the location of the item, type
>>>>>>> C:\\Users\\JHerron\\Documents\\Documents\\
>>>>>>> Personal\\DFS\\NHL\\Julia\\code_for_Github.jl
>>>>>>>  then click on next
>>>>>>>
>>>>>>> start Julia
>>>>>>> julia> Pkg.update() # ignore everything, let it finish
>>>>>>> julia> Pkg.add("Tk") # ignore everything, let it finish
>>>>>>> julia> quit()
>>>>>>>
>>>>>>> start Julia
>>>>>>> julia> using Tk
>>>>>>> julia> include(GetOpenFile())   
>>>>>>> # go to the desktop, select the shortcut you made
>>>>>>> # that code file should load and run
>>>>>>>
>>>>>>>
>>>>>>> On Wednesday, August 24, 2016 at 7:57:30 AM UTC-4, j verzani wrote:
>>>>>>>>
>>>>>>>> I haven't tested it on Windows, but the `Tk` package has 
>>>>>>>> `GetOpenFile()` that should allow for a dialog to navigate the file 
>>>>>>>> system. 
>>>>>>>> Something like `include(GetOpenFile())` should work.
>>>>>>>>
>>>>>>>> On Wednesday, August 24, 2016 at 7:40:10 AM UTC-4, Pigskin Ablanket 
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Looks like his comment got deleted.  Will try it today and follow 
>>>>>>>>> up.  Thanks again for all the help
>>>>>>>>>
>>>>>>>>> On Tuesday, August 23, 2016 at 10:44:19 PM UTC-4, Jeffrey Sarnoff 
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> As Steven mentioned, starting the program from the directory 
>>>>>>>>>> where the files reside allows you to include the file using its 
>>>>>>>>>> filename 
>>>>>>>>>> without the full path.  If that is easy for you, it is probably 
>>>>>>

[julia-users] Re: Running Julia in Ubuntu

[Jeffrey Sarnoff]

click on this  
   (doing that should start the downloading of a prebuit-for-arm copy of 
the development version of julia 
  usually, you would not want the development version -- here, 
the alternative is to rebuild julia 
  and that is something you may not want to do even more than 
using a development version. )
when the file finishes downloading, click the file to decompress its 
contents into a directory of your choice
   (if you have no preference, use the default directory it offers .. but 
add (without the quotes) "/julia")
after the file expands, go into the julia directory and find the 
subdirectory "bin" in that subdirectory
   there should be a file named julia.  That is the one to run to start 
Julia.

I am not familiar with the Arm stuff -- if you have additional questions, 
post them here (along with any
  helpful context) and someone else is likely to continue on.



On Wednesday, August 31, 2016 at 4:49:13 PM UTC-4, Angshuman Goswami wrote:
>
> I don't know how to do this manually. can you please guide.
>
> On Wednesday, August 31, 2016 at 2:54:38 AM UTC-4, Lutfullah Tomak wrote:
>>
>> You are on an arm cpu so Conda cannot install python for you. Also, you 
>> tried downloading x86 cpu linux binaries, instead try arm nightlies.
>> To get away with PyCall issues you have to manually install all 
>> depencies. 
>>
>> On Wednesday, August 31, 2016 at 7:53:24 AM UTC+3, Angshuman Goswami 
>> wrote:
>>>
>>> When i performed build again errors cropped up.
>>>
>>> Pkg.build("PyCall")
>>> WARNING: unable to determine host cpu name.
>>> INFO: Building PyCall
>>> INFO: No system-wide Python was found; got the following error:
>>> could not spawn `/usr/local/lib/python2.7 -c "import 
>>> distutils.sysconfig; 
>>> print(distutils.sysconfig.get_config_var('VERSION'))"`: permission denied 
>>> (EACCES)
>>> using the Python distribution in the Conda package
>>> INFO: Downloading miniconda installer ...
>>>   % Total% Received % Xferd  Average Speed   TimeTime Time  
>>> Current
>>>  Dload  Upload   Total   SpentLeft  
>>> Speed
>>> 100 24.7M  100 24.7M0 0  2401k  0  0:00:10  0:00:10 --:--:-- 
>>> 2743k
>>> INFO: Installing miniconda ...
>>> PREFIX=/home/odroid/.julia/v0.4/Conda/deps/usr
>>> installing: _cache-0.0-py27_x0 ...
>>> installing: python-2.7.11-0 ...
>>> installing: conda-env-2.4.5-py27_0 ...
>>> installing: openssl-1.0.2g-0 ...
>>> installing: pycosat-0.6.1-py27_0 ...
>>> installing: pyyaml-3.11-py27_1 ...
>>> installing: readline-6.2-2 ...
>>> installing: requests-2.9.1-py27_0 ...
>>> installing: sqlite-3.9.2-0 ...
>>> installing: tk-8.5.18-0 ...
>>> installing: yaml-0.1.6-0 ...
>>> installing: zlib-1.2.8-0 ...
>>> installing: conda-4.0.5-py27_0 ...
>>> installing: pycrypto-2.6.1-py27_0 ...
>>> installing: pip-8.1.1-py27_1 ...
>>> installing: wheel-0.29.0-py27_0 ...
>>> installing: setuptools-20.3-py27_0 ...
>>> /home/odroid/.julia/v0.4/Conda/deps/usr/installer.sh: line 288: 
>>> /home/odroid/.julia/v0.4/Conda/deps/usr/pkgs/python-2.7.11-0/bin/python: 
>>> cannot execute binary file: Exec format error
>>> ERROR:
>>> cannot execute native linux-32 binary, output from 'uname -a' is:
>>> Linux odroid 3.10.69 #1 SMP PREEMPT Thu Feb 12 15:22:14 BRST 2015 armv7l 
>>> armv7l armv7l GNU/Linux
>>> ===[ ERROR: PyCall 
>>> ]
>>>
>>> LoadError: failed process: 
>>> Process(`/home/odroid/.julia/v0.4/Conda/deps/usr/installer.sh -b -f -p 
>>> /home/odroid/.julia/v0.4/Conda/deps/usr`, ProcessExited(1)) [1]
>>> while loading /home/odroid/.julia/v0.4/PyCall/deps/build.jl, in 
>>> expression starting on line 17
>>>
>>>
>>> 
>>>
>>> [ BUILD ERRORS 
>>> ]
>>>
>>> WARNING: PyCall had build errors.
>>>
>>>  - packages with build errors remain installed in 
>>> /home/odroid/.julia/v0.4
>>>  - build the package(s) and all dependencies with `Pkg.build("PyCall")`
>>>  - build a single package by running its `deps/build.jl` script
>>>
>>>
>>> 
>>>
>>>
>>> On Wednesday, August 31, 2016 at 12:08:33 AM UTC-4, Angshuman Goswami 
>>> wrote:

 julia> Pkg.status()
 7 required packages:
  - AmplNLWriter  0.2.2
  - CoinOptServices   0.1.2
  - IJulia1.2.0
  - Ipopt 0.2.4
  - JuMP  0.14.0
  - PyCall1.7.1
  - RobotOS   0.4.1
 19 additional packages:
  - BinDeps   0.4.3
  - Calculus  0.1.15
  - Cbc   0.2.3
  - Clp   0.2.2
  - 

[julia-users] Re: Announcing TensorFlow.jl, an interface to Google's TensorFlow machine learning library

[Jeffrey Sarnoff]

 This is very nice, Jon.



(interested parties)

regards,

 Jeffrey