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

[Jeffrey Sarnoff]

We need a few frendly gateguides (so, usually there would not be many days
delay) to assure whatever wants assurance.

If you share with me what this means "this work meets Julia's community
guidelines and so ready for METADATA registration,"
(and direct me to any relevant threads/doc), I will [re]write it for easy
use and handy reference. So if we have experienced volunteers, they have
less to do.


On Fri, Dec 4, 2015 at 1:35 AM, SVAKSHA  wrote:

> There is a "SolveDSGE.jl" package by @RJDennis and other related
> packages are here:
> https://github.com/svaksha/Julia.jl/blob/master/Statistics.md#stochastics
> It would be nicer if some of the overlap between packages was reduced
> via collaboration for METADATA packages. Wishful thinking, perhaps, as
> people will keep writing new packages depending on their requirements.
> SVAKSHA ॥  http://about.me/svaksha  ॥
>
>
> On Fri, Dec 4, 2015 at 6:08 AM, David Anthoff 
> wrote:
> > I don’t think that the package should be registered as DSGE, though.
> DSGE is
> > a type of model, and there are lots and lots of those around. The repo
> from
> > the NY Fed is their specific DSGE model, it is one example of a DSGE
> model.
> > I think a package that in general provided methods to solve DSGE models,
> or
> > define them etc. might be registered as DSGE, but not this specific
> model.
> > But even for such a general package, I’m not sure it should be named
> DSGE:
> > there are lots of different solution methods for DSGE models, and I think
> > different packages might try different implementations (the situation
> might
> > be a little bit like the various MCMC packages floating around). In those
> > cases it is not clear to me that one of these packages should be allowed
> to
> > “own” the official name…
> >
> >
> >
> > From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com]
> On
> > Behalf Of Tony Kelman
> > Sent: Thursday, December 3, 2015 6:17 PM
> > To: julia-users 
> > Subject: [julia-users] Re: ANN: DSGE.jl
> >
> >
> >
> > DSGE is against the usual naming guidelines of trying to avoid acronyms,
> but
> > at least this one is unambiguously googlable with one dominant result.
> I'd
> > never heard of it as a non-economist, but given this is a big project
> from a
> > major institution we can perhaps make an exception to the usual
> guidelines.
> >
> >
> >
> > On Thursday, December 3, 2015 at 1:20:51 PM UTC-8, Patrick Kofod Mogensen
> > wrote:
> >
> > Fellow economist here, great stuff! I'm curious to see what choices were
> > made, and how it compares to other DSGE toolboxes and tools out there.
> >
> > Is it going to be registered in METADATA? If so, would a name like DSGE
> be
> > "allowed"?
> >
> > On Thursday, December 3, 2015 at 3:05:57 PM UTC+1, Spencer Lyon wrote:
> >
> > The Federal Reserve bank of New York has finished moving their fairly
> large
> > DSGE model from Matlab to Julia. This model is used inside the Fed for
> > forecasting and policy analysis.
> >
> >
> >
> > As part of the move to Julia, the code base has been open sourced.
> >
> >
> >
> > A blog post announcing the release is here:
> >
> http://libertystreeteconomics.newyorkfed.org/2015/12/the-frbny-dsge-model-meets-julia.html
> >
> >
> >
> > And the repository can be found here:
> https://github.com/FRBNY-DSGE/DSGE.jl
> >
> >
> >
> >
>

Re: [julia-users] Re: File downloading and caching best practices?

[Penn Taylor]

After looking through those options, I agree with you that 
BinDeps.download_cmd is currently the best fit for my requirements for 
question 1.

On Wednesday, December 2, 2015 at 9:23:30 AM UTC-6, Tony Kelman wrote:
>
> Regarding question 1, the most widely tested option is probably 
> BinDeps.download_cmd. That is similar to Base.download but with an 
> additional more reliable fallback on Windows to calling PowerShell. You 
> could also look into LibCURL.jl or Requests.jl, which use BinDeps to ensure 
> the binary libraries they depend on will be in place. There's a discussion 
> in an issue, I think in BinDeps, that general file downloading is in need 
> of a refactoring and consolidation between what's in Base, BinDeps, WinRPM, 
> and other implementations floating around. The proposal hasn't been acted 
> on yet though, so it's still a little bit of a mess.
>
>
> On Wednesday, December 2, 2015 at 3:50:55 AM UTC-8, Tony Kelman wrote:
>>
>> No, please don't shell out to curl on windows. That will be going away, 
>> it's only present as a side effect of being bundled with git. We don't use 
>> bundled git any more.
>
>

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

[SVAKSHA]

There is a "SolveDSGE.jl" package by @RJDennis and other related
packages are here:
https://github.com/svaksha/Julia.jl/blob/master/Statistics.md#stochastics
It would be nicer if some of the overlap between packages was reduced
via collaboration for METADATA packages. Wishful thinking, perhaps, as
people will keep writing new packages depending on their requirements.
SVAKSHA ॥  http://about.me/svaksha  ॥


On Fri, Dec 4, 2015 at 6:08 AM, David Anthoff  wrote:
> I don’t think that the package should be registered as DSGE, though. DSGE is
> a type of model, and there are lots and lots of those around. The repo from
> the NY Fed is their specific DSGE model, it is one example of a DSGE model.
> I think a package that in general provided methods to solve DSGE models, or
> define them etc. might be registered as DSGE, but not this specific model.
> But even for such a general package, I’m not sure it should be named DSGE:
> there are lots of different solution methods for DSGE models, and I think
> different packages might try different implementations (the situation might
> be a little bit like the various MCMC packages floating around). In those
> cases it is not clear to me that one of these packages should be allowed to
> “own” the official name…
>
>
>
> From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On
> Behalf Of Tony Kelman
> Sent: Thursday, December 3, 2015 6:17 PM
> To: julia-users 
> Subject: [julia-users] Re: ANN: DSGE.jl
>
>
>
> DSGE is against the usual naming guidelines of trying to avoid acronyms, but
> at least this one is unambiguously googlable with one dominant result. I'd
> never heard of it as a non-economist, but given this is a big project from a
> major institution we can perhaps make an exception to the usual guidelines.
>
>
>
> On Thursday, December 3, 2015 at 1:20:51 PM UTC-8, Patrick Kofod Mogensen
> wrote:
>
> Fellow economist here, great stuff! I'm curious to see what choices were
> made, and how it compares to other DSGE toolboxes and tools out there.
>
> Is it going to be registered in METADATA? If so, would a name like DSGE be
> "allowed"?
>
> On Thursday, December 3, 2015 at 3:05:57 PM UTC+1, Spencer Lyon wrote:
>
> The Federal Reserve bank of New York has finished moving their fairly large
> DSGE model from Matlab to Julia. This model is used inside the Fed for
> forecasting and policy analysis.
>
>
>
> As part of the move to Julia, the code base has been open sourced.
>
>
>
> A blog post announcing the release is here:
> http://libertystreeteconomics.newyorkfed.org/2015/12/the-frbny-dsge-model-meets-julia.html
>
>
>
> And the repository can be found here: https://github.com/FRBNY-DSGE/DSGE.jl
>
>
>
>

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

[Jeffrey Sarnoff]

*ahh to advertise as do movies, using quotes as collage*

"We have found ... working with [Julia is] simply more pleasant and 
user-friendly than working with our old codebase. ...[using Julia] has made 
our development workflow significantly more robust.. [and makes] it easy to 
be much more expressive with our code. .. We find the benefits of a 
transition to Julia are significant .. [resulting] in code that is 
high-quality from the outset."

On Thursday, December 3, 2015 at 9:36:11 PM UTC-5, Viral Shah wrote:
>
> DSGE is a very common name in economics, but Dynamic Stochastic General 
> Equilibrium Models don’t mean much elsewhere. I would love to see some of 
> those components underneath such as the Kalman filter come from other 
> packages eventually. 
>
> -viral 
>
>
>
> > On 04-Dec-2015, at 7:47 AM, Tony Kelman  
> wrote: 
> > 
> > DSGE is against the usual naming guidelines of trying to avoid acronyms, 
> but at least this one is unambiguously googlable with one dominant result. 
> I'd never heard of it as a non-economist, but given this is a big project 
> from a major institution we can perhaps make an exception to the usual 
> guidelines. 
> > 
> > 
> > On Thursday, December 3, 2015 at 1:20:51 PM UTC-8, Patrick Kofod 
> Mogensen wrote: 
> > Fellow economist here, great stuff! I'm curious to see what choices were 
> made, and how it compares to other DSGE toolboxes and tools out there. 
> > 
> > Is it going to be registered in METADATA? If so, would a name like DSGE 
> be "allowed"? 
> > 
> > On Thursday, December 3, 2015 at 3:05:57 PM UTC+1, Spencer Lyon wrote: 
> > The Federal Reserve bank of New York has finished moving their fairly 
> large DSGE model from Matlab to Julia. This model is used inside the Fed 
> for forecasting and policy analysis. 
> > 
> > As part of the move to Julia, the code base has been open sourced. 
> > 
> > A blog post announcing the release is here: 
> http://libertystreeteconomics.newyorkfed.org/2015/12/the-frbny-dsge-model-meets-julia.html
>  
> > 
> > And the repository can be found here: 
> https://github.com/FRBNY-DSGE/DSGE.jl 
> > 
> > 
>
>

