Re: [julia-users] Re: Homebrew problem(?): Can't add or build Gtk

[Christoph Ortner]

done

https://github.com/JuliaLang/Gtk.jl/issues/186

On Sunday, 27 September 2015 11:28:33 UTC+1, Tim Holy wrote:
>
> On Sunday, September 27, 2015 03:04:03 AM Christoph Ortner wrote: 
> > I had the same happen to me. 
> > Christoph 
>
> Please do post an issue over at https://github.com/JuliaLang/Gtk.jl; 
> Elliot is 
> very responsive about Homebrew-related issues, but not everyone reads 
> julia- 
> users carefully. 
>
> Best, 
> --Tim 
>

Re: [julia-users] Pkg.[update()/install()/build()] woes on Windows 10 64 bit

[Evan Fields]

Deleted everything in the .cache folder. Now new exciting errors on 
Pkg.update():

   _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.3.11 (2015-07-27 06:18 UTC)
 _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
|__/   |  x86_64-w64-mingw32

julia> Pkg.update()
INFO: Updating METADATA...
INFO: Cloning cache of Hexagons from 
git://github.com/dcjones/Hexagons.jl.git
INFO: Cloning cache of Images from git://github.com/timholy/Images.jl.git
INFO: Cloning cache of Contour from git://github.com/tlycken/Contour.jl.git
INFO: Cloning cache of Lazy from 
git://github.com/one-more-minute/Lazy.jl.git
INFO: Cloning cache of Requires from 
git://github.com/one-more-minute/Requires.jl.git
INFO: Cloning cache of ArrayViews from 
git://github.com/JuliaLang/ArrayViews.jl.git
INFO: Cloning cache of Gadfly from git://github.com/dcjones/Gadfly.jl.git
INFO: Cloning cache of BinDeps from 
git://github.com/JuliaLang/BinDeps.jl.git
INFO: Cloning cache of ImmutableArrays from 
git://github.com/JuliaGeometry/ImmutableArrays.jl.git
INFO: Cloning cache of StatsBase from 
git://github.com/JuliaStats/StatsBase.jl.git
INFO: Cloning cache of Graphics from 
git://github.com/JuliaLang/Graphics.jl.git
INFO: Cloning cache of MacroTools from 
git://github.com/one-more-minute/MacroTools.jl.git
INFO: Cloning cache of URIParser from 
git://github.com/JuliaWeb/URIParser.jl.git
INFO: Cloning cache of DataFrames from 
git://github.com/JuliaStats/DataFrames.jl.git
INFO: Cloning cache of Distributions from 
git://github.com/JuliaStats/Distributions.jl.git
INFO: Cloning cache of FactCheck from 
git://github.com/JuliaLang/FactCheck.jl.git
INFO: Cloning cache of Dates from git://github.com/quinnj/Dates.jl.git
INFO: Cloning cache of NaNMath from git://github.com/mlubin/NaNMath.jl.git
INFO: Cloning cache of DataArrays from 
git://github.com/JuliaStats/DataArrays.jl.git
INFO: Cloning cache of Grid from git://github.com/timholy/Grid.jl.git
INFO: Cloning cache of Loess from git://github.com/dcjones/Loess.jl.git
INFO: Cloning cache of Compose from git://github.com/dcjones/Compose.jl.git
INFO: Cloning cache of FixedPointNumbers from 
git://github.com/JeffBezanson/FixedPointNumbers.jl.git
INFO: Cloning cache of Compat from git://github.com/JuliaLang/Compat.jl.git
INFO: Cloning cache of SHA from git://github.com/staticfloat/SHA.jl.git
INFO: Cloning cache of Iterators from 
git://github.com/JuliaLang/Iterators.jl.git
INFO: Cloning cache of Color from git://github.com/JuliaLang/Color.jl.git
INFO: Cloning cache of WoodburyMatrices from 
git://github.com/timholy/WoodburyMatrices.jl.git
INFO: Cloning cache of JuliaParser from 
git://github.com/jakebolewski/JuliaParser.jl.git
INFO: Cloning cache of JSON from git://github.com/JuliaLang/JSON.jl.git
INFO: Cloning cache of Codecs from git://github.com/dcjones/Codecs.jl.git
INFO: Cloning cache of GZip from git://github.com/JuliaLang/GZip.jl.git
INFO: Cloning cache of TexExtensions from 
git://github.com/Keno/TexExtensions.jl.git
INFO: Cloning cache of KernelDensity from 
git://github.com/JuliaStats/KernelDensity.jl.git
INFO: Cloning cache of Distances from 
git://github.com/JuliaStats/Distances.jl.git
INFO: Cloning cache of Reexport from 
git://github.com/simonster/Reexport.jl.git
INFO: Cloning cache of DataStructures from 
git://github.com/JuliaLang/DataStructures.jl.git
INFO: Cloning cache of Showoff from git://github.com/dcjones/Showoff.jl.git
INFO: Cloning cache of Optim from git://github.com/JuliaOpt/Optim.jl.git
INFO: Cloning cache of SortingAlgorithms from 
git://github.com/JuliaLang/SortingAlgorithms.jl.git
INFO: Cloning cache of Docile from 
git://github.com/MichaelHatherly/Docile.jl.git
INFO: Cloning cache of SIUnits from git://github.com/Keno/SIUnits.jl.git
INFO: Cloning cache of Zlib from git://github.com/dcjones/Zlib.jl.git
INFO: Cloning cache of LNR from git://github.com/one-more-minute/LNR.jl.git
INFO: Cloning cache of Calculus from 
git://github.com/johnmyleswhite/Calculus.jl.git
INFO: Cloning cache of PDMats from git://github.com/JuliaStats/PDMats.jl.git
INFO: Cloning cache of DualNumbers from 
git://github.com/JuliaDiff/DualNumbers.jl.git
INFO: Cloning cache of Jewel from 
git://github.com/one-more-minute/Jewel.jl.git
INFO: Computing changes...
INFO: Cloning cache of ColorTypes from 
git://github.com/JuliaGraphics/ColorTypes.jl.git
INFO: Cloning cache of ColorVectorSpace from 
git://github.com/JuliaGraphics/ColorVectorSpace.jl.git
INFO: Cloning cache of Colors from 
git://github.com/JuliaGraphics/Colors.jl.git
INFO: Cloning cache of HttpCommon from 
git://github.com/JuliaWeb/HttpCommon.jl.git
INFO: Cloning cache of StatsFuns from 
git://github.com/JuliaStats/StatsFuns.jl.git
INFO: Upgrading ArrayViews: v0.6.2 => v0.6.4
error: unable to create directory for 

[julia-users] Will Julia likely ever allow negative indexing of arrays

[Mark Sherlock]

Hi,

I work in computational physics. The main reason we all use Fortran in my 
area is because it allows arrays to have negative indices. This is very 
useful when solving some partial differential equations (in e.g. plasma 
physics, astrophysics, fluid mechanics).

I and my colleagues frequently consider alternative languages but in the 
end never change due to the headaches involved regarding this. Since Julia 
seems to be focused on computational science,
I am wondering how likely it is that this would ever be implemented, and/or 
how we could encourage the developers to do this?

In all other areas Julia looks fantastic for our needs!

[julia-users] Re: UTF16String or UTF8String?

[Páll Haraldsson]

UTF-16 was earlier (strictly speaking UCS-2) and Windows adopted it (and 
also used elsewhere..). UTF-8 is almost in all cases better (except in 
East-Asian languages, but not even there, if you use, something HTML (or I 
guess XML..), that has has lots of ASCII for tags etc.):

http://utf8everywhere.org/

-- 
Palli.

On Sunday, September 27, 2015 at 6:14:34 PM UTC, Daniel Carrera wrote:
>
> Hello,
>
> I just read of Wikipedia that UTF16 is not compatible with ASCII, but UTF8 
> is a proper super-set of ASCII. If that's the case, why would anyone use 
> UTF16String instead of UTF8String? It seems like UTF8 has the lowest 
> probability of creating hassle down the road. Every valid ASCII string is a 
> valid UTF8 string. But at the same time, presumably UTF16 would not have 
> been invented if it didn't serve some purpose. Does anyone know what the 
> advantage of UTF16 is?
>
> Cheers,
> Daniel.
>

Re: [julia-users] Will Julia likely ever allow negative indexing of arrays

[Tom Breloff]

Do you need the bracket notarion 'x[-5]'? This would be best implemented as
a package with explicit get/set, as Matt implied... As otherwise you risk
some tricky bugs. Also if you're implementing "array-like" types, I would
definitely use 0.4+.

On Sunday, September 27, 2015, Matt Bauman  wrote:

> There has been a lot of discussion about this in the past few weeks
>
> https://groups.google.com/d/msg/julia-users/ScwXMfQIBGs/wD1HTXeZBQAJ
> https://groups.google.com/d/msg/julia-users/fNisYpMdZ6o/DvFaQi_ZBAAJ
>
> TL;DR, yes, it is possible, but it takes some care since it's violating a
> fairly well-entrenched assumption about how arrays behave.
>
> On Sunday, September 27, 2015 at 10:48:22 AM UTC-4, Mark Sherlock wrote:
>>
>> Hi,
>>
>> I work in computational physics. The main reason we all use Fortran in my
>> area is because it allows arrays to have negative indices. This is very
>> useful when solving some partial differential equations (in e.g. plasma
>> physics, astrophysics, fluid mechanics).
>>
>> I and my colleagues frequently consider alternative languages but in the
>> end never change due to the headaches involved regarding this. Since Julia
>> seems to be focused on computational science,
>> I am wondering how likely it is that this would ever be implemented,
>> and/or how we could encourage the developers to do this?
>>
>> In all other areas Julia looks fantastic for our needs!
>>
>

Re: [julia-users] Nesting Macros passing Expressions

[Yichao Yu]

On Sun, Sep 27, 2015 at 12:20 PM, Leonardo  wrote:
> Hi all,
> I need manipulate AST of an expression in a macro, and pass same expression
> in input to another macro, but I experience some problem.
>
> I try to express my doubt with a simplified example:
> macro tst2(e2::Expr)
> println(e2.head)
> end
>
> macro tst(e1::Expr)
> @tst2 esc(e1)
> end

```
macro tst(e1::Expr)
quote
@tst2 $(esc(e1))
end
end
```

otherwise, `@tst2` will be run at `tst` definition time.

> In previous code I want that call to @tst2 behave exact like call to @tst.
>
> E.g. calling @tst2 in REPL I obtain:
> julia> a = 2
> julia> @tst2(a < 3)
> comparison
> but same call to @tst has no effect, and I cannot find an alternative
> working form for @tst
>
> Someone can help me to understand this odd behaviour of Julia's macro?
>
> Many thanks in advance
>
> Leonardo
>

[julia-users] Re: API deployments on JuliaBox

[Miguel Belbut Gaspar]

Hi,

Thanks for this, it is a very interesting feature.

