I don't think Julia is really amenable to this kind of organization because
Julia's modules have no logical relationship to filesystem layouts, whereas
Python's system is all about filesystem layout and has nothing to do with
textual inclusion.
On Wednesday, February 24, 2016 at 1:28:08 PM
(offered with the caveat that I cannot answer your question)
It seems to me that duplicating any singleton is incorrect, and so this is
appropriately an "issue" with deepcopy.
On Tuesday, February 23, 2016 at 10:10:24 AM UTC-5, Bill Hart wrote:
>
> Just correcting a typo in my question (the
Thank you for your answers, they helped me a lot. I don't have a
Python-like solution yet, but I have a starting point.
On Wednesday, February 24, 2016 at 6:33:51 PM UTC-5, Yichao Yu wrote:
>
> On Wed, Feb 24, 2016 at 6:21 PM, Jeffrey Sarnoff
> wrote:
> > To allow
Actually it's https://github.com/JuliaLang/julia/pull/14798
On Wednesday, February 24, 2016 at 6:23:14 AM UTC-8, Kristoffer Carlsson
wrote:
>
> https://github.com/JuliaLang/julia/pull/12608
>
> On Wednesday, February 24, 2016 at 3:21:59 PM UTC+1, Christoph Ortner
> wrote:
>>
>> Can you post a
understood ...
i was really focusing on this:
"... essentially each macro introduces a new keyword."
which is either true, or false ... and not having any real
experience with the macro space i am assuming that
it is true ...
if it is true, then it seems reasonable to have the means
to
I think he was just referring to the fact that it's "one more thing to
remember". For the record, I would never actually use this macro, for
reasons implied by Mauro, but there are other, similar uses that this
strategy could be benficial. The choice (IMO) should come down to which is
more
interesting ...
what facilities are available to survey
and reason about this "keyword" space ?
On Wednesday, February 24, 2016 at 11:05:34 AM UTC-8, Mauro wrote:
>
> ... essentially each macro introduces a new keyword.
>
On Wed, Feb 24, 2016 at 6:21 PM, Jeffrey Sarnoff
wrote:
> To allow different independent capabilities and have them be read only if
> chosen, you should have each capability be written as a separate module with
> its own [set of] files.
> If you want the user to see
To allow different independent capabilities and have them be read only if
chosen, you should have each capability be written as a separate module
with its own [set of] files.
If you want the user to see them as subordinate to a larger package, let
the larger package import each conditionally.
On Wednesday, February 24, 2016 at 4:15:49 PM UTC-5, Jeffrey Sarnoff wrote:
>
> This should not be a problem. What is your concern?
>
Loading time/RAM usage. I'm trying to wrap/port scikit-learn, and their
module arrangement makes a lot of sense. In Python, I don't get to load
code for
I'm interested in feedback on the following unregistered package that
implements a build-dependency system like the *make* utility or Ruby's Rake:
https://github.com/tshort/Make.jl (based on Mike Nolta's Rake.jl)
For me, a typical project will have a script that reads in data followed by
With Julia, submodules are present in support of the packaged module's
purpose. If the submodule is in a separate file and the package module
include()s the submodule's file, it is read. If the submodule is in the
same file as the other module and it really is a submodule, then it is
In Python, loading a module (i.e. importing a file) does not load
sub-modules, eg.:
import sklearn
import sklearn.linear_model
Is there any way to achieve the same thing in Julia?
module A
println("loaded A")
module B
println("loaded B")
end
end
Can I have "loaded A" without "loaded B"?
> this is awesome
>
> thanks!
A small word of caution: macros can make it harder for others (or your
future self) to read the code, as essentially each macro introduces a
new keyword. Just something to consider when introducing a macro;
awesome as they are.
> On Wednesday, February 24, 2016 at
Nice to see an alternate approach. This should satisfy people who don't
need the full async and minimal allocation of the upcoming DBAPI
PostgreSQL.jl and want a simpler and more intuitive interface. I also like
how you've handled types at the connection level.
On Friday, 19 February 2016
this is awesome
thanks!
On Wednesday, February 24, 2016 at 3:32:48 PM UTC+1, Tom Breloff wrote:
>
> Enjoy:
>
>
> julia> macro n(expr::Expr)
>@assert expr.head == :function
>s = expr.args[1].args[2]
>if isa(s,Expr) && s.head == :(::)
>s =
On Wed, Feb 24, 2016 at 8:46 AM, Lars Mescheder wrote:
> Hi,
> first thanks for all the amazing work on julia! I am currently trying to
> write a very general version of some optimization algorithm. Ideally, it
> would take an array of linear maps as input and then perform
Enjoy:
julia> macro n(expr::Expr)
@assert expr.head == :function
s = expr.args[1].args[2]
if isa(s,Expr) && s.head == :(::)
s = s.args[1]
end
unshift!(expr.args[2].args, :(n = length($s)))
esc(expr)
end
Julia encourages both abstract types and unions as function arguments.
However, in type declarations, parametric types are preferred. Both
are likely to be handled at compile time, without run time overhead.
This is, of course, only a rule of thumb. There are many cases where
there is no good way
https://github.com/JuliaLang/julia/pull/12608
On Wednesday, February 24, 2016 at 3:21:59 PM UTC+1, Christoph Ortner wrote:
>
> Can you post a link to that pull request?
> Thanks, Christoph
>
> On Wednesday, 24 February 2016 04:26:35 UTC, Tony Kelman wrote:
>>
>> It is possible to store explicit
Can you post a link to that pull request?
Thanks, Christoph
On Wednesday, 24 February 2016 04:26:35 UTC, Tony Kelman wrote:
>
> It is possible to store explicit zero values in sparse matrices, but not
> via the sparse() function at the moment. You currently have to construct a
> sparse matrix
Hi everybody,
I have several functions operating on one dimensional vectors.
Within each function the first thing I do is to define variable n holding
the length of input vector x:
n = length(x)
Is that possible to factor out this pattern somehow from all functions
definitions?
(...like
>
> Project like JuliaDB isn't quite what I was looking for since I'm arguing
> for a basic, core interface which will be used by julia's ecosystem of
> plotting libraries, statistical packages, ML libraries, etc. The data may
> come from a database or a csv or even generated on-the-fly.
I think
Hi,
first thanks for all the amazing work on julia! I am currently trying to
write a very general version of some optimization algorithm. Ideally, it
would take an array of linear maps as input and then perform optimization
depending on those.
So, is it possible to make a function of the form
Le mardi 23 février 2016 à 19:48 -0800, cdm a écrit :
>
> potentially of interest:
>
> http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-datafram
> es-are-still-slow/
>
>
>
> enjoy !!!
Other references I forgot to mention:
> I know in F# people encourage Discriminated Unions, what about in Julia?
I would say that Julia does not encourage them, but it is fine to use
them.
> I would like to do the following:
>
> immutable B end
> immutable C end
>
> typealias A Union{B,C}
>
> function A(x::Int)
> if x > 0
>
There is also:
- https://github.com/mbauman/RaggedArrays.jl which is being developed
(I think)
- https://bitbucket.org/maurow/ragged.jl/ which I abandoned. If I pick
it up again, I'll probably use https://github.com/mbauman/RaggedArrays.jl
See also:
Thanks! RaggedArrays.jl looks like a good start, though it looks
abandoned so I guess I’ll copy the necessary code (w/ License) and update as
needed.
> On 24 Feb 2016, at 5:25 PM, Tamas Papp wrote:
>
> These are called "ragged arrays", searching the list for this
28 matches
Mail list logo