RE: [julia-users] Re: ANN: DSGE.jl

[David Anthoff]

I don’t think that the package should be registered as DSGE, though. DSGE is a 
type of model, and there are lots and lots of those around. The repo from the 
NY Fed is their specific DSGE model, it is one example of a DSGE model. I think 
a package that in general provided methods to solve DSGE models, or define them 
etc. might be registered as DSGE, but not this specific model. But even for 
such a general package, I’m not sure it should be named DSGE: there are lots of 
different solution methods for DSGE models, and I think different packages 
might try different implementations (the situation might be a little bit like 
the various MCMC packages floating around). In those cases it is not clear to 
me that one of these packages should be allowed to “own” the official name… 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Tony Kelman
Sent: Thursday, December 3, 2015 6:17 PM
To: julia-users 
Subject: [julia-users] Re: ANN: DSGE.jl

 

DSGE is against the usual naming guidelines of trying to avoid acronyms, but at 
least this one is unambiguously googlable with one dominant result. I'd never 
heard of it as a non-economist, but given this is a big project from a major 
institution we can perhaps make an exception to the usual guidelines.



On Thursday, December 3, 2015 at 1:20:51 PM UTC-8, Patrick Kofod Mogensen wrote:

Fellow economist here, great stuff! I'm curious to see what choices were made, 
and how it compares to other DSGE toolboxes and tools out there.

Is it going to be registered in METADATA? If so, would a name like DSGE be 
"allowed"?

On Thursday, December 3, 2015 at 3:05:57 PM UTC+1, Spencer Lyon wrote:

The Federal Reserve bank of New York has finished moving their fairly large 
DSGE model from Matlab to Julia. This model is used inside the Fed for 
forecasting and policy analysis. 

 

As part of the move to Julia, the code base has been open sourced.

 

A blog post announcing the release is here: 
http://libertystreeteconomics.newyorkfed.org/2015/12/the-frbny-dsge-model-meets-julia.html

 

And the repository can be found here: https://github.com/FRBNY-DSGE/DSGE.jl

 

 

Re: [julia-users] Re: slow wordcount

[James Gilbert]

I don't understand this line in Tim's code:

  data = readuntil(s, delim % UInt8)

Is it the same as:

  data = readuntil(s, UInt8(delim))

? I guess its purpose is to select this method:

  readuntil(s::IOStream, delim::UInt8)

which is faster than:

  readuntil(s::IO, delim::Char)

[julia-users] Silicon Valley Start-Up Software Engineer Position

[Charles Novaes de Santana]

Hi people,

Just received this advertisement. It makes me feel so bappy when I see
Julia as a reference for such great job positions... :)

Charles

--

SFI External Faculty member Jessica Green is advertising the following
position at her company Phylagen http://phylagen.com/ .  The ad is below
and can be found here: https://goo.gl/RfO9jv .  Please feel free to
distribute.

-Jennifer Dunne

Vice President for Science | Santa Fe Institute



*Bioinformatics Engineer Full Time Position*

We are adding a new team member at Phylagen, Inc. (phylagen.com). If you
know a software engineer who fits, please direct them to
j...@phylagen.com  > .

We are an energized team developing microbiome data analytic tools and
bioinformatics pipelines that are being applied to a wide range of
environments.

We plan to bring on an innovative coder - ideally with a M.S or Ph.D. in
computer science, engineering, statistics, or bioinformatics
(translating to 4-5 years software engineering experience). We want
someone deeply knowledgeable in data analysis scripting
(R/Python/Julia), and in algorithm optimization, including
parallelization, distributed execution and implementing methods in a
lower-level language (e.g. C, C++, Java). The position will entail
combining code and data from different disciplines, translating and
optimizing published research algorithms into industry products, and
creating reference databases that can be used in machine learning
applications. Expertise in the analysis of metagenomics data and
bioinformatics pipelines is a bonus. We are looking someone who is
flexible - a fast learner with relevant experience that will allow them
to contribute quickly. You will be a key player in a cutting edge,
rapidly growing venture-backed microbiome startup.






-- 
Um axé! :)

--
Charles Novaes de Santana, PhD
http://www.imedea.uib-csic.es/~charles


Attached
Description: Binary data

[julia-users] Re: Fw: Fwd: [External-faculty] Silicon Valley Start-Up Software Engineer Position

[Charles Novaes de Santana]

"bappy" is "happy" before 10am :)

Charles

On Thursday, December 3, 2015, Charles Novaes de Santana <
charles.sant...@gmail.com> wrote:

> Hi people,
>
> Just received this advertisement. It makes me feel so bappy when I see
> Julia as a reference for such great job positions... :)
>
> Charles
>
> --
>
> SFI External Faculty member Jessica Green is advertising the following
> position at her company Phylagen http://phylagen.com/ .  The ad is below
> and can be found here: https://goo.gl/RfO9jv .  Please feel free to
> distribute.
>
> -Jennifer Dunne
>
> Vice President for Science | Santa Fe Institute
>
>
> 
>
> *Bioinformatics Engineer Full Time Position*
>
> We are adding a new team member at Phylagen, Inc. (phylagen.com). If you
> know a software engineer who fits, please direct them to
> j...@phylagen.com  .
>
> We are an energized team developing microbiome data analytic tools and
> bioinformatics pipelines that are being applied to a wide range of
> environments.
>
> We plan to bring on an innovative coder - ideally with a M.S or Ph.D. in
> computer science, engineering, statistics, or bioinformatics
> (translating to 4-5 years software engineering experience). We want
> someone deeply knowledgeable in data analysis scripting
> (R/Python/Julia), and in algorithm optimization, including
> parallelization, distributed execution and implementing methods in a
> lower-level language (e.g. C, C++, Java). The position will entail
> combining code and data from different disciplines, translating and
> optimizing published research algorithms into industry products, and
> creating reference databases that can be used in machine learning
> applications. Expertise in the analysis of metagenomics data and
> bioinformatics pipelines is a bonus. We are looking someone who is
> flexible - a fast learner with relevant experience that will allow them
> to contribute quickly. You will be a key player in a cutting edge,
> rapidly growing venture-backed microbiome startup.
>
>
>
>
>
>
> --
> Um axé! :)
>
> --
> Charles Novaes de Santana, PhD
> http://www.imedea.uib-csic.es/~charles
>
>

-- 
Um axé! :)

--
Charles Novaes de Santana, PhD
http://www.imedea.uib-csic.es/~charles

Re: [julia-users] Proposal: NoveltyColors.jl

[Tomas Lycken]

Randy, that was my point exactly :)

// T

On Wednesday, December 2, 2015 at 8:38:28 PM UTC+1, Stefan Karpinski wrote:
>
> Parkinson's law of triviality 
> 
>
> On Wed, Dec 2, 2015 at 2:26 PM, Randy Zwitch  > wrote:
>
>> On Wednesday, December 2, 2015 at 3:12:36 AM UTC-5, Tomas Lycken wrote:
>>>
>>> Also, the naming discussion here is not *only* on naming; it's also on 
>>> the possibility of including *more things *in the package. I would be 
>>> all for having a package like Palettes.jl, which would include both 
>>> NoveltyColors.jl and other palettes, but that's not in conflict with the 
>>> current package - it's an extension, that might happen tomorrow, in a year, 
>>> or never at all, depending on whether someone actually finds it useful 
>>> enough to implement it.
>>>
>>
>> People are free to extend my package as much as they like, or create a 
>> wrapper package that aggregates all these different packages. Not sure why 
>> that needs a waiting period for my package. 
>>
>> On Wednesday, December 2, 2015 at 1:22:21 PM UTC-5, cormu...@mac.com 
>> wrote:
>>>
>>> I'm using [ColorSchemes.jl](
>>> https://github.com/cormullion/ColorSchemes.jl) for my own purposes, but 
>>> I'm happy to rename it if someone else wants the name.
>>
>>
>> Is this on METADATA? I thought I had checked, but maybe I had missed. If 
>> so, then it makes my package a bit redundant, as I could've submitted a PR 
>> to your package. 
>>
>> On Wednesday, December 2, 2015 at 1:39:09 PM UTC-5, Stefan Karpinski 
>> wrote:
>>>
>>> I'm still pretty unclear on what makes a color scheme a novelty.
>>>
>>>
>> I don't know, it seemed like having a plot based on the colors from the 
>> Grand Budapest Hotel or an outfit Beyonce wore would be a novelty, as 
>> opposed to something like ColorBrewer which explicitly tries to provide 
>> schemes that improve cartography. Since Tim has a majority of the commits 
>> on Color.jl and he thought it was an idea that stood on its own (per my 
>> reading into his approval comment above), I went with it. I really didn't 
>> think it would be this contentious.
>>
>>
>>  
>>
>
>