I think I have the same question as the previous post, which I think wasn't 
addressed by tanmaykm's answer:

Is the server created per-user? If I expose a ls() command, will it list my 
own account home files?
I tried using require(Juliaset.jl/src/Juliaset.jl) instead of 
Pkg.clone(...) as the API command, after having sync'ed the Juliaset.jl git 
to my Juliabox account, but that doesn't seem to work.

Is that by design, i.e., the APIs must have publicly-available source?
Or is it just a current limitation and if so, are there any plans to allow 
using non-public repos or source files in  some way?

Cheers,

Miguel

On Tuesday, September 15, 2015 at 11:44:55 AM UTC+1, tanmaykm wrote:
>
> Hi,
>
> yes, that's right. The APIs will let you share useful functionalities as 
> REST APIs to other users.
>
> The API published with name "list_it" can be accessed at 
> https://api.juliabox.org/list_it/...
> The "..." above refer to the exact method being called and the parameters 
> it expects.
> From anywhere (including from within the JuliaBox container), any 
> mechanism to invoke HTTP can be used.
> All APIs are accessible to everyone, unless the API implementation imposes 
> some authorization.
>
> a couple of examples of JuliaBox APIs can be found at:
> - https://github.com/tanmaykm/Juliaset.jl
> - https://github.com/tanmaykm/JuliaWebAPI.jl
>
> Best,
> Tanmay
>
>>
>>

[julia-users] UTF16String or UTF8String?

[Daniel Carrera]

Hello,

I just read of Wikipedia that UTF16 is not compatible with ASCII, but UTF8 
is a proper super-set of ASCII. If that's the case, why would anyone use 
UTF16String instead of UTF8String? It seems like UTF8 has the lowest 
probability of creating hassle down the road. Every valid ASCII string is a 
valid UTF8 string. But at the same time, presumably UTF16 would not have 
been invented if it didn't serve some purpose. Does anyone know what the 
advantage of UTF16 is?

Cheers,
Daniel.

Re: [julia-users] Pkg.[update()/install()/build()] woes on Windows 10 64 bit

[Tony Kelman]

Not sure what's wrong but your local copies of some packages are in a corrupt 
state. Assuming you haven't made any local modifications to any packages that 
you want to preserve, it is safe to delete any problematic packages from 
.julia, then running Pkg.update() or Pkg.resolve() will put back clean copies 
of them.

Re: [julia-users] Why is String deprecated in favour of AbstractString?

[Milan Bouchet-Valat]

Le dimanche 27 septembre 2015 à 11:00 +0200, Daniel Carrera a écrit :
> 
> On 27 September 2015 at 10:39, Milan Bouchet-Valat  > wrote:
> >  Then the default concrete type can be called String or Str, and
> > that's
> > what people will use. Calling the abstract type String was
> > confusing as
> > it could prompt people to write type-unstable fields believing that
> > it
> > was the concrete one.
> 
> So... it would be a good idea if I made an alias to a concrete type
> the way Gabor did?
> 
> typealias String UTF8String
Since I'm not sure the name of the new string type is fully settled
yet, I would continue using UTF8String for now. Changing is just a
matter of a mass replacement anyway.


Regards

> Is there a reason to use ASCIIString instead of UTF8String? They are
> both concrete types, but UTF8 allows me to include greek characters.
> 
> Cheers,
> Daniel.
> 
> 

[julia-users] Re: Will Julia likely ever allow negative indexing of arrays

[Daniel Carrera]

I don't know anything about PDEs for plasma physics, but you made me 
curious. What do you use negative indices for? Are arrays supposed to wrap 
around?

You can currently use the `end` keyword to write `foo[end-5]`, but I assume 
that this is not useful to you. Right?


On Sunday, 27 September 2015 16:48:22 UTC+2, Mark Sherlock wrote:
>
> Hi,
>
> I work in computational physics. The main reason we all use Fortran in my 
> area is because it allows arrays to have negative indices. This is very 
> useful when solving some partial differential equations (in e.g. plasma 
> physics, astrophysics, fluid mechanics).
>
> I and my colleagues frequently consider alternative languages but in the 
> end never change due to the headaches involved regarding this. Since Julia 
> seems to be focused on computational science,
> I am wondering how likely it is that this would ever be implemented, 
> and/or how we could encourage the developers to do this?
>
> In all other areas Julia looks fantastic for our needs!
>

[julia-users] Re: Julia code 5x to 30x slower than Matlab code

[Marcio Sales]

>
> I hope to have a release version in about a month, which is the estimated 
> time for releasing GMT5.2. There are still several issues from the GMT side 
> but overall most of it works already. Feel free to test it (see the 
> gallery.jl for several usage examples) but note that you'll have to install 
> and build GMT5.2svn yourself. And I only tested it on Windows.
>

Ok. Will Windows binaries be available then? I use windows and 
unfortunately can't install the dependencies required to build in the 
computer I work on. 

[julia-users] Nesting Macros passing Expressions

[Leonardo]

Hi all,
I need manipulate AST of an expression in a macro, and pass same expression 
in input to another macro, but I experience some problem.

I try to express my doubt with a simplified example:
macro tst2(e2::Expr)
println(e2.head)
end

macro tst(e1::Expr)
@tst2 esc(e1)
end
In previous code I want that call to @tst2 behave exact like call to @tst.

E.g. calling @tst2 in REPL I obtain:
julia> a = 2
julia> @tst2(a < 3)
comparison
but same call to @tst has no effect, and I cannot find an alternative 
working form for @tst

Someone can help me to understand this odd behaviour of Julia's macro?

Many thanks in advance

Leonardo

[julia-users] Re: Will Julia likely ever allow negative indexing of arrays

[Matt Bauman]

There has been a lot of discussion about this in the past few weeks

https://groups.google.com/d/msg/julia-users/ScwXMfQIBGs/wD1HTXeZBQAJ
https://groups.google.com/d/msg/julia-users/fNisYpMdZ6o/DvFaQi_ZBAAJ

TL;DR, yes, it is possible, but it takes some care since it's violating a 
fairly well-entrenched assumption about how arrays behave.

On Sunday, September 27, 2015 at 10:48:22 AM UTC-4, Mark Sherlock wrote:
>
> Hi,
>
> I work in computational physics. The main reason we all use Fortran in my 
> area is because it allows arrays to have negative indices. This is very 
> useful when solving some partial differential equations (in e.g. plasma 
> physics, astrophysics, fluid mechanics).
>
> I and my colleagues frequently consider alternative languages but in the 
> end never change due to the headaches involved regarding this. Since Julia 
> seems to be focused on computational science,
> I am wondering how likely it is that this would ever be implemented, 
> and/or how we could encourage the developers to do this?
>
> In all other areas Julia looks fantastic for our needs!
>

Re: [julia-users] Saving complex type to a file

[Marc Stein]

Thanks! That helped quite a bit, I'm further along. Not quite working yet, 
but closer.

On Sunday, September 27, 2015 at 6:33:50 AM UTC-4, Tim Holy wrote:
>
> You can try JLD.jl. 
>
> --Tim 
>
> On Saturday, September 26, 2015 05:31:18 PM Marc Stein wrote: 
> > I'm just starting out with Julia, so please forgive me if this is a 
> > simplistic question. 
> > 
> > I'm using the DecisionTree package which generates an Ensemble of 
> > DecisionTrees in the code below: 
> > 
> > 
> > ## 
> > 
> > using DataFrames 
> > using DecisionTree 
> > 
> > clarity = readtable("/Users/marcstein/Active/julia/clarity.csv"); 
> > head(clarity) 
> > 
> > labels = array(clarity[:, 41]); 
> > features = array(clarity[:, 1:40]); 
> > 
> > # Random Forest Classifier 
> > 
> > # train random forest classifier 
> > # using 2 random features, 10 trees, and 0.5 portion of samples per tree 
> > (optional) 
> > 
> > model = build_forest(labels, features, 2, 10, 0.5) 
> > 
> > # apply learned model 
> > 
> > outcome = apply_forest(model, 
> > 
> [2,761,0,0,2,1.32,74,0,365,3,2,15,10,1,0,1,24,36,2000,0,1,1,0,0,0,1,0,0,0,1, 
>
> > 5,1,0,2,0,2,220,221,220,221]) 
> > 
> > # # run n-fold cross validation for forests 
> > # # using 2 random features, 10 trees, 3 folds and 0.5 of samples per 
> tree 
> > (optional) 
> > 
> > accuracy = nfoldCV_forest(labels, features, 2, 10, 3, 0.5) 
> > 
> > score = (mean(accuracy[1:3])) 
> > 
> > println(outcome) 
> > println(score) 
> > 
> > ## 
> > 
> > 
> > This code works fine. But because the DataFrame that is the training set 
> is 
> > quite large, I want to build the model and store it in one app and then 
> > load the model and generate the outcome in a second app. 
> > 
> > It seems like this should be simple, just persist the model in a file 
> and 
> > pass it into the apply_forest method. 
> > 
> > I can't find a way, though, to persist the model. If I try 
> > 
> > writedlm(outfile,model) 
> > 
> > I get: 
> > 
> > EnsembleERROR: `start` has no method matching start(::Ensemble) 
> >  in writedlm at datafmt.jl:535 
> >  in writedlm at datafmt.jl:554 
> > 
> > If I try: 
> > 
> > print(outfile,model) 
> > 
> > the output file contains: 
> > 
> > Ensemble of Decision Trees 
> > Trees:  10 
> > Avg Leaves: 117.8 
> > Avg Depth:  20.8 
> > 
> > which is a summary of the Ensemble, not the individual elements. 
> > 
> > I'm clearly missing something, but I haven't been able to figure it out 
> so 
> > far. 
> > 
> > Any suggestions would be greatly appreciated! 
>
>

Re: [julia-users] Re: @sprintf with a format string

[Scott Jones]

