Does this file contain valid Julia statements? In which case just `include`
the file.
Say you have a file called config.txt in the current director with the
following text:
a=1
Then, on the REPL
julia include(config.txt)
1
julia a
1
If the statements are not valid Julia, then you'll have
Thx Tim:) I have !
julia A=read(dset)[:,1:2]
5x2 sparse matrix with 0 Int64 entries:
julia fid = jldopen(S.jld,r)
Julia data file version 0.0.2: S.jld
julia dset=fid[S]
JldDataset(HDF5 dataset: /S (file: S.jld),Julia data file version 0.0.2:
S.jld)
julia A=read(dset)[1:3,:]
3x18 sparse
On Friday, August 15, 2014 12:13:42 PM UTC+2, Tobias Knopp wrote:
This is a bug but I am not sure on which side. The convert function is
wrong because it does not create the type that is passed. But maybe Julia
should not create the immutable type when seeing this.
Could you please file
Thanks Jan,
as you may have seen, Jeff agrees that this is a bug in Julia as well. So
you have found two bugs for one test case. Very helpful.
Cheers,
Tobi
Am Montag, 18. August 2014 11:12:05 UTC+2 schrieb Jan Kybic:
On Friday, August 15, 2014 12:13:42 PM UTC+2, Tobias Knopp wrote:
This
I came across this post wondering about the same. After reading the
current documentation it is not clear to me whether parallelizing such a
loop using shared memory is easily achieved in Julia 0.3, or if the same
difficulty remains.
Den torsdag den 7. november 2013 05.08.38 UTC+1 skrev
Hi all,
Is this a bug or a feature?
julia idx = [1:10]
10-element Array{Int64,1}:
1
2
3
4
5
6
7
8
9
10
julia idx .!= 2 idx .!= 8
10-element BitArray{1}:
true
false
true
true
true
true
true
true
true
true
which appears wrong to me. However, by wrapping
Is the capitalization of package names a standard convention we can count
on?
Maybe you are running into #5187
https://github.com/JuliaLang/julia/issues/5187?
On Monday, August 18, 2014 3:11:44 PM UTC+3, Davide Lasagna wrote:
Hi all,
Is this a bug or a feature?
julia idx = [1:10]
10-element Array{Int64,1}:
1
2
3
4
5
6
7
8
9
10
julia
Yes, it is the Julia convention.
There is only one (registered) exception, which is prehistoric in Julia
terms (kNN.jl)
On Monday, August 18, 2014 8:32:40 AM UTC-4, TR NS wrote:
Is the capitalization of package names a standard convention we can count
on?
It is a convention, but it isn't required anywhere or guaranteed. You can
currently count on package names being ASCII.
On Mon, Aug 18, 2014 at 8:32 AM, TR NS transf...@gmail.com wrote:
Is the capitalization of package names a standard convention we can count
on?
Thanks guys. I didn't think of using the dot.
David.
On Friday, 15 August 2014 18:53:43 UTC+2, Patrick O'Leary wrote:
Because that might be subtle to see if you're not looking closely, and you
mentioned a MATLAB background, note that there is an additional dot before
the comparison
I can probably register KNN.jl and deprecate kNN.jl.
— John
On Aug 18, 2014, at 5:45 AM, Iain Dunning iaindunn...@gmail.com wrote:
Yes, it is the Julia convention.
There is only one (registered) exception, which is prehistoric in Julia terms
(kNN.jl)
On Monday, August 18, 2014 8:32:40
This is not a good idea – it will cause endless problems on case-insensitive
file systems like HFS+ on Macs.
On Aug 18, 2014, at 10:08 AM, John Myles White johnmyleswh...@gmail.com
wrote:
I can probably register KNN.jl and deprecate kNN.jl.
— John
On Aug 18, 2014, at 5:45 AM, Iain
Good point. I guess we’ll have to watch until we put kNN.jl inside of another
package before we can get rid of it.
— John
On Aug 18, 2014, at 7:18 AM, Stefan Karpinski stefan.karpin...@gmail.com
wrote:
This is not a good idea – it will cause endless problems on case-insensitive
file
Yes, I think it's totally fine until it can be merged into another package.
The capitalization thing is a convention, not a rule. It's almost good to
have at least one package around that violates the convention so that we
can't assume that all packages start with an uppercase letter.
On Mon,
Good morning,
I am looking for a simple way to convert an Integer DataFrame to a Float
DataFrame. Here is an example of the problem:
julia using DataFrames
julia A=DataFrame([1 2; 3 4])
2x2 DataFrame:
x1 x2
[1,] 1 2
[2,] 3 4
With multiplication, there is no problem automatically converting
Hi,
I have the following problem, which makes debugging of my self-written
module quite difficult. When an exception is thrown inside my module, the
backtrace won't include the position of the error inside my module, but
only the position where I call the function in my module. The following
Hi Bradley,
Would you consider using DataArrays for this? DataFrames no longer support
these operations, so any upgrade in your setup would turn all of this code into
errors.
All of these operations work on DataArrays already.
— John
On Aug 18, 2014, at 7:28 AM, Bradley Setzler
I found that the easiest way was to use two files - one file contains the
function to be run in parallel, the other file uses Require() to load the
function in parallel, and pmap to call the function.
I have a working example of the two-file approach here:
Hi John,
Thanks for your reply, I'm getting the following:
julia A=DataArray([1 2; 3 4])
2x2 DataArray{Int64,2}:
1 2
3 4
julia A*.5
2x2 DataArray{Float64,2}:
0.5 1.0
1.5 2.0
julia A/2.
2x2 DataArray{Float64,2}:
0.5 1.0
1.5 2.0
julia A/2
InexactError()
So it converts to Float if divided by
What versions are you using? This was a bug, but I think it’s been fixed on 0.3
for some time.
— John
On Aug 18, 2014, at 8:02 AM, Bradley Setzler bradley.setz...@gmail.com wrote:
Hi John,
Thanks for your reply, I'm getting the following:
julia A=DataArray([1 2; 3 4])
2x2
This has been fixed in julia 0.3.
--Tim
On Monday, August 18, 2014 06:42:56 AM Martin Klein wrote:
Hi,
I have the following problem, which makes debugging of my self-written
module quite difficult. When an exception is thrown inside my module, the
backtrace won't include the position of
One of the best things you can do for the Julia community is to start using the
release candidates of 0.3. Everyone will be better off if bugs are found now
rather than when 0.3 is released. You can help make 0.3 a better release by
installing one of the latest binaries and testing it out.
I'm glad to report that the general and beautifully functional solution sum(
imap(sinc_plus_x, x)) is in fact as efficient as the devectorized
hand-written one!
It turns out I made the mistake to forget to forward an expression like
{Type{F}} to the imap iterator constructor (cf. code below),
Multiplying a DataFrame by a scalar has been deprecated and will not work
once you update to Julia 0.3 and the associated DataFrames version.
On Monday, August 18, 2014 6:10:44 PM UTC+3, Bradley Setzler wrote:
Update: I found a 1-line command to convert everything in a DataFrame into
a Float
+1,000,000
On Mon, Aug 18, 2014 at 11:25 AM, John Myles White johnmyleswh...@gmail.com
wrote:
One of the best things you can do for the Julia community is to start
using the release candidates of 0.3. Everyone will be better off if bugs
are found now rather than when 0.3 is released. You
is there a way to get this in homebrew? for the last week or so, a
homebrew --HEAD install gives the current 0.4 release.
On Monday, August 18, 2014 10:26:03 AM UTC-5, John Myles White wrote:
One of the best things you can do for the Julia community is to start
using the release candidates
On Monday, August 18, 2014 8:45:58 AM UTC-4, Stefan Karpinski wrote:
It is a convention, but it isn't required anywhere or guaranteed. You can
currently count on package names being ASCII.
Do you expect the ASCII part will eventually change too? If I can count on
ASCII, that means I can
Hm, this is strange. I'm using julia 0.3.0-rc4 and I'm getting the
truncated backtrace shown above. I've compiled Julia from Git by checking
out the v0.3.0-rc4 tag. This is on Debian Testing. Any ideas what is
happening here?
Am Montag, 18. August 2014 17:18:51 UTC+2 schrieb Tim Holy:
This
On Mon, Aug 18, 2014 at 11:56 AM, TR NS transf...@gmail.com wrote:
On Monday, August 18, 2014 8:45:58 AM UTC-4, Stefan Karpinski wrote:
It is a convention, but it isn't required anywhere or guaranteed. You can
currently count on package names being ASCII.
Do you expect the ASCII part will
Thanks John. I'm currently installing 0.3 release candidate at your
suggestion. It's been relatively easy to install - Mac users have to deal
with the minor hassle of making hidden files visible and then deleting
files associated with the old Julia version, but it was fine otherwise.
Julia
On Mon, Aug 18, 2014 at 12:01 PM, Bradley Setzler bradley.setz...@gmail.com
wrote:
Mac users have to deal with the minor hassle of making hidden files
visible and then deleting files associated with the old Julia version, but
it was fine otherwise.
Are you talking about deleting old history
Hey Thomas. Once 0.3.0-rc4 was released, the non-head version of julia was
bumped to 0.3.0-rc4.
On Aug 18, 2014 11:42 AM, Thomas Covert thom.cov...@gmail.com wrote:
is there a way to get this in homebrew? for the last week or so, a
homebrew --HEAD install gives the current 0.4 release.
On
For most Julia code I do I use IJulia
https://github.com/JuliaLang/IJulia.jl. For more IDEish environment I use
LightTable http://www.lighttable.com/, along with Juno aka Jupiter-LT
https://github.com/one-more-minute/Jupiter-LT. Sometime I also just rely
on Atom for simple text editor duties.
Right, deleting the old history files. It's always better for us non-CS
people to avoid handling hidden files. Would it ever be possible to upgrade
Julia from within Julia? Like Pkg.update() for Julia version, something
like Version.update(0.3.0)?
Best,
Bradley
On Monday, August 18, 2014
Thanks, Johan. I have upgraded to 0.3 release candidate and see what you
mean about scalar multiplication not working for DataFrame any more. I see
also that DataArray successfully converts Integer to Float in the way John
was describing earlier, which solves the original problem.
Problem
Thank you for upgrading. You've made our lives a lot easier. :)
-- John
On Aug 18, 2014, at 9:28 AM, Bradley Setzler bradley.setz...@gmail.com wrote:
Thanks, Johan. I have upgraded to 0.3 release candidate and see what you mean
about scalar multiplication not working for DataFrame any more.
Please say it isn't so... :-( (Is there an emoticon for deeply unhappy?)
But I won't shoot the messenger :-).
Anyway, I'm using v0.3.0-rc4 also, but on Kubuntu 14.04. Can you file an issue,
please?
--Tim
On Monday, August 18, 2014 08:58:12 AM Martin Klein wrote:
Hm, this is strange. I'm
This is a really cool family of tricks. Time for me to start replacing some
::Function specifiers in my argument lists...
--Tim
On Monday, August 18, 2014 09:00:22 PM Rafael Fourquet wrote:
I'm glad to report that the general and beautifully functional solution sum(
imap(sinc_plus_x, x)) is
Hi all,
i'm trying to improve the performance of this function:
https://gist.github.com/floswald/9e79f6f51c276becbd74
In a nutshell, I have got a high-dimensional array vbar (in this instance
it is 9D), and I want to obtain another array EV (also 9D), by
matrix-multiplying several dimensions
Have you run it through the profiler already?
On Monday, August 18, 2014, Florian Oswald florian.osw...@gmail.com wrote:
Hi all,
i'm trying to improve the performance of this function:
https://gist.github.com/floswald/9e79f6f51c276becbd74
In a nutshell, I have got a high-dimensional array
On Monday, August 18, 2014 12:13:12 PM UTC-4, Stefan Karpinski wrote:
On Mon, Aug 18, 2014 at 11:56 AM, TR NS tran...@gmail.com javascript:
wrote:
On Monday, August 18, 2014 8:45:58 AM UTC-4, Stefan Karpinski wrote:
It is a convention, but it isn't required anywhere or guaranteed. You
You can ignore any LineNumberNodes in a block; they're used for generating
backtraces. Also, dump() is a great tool for printing out expressions to
inspect their structure.
On Monday, August 18, 2014 4:43:16 AM UTC-6, Tomas Krehlik wrote:
Thanks, sometimes even small nudge helps. I have it
Useful reading!
Thanks!
On Monday, August 18, 2014 1:36:24 PM UTC+1, Johan Sigfrids wrote:
Maybe you are running into #5187
https://github.com/JuliaLang/julia/issues/5187?
On Monday, August 18, 2014 3:11:44 PM UTC+3, Davide Lasagna wrote:
Hi all,
Is this a bug or a feature?
julia
Hi!
yes. I find that
37 % of time spent at line 26
51 % of time spent at line 29
in the gist.
line 26 is
idx1 = idx9(is1,iz1,iy1,ip1,itau1,ia,ih,ij,age,p)
line 29 is
@inbounds tmp += m.vbar[idx1] * Gz[iz + p.nz * (iz1 + p.nz *
(ij-1)-1)] * Gyp[iy + p.ny * ((ip-1) + p.np * ((iy1-1) + p.ny *
What are the dimensions (i.e. sizes) of these 9 dimensions? You might be
interested in trying the tensorcontract routine from TensorOperations.jl
and compare the method=:BLAS vs method=:native approach. Although I do
assume that for a specific case like this (where basically every dimension
is
sounds intriguing! will have a look at that TensorOperations.jl.
the size of the array is
*julia **size(m.EV)*
*(2,4,3,3,2,17,2,9,29)*
On 18 August 2014 22:27, Jutho juthohaege...@gmail.com wrote:
What are the dimensions (i.e. sizes) of these 9 dimensions? You might be
interested in trying
Gotcha. I’m getting some OpenBLAS errors when I try to install this, and have
filed an issue here: https://github.com/staticfloat/homebrew-julia/issues/102
On Aug 18, 2014, at 11:17 AM, Elliot Saba staticfl...@gmail.com wrote:
Hey Thomas. Once 0.3.0-rc4 was released, the non-head version of
./Foo isn't valid syntax, so that's not quite going to work. You could
do @require
./Foo instead. For what it's worth, I don't think that deciding whether
to load a file or package based on capitalization is a good idea. One
alternative would be to load a package if the argument is a symbol and
Is there a named function that does what does, eg (a,b) == ab? I
actually want a multi argument version like $(a,b,c...). Also is that
the name of that function is not and is not overloadable? The same
is not true of |.
*julia **a = zeros(Bool,10);b=[randbool() for j=1:10];*
*julia
This are some of those few operators that need parens to be used in
function call syntax:
julia ()(3,5)
1
julia (|)(3,5)
7
This isn't required in unambiguous situations like as an argument to
another function:
julia reduce(|, 0:8)
15
On Mon, Aug 18, 2014 at 6:20 PM, g
Probably because of our special parsing of in ccall invocations.
-E
On Mon, Aug 18, 2014 at 7:14 PM, Stefan Karpinski ste...@karpinski.org
wrote:
Yeah, I forget exactly why you can't to that with but there's some
parsing ambiguity.
On Mon, Aug 18, 2014 at 6:33 PM, g
That seems likely.
On Aug 18, 2014, at 7:24 PM, Elliot Saba staticfl...@gmail.com wrote:
Probably because of our special parsing of in ccall invocations.
-E
On Mon, Aug 18, 2014 at 7:14 PM, Stefan Karpinski ste...@karpinski.org
wrote:
Yeah, I forget exactly why you can't to that
53 matches
Mail list logo