[julia-users] Re: InexactError for Arrays

[Stephan Buchert]

Thanks, yes, but I had expected that in the second command it would give me 
an Int64 Array, similar as in the 1st command I get automatically an Int64 
scalar. But to be fair, like this it is already much better than Matlab:

>> int32(5370)*8640 

ans =

  2147483647

>> [int32(5370)]*8640

ans =

  2147483647

/Stephan

Re: [julia-users] Re: InexactError for Arrays

[Mauro]

> Thanks, yes, but I had expected that in the second command it would give me
> an Int64 Array,

This would mean that multiplying a Int32 array by a Int64 would double
its size and be considerably slower.  If the array is large, then that
could be problematic.

> similar as in the 1st command I get automatically an Int64
> scalar. But to be fair, like this it is already much better than Matlab:
>
>>> int32(5370)*8640
>
> ans =
>
>   2147483647
>
>>> [int32(5370)]*8640
>
> ans =
>
>   2147483647
>
> /Stephan

Re: [julia-users] InexactError for Arrays

[Milan Bouchet-Valat]

Le jeudi 03 décembre 2015 à 05:30 -0800, Stephan Buchert a écrit :
> Is there a good reason for this?
> 
>   _
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "?help" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.4.1 (2015-11-08 10:33 UTC)
>  _/ |\__'_|_|_|\__'_|  |  
> |__/   |  x86_64-redhat-linux
> 
> julia> Int32(5730)*8640
> 49507200
> 
> julia> Int32[5730]*8640
> ERROR: InexactError()
>  in .* at arraymath.jl:127
>  in * at abstractarraymath.jl:55
> 
> julia> 
Yes. Though the difference is hard to get at first, it comes from the
fact that the result doesn't fit in an Int32. Indeed, multiplication of
an Int32 by and Int64 gives an Int64 (first command). In your second
command, that Int64 value has to be stored in the Int32 array, which
would incur an overflow. You can get the same error with this:
julia> Int32(5730*8640)
ERROR: InexactError()
 in call at ./essentials.jl:58
 in eval at ./boot.jl:263

If you really want the overflowing behavior, you can write this:
julia> Int32[5730]*Int32(8640)
1-element Array{Int32,1}:
 1150760960

This works since Int32 * Int32 gives back an Int32, without overflow
checks (but you probably don't want this...).


Regards

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

[Mauro]

Their write-up of their transition from Matlab to Julia is a nice read
too:
https://github.com/FRBNY-DSGE/DSGE.jl/blob/master/doc/MatlabToJuliaTransition.md

Adding to that: I found myself that MATLAB.jl can make the migration
easier as then it can be done step by step: just call the not yet
converted Matlab functions through MATLAB.jl.

And in case anyone else wonders what DSGE means: Dynamic stochastic
general equilibrium

https://en.wikipedia.org/wiki/Dynamic_stochastic_general_equilibrium

On Thu, 2015-12-03 at 15:05, Spencer Lyon  wrote:
> The Federal Reserve bank of New York has finished moving their fairly large
> DSGE model from Matlab to Julia. This model is used inside the Fed for
> forecasting and policy analysis.
>
> As part of the move to Julia, the code base has been open sourced.
>
> A blog post announcing the release is
> here: 
> http://libertystreeteconomics.newyorkfed.org/2015/12/the-frbny-dsge-model-meets-julia.html
>
> And the repository can be found here: https://github.com/FRBNY-DSGE/DSGE.jl

[julia-users] Re: Julia career advice question (x-post r/julia)

[André Lage]

hi,

Take a look at the this good course on Machine Learning by Prof. Yaser 
Abu-Mostafa with videos at Youtube:

http://work.caltech.edu/telecourse.html#lectures


André Lage.

On Tuesday, December 1, 2015 at 11:32:10 PM UTC-3, Jeffrey Sarnoff wrote:
>
> I am not current with tutorials for either language.  This may help:
>
>
> Python
>
> (not to be missed)   Robert Sedgewick's new book "Introduction To 
> Programming in Python" 
> (Python explained)   The second edition of "Python Programming" by 
> John Zelle
> (short pithy code)   The third edition of "Python Cookbook" by David 
> Beazley
>
> Julia
>
> Look at these topical videos, many very good 
> , watch 
> some of them in there entirety.
> Sign up for early access to Chris von Csefalvay's book 
>  (site says code MLCSEFAL 
> halves the cost)
> 
> (There are more *very* good Julia resources, had I had them handy ...)
>
>
> On Tuesday, December 1, 2015 at 6:18:23 PM UTC-5, Sisyphuss wrote:
>>
>>
>>> With these languages, working through good, focused, tutorials is worth 
>>> the investment of time.  
>>>
>>
>> Any recommendation?  
>>
>

Re: [julia-users] Re: InexactError for Arrays

[Milan Bouchet-Valat]

Le jeudi 03 décembre 2015 à 06:36 -0800, Stephan Buchert a écrit :
> julia> Int32[5730]*Int32(86400)
> 1-element Array{Int32,1}:
>  495072000
> 
> should certainly give the in memory smaller Int32 Array (and
> InexactError if applicable). But an Int32 Array times an Int64 scalar
> could well give automatically an Int64 array, I think. Then 
You can argue this as well, in the end it's a judgment call, based in
particular on what kind of scenarios you expect. As Mauro said, the
idea behind the current behavior is that an array of Int32 is not the
default, so if you chose it you must have good reasons, like reducing
memory consumption when storing small numbers.

It's true that it's a bit inconsistent with the fact that Int32 * Int64
gives Int64 (on 64-bit systems).

> julia> Int32[5730]*1
> 
> and similar things could be used to promote arrays (which otherwise 
> seems not that easy in Julia).
At least, this doesn't sound like a good justification. What's wrong
with these solutions?
julia> Array{Int64}(Int32[5730])
1-element Array{Int64,1}:
 5730

julia> convert(Array{Int64}, Int32[5730])
1-element Array{Int64,1}:
 5730

julia> map(Int64, Int32[5730])
1-element Array{Int64,1}:
 5730


Regards

[julia-users] ANN: DSGE.jl

[Spencer Lyon]

The Federal Reserve bank of New York has finished moving their fairly large 
DSGE model from Matlab to Julia. This model is used inside the Fed for 
forecasting and policy analysis. 

As part of the move to Julia, the code base has been open sourced.

A blog post announcing the release is 
here: 
http://libertystreeteconomics.newyorkfed.org/2015/12/the-frbny-dsge-model-meets-julia.html

And the repository can be found here: https://github.com/FRBNY-DSGE/DSGE.jl

[julia-users] InexactError for Arrays

[Stephan Buchert]

Is there a good reason for this?

  _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.1 (2015-11-08 10:33 UTC)
 _/ |\__'_|_|_|\__'_|  |  
|__/   |  x86_64-redhat-linux

julia> Int32(5730)*8640
49507200

julia> Int32[5730]*8640
ERROR: InexactError()
 in .* at arraymath.jl:127
 in * at abstractarraymath.jl:55

julia> 

Thanks,
Stephan

[julia-users] Re: InexactError for Arrays

[Stephan Buchert]

julia> Int32[5730]*Int32(86400)
1-element Array{Int32,1}:
 495072000

should certainly give the in memory smaller Int32 Array (and InexactError 
if applicable). But an Int32 Array times an Int64 scalar could well give 
automatically an Int64 array, I think. Then 

julia> Int32[5730]*1

and similar things could be used to promote arrays (which otherwise seems 
not that easy in Julia).

/Stephan

Re: [julia-users] 3D image matrix

[André Lage]

hi Rivo,

Could you try to run this code (plot the image) in Julia 0.4.1?

What's the output of `methods(view)` in both versions 0.3.? and 0.4.1 (are 
you sure it's Julia 0.3.2 or it'd be 0.3.8 instead)?