I'm sorry - I meant to test it out right after you submitted the PR, I *do* 
think you are on the right track,
but I've been caught up in the fun of writing code for my happy Belgian 
company (luckily, it's in Julia),
and we hadn't gotten to the point where we needed nice formatting yet.

I've since been thinking about having a string macro, that would have a 
simple syntax for calling your
fmt function (and probably some other goodies):
Something like:
v1 = 10.23
v2 = 1234567
fmt_default!(Int, :commas, width = 12)
println(f"This is a test of formatting <\{v1,3,7}> <\{v2}>")
would print:
This is a test of formatting < 10.230> < 1,234,567>

So that essentially, \{...} is simply a shortcut that acts like $(fmt(...)).

On Tuesday, September 22, 2015 at 10:20:41 AM UTC-4, Tom Breloff wrote:
>
> Chill guys.
>
> Anyways... I started to tackle this problem, but didn't get any (much 
> needed) comments on whether I was on the right track.  Here's some sample 
> preliminary usage of what I was working on.  Please let me know if you 
> think it's worth continuing, and what you'd ideally like to see in a 
> formatter.
>
> https://github.com/tbreloff/Formatting.jl/blob/tom-fmt/test/fmt.jl
>
> On Tue, Sep 22, 2015 at 10:05 AM, Daniel Carrera  > wrote:
>
>> Coding sprintf() is beyond my skill, I tried. My contributions to Julia 
>> have to lie elsewhere (recently I've been putting a lot of time making 
>> mockups of a Julia IDE, and helping a new user port his Matlab code). I 
>> think it is rude to say "if you don't like it, fix it yourself"; especially 
>> after you wrote a post claiming that the non-implementation of sprintf() 
>> was an intentional omission because developers weren't sure how to do it 
>> right. I showed, correctly, that that argument is nonsense; so you spinned 
>> around and changed it to "if you don't like it, fix it yourself". That 
>> answer is only a way to reject valid complaints, and it feels like a thinly 
>> veiled "fuck you". Imagine if that's how people responded in bug reports. 
>> This is not the type of answer that Julia developers normally give, and it 
>> is not the type of answer that I expect in Julia; especially after giving a 
>> very different answer to the same question. I do try to contribute to 
>> Julia, and it is rude and unreasonable to hold me personally responsible 
>> for fixing everything that does not work in Julia. A healthy community 
>> needs room for receiving legitimate complaints.
>>
>> Daniel.
>>
>> On 22 September 2015 at 15:49, Tomas Lycken > > wrote:
>>
>>> > If C can have one, why can't Julia?
>>>
>>> *The hard truth, and nothing but it:* If Julia is missing a feature, or 
>>> has one that works in a way that's not the way you want, it's because 
>>> no-one has wanted what you want enough to actually implement it.
>>>
>>> That's it. There's no "it can't be done" - Julia is Turing complete, so 
>>> "everything" can be done. There's no "it's not allowed" - no-one is 
>>> stopping you from writing your own package, with your own implementation 
>>> that does what you want the way you want it done, putting it in the package 
>>> repository and seeing it take off. Chances are that if you write something 
>>> that it turns out many others want as well, it will be included in the 
>>> default package distribution in the future (or even in base Julia). Or it 
>>> might not take off, but at least be there for your own enjoyment.
>>>
>>> But the entire language, with all tooling, packages, etc - everything 
>>> that is Julia - is very much a community-built product. Everything that is 
>>> there, is there because someone at some point said *hey, this is so 
>>> important to me that I'm going to put it at the very top of my priority 
>>> list*. Creating a sprintf function that fulfills your needs might not 
>>> have made it there for anyone yet. If it's that important to you, maybe 
>>> that's your next contribution?
>>>
>>> // T
>>>
>>> On Tuesday, September 22, 2015 at 3:17:55 PM UTC+2, Daniel Carrera wrote:

 I might be wrong, but to me Formatting.jl looks next to useless. The 
 "sprintf" functions it provides only accept one parameter. The main 
 function provided is `sprintf1()`, but even the very clumsy 
 `generate_formatter()` function fails at the most basic tasks:

 julia> fmtrfunc = generate_formatter( "%10.3f   %6d  %3d" )
 ERROR: Only one AND undecorated format string is allowed
  in generate_formatter at 
 /home/daniel/.julia/v0.3/Formatting/src/cformat.jl:23


 I really don't understand why sprintf() is such a big deal. If C can 
 have one, why can't Julia? I understand the argument that you might want 
 to 
 rewrite the implementation later. Fine. Just call the function 
 "__temp_sprintf()" and put it in a package called 
 "FunctionThatWillGoAwayLater". I don't care. I just want to be able to 
 print formatted strings without a ton 

[julia-users] Re: Will Julia likely ever allow negative indexing of arrays

[John Gibson]

Probably it's for something like indexing by Fourier wavenumber.  You 
represent a real-valued periodic function as a linear combination of 
Fourier modes exp(2 pi i k x/L) where k varies from -K to K-1. The primary 
representation in data is an array of complex coefficients for those modes. 
It might be convenient to index that array using k over the same range. 

Personally, I'm ok with using 0-based or 1-based indices to index into the 
array and translating into Fourier wavenumber as necessary. In C++ I just 
have a couple array index -> wavenumber and wavenumber -> array index 
member functions in my Fourier-expansion classes. 

John

On Sunday, September 27, 2015 at 2:18:08 PM UTC-4, Daniel Carrera wrote:
>
> I don't know anything about PDEs for plasma physics, but you made me 
> curious. What do you use negative indices for? Are arrays supposed to wrap 
> around?
>
> You can currently use the `end` keyword to write `foo[end-5]`, but I 
> assume that this is not useful to you. Right?
>
>
> On Sunday, 27 September 2015 16:48:22 UTC+2, Mark Sherlock wrote:
>>
>> Hi,
>>
>> I work in computational physics. The main reason we all use Fortran in my 
>> area is because it allows arrays to have negative indices. This is very 
>> useful when solving some partial differential equations (in e.g. plasma 
>> physics, astrophysics, fluid mechanics).
>>
>> I and my colleagues frequently consider alternative languages but in the 
>> end never change due to the headaches involved regarding this. Since Julia 
>> seems to be focused on computational science,
>> I am wondering how likely it is that this would ever be implemented, 
>> and/or how we could encourage the developers to do this?
>>
>> In all other areas Julia looks fantastic for our needs!
>>
>

Re: [julia-users] How do I pass an event handle via ccall?

[Spencer Russell]

I’m not that familiar with the FDTI library, but it looks like you’ll need to 
write some platform-specific code (the PDF describes windows and linux code, 
not sure if the linux code is also supposed to work on OSX). So you’d use 
`ccall` to set up the handle as per the FTDI docs. One tricky bit is that it 
looks like the event can get signaled from a separate thread. Julia code should 
not in general get called from a separate thread.

Check out the manual: 
http://julia.readthedocs.org/en/latest/manual/calling-c-and-fortran-code/ 
, 
specifically the part about SingleAsyncWork, which is the mechanism for waking 
up a waiting Julia Task from a different thread.

I have a use case for SingleAsyncWork that I’ll be digging into soon, so I’m 
hoping to add a more concrete example to the docs for it and hopefully make it 
a little easier to make use of it.

-s


> On Sep 27, 2015, at 12:36 PM, Chris Stook  wrote:
> 
> I am wrapping this c library:
> 
> http://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_71).pdf
>  
> 
> 
> The function FT_SetEventNotification requires passing a handle to an event.  
> The closest thing I see in julia is a Condition().  Would it make sense to 
> pass a pointer to a condition to this function?  What is the proper way to 
> handle this?
> 
> Thanks,
> Chris
> 

Re: [julia-users] Re: UTF16String or UTF8String?

[Scott Jones]

On Sunday, September 27, 2015 at 4:56:28 PM UTC-4, Jameson wrote:
>
> UTF-16 is much faster in many situations than UTF-8.
>>
>  
> an encoding is not a speed. it is a format. Both formats are 
> variable-length encodings, and therefore both algorithms have the same time 
> and space complexity (although the implementation of UTF16 does appear to 
> be simpler from the length of the Julia decoding functions)
>

Please go run some benchmarks on typical strings yourself, doing various 
functions,
and tell me what you see.
UTF-16 processing is pretty simple, and the operation to find out if you 
have a surrogate pair is
simple, and the only invalid sequences in UTF-16 are single surrogates, and 
out-of-order surrogates,
which makes it much faster to deal with all the very many ways that 
supposed UTF-8 strings can be
encoded incorrectly.  Take a look at the checkstring functions that I 
implemented to get an idea of that.
Also, many operations with UTF-8 strings, such as uppercase or lowercase 
can require more
 

> > as well as bloat the size of any buffers you need - because you'll need 
> to allocate 50% more space than for UTF-16, to be sure you can hold the 
> same # of characters.
>
> The unicode wchar_t is 32-bits, which defines the maximum space needed to 
> be certain of the ability to hold a block of a certain number of unknown 
> unicode codepoints*. That quantity is not format-dependent.
>
> What is certain, is that for the ASCII subset, the UTF16 encoding requires 
> exactly double the space of the UTF8 encoding. For any other measurement, 
> you would need to first define a representative data sample.
>

Yes, and for the ANSI Latin1 subset, the UTF8 encoding requires exactly 
double the space as if you'd stored
it in bytes (which is what Python 3 does).

I'm saying that if you know that something is just ASCII, then yes, keep it 
as an ASCIIString, which has the
nice feature that it is directly indexable.  If Julia had a Latin1String 
type, then that would also be a proper subset of the Unicode characters, 
representable with 1-byte code units, and directly indexable.

Once you get out of the range of 0x80-0x7ff, then UTF-8 takes 3 bytes per 
character, which you need to take into account if you are allocating a 
buffer and using UTF-8.

* my understanding is that unicode doesn't have a definition for character, 
> per se., and that codepoint is the more accurate term for indicating a 
> particular index into the code page.
>

OK, if you want to get very technical about it, but it doesn't change 
anything here.
I generally just say character, because sometimes people get confused 
because of the similar terms
codeunit != codepoint.
 

>
> > UTF-16, but with no surrogate pairs, when there are any characters > 
> 0xff, but none > 0x
>
> Isn't that technically UCS-2, not UTF-16?
>

Not really, if you want to get really technical about it.  UCS-2 is just 
the name for how 16-bit Unicode 1.0 was stored, and is really an obsolete 
term, but many people (including myself!) do use it to talk about strings
that only hold BMP code points.  Python 3 is also smart about keeping track 
of whether a string only has BMP characters, and using a directly 
addressable UTF-16 encoded string (UCS-2 if you like) to store it.
Objective-C and Swift I believe always use UTF-16 encoding for text strings.

Re: [julia-users] Re: UTF16String or UTF8String?

[Jameson Nash]

>
> UTF-16 is much faster in many situations than UTF-8.
>

an encoding is not a speed. it is a format. Both formats are
variable-length encodings, and therefore both algorithms have the same time
and space complexity (although the implementation of UTF16 does appear to
be simpler from the length of the Julia decoding functions)

> as well as bloat the size of any buffers you need - because you'll need
to allocate 50% more space than for UTF-16, to be sure you can hold the
same # of characters.

The unicode wchar_t is 32-bits, which defines the maximum space needed to
be certain of the ability to hold a block of a certain number of unknown
unicode codepoints*. That quantity is not format-dependent.

What is certain, is that for the ASCII subset, the UTF16 encoding requires
exactly double the space of the UTF8 encoding. For any other measurement,
you would need to first define a representative data sample.

* my understanding is that unicode doesn't have a definition for character,
per se., and that codepoint is the more accurate term for indicating a
particular index into the code page

> UTF-16, but with no surrogate pairs, when there are any characters >
0xff, but none > 0x

Isn't that technically UCS-2, not UTF-16?


On Sun, Sep 27, 2015 at 4:29 PM Scott Jones 
wrote:

> UTF-16 is much faster in many situations than UTF-8.
>
It really depends a lot on just what you are doing, and the data you are
> processing.
> If it is mainly in North/South America, Western Europe, or Australia/NZ,
> UTF-8 does OK.
> UTF-8 is great for data interchange, but can really slow things down if
> you have many non-ASCII characters
> (as well as bloat the size of any buffers you need - because you'll need
> to allocate 50% more space than for UTF-16, to be sure you can hold the
> same # of characters).
>

> UTF-16 is used by Windows APIs, but also ICU, Java, C++ UnicodeString.
> Python 3 actually picks a 1,2,4 byte representation depending on what
> characters are in the string (so UTF-16, but with no surrogate pairs, when
> there are any characters > 0xff, but none > 0x).
>
> Scott
>

Re: [julia-users] Re: UTF16String or UTF8String?

[Daniel Carrera]

Thanks.

On 27 September 2015 at 20:42, Páll Haraldsson 
wrote:

>
> UTF-16 was earlier (strictly speaking UCS-2) and Windows adopted it (and
> also used elsewhere..). UTF-8 is almost in all cases better (except in
> East-Asian languages, but not even there, if you use, something HTML (or I
> guess XML..), that has has lots of ASCII for tags etc.):
>
> http://utf8everywhere.org/
>
> --
> Palli.
>
> On Sunday, September 27, 2015 at 6:14:34 PM UTC, Daniel Carrera wrote:
>>
>> Hello,
>>
>> I just read of Wikipedia that UTF16 is not compatible with ASCII, but
>> UTF8 is a proper super-set of ASCII. If that's the case, why would anyone
>> use UTF16String instead of UTF8String? It seems like UTF8 has the lowest
>> probability of creating hassle down the road. Every valid ASCII string is a
>> valid UTF8 string. But at the same time, presumably UTF16 would not have
>> been invented if it didn't serve some purpose. Does anyone know what the
>> advantage of UTF16 is?
>>
>> Cheers,
>> Daniel.
>>
>

Re: [julia-users] downloaded binaries vs source compilation

[Jameson Nash]

The performance should be fairly close. The advantage of source compilation
is that it is easier to edit files in Base and submit those changes as a PR.

On Sun, Sep 27, 2015 at 2:33 AM Gabor  wrote:

> I have always used the downloadable binaries of Julia.
>
> Please advise:
>
> Running 64-bit Windows 7 on a Haswell processor with AVX2 instructions
> should I expect a speedup or any other advantage from source compilation?
>

Re: [julia-users] Re: UTF16String or UTF8String?

[Páll Haraldsson]

2015-09-27 20:29 GMT+00:00 Scott Jones :

> If it is mainly in North/South America, Western Europe, or Australia/NZ,
> UTF-8 does OK.
> UTF-8 is great for data interchange, but can really slow things down if
> you have many non-ASCII characters
>

Did you mean non-BMP? Non-ASCII, but BMP ("European") will take 16 bits,
same as in UTF-16.

If you are not talking about indexing, then I'm a little surprised that
UTF-16, in that case can be faster as it will always be bigger.


> (as well as bloat the size of any buffers you need - because you'll need
> to allocate 50% more space than for UTF-16, to be sure you can hold the
> same # of characters).
>

This seems to be a limitation of allocating fixed length
buffers/non-varchar and/or in number of chars, not bytes.

At least in PostgreSQL, varchar is the preferred "default", that I use..
Why would I use fixed size buffers (in chars)?

UTF-16 is used by Windows APIs, but also ICU, Java, C++ UnicodeString.
> Python 3 actually picks a 1,2,4 byte representation depending on what
> characters are in the string (so UTF-16, but with no surrogate pairs, when
> there are any characters > 0xff, but none > 0x).
>

I know. Helps with indexing, unless you want to, write into a string (a
char, not matching assumption..).

-- 
Palli.

Re: [julia-users] Re: UTF16String or UTF8String?

[Scott Jones]

On Sunday, September 27, 2015 at 5:40:03 PM UTC-4, Páll Haraldsson wrote:
>
> 2015-09-27 21:26 GMT+00:00 Páll Haraldsson  >:
>
>> 2015-09-27 20:29 GMT+00:00 Scott Jones > >:
>>
>>> If it is mainly in North/South America, Western Europe, or Australia/NZ, 
>>> UTF-8 does OK.
>>> UTF-8 is great for data interchange, but can really slow things down if 
>>> you have many non-ASCII characters
>>>
>>
>> Did you mean non-BMP? Non-ASCII, but BMP ("European") will take 16 bits, 
>> same as in UTF-16.
>>
>
> Sorry, I was thinking of my own language/Latin1. You can expect three 
> bytes also, but I would guess balanced out by 1 byte chars..
>

That's true for the places I mentioned above (Americas, Western Europe), 
but it's not true for text from
Japan, Korea, China, for example
(except for the case of stuff like XML or HTML, and even then it depends on 
how much data vs. how much formatting is present).
 

> Anyway, in general UTF-8 can go up to four bytes (5 or 6 are no longer 
> allowed..). Probably allocating 50% not double for buffers is something 
> someone thought ok.. I'm not sure standards allow strictly (for SQL)..
>
> -- 
> Palli.
>

Re: [julia-users] Will Julia likely ever allow negative indexing of arrays

[Scott Jones]

Could you elaborate on what sort of tricky bugs that would cause?  Thanks!

On Sunday, September 27, 2015 at 11:46:38 AM UTC-4, Tom Breloff wrote:
>
> Do you need the bracket notarion 'x[-5]'? This would be best implemented 
> as a package with explicit get/set, as Matt implied... As otherwise you 
> risk some tricky bugs. Also if you're implementing "array-like" types, I 
> would definitely use 0.4+. 
>
> On Sunday, September 27, 2015, Matt Bauman  
> wrote:
>
>> There has been a lot of discussion about this in the past few weeks
>>
>> https://groups.google.com/d/msg/julia-users/ScwXMfQIBGs/wD1HTXeZBQAJ
>> https://groups.google.com/d/msg/julia-users/fNisYpMdZ6o/DvFaQi_ZBAAJ
>>
>> TL;DR, yes, it is possible, but it takes some care since it's violating a 
>> fairly well-entrenched assumption about how arrays behave.
>>
>> On Sunday, September 27, 2015 at 10:48:22 AM UTC-4, Mark Sherlock wrote:
>>>
>>> Hi,
>>>
>>> I work in computational physics. The main reason we all use Fortran in 
>>> my area is because it allows arrays to have negative indices. This is very 
>>> useful when solving some partial differential equations (in e.g. plasma 
>>> physics, astrophysics, fluid mechanics).
>>>
>>> I and my colleagues frequently consider alternative languages but in the 
>>> end never change due to the headaches involved regarding this. Since Julia 
>>> seems to be focused on computational science,
>>> I am wondering how likely it is that this would ever be implemented, 
>>> and/or how we could encourage the developers to do this?
>>>
>>> In all other areas Julia looks fantastic for our needs!
>>>
>>

Re: [julia-users] How do I pass an event handle via ccall?

[Chris Stook]

Thanks!  I'll read the section on SignalAsyncWork more carefully.

- Chris

Re: [julia-users] Re: UTF16String or UTF8String?

[Páll Haraldsson]

2015-09-27 21:26 GMT+00:00 Páll Haraldsson :

> 2015-09-27 20:29 GMT+00:00 Scott Jones :
>
>> If it is mainly in North/South America, Western Europe, or Australia/NZ,
>> UTF-8 does OK.
>> UTF-8 is great for data interchange, but can really slow things down if
>> you have many non-ASCII characters
>>
>
> Did you mean non-BMP? Non-ASCII, but BMP ("European") will take 16 bits,
> same as in UTF-16.
>

Sorry, I was thinking of my own language/Latin1. You can expect three bytes
also, but I would guess balanced out by 1 byte chars..

Anyway, in general UTF-8 can go up to four bytes (5 or 6 are no longer
allowed..). Probably allocating 50% not double for buffers is something
someone thought ok.. I'm not sure standards allow strictly (for SQL)..

-- 
Palli.

Re: [julia-users] How do I pass an event handle via ccall?

[Isaiah Norton]

See also:
https://groups.google.com/d/msg/julia-users/dlAx4OY55eg/tqc9mXp32tEJ
https://github.com/JuliaLang/julia/pull/12503

On Sun, Sep 27, 2015 at 5:41 PM, Chris Stook  wrote:

> Thanks!  I'll read the section on SignalAsyncWork more carefully.
>
> - Chris
>
>

Re: [julia-users] Re: UTF16String or UTF8String?

[Scott Jones]

On Sunday, September 27, 2015 at 5:26:26 PM UTC-4, Páll Haraldsson wrote:
>
> 2015-09-27 20:29 GMT+00:00 Scott Jones  >:
>
>> If it is mainly in North/South America, Western Europe, or Australia/NZ, 
>> UTF-8 does OK.
>> UTF-8 is great for data interchange, but can really slow things down if 
>> you have many non-ASCII characters
>>
>
> Did you mean non-BMP? Non-ASCII, but BMP ("European") will take 16 bits, 
> same as in UTF-16.
>

No.  Most characters used in the countries I mentioned above can be 
represented using just ANSI Latin1
(which is why I specified *Western Europe*), so UTF-8 will take 1 or 2 
bytes for each character,
but when you are dealing with the Middle East, India, or Asia (with a lot 
of the world's population!), UTF-8 takes 3 bytes per characters usually 
(non-BMP characters are still not that common, except in Tweets!)
 

> If you are not talking about indexing, then I'm a little surprised that 
> UTF-16, in that case can be faster as it will always be bigger.
>

Processing UTF-8, you have to do a lot of comparisons branching, or always 
be doing table lookups,
and the checks for invalid sequences are painful.
 

> (as well as bloat the size of any buffers you need - because you'll need 
>> to allocate 50% more space than for UTF-16, to be sure you can hold the 
>> same # of characters).
>>
>
> This seems to be a limitation of allocating fixed length 
> buffers/non-varchar and/or in number of chars, not bytes.
>

However you say it, if you are expecting up to 100 Kanji characters (just 
BMP, for sake of argument),
then you'll need 300 bytes if UTF-8, or 200 bytes, if UTF-16.
Let's say you want to allow up to 20% non-BMP characters, so that would be 
240 bytes for UTF-16, or
320 bytes for UTF-8.

At least in PostgreSQL, varchar is the preferred "default", that I use.. 
> Why would I use fixed size buffers (in chars)?
>

Depending on the SQL implementation, VARCHAR (as opposed to a CLOB) may end 
up allocating enough bytes to hold that many *characters* that you 
specified for your maximum, i.e. VARCHAR(255)), depending on what character 
set you used.

UTF-16 is used by Windows APIs, but also ICU, Java, C++ UnicodeString. 
>> Python 3 actually picks a 1,2,4 byte representation depending on what 
>> characters are in the string (so UTF-16, but with no surrogate pairs, when 
>> there are any characters > 0xff, but none > 0x).
>>
>
> I know. Helps with indexing, unless you want to, write into a string (a 
> char, not matching assumption..).
>
> -- 
> Palli.
>

Re: [julia-users] downloaded binaries vs source compilation

[Gabor]

Thank you.
So the average user should stick to the binaries.

On Sunday, September 27, 2015 at 9:11:28 PM UTC+2, Jameson wrote:
>
> The performance should be fairly close. The advantage of source 
> compilation is that it is easier to edit files in Base and submit those 
> changes as a PR.
>
> On Sun, Sep 27, 2015 at 2:33 AM Gabor  wrote:
>
>> I have always used the downloadable binaries of Julia.
>>
>> Please advise:
>>
>> Running 64-bit Windows 7 on a Haswell processor with AVX2 instructions
>> should I expect a speedup or any other advantage from source compilation?
>>
>

Re: [julia-users] Re: UTF16String or UTF8String?

[Scott Jones]

UTF-16 is much faster in many situations than UTF-8.
It really depends a lot on just what you are doing, and the data you are 
processing.
If it is mainly in North/South America, Western Europe, or Australia/NZ, 
UTF-8 does OK.
UTF-8 is great for data interchange, but can really slow things down if you 
have many non-ASCII characters
(as well as bloat the size of any buffers you need - because you'll need to 
allocate 50% more space than for UTF-16, to be sure you can hold the same # 
of characters).

UTF-16 is used by Windows APIs, but also ICU, Java, C++ UnicodeString. 
Python 3 actually picks a 1,2,4 byte representation depending on what 
characters are in the string (so UTF-16, but with no surrogate pairs, when 
there are any characters > 0xff, but none > 0x).

Scott

Re: [julia-users] Re: UTF16String or UTF8String?

[Daniel Carrera]

On 27 September 2015 at 23:41, Scott Jones 
wrote:

> No.  Most characters used in the countries I mentioned above can be
> represented using just ANSI Latin1
> (which is why I specified *Western Europe*), so UTF-8 will take 1 or 2
> bytes for each character,
> but when you are dealing with the Middle East, India, or Asia (with a lot
> of the world's population!), UTF-8 takes 3 bytes per characters usually
> (non-BMP characters are still not that common, except in Tweets!)
>


This discussion is well over my head, but out of curiosity, is Greek
included as Western Europe? I mainly just care about Greek characters, and
possible German and Swedish.

Daniel.

Re: [julia-users] Re: @sprintf with a format string

[Scott Jones]

On Sunday, September 27, 2015 at 8:33:15 PM UTC-4, Tony Fong wrote:
>
> did you see the format function in the last part of Formatting.jl's readme?
>

Yes - and there were some ambiguity problems with that, that limited its 
extensibility,
because you could have:
1) format(formatstring, args...)
2) format(formatexpr, args...)
3) format(number, args...)

Also, the formatstring or formatexpr could contain a lot of different 
format "directives", which means if you compile them, you get into that 
same problem with generating lots of different code I believe.
Tom's approach allows you to have a fmt methods for strings, for integers, 
for binary floats, decimal floats, whatever you want to add, and set up 
default format characteristics as well.

If combined with a simple string macro, that can interpolate values and 
format information in-line in the string,
I think that could get much better performance than is possible with C/C++s 
*printf functions, as well as being a lot easier to read, since the values 
(or expressions) being formatting are right next to the formatting,
not passed in as arguments sometimes far separated from where they are 
formatted.

Scott

On Sunday, September 27, 2015 at 3:00:23 PM UTC-4, Scott Jones wrote:
>>
>> I'm sorry - I meant to test it out right after you submitted the PR, I 
>> *do* think you are on the right track,
>> but I've been caught up in the fun of writing code for my happy Belgian 
>> company (luckily, it's in Julia),
>> and we hadn't gotten to the point where we needed nice formatting yet.
>>
>> I've since been thinking about having a string macro, that would have a 
>> simple syntax for calling your
>> fmt function (and probably some other goodies):
>> Something like:
>> v1 = 10.23
>> v2 = 1234567
>> fmt_default!(Int, :commas, width = 12)
>> println(f"This is a test of formatting <\{v1,3,7}> <\{v2}>")
>> would print:
>> This is a test of formatting < 10.230> < 1,234,567>
>>
>> So that essentially, \{...} is simply a shortcut that acts like 
>> $(fmt(...)).
>>
>> On Tuesday, September 22, 2015 at 10:20:41 AM UTC-4, Tom Breloff wrote:
>>>
>>> Chill guys.
>>>
>>> Anyways... I started to tackle this problem, but didn't get any (much 
>>> needed) comments on whether I was on the right track.  Here's some sample 
>>> preliminary usage of what I was working on.  Please let me know if you 
>>> think it's worth continuing, and what you'd ideally like to see in a 
>>> formatter.
>>>
>>> https://github.com/tbreloff/Formatting.jl/blob/tom-fmt/test/fmt.jl
>>>
>>> On Tue, Sep 22, 2015 at 10:05 AM, Daniel Carrera  
>>> wrote:
>>>
 Coding sprintf() is beyond my skill, I tried. My contributions to Julia 
 have to lie elsewhere (recently I've been putting a lot of time making 
 mockups of a Julia IDE, and helping a new user port his Matlab code). I 
 think it is rude to say "if you don't like it, fix it yourself"; 
 especially 
 after you wrote a post claiming that the non-implementation of sprintf() 
 was an intentional omission because developers weren't sure how to do it 
 right. I showed, correctly, that that argument is nonsense; so you spinned 
 around and changed it to "if you don't like it, fix it yourself". That 
 answer is only a way to reject valid complaints, and it feels like a 
 thinly 
 veiled "fuck you". Imagine if that's how people responded in bug reports. 
 This is not the type of answer that Julia developers normally give, and it 
 is not the type of answer that I expect in Julia; especially after giving 
 a 
 very different answer to the same question. I do try to contribute to 
 Julia, and it is rude and unreasonable to hold me personally responsible 
 for fixing everything that does not work in Julia. A healthy community 
 needs room for receiving legitimate complaints.

 Daniel.

 On 22 September 2015 at 15:49, Tomas Lycken  
 wrote:

> > If C can have one, why can't Julia?
>
> *The hard truth, and nothing but it:* If Julia is missing a feature, 
> or has one that works in a way that's not the way you want, it's because 
> no-one has wanted what you want enough to actually implement it.
>
> That's it. There's no "it can't be done" - Julia is Turing complete, 
> so "everything" can be done. There's no "it's not allowed" - no-one is 
> stopping you from writing your own package, with your own implementation 
> that does what you want the way you want it done, putting it in the 
> package 
> repository and seeing it take off. Chances are that if you write 
> something 
> that it turns out many others want as well, it will be included in the 
> default package distribution in the future (or even in base Julia). Or it 
> might not take off, but at least be there for your own enjoyment.
>
> But the entire language, with all tooling, packages, etc - 

[julia-users] Julia convert BitArray to Integer array

[Sweta Yamini]

Hi,

I am new to Julia. I have an N X N BitArray that I want to pack to Uint8 of 
size N X ceil(N/8)

I tried to reinterpret the array as

packed = reinterpret(Uint8, mybitarray)

but it gives me an error "auto_unbox: unable to determine argument type"

I tried

packed = convert(Array{Uint8}, bitpack(mybitarray))

but it just gives me an N X N Uint8 array with 0 and 1.

Could you help me with this?

Sweta

[julia-users] PyCall Overhead

[Christoph Ortner]

I am writing a Julia wrapper for a molecular simulation library, ASE. As 
with previous PyCall experiences, this works really well UNTIL I started to 
benchmark a certain critical portion of the code. For context: I iterate 
over all atoms and for each atom get the interaction neighbourhood from 
ASE's neighbourlist.  The call get_neighbours(n) returns bumpy arrays of 
type Int64.

# [1] Standard call: 0.356330 seconds (89.00 k allocations: 3.258 MB)
@time for n = 1:500 I, off = nlist.po[:get_neighbors](0); end   

# [2] get a tuple of PyArrays to avoid automatic conversion of integer 
arrays: 0.379282 seconds (62.00 k allocations: 2.022 MB)
@time for n = 1:500 ret = pycall(nlist.po[:get_neighbors], Tuple{PyArray, 
PyArray}, 0); end

# [3] just get a PyObject: 0.039529 seconds (9.50 k allocations: 273.438 KB)
@time for n = 1:500 begin 
ret = pycall(nlist.po[:get_neighbors], PyObject, 0); end
# ret1 = pycall(ret[:__getitem__], PyObject, 0)
# ret2 = pycall(ret[:__getitem__], PyObject, 1)
end

# [4]  with lines 2-3 in [3] uncommented: 0.101147 seconds (28.50 k 
allocations: 820.313 KB)