Thanks,


André.

On Wednesday, December 2, 2015 at 11:06:13 AM UTC-3, Rivo Sarmento wrote:
>
> ImageView.view(img) works also, thanks!
>
> This is a Polarimetric SAR image from San Andreas Fault, CA. 
>
> Em terça-feira, 1 de dezembro de 2015 23:08:59 UTC-3, Benjamin Deonovic 
> escreveu:
>>
>> So whats the image of? 
>>
>> On Tuesday, December 1, 2015 at 4:50:51 PM UTC-6, Rivo Sarmento wrote:
>>>
>>> Currently the imports, or using package, are in the begining of the code.
>>> I got it to work only if using is the last step before using `view`.
>>>
>>> I can't think of a particular reason for it to happen. Although, in my 
>>> 0.3.2 Julia importing ImageView returns:
>>>
>>> julia> using ImageView
>>> Warning: could not import Base.Text into Tk
>>>
>>> I finally got, as we can see in the attached file, thank you very much.
>>>
>>> Em terça-feira, 1 de dezembro de 2015 19:19:03 UTC-3, Tim Holy escreveu:

 On Tuesday, December 01, 2015 01:36:28 PM Rivo Sarmento wrote: 
 > But `view` returns: 
 > 
 > julia> view(img) 
 > ERROR: `view` has no method matching 
 > view(::Image{Float64,3,Array{Float64,3}}) 

 Are you sure you first said 
 using ImageView? 

 julia> methods(view) 
 # 3 methods for generic function "view": 
 view{A<:AbstractArray{T,N}}(img::A<:AbstractArray{T,N}) at 
 /home/tim/.julia/v0.4/ImageView/src/display.jl:233 
 view{A<:AbstractArray{T,N}}(imgc::ImageView.ImageCanvas, 
 img::A<:AbstractArray{T,N}) at 
 /home/tim/.julia/v0.4/ImageView/src/display.jl:344 
 view{A<:AbstractArray{T,N}}(c::Tk.Canvas, img::A<:AbstractArray{T,N}) 
 at 
 /home/tim/.julia/v0.4/ImageView/src/display.jl:364 

 That first method covers any AbstractArray. 

 --Tim 

Re: [julia-users] Re: InexactError for Arrays

[Stefan Karpinski]

Issue opened: https://github.com/JuliaLang/julia/issues/14252.

On Thu, Dec 3, 2015 at 11:53 AM, Stefan Karpinski 
wrote:

> I think we should move to having scalar+scalar, scalar+array and
> array+array promotions behave the same. We started out having scalar*scalar
> operations promote quite liberally. For example, Int8+Int8 promoted to Int
> rather than giving an Int8 result even though both arguments are of that
> type, based on the reasoning that we could give a correct value more often
> that way, and the promotion is generally free or cheap on modern CPUs. And
> IIRC, way back in the day Array{Int8}.+Array{Int8} followed this behavior.
> But of course, that's bad for large arrays since the result is then 8x
> larger than either of the arguments. So now we've moved to letting the
> desirable behavior for *array* dictate the behavior for scalars instead of
> the other way around; it's not immediately obvious that it should go in
> this direction, but for a language where arrays are so important, I think
> it's the right way to go. The old scalar behavior was also annoying when
> trying to write type-stable code for scalars. To that end, I would be
> interested in a PR making all scalar+scalar, scalar+array and array+array
> ops behave the same in terms of element types.
>
> On Thu, Dec 3, 2015 at 11:36 AM, Stephan Buchert 
> wrote:
>
>> Yes, certainly one can argue here back and forth:
>>
>> julia> Int32[5730]*86400e3
>> 1-element Array{Float64,1}:
>>  4.95072e11
>>
>> julia> Int32[5730]*86400f3
>> 1-element Array{Float32,1}:
>>  4.95072e11
>>
>> i.e. promotion also here the same as for scalar*scalar. My data are from
>> hardware sensors or counters, which deliver 8, 16 or 32 bit, memory
>> consumption in the computer is normally not an issue.
>>
>> What's wrong with these solutions?
>>> julia> Array{Int64}(Int32[5730])
>>> 1-element Array{Int64,1}:
>>>  5730
>>>
>>> julia> convert(Array{Int64}, Int32[5730])
>>> 1-element Array{Int64,1}:
>>>  5730
>>>
>>> julia> map(Int64, Int32[5730])
>>> 1-element Array{Int64,1}:
>>>  5730
>>
>>
>> Good comprehensive set of solutions, thanks. Still,
>>
>> julia> Int32[5730]*1
>>
>> would be shorter and nevertheless easily readable, according to my taste.
>>
>> Regards,
>> Stephan
>>
>
>

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

[Viral Shah]

This is really fantastic! Also great to see more economics codebases being 
open sourced, and some high quality libraries. Hoping such tools becomes a 
standard tool at central banks worldwide, and more code is open sourced!

-viral

On Thursday, December 3, 2015 at 7:35:57 PM UTC+5:30, Spencer Lyon wrote:
>
> The Federal Reserve bank of New York has finished moving their fairly 
> large DSGE model from Matlab to Julia. This model is used inside the Fed 
> for forecasting and policy analysis. 
>
> As part of the move to Julia, the code base has been open sourced.
>
> A blog post announcing the release is here: 
> http://libertystreeteconomics.newyorkfed.org/2015/12/the-frbny-dsge-model-meets-julia.html
>
> And the repository can be found here: 
> https://github.com/FRBNY-DSGE/DSGE.jl
>
>
>

Re: [julia-users] Re: InexactError for Arrays

[Stephan Buchert]

Yes, certainly one can argue here back and forth:

julia> Int32[5730]*86400e3
1-element Array{Float64,1}:
 4.95072e11

julia> Int32[5730]*86400f3
1-element Array{Float32,1}:
 4.95072e11

i.e. promotion also here the same as for scalar*scalar. My data are from 
hardware sensors or counters, which deliver 8, 16 or 32 bit, memory 
consumption in the computer is normally not an issue. 

What's wrong with these solutions? 
> julia> Array{Int64}(Int32[5730]) 
> 1-element Array{Int64,1}: 
>  5730 
>
> julia> convert(Array{Int64}, Int32[5730]) 
> 1-element Array{Int64,1}: 
>  5730 
>
> julia> map(Int64, Int32[5730]) 
> 1-element Array{Int64,1}: 
>  5730


Good comprehensive set of solutions, thanks. Still, 

julia> Int32[5730]*1

would be shorter and nevertheless easily readable, according to my taste.

Regards,
Stephan

Re: [julia-users] Re: InexactError for Arrays

[Stefan Karpinski]

I think we should move to having scalar+scalar, scalar+array and
array+array promotions behave the same. We started out having scalar*scalar
operations promote quite liberally. For example, Int8+Int8 promoted to Int
rather than giving an Int8 result even though both arguments are of that
type, based on the reasoning that we could give a correct value more often
that way, and the promotion is generally free or cheap on modern CPUs. And
IIRC, way back in the day Array{Int8}.+Array{Int8} followed this behavior.
But of course, that's bad for large arrays since the result is then 8x
larger than either of the arguments. So now we've moved to letting the
desirable behavior for *array* dictate the behavior for scalars instead of
the other way around; it's not immediately obvious that it should go in
this direction, but for a language where arrays are so important, I think
it's the right way to go. The old scalar behavior was also annoying when
trying to write type-stable code for scalars. To that end, I would be
interested in a PR making all scalar+scalar, scalar+array and array+array
ops behave the same in terms of element types.

On Thu, Dec 3, 2015 at 11:36 AM, Stephan Buchert 
wrote:

> Yes, certainly one can argue here back and forth:
>
> julia> Int32[5730]*86400e3
> 1-element Array{Float64,1}:
>  4.95072e11
>
> julia> Int32[5730]*86400f3
> 1-element Array{Float32,1}:
>  4.95072e11
>
> i.e. promotion also here the same as for scalar*scalar. My data are from
> hardware sensors or counters, which deliver 8, 16 or 32 bit, memory
> consumption in the computer is normally not an issue.
>
> What's wrong with these solutions?
>> julia> Array{Int64}(Int32[5730])
>> 1-element Array{Int64,1}:
>>  5730
>>
>> julia> convert(Array{Int64}, Int32[5730])
>> 1-element Array{Int64,1}:
>>  5730
>>
>> julia> map(Int64, Int32[5730])
>> 1-element Array{Int64,1}:
>>  5730
>
>
> Good comprehensive set of solutions, thanks. Still,
>
> julia> Int32[5730]*1
>
> would be shorter and nevertheless easily readable, according to my taste.
>
> Regards,
> Stephan
>

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

[Christopher Alexander]

This is great, great stuff.  It is awesome to see more Julia in the 
finance/econ world.

On Thursday, December 3, 2015 at 9:05:57 AM UTC-5, Spencer Lyon wrote:
>
> The Federal Reserve bank of New York has finished moving their fairly 
> large DSGE model from Matlab to Julia. This model is used inside the Fed 
> for forecasting and policy analysis. 
>
> As part of the move to Julia, the code base has been open sourced.
>
> A blog post announcing the release is here: 
> http://libertystreeteconomics.newyorkfed.org/2015/12/the-frbny-dsge-model-meets-julia.html
>
> And the repository can be found here: 
> https://github.com/FRBNY-DSGE/DSGE.jl
>
>
>

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

[Stefan Karpinski]

Great stuff. The transition document is actually linked to from the blog
post, so not exactly secret ;-). Regarding the transition doc, the
benchmarks would probably be clearer and more impactful expressed as
speedup relative to Matlab. Relative time is a decent metric when the
baseline is faster (e.g. typical comparison to C), but when the baseline is
slower, speedup is generally a better metric with the additional advantage
that bigger is better, which seems to be more intuitive as a general rule.

On Thu, Dec 3, 2015 at 11:15 AM, Tim Holy  wrote:

> Very nice. I'd be curious to know what you see as the major shortcomings of
> the profiler? Personally, I like the Julia profiler better than the Matlab
> one.
> That's conditional on using ProfileView, of course.
>
> Of course, I'm heavily biased since I wrote most of those tools myself. A
> list
> of shortcomings would be useful perspective. If they're mostly
> visualization
> rather than performance, might be best to file as an issue over at
> ProfileView.
>
> --Tim
>
> On Thursday, December 03, 2015 07:06:29 AM Spencer Lyon wrote:
> > Ahh nice,
> >
> > You found the draft of our next post ;)
> >
> > Good point about matlab.jl. we did make heavy use of that when
> transitioning
> > to julia.
>
>

[julia-users] Re: Fw: Fwd: [External-faculty] Silicon Valley Start-Up Software Engineer Position

[Brendan Tracey]

I got that email too!

Re: [julia-users] Re: slow wordcount

[Stefan Karpinski]

UInt8(delim) converts with a check to make sure that delim fits in the
UInt8 type. (delim % UInt8) computes delim modulo 256 as a UInt8 – i.e. it
just drops the high bits.

On Thu, Dec 3, 2015 at 7:35 AM, James Gilbert  wrote:

> I don't understand this line in Tim's code:
>
>   data = readuntil(s, delim % UInt8)
>
> Is it the same as:
>
>   data = readuntil(s, UInt8(delim))
>
> ? I guess its purpose is to select this method:
>
>   readuntil(s::IOStream, delim::UInt8)
>
> which is faster than:
>
>   readuntil(s::IO, delim::Char)
>
>
>

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

[Tim Holy]

Very nice. I'd be curious to know what you see as the major shortcomings of 
the profiler? Personally, I like the Julia profiler better than the Matlab one. 
That's conditional on using ProfileView, of course.

Of course, I'm heavily biased since I wrote most of those tools myself. A list 
of shortcomings would be useful perspective. If they're mostly visualization 
rather than performance, might be best to file as an issue over at ProfileView.

--Tim

On Thursday, December 03, 2015 07:06:29 AM Spencer Lyon wrote:
> Ahh nice,
> 
> You found the draft of our next post ;)
> 
> Good point about matlab.jl. we did make heavy use of that when transitioning
> to julia.

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

[Spencer Lyon]

Ahh nice,

You found the draft of our next post ;)

Good point about matlab.jl. we did make heavy use of that when transitioning to 
julia. 

Re: [julia-users] How to: grep an Array of strings

[Erik Schnetter]

You are looking for `filter`:

filter(line->match(r"parameter", line), rLines)

-erik

On Thu, Dec 3, 2015 at 2:52 PM, Jason McConochie  wrote:

> Is there grep for an Array of AbstractStrings?  See code below
>
>
> # A. Read a file into memory (nLines pre-determined)
>
> fID=open(fName)
>
> iLine=0;
>
> rLines=Array(ASCIIString,nLines);
>
> while !eof(fID)
>
>   iLine+=1
>
>   rLines[iLine]=readline(fID)
>
> end
>
>
> # B. Find all strings in rLines with "parameter"
>
>  Is something like this possible?
>
> indices=grep(rLines,r"parameter")
>
>
>
>


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

Re: [julia-users] How to: grep an Array of strings

[David P. Sanders]

El jueves, 3 de diciembre de 2015, 13:54:01 (UTC-6), Erik Schnetter 
escribió:
>
> You are looking for `filter`:
>
> filter(line->match(r"parameter", line), rLines)
>

Apparently this needs to be

filter(line->ismatch(r"3", line) != nothing, rLines)  

(replace "match" with "ismatch" to get a Boolean expression instead of a 
RegexMatch object).
 

>
> -erik
>
> On Thu, Dec 3, 2015 at 2:52 PM, Jason McConochie  > wrote:
>
>> Is there grep for an Array of AbstractStrings?  See code below
>>
>>
>> # A. Read a file into memory (nLines pre-determined)
>>
>> fID=open(fName)
>>
>> iLine=0;
>>
>> rLines=Array(ASCIIString,nLines);
>>
>> while !eof(fID)
>>
>>   iLine+=1
>>
>>   rLines[iLine]=readline(fID)
>>
>> end
>>
>>
>> # B. Find all strings in rLines with "parameter"
>>
>>  Is something like this possible?
>>
>> indices=grep(rLines,r"parameter")
>>
>>
>>
>>
>
>
> -- 
> Erik Schnetter  
> http://www.perimeterinstitute.ca/personal/eschnetter/
>

[julia-users] How to: grep an Array of strings

[Jason McConochie]

Is there grep for an Array of AbstractStrings?  See code below


# A. Read a file into memory (nLines pre-determined)

fID=open(fName)

iLine=0;

rLines=Array(ASCIIString,nLines);

while !eof(fID)

  iLine+=1

  rLines[iLine]=readline(fID)

end


# B. Find all strings in rLines with "parameter"

 Is something like this possible?

indices=grep(rLines,r"parameter")

[julia-users] Re: How to: grep an Array of strings

[Seth]

If you don't like regexes,

julia> a = ["apple","bear","ape","collar"]
4-element Array{ASCIIString,1}:
 "apple"
 "bear"
 "ape"
 "collar"


julia> filter(x->contains(x,"ap"),a)
2-element Array{ASCIIString,1}:
 "apple"
 "ape"


julia> filter(x->contains(x,"ar"),a)
2-element Array{ASCIIString,1}:
 "bear"
 "collar"


On Thursday, December 3, 2015 at 11:52:34 AM UTC-8, Jason McConochie wrote:
>
> Is there grep for an Array of AbstractStrings?  See code below
>
>
> # A. Read a file into memory (nLines pre-determined)
>
> fID=open(fName)
>
> iLine=0;
>
> rLines=Array(ASCIIString,nLines);
>
> while !eof(fID)
>
>   iLine+=1
>
>   rLines[iLine]=readline(fID)
>
> end
>
>
> # B. Find all strings in rLines with "parameter"
>
>  Is something like this possible?
>
> indices=grep(rLines,r"parameter")
>
>
>
>

[julia-users] Re: How to: grep an Array of strings

[Jason McConochie]

Thank you to all.  In particular, how can the indices of the matching lines 
be returned - I've a matlab background so am used to working from the 
indices.


On Thursday, December 3, 2015 at 8:52:34 PM UTC+1, Jason McConochie wrote:
>
> Is there grep for an Array of AbstractStrings?  See code below
>
>
> # A. Read a file into memory (nLines pre-determined)
>
> fID=open(fName)
>
> iLine=0;
>
> rLines=Array(ASCIIString,nLines);
>
> while !eof(fID)
>
>   iLine+=1
>
>   rLines[iLine]=readline(fID)
>
> end
>
>
> # B. Find all strings in rLines with "parameter"
>
>  Is something like this possible?
>
> indices=grep(rLines,r"parameter")
>
>
>
>

Re: [julia-users] getindex for a real number

[Ehsan Eftekhari]

>
> Sure, but it should be one way or the other, not half way between.
>
+100 