The plain call without conversion is so much faster that I decided to start 
digging around where to get back some time. I am fairly confident that it 
is not related to issue [https://github.com/stevengj/PyCall.jl/issues/90] 
(but who knows?). [4] suggests that a large proportion of the 0.039 seconds 
is still overhead even though no conversion was performed? This poor 
performance makes this unfortunately useless and means I will have to write 
my own neighbourlist in pure Julia (which is perfectly doable in 300-500 
lines; the bigger issue is maintenance and compatibility as ASE evolves). 
So my 

QUESTION: is there a way (ideally staying in pure Julia) to directly access 
the data in the PyObject, with minimal overhead, provided I know exactly 
beforehand what the objects are?

Many thanks,
 Christoph

Re: [julia-users] Re: Multi-dimensional Arrays

[Leonardo]

Oops!
Many thanks

Leonardo


Il giorno martedì 15 settembre 2015 12:32:02 UTC+2, Tim Holy ha scritto:
>
> `next` requires a second argument, the `state` variable. Your code doesn't 
> pass a second argument, which is why you're getting the error. 
>
> --Tim 
>
> On Tuesday, September 15, 2015 08:18:09 AM Leonardo wrote: 
> > Sorry, 
> > but now I have some doubt relative to concatenation for my redefined 
> Array. 
> > 
> > In my exampled (attached) I've redefined AbstractArray creating a simple 
> > container for an Array, and I redefined also start() / next() / done() 
> > calling same operations for internal Array, but in following few lines 
> > of code: 
> > 
> > a = MyArr{2}(1,2) 
> > a[1,1] = "hello" 
> > a[1,2] = "world" 
> > cat(1, a, ["bob" "alice"]) 
> > 
> > cat() fails with following error: 
> > 
> > ERROR: MethodError: `next` has no method matching 
> > next(::Array{AbstractString,2}) 
> > Closest candidates are: 
> >next(::Array{T,N}, ::Any) 
> >next(::AbstractArray{T,N}, ::Any) 
> >   in _unsafe_batchsetindex! at multidimensional.jl:328 
> >   in setindex! at abstractarray.jl:572 
> >   in cat_t at abstractarray.jl:840 
> >   in vcat at abstractarray.jl:861 
> > 
> > Anyone can indicate me what MUST be reimplemented for AbstractArray{T,N} 
> > to support concatenation operations? 
> > 
> > Many thanks in advance 
> > 
> > Leonardo 
> > 
> > Il 13/09/2015 09:48, Leonardo ha scritto: 
> > > Many thanks! 
> > > I've understood that parametric type and number of dimension are 
> > > necessary, then I can write something like: 
> > > type MyArr{N} <: AbstractArray{String,N} 
> > > ... 
> > > end 
> > > 
> > > but, cause I want constructor receives the range of components for 
> > > each dimension like: 
> > > a = MyArr{3}(2,3,4) 
> > > I MUST ensure that parametric dimension be consistent with passed 
> > > number of indexes, highlighting (with an Error) that forms like: 
> > > a = MyArr{3}(2,3) 
> > > are illegal (see my attached example) 
> > > 
> > > (maybe OT: I think that using Integer as Type Parameter is a bit 
> > > confusing for people like me that have developed by many year in other 
> > > languages with generics as Java, C++, C# because use of a 
> > > object-parameter opposed to conventional type-parameter is a bit odd; 
> > > see also 
> https://groups.google.com/forum/#!topic/julia-users/3NM7tZV5buQ ) 
> > > 
> > > Leonardo 
> > > 
> > > P.S. surprisingly chapters 
> > > http://docs.julialang.org/en/release-0.4/manual/interfaces/ and 
> > > http://docs.julialang.org/en/latest/manual/interfaces/ are 
> unavailable 
> > > into relative PDFs on readthedocs.org 
> > > 
> > > Il 11/09/2015 14:46, Matt Bauman ha scritto: 
> > >> On Friday, September 11, 2015 at 3:11:48 AM UTC-4, Leonardo wrote: 
> > >> I like to have a /unique/ type that contains only a specified 
> > >> type and that can handle any dimension, but only during object 
> > >> instancing (not during subsequent lifecycle of object, also if 
> > >> both phases are at runtime), than parametrized dimension (the 
> > >> N in AbstractArray{T,N}) is not useful for me. 
> > >> 
> > >> You can have a constructor that deals with the parameter for you: 
> > >> 
> > >> MyArr(number_of_dimensions::Int) = MyArr{Any, number_of_dimensions}() 
> > >> 
> > >> I'm afraid I still don't understand why you want to do this, so my 
> > >> answers probably aren't all that helpful. 
> > >> 
> > >> But - if I understood your indications - there is no way to do 
> > >> this without redefine a bunch of methods. 
> > >> At least, can I find somewhere a minimal list of these methods? 
> > >> 
> > >> That's correct.  Omitting the dimensionality isn't a supported way to 
> > >> subtype AbstractArray.  I suppose you can still do it, but being 
> > >> unsupported means that you're on your own to figure out what all 
> > >> needs to be re-implemented.  And unfortunately, I'm afraid that the 
> > >> list isn't so minimal.  It's a part of the AbstractArray definition 
> > >> that is very heavily leveraged in the base code to improve 
> > >> performance and specify behavior. 
> > >> 
> > >> You can start to get a sense of how heavily these parameters are used 
> > >> by looking at the methods defined for AbstractArray{T,1} 
> > >> (AbstractVector) and AbstractArray{T,2} (AbstractMatrix): 
> > >> 
> > >> julia> methodswith(AbstractVector) 
> > >> 151-element Array{Method,1}: … 
> > >> 
> > >> julia> methodswith(AbstractMatrix) 
> > >> 164-element Array{Method,1}: … 
> > >> 
> > >> Those don't even include methods defined for arbitrary dimensionality 
> > >> but still require N to be defined, like 
> > >> `ndims{T,N}(A::AbstractArray{T,N}) = N`. 
>
>

Re: [julia-users] Re: @sprintf with a format string

[Tony Fong]

did you see the format function in the last part of Formatting.jl's readme?

On Sunday, September 27, 2015 at 3:00:23 PM UTC-4, Scott Jones wrote:
>
> I'm sorry - I meant to test it out right after you submitted the PR, I 
> *do* think you are on the right track,
> but I've been caught up in the fun of writing code for my happy Belgian 
> company (luckily, it's in Julia),
> and we hadn't gotten to the point where we needed nice formatting yet.
>
> I've since been thinking about having a string macro, that would have a 
> simple syntax for calling your
> fmt function (and probably some other goodies):
> Something like:
> v1 = 10.23
> v2 = 1234567
> fmt_default!(Int, :commas, width = 12)
> println(f"This is a test of formatting <\{v1,3,7}> <\{v2}>")
> would print:
> This is a test of formatting < 10.230> < 1,234,567>
>
> So that essentially, \{...} is simply a shortcut that acts like 
> $(fmt(...)).
>
> On Tuesday, September 22, 2015 at 10:20:41 AM UTC-4, Tom Breloff wrote:
>>
>> Chill guys.
>>
>> Anyways... I started to tackle this problem, but didn't get any (much 
>> needed) comments on whether I was on the right track.  Here's some sample 
>> preliminary usage of what I was working on.  Please let me know if you 
>> think it's worth continuing, and what you'd ideally like to see in a 
>> formatter.
>>
>> https://github.com/tbreloff/Formatting.jl/blob/tom-fmt/test/fmt.jl
>>
>> On Tue, Sep 22, 2015 at 10:05 AM, Daniel Carrera  
>> wrote:
>>
>>> Coding sprintf() is beyond my skill, I tried. My contributions to Julia 
>>> have to lie elsewhere (recently I've been putting a lot of time making 
>>> mockups of a Julia IDE, and helping a new user port his Matlab code). I 
>>> think it is rude to say "if you don't like it, fix it yourself"; especially 
>>> after you wrote a post claiming that the non-implementation of sprintf() 
>>> was an intentional omission because developers weren't sure how to do it 
>>> right. I showed, correctly, that that argument is nonsense; so you spinned 
>>> around and changed it to "if you don't like it, fix it yourself". That 
>>> answer is only a way to reject valid complaints, and it feels like a thinly 
>>> veiled "fuck you". Imagine if that's how people responded in bug reports. 
>>> This is not the type of answer that Julia developers normally give, and it 
>>> is not the type of answer that I expect in Julia; especially after giving a 
>>> very different answer to the same question. I do try to contribute to 
>>> Julia, and it is rude and unreasonable to hold me personally responsible 
>>> for fixing everything that does not work in Julia. A healthy community 
>>> needs room for receiving legitimate complaints.
>>>
>>> Daniel.
>>>
>>> On 22 September 2015 at 15:49, Tomas Lycken  wrote:
>>>
 > If C can have one, why can't Julia?

 *The hard truth, and nothing but it:* If Julia is missing a feature, 
 or has one that works in a way that's not the way you want, it's because 
 no-one has wanted what you want enough to actually implement it.

 That's it. There's no "it can't be done" - Julia is Turing complete, so 
 "everything" can be done. There's no "it's not allowed" - no-one is 
 stopping you from writing your own package, with your own implementation 
 that does what you want the way you want it done, putting it in the 
 package 
 repository and seeing it take off. Chances are that if you write something 
 that it turns out many others want as well, it will be included in the 
 default package distribution in the future (or even in base Julia). Or it 
 might not take off, but at least be there for your own enjoyment.

 But the entire language, with all tooling, packages, etc - everything 
 that is Julia - is very much a community-built product. Everything that is 
 there, is there because someone at some point said *hey, this is so 
 important to me that I'm going to put it at the very top of my priority 
 list*. Creating a sprintf function that fulfills your needs might not 
 have made it there for anyone yet. If it's that important to you, maybe 
 that's your next contribution?

 // T

 On Tuesday, September 22, 2015 at 3:17:55 PM UTC+2, Daniel Carrera 
 wrote:
>
> I might be wrong, but to me Formatting.jl looks next to useless. The 
> "sprintf" functions it provides only accept one parameter. The main 
> function provided is `sprintf1()`, but even the very clumsy 
> `generate_formatter()` function fails at the most basic tasks:
>
> julia> fmtrfunc = generate_formatter( "%10.3f   %6d  %3d" )
> ERROR: Only one AND undecorated format string is allowed
>  in generate_formatter at 
> /home/daniel/.julia/v0.3/Formatting/src/cformat.jl:23
>
>
> I really don't understand why sprintf() is such a big deal. If C can 
> have one, why can't Julia? I understand the argument that 

[julia-users] Re: Julia code 5x to 30x slower than Matlab code

[J Luis]

Yes, we will be releasing Win binaries when it's released. It's for the 
mean time that interested people needs to build from source.

domingo, 27 de Setembro de 2015 às 14:50:25 UTC+1, Marcio Sales escreveu:
>
> I hope to have a release version in about a month, which is the estimated 
>> time for releasing GMT5.2. There are still several issues from the GMT side 
>> but overall most of it works already. Feel free to test it (see the 
>> gallery.jl for several usage examples) but note that you'll have to install 
>> and build GMT5.2svn yourself. And I only tested it on Windows.
>>
>
> Ok. Will Windows binaries be available then? I use windows and 
> unfortunately can't install the dependencies required to build in the 
> computer I work on. 
>

[julia-users] Re: API deployments on JuliaBox

[tanmaykm]

Hi Miguel,

Server instances are created per API. Server instances are stateless, and 
are reused across API calls and across users. Based on load, an API can 
also have more than one server instances.

Server instances are brought up on a clean Julia container. They do not 
have any files from the user's account. So listing the files will show a 
folder that is mostly empty.

While registering an API endpoint, you are required to submit a short 
bootstrap code. When a new instance of the API server needs is brought up, 
the bootstrap code is executed on a clean Julia container on startup. The 
bootstrap code should then pull the remaining code/data to handle API calls.

It is possible to pull from non public repos or private S3 URLs too, by 
embedding the access keys in the bootstrap code. The bootstrap code is 
visible only to the publisher (that is you for all of your APIs). We have 
thought about having better support for non-public repos and pre-build 
docker images with binary code as well in the future.

Also, JuliaBox does not currently provide any permanent storage for the 
APIs. But it is possible to access storage/databases like (e.g. S3, 
DynamoDB) over the internet.

Best,
Tanmay

On Sunday, September 27, 2015 at 11:44:32 PM UTC+5:30, Miguel Belbut Gaspar 
wrote:
>
> Hi,
>
> Thanks for this, it is a very interesting feature.
>
> I think I have the same question as the previous post, which I think 
> wasn't addressed by tanmaykm's answer:
>
> Is the server created per-user? If I expose a ls() command, will it list 
> my own account home files?
> I tried using require(Juliaset.jl/src/Juliaset.jl) instead of 
> Pkg.clone(...) as the API command, after having sync'ed the Juliaset.jl git 
> to my Juliabox account, but that doesn't seem to work.
>
> Is that by design, i.e., the APIs must have publicly-available source?
> Or is it just a current limitation and if so, are there any plans to allow 
> using non-public repos or source files in  some way?
>
> Cheers,
>
> Miguel
>
> On Tuesday, September 15, 2015 at 11:44:55 AM UTC+1, tanmaykm wrote:
>>
>> Hi,
>>
>> yes, that's right. The APIs will let you share useful functionalities as 
>> REST APIs to other users.
>>
>> The API published with name "list_it" can be accessed at 
>> https://api.juliabox.org/list_it/...
>> The "..." above refer to the exact method being called and the parameters 
>> it expects.
>> From anywhere (including from within the JuliaBox container), any 
>> mechanism to invoke HTTP can be used.
>> All APIs are accessible to everyone, unless the API implementation 
>> imposes some authorization.
>>
>> a couple of examples of JuliaBox APIs can be found at:
>> - https://github.com/tanmaykm/Juliaset.jl
>> - https://github.com/tanmaykm/JuliaWebAPI.jl
>>
>> Best,
>> Tanmay
>>
>>>
>>>

Re: [julia-users] Will Julia likely ever allow negative indexing of arrays

[Kevin Squire]

An older attempt at this can be found here:

https://gist.github.com/alsam/8283205

On Sunday, September 27, 2015, Tom Breloff  wrote:

> Do you need the bracket notarion 'x[-5]'? This would be best implemented
> as a package with explicit get/set, as Matt implied... As otherwise you
> risk some tricky bugs. Also if you're implementing "array-like" types, I
> would definitely use 0.4+.
>
> On Sunday, September 27, 2015, Matt Bauman  > wrote:
>
>> There has been a lot of discussion about this in the past few weeks
>>
>> https://groups.google.com/d/msg/julia-users/ScwXMfQIBGs/wD1HTXeZBQAJ
>> https://groups.google.com/d/msg/julia-users/fNisYpMdZ6o/DvFaQi_ZBAAJ
>>
>> TL;DR, yes, it is possible, but it takes some care since it's violating a
>> fairly well-entrenched assumption about how arrays behave.
>>
>> On Sunday, September 27, 2015 at 10:48:22 AM UTC-4, Mark Sherlock wrote:
>>>
>>> Hi,
>>>
>>> I work in computational physics. The main reason we all use Fortran in
>>> my area is because it allows arrays to have negative indices. This is very
>>> useful when solving some partial differential equations (in e.g. plasma
>>> physics, astrophysics, fluid mechanics).
>>>
>>> I and my colleagues frequently consider alternative languages but in the
>>> end never change due to the headaches involved regarding this. Since Julia
>>> seems to be focused on computational science,
>>> I am wondering how likely it is that this would ever be implemented,
>>> and/or how we could encourage the developers to do this?
>>>
>>> In all other areas Julia looks fantastic for our needs!
>>>
>>

Re: [julia-users] Implementing printf() and sprintf() in Julia.

[Kevin Squire]

How about submitting a patch to Formatting.jl?

On Sunday, September 27, 2015, Michael Hatherly 
wrote:

> As mentioned in the other thread,
> https://groups.google.com/d/msg/julia-users/hBbEGEopi0A/OX4ZEhFnBgAJ and
> https://groups.google.com/d/msg/julia-users/hBbEGEopi0A/fKQcqDEVBgAJ,
> there are concerns about generating new code for every single formatting
> string used. I guess generally this won’t be much of an issue, but it could
> be. Maybe write a package and see how much interest there is first?
>
> — Mike
> ​
> On Sunday, 27 September 2015 13:02:25 UTC+2, Daniel Carrera wrote:
>>
>> Hello,
>>
>> I made a trivial change to a some clever code by Tim Holy, and used it to
>> make printf() and sprintf() function with the familiar syntax that we know
>> from C/C++ (requires Julia 0.4):
>>
>>
>> immutable FormatString{S} end
>>
>> FormatString(str::AbstractString) = FormatString{symbol(str)}
>>
>> @generated function Base.print{format}(::Type{FormatString{format}},
>> args...)
>> meta = Expr(:meta, :inline)
>> fmt = string(format)
>> allargs = [:(args[$d]) for d = 1:length(args)]
>> quote
>> @printf($fmt, $(allargs...))
>> end
>> end
>> @generated function Base.sprint{format}(::Type{FormatString{format}},
>> args...)
>> meta = Expr(:meta, :inline)
>> fmt = string(format)
>> allargs = [:(args[$d]) for d = 1:length(args)]
>> quote
>> @sprintf($fmt, $(allargs...))
>> end
>> end
>>
>> function printf(s::AbstractString, args...)
>> print(FormatString(s), args...)
>> end
>> function sprintf(s::AbstractString, args...)
>> print(FormatString(s), args...)
>> end
>>
>>
>> Could (or should) something like this be included in Julia by default?
>> The first time you call printf() sprintf() with a new format string, the
>> function call is slower than the @printf and @sprintf macros, but
>> subsequent calls are just as fast:
>>
>> julia> @time @printf("%7d  %7.2f", 220/7, 22/7)
>>  31 3.14  0.024334 seconds (20.68 k allocations: 912.738 KB)
>>
>> julia> @time @printf("%7d  %7.2f", 220/7, 22/7)
>>  31 3.14  0.000102 seconds (30 allocations: 1.094 KB)
>>
>> julia>
>>
>> julia> fmt = "%6d  %7.2f"
>> "%6d  %7.2f"
>>
>> julia> @time printf(fmt, 220/7, 22/7)
>> 31 3.14  0.036154 seconds (36.81 k allocations: 1.675 MB)
>>
>> julia> @time printf(fmt, 220/7, 22/7)
>> 31 3.14  0.95 seconds (37 allocations: 1.250 KB)
>>
>>
>>
>> Daniel.
>>
>

Re: [julia-users] Nesting Macros passing Expressions

[Leonardo]

Many thanks!

I have a similar problem calling a function in following scenario:
function tst3(i::Int)
println(i)
end

macro tst(i::Int)
tst3(i)
end

I obtain an error executing code:
julia> b = 2::Int
julia> @tst b
complaining for a problem of type, because tst3 seems to receive a 
Symbol instead an Integer:

ERROR: TypeError: anonymous: in typeassert, expected Int64, got Symbol

What is correct form in this case?

Leonardo


Il 27/09/2015 18:58, Yichao Yu ha scritto:

On Sun, Sep 27, 2015 at 12:20 PM, Leonardo  wrote:

Hi all,
I need manipulate AST of an expression in a macro, and pass same expression
in input to another macro, but I experience some problem.

I try to express my doubt with a simplified example:
macro tst2(e2::Expr)
 println(e2.head)
end

macro tst(e1::Expr)
 @tst2 esc(e1)
end

```
macro tst(e1::Expr)
 quote
 @tst2 $(esc(e1))
 end
end
```

otherwise, `@tst2` will be run at `tst` definition time.


In previous code I want that call to @tst2 behave exact like call to @tst.

E.g. calling @tst2 in REPL I obtain:
julia> a = 2
julia> @tst2(a < 3)
comparison
but same call to @tst has no effect, and I cannot find an alternative
working form for @tst

Someone can help me to understand this odd behaviour of Julia's macro?

Many thanks in advance

Leonardo

[julia-users] How do I pass an event handle via ccall?

[Chris Stook]

I am wrapping this c library:

http://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_71).pdf

The function FT_SetEventNotification requires passing a handle to an event. 
 The closest thing I see in julia is a Condition().  Would it make sense to 
pass a pointer to a condition to this function?  What is the proper way to 
handle this?

Thanks,
Chris

[julia-users] Why is String deprecated in favour of AbstractString?

[Daniel Carrera]

Why are we changing from String to AbstractString? Obviously, the former is 
easier to type. Even if there are some changes to the guts of the string 
implementation, I would have thought that you could just keep the shorter 
name "String".

Cheers,
Daniel.

[julia-users] Re: Why is String deprecated in favour of AbstractString?

[Gabor]

I do not know the answer, and may not be a solution for you,
but here is what I do:

typealias String   ASCIIString

It turned out that I unnecessarily used an abstract type before,
so from here on I use and alias the concrete ASCIIString type in my program.


On Sunday, September 27, 2015 at 9:40:31 AM UTC+2, Daniel Carrera wrote:
>
> Why are we changing from String to AbstractString? Obviously, the former 
> is easier to type. Even if there are some changes to the guts of the string 
> implementation, I would have thought that you could just keep the shorter 
> name "String".
>
> Cheers,
> Daniel.
>

[julia-users] Saving complex type to a file

[Marc Stein]

I'm just starting out with Julia, so please forgive me if this is a 
simplistic question.

I'm using the DecisionTree package which generates an Ensemble of 
DecisionTrees in the code below:


##

using DataFrames
using DecisionTree

clarity = readtable("/Users/marcstein/Active/julia/clarity.csv");
head(clarity)

labels = array(clarity[:, 41]);
features = array(clarity[:, 1:40]);

# Random Forest Classifier

# train random forest classifier
# using 2 random features, 10 trees, and 0.5 portion of samples per tree 
(optional)

model = build_forest(labels, features, 2, 10, 0.5)

# apply learned model

outcome = apply_forest(model, 
[2,761,0,0,2,1.32,74,0,365,3,2,15,10,1,0,1,24,36,2000,0,1,1,0,0,0,1,0,0,0,1,5,1,0,2,0,2,220,221,220,221])

# # run n-fold cross validation for forests
# # using 2 random features, 10 trees, 3 folds and 0.5 of samples per tree 
(optional)

accuracy = nfoldCV_forest(labels, features, 2, 10, 3, 0.5)

score = (mean(accuracy[1:3]))

println(outcome)
println(score)

##


This code works fine. But because the DataFrame that is the training set is 
quite large, I want to build the model and store it in one app and then 
load the model and generate the outcome in a second app. 

It seems like this should be simple, just persist the model in a file and 
pass it into the apply_forest method.

I can't find a way, though, to persist the model. If I try 

writedlm(outfile,model)

I get:

EnsembleERROR: `start` has no method matching start(::Ensemble)
 in writedlm at datafmt.jl:535
 in writedlm at datafmt.jl:554

If I try:

print(outfile,model)

the output file contains:

Ensemble of Decision Trees
Trees:  10
Avg Leaves: 117.8
Avg Depth:  20.8

which is a summary of the Ensemble, not the individual elements.

I'm clearly missing something, but I haven't been able to figure it out so 
far.

Any suggestions would be greatly appreciated!

Re: [julia-users] Why is String deprecated in favour of AbstractString?

[Milan Bouchet-Valat]

Le dimanche 27 septembre 2015 à 00:40 -0700, Daniel Carrera a écrit :
> Why are we changing from String to AbstractString? Obviously, the
> former is easier to type. Even if there are some changes to the guts
> of the string implementation, I would have thought that you could
> just keep the shorter name "String".
That's exactly the point of the change: AbstractString shouldn't be
used very often -- basically only to restrict the arguments type, as in
f(s::AbstractString).

Then the default concrete type can be called String or Str, and that's
what people will use. Calling the abstract type String was confusing as
it could prompt people to write type-unstable fields believing that it
was the concrete one.


Regards

[julia-users] downloaded binaries vs source compilation

[Gabor]

I have always used the downloadable binaries of Julia.

Please advise:

Running 64-bit Windows 7 on a Haswell processor with AVX2 instructions
should I expect a speedup or any other advantage from source compilation?

Re: [julia-users] Why is String deprecated in favour of AbstractString?

[Gabor]

Of course, if you need Greek characters, then use UTF8String,
I used ASCIIString just for filenames and atom types.

On Sunday, September 27, 2015 at 11:00:17 AM UTC+2, Daniel Carrera wrote:
>
>
> On 27 September 2015 at 10:39, Milan Bouchet-Valat  > wrote:
>>
>> Then the default concrete type can be called String or Str, and that's
>> what people will use. Calling the abstract type String was confusing as
>> it could prompt people to write type-unstable fields believing that it
>> was the concrete one.
>>
>
>
> So... it would be a good idea if I made an alias to a concrete type the 
> way Gabor did?
>
> typealias String UTF8String
>
>
> Is there a reason to use ASCIIString instead of UTF8String? They are both 
> concrete types, but UTF8 allows me to include greek characters.
>
> Cheers,
> Daniel.
>
>
>

[julia-users] Re: Homebrew problem(?): Can't add or build Gtk

[Christoph Ortner]

I had the same happen to me.
Christoph

Re: [julia-users] Saving complex type to a file

[Tim Holy]

You can try JLD.jl.

--Tim

On Saturday, September 26, 2015 05:31:18 PM Marc Stein wrote:
> I'm just starting out with Julia, so please forgive me if this is a
> simplistic question.
> 
> I'm using the DecisionTree package which generates an Ensemble of
> DecisionTrees in the code below:
> 
> 
> ##
> 
> using DataFrames
> using DecisionTree
> 
> clarity = readtable("/Users/marcstein/Active/julia/clarity.csv");
> head(clarity)
> 
> labels = array(clarity[:, 41]);
> features = array(clarity[:, 1:40]);
> 
> # Random Forest Classifier
> 
> # train random forest classifier
> # using 2 random features, 10 trees, and 0.5 portion of samples per tree
> (optional)
> 
> model = build_forest(labels, features, 2, 10, 0.5)
> 
> # apply learned model
> 
> outcome = apply_forest(model,
> [2,761,0,0,2,1.32,74,0,365,3,2,15,10,1,0,1,24,36,2000,0,1,1,0,0,0,1,0,0,0,1,
> 5,1,0,2,0,2,220,221,220,221])
> 
> # # run n-fold cross validation for forests
> # # using 2 random features, 10 trees, 3 folds and 0.5 of samples per tree
> (optional)
> 
> accuracy = nfoldCV_forest(labels, features, 2, 10, 3, 0.5)
> 
> score = (mean(accuracy[1:3]))
> 
> println(outcome)
> println(score)
> 
> ##
> 
> 
> This code works fine. But because the DataFrame that is the training set is
> quite large, I want to build the model and store it in one app and then
> load the model and generate the outcome in a second app.
> 
> It seems like this should be simple, just persist the model in a file and
> pass it into the apply_forest method.
> 
> I can't find a way, though, to persist the model. If I try
> 
> writedlm(outfile,model)
> 
> I get:
> 
> EnsembleERROR: `start` has no method matching start(::Ensemble)
>  in writedlm at datafmt.jl:535
>  in writedlm at datafmt.jl:554
> 
> If I try:
> 
> print(outfile,model)
> 
> the output file contains:
> 
> Ensemble of Decision Trees
> Trees:  10
> Avg Leaves: 117.8
> Avg Depth:  20.8
> 
> which is a summary of the Ensemble, not the individual elements.
> 
> I'm clearly missing something, but I haven't been able to figure it out so
> far.
> 
> Any suggestions would be greatly appreciated!

Re: [julia-users] Re: Homebrew problem(?): Can't add or build Gtk

[Tim Holy]

On Sunday, September 27, 2015 03:04:03 AM Christoph Ortner wrote:
> I had the same happen to me.
> Christoph

Please do post an issue over at https://github.com/JuliaLang/Gtk.jl; Elliot is 
very responsive about Homebrew-related issues, but not everyone reads julia-
users carefully.

Best,
--Tim

Re: [julia-users] Why is String deprecated in favour of AbstractString?

[Tim Holy]

I think the only advantage of ASCIIString is that str[8:12] is performant, 
because you know the byte offset directly from the index. That's not true for 
UTF8String.

--Tim

On Sunday, September 27, 2015 11:00:14 AM Daniel Carrera wrote:
> On 27 September 2015 at 10:39, Milan Bouchet-Valat 
> 
> wrote:
> > Then the default concrete type can be called String or Str, and that's
> > what people will use. Calling the abstract type String was confusing as
> > it could prompt people to write type-unstable fields believing that it
> > was the concrete one.
> 
> So... it would be a good idea if I made an alias to a concrete type the way
> Gabor did?
> 
> typealias String UTF8String
> 
> 
> Is there a reason to use ASCIIString instead of UTF8String? They are both
> concrete types, but UTF8 allows me to include greek characters.
> 
> Cheers,
> Daniel.

Re: [julia-users] Why is String deprecated in favour of AbstractString?

[Daniel Carrera]

Thanks.

On 27 September 2015 at 12:31, Tim Holy  wrote:

> I think the only advantage of ASCIIString is that str[8:12] is performant,
> because you know the byte offset directly from the index. That's not true
> for
> UTF8String.
>
> --Tim
>
> On Sunday, September 27, 2015 11:00:14 AM Daniel Carrera wrote:
> > On 27 September 2015 at 10:39, Milan Bouchet-Valat 
> >
> > wrote:
> > > Then the default concrete type can be called String or Str, and that's
> > > what people will use. Calling the abstract type String was confusing as
> > > it could prompt people to write type-unstable fields believing that it
> > > was the concrete one.
> >
> > So... it would be a good idea if I made an alias to a concrete type the
> way
> > Gabor did?
> >
> > typealias String UTF8String
> >
> >
> > Is there a reason to use ASCIIString instead of UTF8String? They are both
> > concrete types, but UTF8 allows me to include greek characters.
> >
> > Cheers,
> > Daniel.
>
>

[julia-users] Implementing printf() and sprintf() in Julia.

[Daniel Carrera]

Hello,

I made a trivial change to a some clever code by Tim Holy, and used it to 
make printf() and sprintf() function with the familiar syntax that we know 
from C/C++ (requires Julia 0.4):


immutable FormatString{S} end

FormatString(str::AbstractString) = FormatString{symbol(str)}

@generated function Base.print{format}(::Type{FormatString{format}}, 
args...)
meta = Expr(:meta, :inline)
fmt = string(format)
allargs = [:(args[$d]) for d = 1:length(args)]
quote
@printf($fmt, $(allargs...))
end
end
@generated function Base.sprint{format}(::Type{FormatString{format}}, 
args...)
meta = Expr(:meta, :inline)
fmt = string(format)
allargs = [:(args[$d]) for d = 1:length(args)]
quote
@sprintf($fmt, $(allargs...))
end
end

function printf(s::AbstractString, args...)
print(FormatString(s), args...)
end
function sprintf(s::AbstractString, args...)
print(FormatString(s), args...)
end


Could (or should) something like this be included in Julia by default? The 
first time you call printf() sprintf() with a new format string, the 
function call is slower than the @printf and @sprintf macros, but 
subsequent calls are just as fast:

julia> @time @printf("%7d  %7.2f", 220/7, 22/7)
 31 3.14  0.024334 seconds (20.68 k allocations: 912.738 KB)

julia> @time @printf("%7d  %7.2f", 220/7, 22/7)
 31 3.14  0.000102 seconds (30 allocations: 1.094 KB)

julia> 

julia> fmt = "%6d  %7.2f"
"%6d  %7.2f"

julia> @time printf(fmt, 220/7, 22/7)
31 3.14  0.036154 seconds (36.81 k allocations: 1.675 MB)

julia> @time printf(fmt, 220/7, 22/7)
31 3.14  0.95 seconds (37 allocations: 1.250 KB)



Daniel.

[julia-users] Re: Implementing printf() and sprintf() in Julia.

[Michael Hatherly]

As mentioned in the other thread, 
https://groups.google.com/d/msg/julia-users/hBbEGEopi0A/OX4ZEhFnBgAJ and 
https://groups.google.com/d/msg/julia-users/hBbEGEopi0A/fKQcqDEVBgAJ, there 
are concerns about generating new code for every single formatting string 
used. I guess generally this won’t be much of an issue, but it could be. 
Maybe write a package and see how much interest there is first?

— Mike
​
On Sunday, 27 September 2015 13:02:25 UTC+2, Daniel Carrera wrote:
>
> Hello,
>
> I made a trivial change to a some clever code by Tim Holy, and used it to 
> make printf() and sprintf() function with the familiar syntax that we know 
> from C/C++ (requires Julia 0.4):
>
>
> immutable FormatString{S} end
>
> FormatString(str::AbstractString) = FormatString{symbol(str)}
>
> @generated function Base.print{format}(::Type{FormatString{format}}, 
> args...)
> meta = Expr(:meta, :inline)
> fmt = string(format)
> allargs = [:(args[$d]) for d = 1:length(args)]
> quote
> @printf($fmt, $(allargs...))
> end
> end
> @generated function Base.sprint{format}(::Type{FormatString{format}}, 
> args...)
> meta = Expr(:meta, :inline)
> fmt = string(format)
> allargs = [:(args[$d]) for d = 1:length(args)]
> quote
> @sprintf($fmt, $(allargs...))
> end
> end
>
> function printf(s::AbstractString, args...)
> print(FormatString(s), args...)
> end
> function sprintf(s::AbstractString, args...)
> print(FormatString(s), args...)
> end
>
>
> Could (or should) something like this be included in Julia by default? The 
> first time you call printf() sprintf() with a new format string, the 
> function call is slower than the @printf and @sprintf macros, but 
> subsequent calls are just as fast:
>
> julia> @time @printf("%7d  %7.2f", 220/7, 22/7)
>  31 3.14  0.024334 seconds (20.68 k allocations: 912.738 KB)
>
> julia> @time @printf("%7d  %7.2f", 220/7, 22/7)
>  31 3.14  0.000102 seconds (30 allocations: 1.094 KB)
>
> julia> 
>
> julia> fmt = "%6d  %7.2f"
> "%6d  %7.2f"
>
> julia> @time printf(fmt, 220/7, 22/7)
> 31 3.14  0.036154 seconds (36.81 k allocations: 1.675 MB)
>
> julia> @time printf(fmt, 220/7, 22/7)
> 31 3.14  0.95 seconds (37 allocations: 1.250 KB)
>
>
>
> Daniel.
>