On Wednesday, December 2, 2015 at 6:51:35 PM UTC+1, Cedric St-Jean wrote:
>
> There's also
>
> x = [1 2; 3 4]
> x[:,[1]] # returns 2D array
> x[:, 1] # returns 1D array
> x[1, :] # AFAIK, returns 2D under Julia 0.4 and 1D under 0.5
>
> I like the 0.5 behaviour a lot better.
>
> On Wednesday, December 2, 2015 at 12:21:34 PM UTC-5, Tim Holy wrote:
>>
>> Glen, that's a great list of bugs. Have you considered filing them as 
>> issue(s)? 
>>
>> Some immediate thoughts: 
>>
>> On Wednesday, December 02, 2015 06:17:06 AM Glen O wrote: 
>> > As an example, reshape(1,1) throws an error 
>>
>> I'm not sure that's a real problem, although indeed implementing reshape 
>> on 
>> numbers would be more efficient than reshape([1], (1,1,1)) because in the 
>> latter 
>> you're creating two arrays. So possibly this is something we should 
>> implement. 
>>
>> > , and squeeze(1,(1,)) gets stuck 
>> > in an infinite loop. 
>>
>> That's definitely a bug. It's surely a very slow stack overflow (infinite 
>> recursion). 
>>
>> > vec(1) 
>>
>> Similar to reshape...maybe/maybe not. 
>>
>> > throws an error, as does cumsum(1). 
>>
>> Since sum(1) works, this should too. Bug. 
>>
>> > And of 
>> > course there's the issue with getindex involving colon, arrays or 
>> ranges 
>> > for indexing (you'd think that, just as a[[1,1]] gives the value of 
>> a[1] 
>> > twice for an array, that it would do the same for a scalar, but it 
>> doesn't). 
>>
>> Bug 
>>
>> > I can understand the desire not to have them be identical (since there 
>> are 
>> > cases where a function should do a different thing for a number than it 
>> > does for an array), yet allow partial compatibility... it's just a 
>> little 
>> > arbitrary which cases work and which don't. 
>>
>> Reports would help---not everyone hits these (I'm not sure I ever have). 
>>
>>

Re: [julia-users] Hello World.jl

[El suisse]

run the script from REPL:

julia>include("path/to/hello.jl")

for more information about workflow:

http://docs.julialang.org/en/release-0.4/manual/workflow-tips/
​

2015-12-03 14:30 GMT-03:00 Mark Kugel :

>
>
> Hi, I'm just starting to work with JULIA, and I have a couple of questions
> :
>
> 1) To get in touch with Julia, I have a small "hello.jl" script with only 
> "*println("Hello
> World.")*". How do I run it through Julia ? Is there somewhere in my mac
> a misty folder that Julia read and where I should store all my scripts ?
> 2) I want to use some data stored in a excel file. In my program, I use
> "ExcelReaders". Where do I have to store my Excel file to let Julia read it
> ?
>
>
> Some info : *Julia Version 0.4.1, installed on my Mac Book Pro in
> '/Applications/Julia-0.4.1.app'*
>
>
> Thank you
>
>
> MK
>

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

[David Anthoff]

This is fantastic! Cheers, David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Spencer Lyon
Sent: Thursday, December 3, 2015 6:06 AM
To: julia-users 
Subject: [julia-users] ANN: DSGE.jl

 

The Federal Reserve bank of New York has finished moving their fairly large 
DSGE model from Matlab to Julia. This model is used inside the Fed for 
forecasting and policy analysis. 

 

As part of the move to Julia, the code base has been open sourced.

 

A blog post announcing the release is here: 
http://libertystreeteconomics.newyorkfed.org/2015/12/the-frbny-dsge-model-meets-julia.html

 

And the repository can be found here: https://github.com/FRBNY-DSGE/DSGE.jl

 

 

[julia-users] Re: How to: grep an Array of strings

[Seth]

One way using my previous code:

julia> find(x->contains(x,"ap"),a)
2-element Array{Int64,1}:
 1
 3

julia> find(x->contains(x,"ar"),a)
2-element Array{Int64,1}:
 2
 4


On Thursday, December 3, 2015 at 1:24:07 PM UTC-8, Jason McConochie wrote:
>
> Thank you to all.  In particular, how can the indices of the matching 
> lines be returned - I've a matlab background so am used to working from the 
> indices.
>
>
> On Thursday, December 3, 2015 at 8:52:34 PM UTC+1, Jason McConochie wrote:
>>
>> Is there grep for an Array of AbstractStrings?  See code below
>>
>>
>> # A. Read a file into memory (nLines pre-determined)
>>
>> fID=open(fName)
>>
>> iLine=0;
>>
>> rLines=Array(ASCIIString,nLines);
>>
>> while !eof(fID)
>>
>>   iLine+=1
>>
>>   rLines[iLine]=readline(fID)
>>
>> end
>>
>>
>> # B. Find all strings in rLines with "parameter"
>>
>>  Is something like this possible?
>>
>> indices=grep(rLines,r"parameter")
>>
>>
>>
>>

Re: [julia-users] How to: grep an Array of strings

[Seth]

That's really elegant. Is there a reason filter() is defined for regex 
strings but not ASCIIStrings?

On Thursday, December 3, 2015 at 12:55:50 PM UTC-8, Stefan Karpinski wrote:
>
> You can just pass a Regex object to filter:
>
> filter(r"a.*b.*c"i, map(chomp,open(readlines,"/usr/share/dict/words")))
>
> This gives all dictionary words containing "a", "b" and "c" in order but 
> not contiguous.
>
> On Thu, Dec 3, 2015 at 3:29 PM, David P. Sanders  > wrote:
>
>>
>>
>> El jueves, 3 de diciembre de 2015, 13:54:01 (UTC-6), Erik Schnetter 
>> escribió:
>>>
>>> You are looking for `filter`:
>>>
>>> filter(line->match(r"parameter", line), rLines)
>>>
>>
>> Apparently this needs to be
>>
>> filter(line->ismatch(r"3", line) != nothing, rLines)  
>>
>> (replace "match" with "ismatch" to get a Boolean expression instead of a 
>> RegexMatch object).
>>  
>>
>>>
>>> -erik
>>>
>>> On Thu, Dec 3, 2015 at 2:52 PM, Jason McConochie  
>>> wrote:
>>>
 Is there grep for an Array of AbstractStrings?  See code below


 # A. Read a file into memory (nLines pre-determined)

 fID=open(fName)

 iLine=0;

 rLines=Array(ASCIIString,nLines);

 while !eof(fID)

   iLine+=1

   rLines[iLine]=readline(fID)

 end


 # B. Find all strings in rLines with "parameter"

  Is something like this possible?

 indices=grep(rLines,r"parameter")




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

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

[Patrick Kofod Mogensen]

Fellow economist here, great stuff! I'm curious to see what choices were 
made, and how it compares to other DSGE toolboxes and tools out there.

Is it going to be registered in METADATA? If so, would a name like DSGE be 
"allowed"?

On Thursday, December 3, 2015 at 3:05:57 PM UTC+1, Spencer Lyon wrote:
>
> The Federal Reserve bank of New York has finished moving their fairly 
> large DSGE model from Matlab to Julia. This model is used inside the Fed 
> for forecasting and policy analysis. 
>
> As part of the move to Julia, the code base has been open sourced.
>
> A blog post announcing the release is here: 
> http://libertystreeteconomics.newyorkfed.org/2015/12/the-frbny-dsge-model-meets-julia.html
>
> And the repository can be found here: 
> https://github.com/FRBNY-DSGE/DSGE.jl
>
>
>

Re: [julia-users] How to: grep an Array of strings

[Stefan Karpinski]

You can just pass a Regex object to filter:

filter(r"a.*b.*c"i, map(chomp,open(readlines,"/usr/share/dict/words")))

This gives all dictionary words containing "a", "b" and "c" in order but
not contiguous.

On Thu, Dec 3, 2015 at 3:29 PM, David P. Sanders 
wrote:

>
>
> El jueves, 3 de diciembre de 2015, 13:54:01 (UTC-6), Erik Schnetter
> escribió:
>>
>> You are looking for `filter`:
>>
>> filter(line->match(r"parameter", line), rLines)
>>
>
> Apparently this needs to be
>
> filter(line->ismatch(r"3", line) != nothing, rLines)
>
> (replace "match" with "ismatch" to get a Boolean expression instead of a
> RegexMatch object).
>
>
>>
>> -erik
>>
>> On Thu, Dec 3, 2015 at 2:52 PM, Jason McConochie 
>> wrote:
>>
>>> Is there grep for an Array of AbstractStrings?  See code below
>>>
>>>
>>> # A. Read a file into memory (nLines pre-determined)
>>>
>>> fID=open(fName)
>>>
>>> iLine=0;
>>>
>>> rLines=Array(ASCIIString,nLines);
>>>
>>> while !eof(fID)
>>>
>>>   iLine+=1
>>>
>>>   rLines[iLine]=readline(fID)
>>>
>>> end
>>>
>>>
>>> # B. Find all strings in rLines with "parameter"
>>>
>>>  Is something like this possible?
>>>
>>> indices=grep(rLines,r"parameter")
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Erik Schnetter 
>> http://www.perimeterinstitute.ca/personal/eschnetter/
>>
>

Re: [julia-users] How to: grep an Array of strings

[Stefan Karpinski]

There's an obvious predicate implied by a Regex: does it match a string?
What's the obvious predicate for a string? Checking whether it is contained
in another string is one option but that's pretty arbitrary. You could just
as well check for containment the other way. Or prefix, or suffix, etc.

On Thu, Dec 3, 2015 at 4:01 PM, Seth  wrote:

> That's really elegant. Is there a reason filter() is defined for regex
> strings but not ASCIIStrings?
>
> On Thursday, December 3, 2015 at 12:55:50 PM UTC-8, Stefan Karpinski wrote:
>>
>> You can just pass a Regex object to filter:
>>
>> filter(r"a.*b.*c"i, map(chomp,open(readlines,"/usr/share/dict/words")))
>>
>> This gives all dictionary words containing "a", "b" and "c" in order but
>> not contiguous.
>>
>> On Thu, Dec 3, 2015 at 3:29 PM, David P. Sanders 
>> wrote:
>>
>>>
>>>
>>> El jueves, 3 de diciembre de 2015, 13:54:01 (UTC-6), Erik Schnetter
>>> escribió:

 You are looking for `filter`:

 filter(line->match(r"parameter", line), rLines)

>>>
>>> Apparently this needs to be
>>>
>>> filter(line->ismatch(r"3", line) != nothing, rLines)
>>>
>>> (replace "match" with "ismatch" to get a Boolean expression instead of a
>>> RegexMatch object).
>>>
>>>

 -erik

 On Thu, Dec 3, 2015 at 2:52 PM, Jason McConochie  wrote:

> Is there grep for an Array of AbstractStrings?  See code below
>
>
> # A. Read a file into memory (nLines pre-determined)
>
> fID=open(fName)
>
> iLine=0;
>
> rLines=Array(ASCIIString,nLines);
>
> while !eof(fID)
>
>   iLine+=1
>
>   rLines[iLine]=readline(fID)
>
> end
>
>
> # B. Find all strings in rLines with "parameter"
>
>  Is something like this possible?
>
> indices=grep(rLines,r"parameter")
>
>
>
>


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

>>>
>>

Re: [julia-users] How to: grep an Array of strings

[Seth]

Makes sense. Thanks!

On Thursday, December 3, 2015 at 1:06:16 PM UTC-8, Stefan Karpinski wrote:
>
> There's an obvious predicate implied by a Regex: does it match a string? 
> What's the obvious predicate for a string? Checking whether it is contained 
> in another string is one option but that's pretty arbitrary. You could just 
> as well check for containment the other way. Or prefix, or suffix, etc.
>
> On Thu, Dec 3, 2015 at 4:01 PM, Seth  > wrote:
>
>> That's really elegant. Is there a reason filter() is defined for regex 
>> strings but not ASCIIStrings?
>>
>> On Thursday, December 3, 2015 at 12:55:50 PM UTC-8, Stefan Karpinski 
>> wrote:
>>>
>>> You can just pass a Regex object to filter:
>>>
>>> filter(r"a.*b.*c"i, map(chomp,open(readlines,"/usr/share/dict/words")))
>>>
>>> This gives all dictionary words containing "a", "b" and "c" in order but 
>>> not contiguous.
>>>
>>> On Thu, Dec 3, 2015 at 3:29 PM, David P. Sanders  
>>> wrote:
>>>


 El jueves, 3 de diciembre de 2015, 13:54:01 (UTC-6), Erik Schnetter 
 escribió:
>
> You are looking for `filter`:
>
> filter(line->match(r"parameter", line), rLines)
>

 Apparently this needs to be

 filter(line->ismatch(r"3", line) != nothing, rLines)  

 (replace "match" with "ismatch" to get a Boolean expression instead of 
 a RegexMatch object).
  

>
> -erik
>
> On Thu, Dec 3, 2015 at 2:52 PM, Jason McConochie <
> jason.mc...@gmail.com> wrote:
>
>> Is there grep for an Array of AbstractStrings?  See code below
>>
>>
>> # A. Read a file into memory (nLines pre-determined)
>>
>> fID=open(fName)
>>
>> iLine=0;
>>
>> rLines=Array(ASCIIString,nLines);
>>
>> while !eof(fID)
>>
>>   iLine+=1
>>
>>   rLines[iLine]=readline(fID)
>>
>> end
>>
>>
>> # B. Find all strings in rLines with "parameter"
>>
>>  Is something like this possible?
>>
>> indices=grep(rLines,r"parameter")
>>
>>
>>
>>
>
>
> -- 
> Erik Schnetter  
> http://www.perimeterinstitute.ca/personal/eschnetter/
>

>>>
>

[julia-users] Hello World.jl

[Mark Kugel]

Hi, I'm just starting to work with JULIA, and I have a couple of questions :

1) To get in touch with Julia, I have a small "hello.jl" script with only 
"*println("Hello 
World.")*". How do I run it through Julia ? Is there somewhere in my mac a 
misty folder that Julia read and where I should store all my scripts ?
2) I want to use some data stored in a excel file. In my program, I use 
"ExcelReaders". Where do I have to store my Excel file to let Julia read it 
?


Some info : *Julia Version 0.4.1, installed on my Mac Book Pro in 
'/Applications/Julia-0.4.1.app'*


Thank you


MK

Re: [julia-users] Re: Julia Docker images

[Jonathan Malmaud]

No

On Thu, Dec 3, 2015 at 6:35 PM Jeffrey Sarnoff 
wrote:

> Do Gallium and Cxx now come along with "docker run -it julia"?
>
>
> On Tuesday, October 13, 2015 at 9:15:29 PM UTC-4, Jonathan Malmaud wrote:
>>
>> There's an official Julia docker repository now:
>> https://hub.docker.com/_/julia/
>>
>> There is a PR to uptdate it to 0.4:
>> https://github.com/docker-library/official-images/pull/1121/files
>>
>> I'm working on creating Dockerfiles for versions of Julia that support
>> Gallium (the debugger) and Cxx (the C++ foreign function interface).
>>
>> I'm excited that anyone on any platform with docker installed could just
>> run "docker run -it julia" and be at a Julia prompt.
>>
>> On Wednesday, September 2, 2015 at 9:21:32 AM UTC-4, André Lage wrote:
>>>
>>> Hi,
>>>
>>> Any news on official Julia Docker images? Any chance of being one of
>>> these listed at Docker Hub?
>>>
>>>
>>> https://hub.docker.com/search/?q=juliabox=1=0=0=0=0
>>>
>>> We are using Julia, Docker and we plan to use JuliaBox as Web interface
>>> to test our research prototype. I think it would be easier and
>>> straightforward for us to use an official JuliaBox image instead of
>>> customizing other Docker image.
>>>
>>> Thanks,
>>>
>>>
>>> André Lage.
>>>
>>> On Monday, June 1, 2015 at 12:55:08 PM UTC-3, André Lage wrote:

 Hi Viral,

 That's a great idea! It would be interesting to include some packages
 for big data applications, i.e., to enable data analysis and visualization.
 For instance, DataFrame, Gadfly, HDFS, JSON, Mongo.

 Moreover, I agree with James: Julia docker images would be very useful
 and handy for reproducible research purposes.

 Best regards,

 André Lage.

 On Thursday, May 21, 2015 at 10:37:50 AM UTC-3, James Fairbanks wrote:
>
> Yes we should encourage people to use docker by pointing to the
> images. I am using the images after finding them on the Julia box github
> page. Putting a research project in a docker will aid in reproducible
> research.

[julia-users] Re: Julia Docker images

[Jeffrey Sarnoff]

Do Gallium and Cxx now come along with "docker run -it julia"?

On Tuesday, October 13, 2015 at 9:15:29 PM UTC-4, Jonathan Malmaud wrote:
>
> There's an official Julia docker repository now: 
> https://hub.docker.com/_/julia/
>
> There is a PR to uptdate it to 0.4: 
> https://github.com/docker-library/official-images/pull/1121/files
>
> I'm working on creating Dockerfiles for versions of Julia that support 
> Gallium (the debugger) and Cxx (the C++ foreign function interface).
>
> I'm excited that anyone on any platform with docker installed could just 
> run "docker run -it julia" and be at a Julia prompt. 
>
> On Wednesday, September 2, 2015 at 9:21:32 AM UTC-4, André Lage wrote:
>>
>> Hi,
>>
>> Any news on official Julia Docker images? Any chance of being one of 
>> these listed at Docker Hub?
>>
>>
>> https://hub.docker.com/search/?q=juliabox=1=0=0=0=0
>>
>> We are using Julia, Docker and we plan to use JuliaBox as Web interface 
>> to test our research prototype. I think it would be easier and 
>> straightforward for us to use an official JuliaBox image instead of 
>> customizing other Docker image.
>>
>> Thanks,
>>
>>
>> André Lage.
>>
>> On Monday, June 1, 2015 at 12:55:08 PM UTC-3, André Lage wrote:
>>>
>>> Hi Viral,
>>>
>>> That's a great idea! It would be interesting to include some packages 
>>> for big data applications, i.e., to enable data analysis and visualization. 
>>> For instance, DataFrame, Gadfly, HDFS, JSON, Mongo.
>>>
>>> Moreover, I agree with James: Julia docker images would be very useful 
>>> and handy for reproducible research purposes.
>>>
>>> Best regards,
>>>
>>> André Lage.
>>>
>>> On Thursday, May 21, 2015 at 10:37:50 AM UTC-3, James Fairbanks wrote:

 Yes we should encourage people to use docker by pointing to the images. 
 I am using the images after finding them on the Julia box github page. 
 Putting a research project in a docker will aid in reproducible research. 
>>>
>>>

[julia-users] Re: Why are Eigenvectors more sparse than left singular vectors?

[Steven G. Johnson]

>
> The second option is cheaper and should be more accurate, as it avoids the 
> cost and undesirable conditioning effect of computing *A*' * *A*. The 
> speedup is noticeable, but a negative side effect overwhelms the 
> improvement in my case. Sparsity is important in my application, and I am 
> using *U* to rotate a quadratic (and to reverse the rotation later on). 
> So I must perform multiple matrix-matrix multiplications involving *U*. 
> It turns out that the overall algorithm cost is *greater* with svd than 
> with eig due to the difference in density of *U*. 


Up to a scale factor, the eigenvectors that you get from eig(A'A) should be 
identical to the corresponding singular vectors from svd(A), by the 
definition of the SVD.If you are seeing a difference in sparsity, I can 
think of only two explanations:

1) The differences are just roundoff errors.  i.e. if you set U[abs(U) .< 
THRESHOLD] = 0 for some appropriate threshold, then the results will be the 
same.

2) You matrix has a lot of degeneracies, so the eigenvectors are not unique 
and different algorithms result in different choices.  You could try to 
find a sparsifying unitary transform (google this) to try and find the 
sparsest eigenvectors for each eigenvalue with multiplicity > 1.

Without knowing more about your matrix A, it's hard to say more.

Re: [julia-users] Re: Julia Docker images

[Tony Kelman]

We might want to check out quay.io as a hosted docker container build 
service, it says it has "unlimited storage and serving of public 
repositories" at https://quay.io/plans/. Not sure if that extends to 
building open source containers (or how their time limit and auto-building 
setup compares to docker hub), but it may be worth trying. Travis CI uses 
it for their docker containers.


On Thursday, December 3, 2015 at 4:10:17 PM UTC-8, Jonathan Malmaud wrote:
>
> No
>
> On Thu, Dec 3, 2015 at 6:35 PM Jeffrey Sarnoff  > wrote:
>
>> Do Gallium and Cxx now come along with "docker run -it julia"?
>>
>>
>> On Tuesday, October 13, 2015 at 9:15:29 PM UTC-4, Jonathan Malmaud wrote:
>>>
>>> There's an official Julia docker repository now: 
>>> https://hub.docker.com/_/julia/
>>>
>>> There is a PR to uptdate it to 0.4: 
>>> https://github.com/docker-library/official-images/pull/1121/files
>>>
>>> I'm working on creating Dockerfiles for versions of Julia that support 
>>> Gallium (the debugger) and Cxx (the C++ foreign function interface).
>>>
>>> I'm excited that anyone on any platform with docker installed could just 
>>> run "docker run -it julia" and be at a Julia prompt. 
>>>
>>> On Wednesday, September 2, 2015 at 9:21:32 AM UTC-4, André Lage wrote:

 Hi,

 Any news on official Julia Docker images? Any chance of being one of 
 these listed at Docker Hub?


 https://hub.docker.com/search/?q=juliabox=1=0=0=0=0

 We are using Julia, Docker and we plan to use JuliaBox as Web interface 
 to test our research prototype. I think it would be easier and 
 straightforward for us to use an official JuliaBox image instead of 
 customizing other Docker image.

 Thanks,


 André Lage.

 On Monday, June 1, 2015 at 12:55:08 PM UTC-3, André Lage wrote:
>
> Hi Viral,
>
> That's a great idea! It would be interesting to include some packages 
> for big data applications, i.e., to enable data analysis and 
> visualization. 
> For instance, DataFrame, Gadfly, HDFS, JSON, Mongo.
>
> Moreover, I agree with James: Julia docker images would be very useful 
> and handy for reproducible research purposes.
>
> Best regards,
>
> André Lage.
>
> On Thursday, May 21, 2015 at 10:37:50 AM UTC-3, James Fairbanks wrote:
>>
>> Yes we should encourage people to use docker by pointing to the 
>> images. I am using the images after finding them on the Julia box github 
>> page. Putting a research project in a docker will aid in reproducible 
>> research. 
>
>

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

[Tony Kelman]

DSGE is against the usual naming guidelines of trying to avoid acronyms, 
but at least this one is unambiguously googlable with one dominant result. 
I'd never heard of it as a non-economist, but given this is a big project 
from a major institution we can perhaps make an exception to the usual 
guidelines.


On Thursday, December 3, 2015 at 1:20:51 PM UTC-8, Patrick Kofod Mogensen 
wrote:
>
> Fellow economist here, great stuff! I'm curious to see what choices were 
> made, and how it compares to other DSGE toolboxes and tools out there.
>
> Is it going to be registered in METADATA? If so, would a name like DSGE be 
> "allowed"?
>
> On Thursday, December 3, 2015 at 3:05:57 PM UTC+1, Spencer Lyon wrote:
>>
>> The Federal Reserve bank of New York has finished moving their fairly 
>> large DSGE model from Matlab to Julia. This model is used inside the Fed 
>> for forecasting and policy analysis. 
>>
>> As part of the move to Julia, the code base has been open sourced.
>>
>> A blog post announcing the release is here: 
>> http://libertystreeteconomics.newyorkfed.org/2015/12/the-frbny-dsge-model-meets-julia.html
>>
>> And the repository can be found here: 
>> https://github.com/FRBNY-DSGE/DSGE.jl
>>
>>
>>

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

[Viral Shah]

DSGE is a very common name in economics, but Dynamic Stochastic General 
Equilibrium Models don’t mean much elsewhere. I would love to see some of those 
components underneath such as the Kalman filter come from other packages 
eventually.

-viral



> On 04-Dec-2015, at 7:47 AM, Tony Kelman  wrote:
> 
> DSGE is against the usual naming guidelines of trying to avoid acronyms, but 
> at least this one is unambiguously googlable with one dominant result. I'd 
> never heard of it as a non-economist, but given this is a big project from a 
> major institution we can perhaps make an exception to the usual guidelines.
> 
> 
> On Thursday, December 3, 2015 at 1:20:51 PM UTC-8, Patrick Kofod Mogensen 
> wrote:
> Fellow economist here, great stuff! I'm curious to see what choices were 
> made, and how it compares to other DSGE toolboxes and tools out there.
> 
> Is it going to be registered in METADATA? If so, would a name like DSGE be 
> "allowed"?
> 
> On Thursday, December 3, 2015 at 3:05:57 PM UTC+1, Spencer Lyon wrote:
> The Federal Reserve bank of New York has finished moving their fairly large 
> DSGE model from Matlab to Julia. This model is used inside the Fed for 
> forecasting and policy analysis. 
> 
> As part of the move to Julia, the code base has been open sourced.
> 
> A blog post announcing the release is here: 
> http://libertystreeteconomics.newyorkfed.org/2015/12/the-frbny-dsge-model-meets-julia.html
> 
> And the repository can be found here: https://github.com/FRBNY-DSGE/DSGE.jl
> 
>