Le mardi 13 mai 2014 à 00:39 -0400, Stefan Karpinski a écrit :
> I'm not sure that map! on a Set makes sense. The behavior of map! is
> that it replaces each element of a collection with a transformed value
> of that element. Implicit in that is that there is a notion of
> position – a place where
Maybe
https://github.com/dlfivefifty/ApproxFun#solving-differential-equations
could work?
W dniu niedziela, 11 maja 2014 09:33:15 UTC+2 użytkownik Tony Kelman
napisał:
>
> I couldn't find one, I don't think Sundials or DASSL do BVP's. Would be a
> useful thing to write though!
>
> Porting some
Hi,
Were you aware that matplotlib itself has a PGF/TikZ backend
> http://matplotlib.org/users/pgf.html ?
>
No but this is really cool I think!
> An example of how to save a figure in PGF source:
>
> using PyPlot
>
> # plot appearance setup
> linewidth = 0.4
> plt.rc("axes", linewidth=li
This would certainly serve as a good template for a julia version. Thanks!
Den mandag den 12. maj 2014 15.42.28 UTC+2 skrev Miguel Bazdresch:
>
> Some time ago I wrote a script to use pgfplots from octave/Matlab:
>
>
> https://bitbucket.org/mbaz/printpgf/src/28cead667bda6ec745a4418bc408f7f712cf843
The current behavior is useful in a number of contexts; for example, you can
write algorithms that take either a Vector or Matrix input without having to
reshape to a matrix. Note that you can index a vector as v[i,1] without error,
too.
But if you have a compelling example of where this leads
Ah, you should read the first line from the stream first. The stream reader
starts after the magic bytes. See here for information about the format:
http://en.wikipedia.org/wiki/Netpbm_format
--Tim
On Monday, May 12, 2014 11:54:43 PM Yakir Gagnon wrote:
> Thanks for the quick replay!
> I'm sure
You are right, it cannot even load the file. That is indeed very weird. I
run this on a MacBook Pro Retina (2013), latest Mac OS X, in a bash shell
inside of iTerm 2.
Details and julia versions below:
feldt:~$ julia "/Users/feldt/Library/Application
Support/LightTable/plugins/Jewel/jl/init.jl"
Weird. Given that this is a Julia issue, I'd either open an issue on github
or start a new thread on the mailing list – you'll get much better help
than I can offer you alone.
On Tuesday, 13 May 2014 12:24:54 UTC+1, Robert Feldt wrote:
>
> You are right, it cannot even load the file. That is ind
Ok, seems to be a problem with my Julia install since I installed Julia
0.2.1 and got the BoundsError:
feldt:~$ /Applications/Julia-0.2.1.app/Contents/Resources/julia/bin/julia
"/Users/feldt/Library/Application
Support/LightTable/plugins/Jewel/jl/init.jl"
ERROR: BoundsError()
in indexed_next a
Unfortunately after a restart I'm even more confused. Something might be
very weird with my setup. If anyone has pointers I'd appreciate them though:
feldt:~$ which julia
/usr/local/bin/julia
feldt:~$ ls -al /usr/local/bin/julia
lrwxr-xr-x 1 feldt admin 64 13 Maj 13:47 /usr/local/bin/julia ->
function f{T<:Float64}(x::T...)
print(x)
end
function f{T<:BigInt}(x::T...)
print(x)
end
I think it is because f(x::T...) can mean f() which cannot dispatch on T.
Hence the message
To fix, define
f()
before the new definition.
2014-05-13 14:38 GMT+02:00 Ariel Keselman :
> function f{T<:Float64}(x::T...)
> print(x)
> end
>
> function f{T<:BigInt}(x::T...)
> print(x)
>
...if you want at least one argument you could write f(x::T, y::T...)
2014-05-13 14:42 GMT+02:00 Andreas Noack Jensen <
andreasnoackjen...@gmail.com>:
> I think it is because f(x::T...) can mean f() which cannot dispatch on T.
> Hence the message
>
> To fix, define
>
> f()
>
> before the new
Le lundi 12 mai 2014 à 23:11 -0700, Ganesh Rapolu a écrit :
> I don't have any experience with tensors but it seems, at least on the
> surface, that the convenience is not worth allowing the bugs that
> could be prevented by enforcing 1 <= n <= ndims(A).
>
> However if that was the correct way to
Hi,
I just wanted to let you know that I plan to start the Zurich Julia User
Group.
If you are interested don't hesitate and join this goup. You can do this
here:
http://www.meetup.com/Zurich-Julia-User-Group/events/182818252/
The Zurich Julia User Group is located in Zurich, Switzerland, one
Yes, I agree that this bit is inconsistent.
On Tue, May 13, 2014 at 9:20 AM, Milan Bouchet-Valat wrote:
> Le lundi 12 mai 2014 à 23:11 -0700, Ganesh Rapolu a écrit :
>
> I don't have any experience with tensors but it seems, at least on the
> surface, that the convenience is not worth allowing
Wonderful! Would you make a PR to add a link to the community page:
https://github.com/JuliaLang/julialang.github.com/blob/master/community/index.md
On Tue, May 13, 2014 at 9:29 AM, Dominik Holenstein
wrote:
> Hi,
>
> I just wanted to let you know that I plan to start the Zurich Julia User
> Gr
On Tue, May 13, 2014 at 5:38 AM, Milan Bouchet-Valat wrote:
> IMHO map! isn't very helpful for Sets not because there's no order, but
> because it doesn't replace elements in the same memory slot, like it would
> in an array.
>
I didn't actually say anything about order, but rather about *place*,
Thank you!
Yes, I have added a line there below the London Julia Users Group.
Dominik
Am Dienstag, 13. Mai 2014 15:32:10 UTC+2 schrieb Stefan Karpinski:
>
> Wonderful! Would you make a PR to add a link to the community page:
>
>
> https://github.com/JuliaLang/julialang.github.com/blob/master/com
:-)
On Tue, May 13, 2014 at 9:51 AM, Dominik Holenstein
wrote:
> Thank you!
> Yes, I have added a line there below the London Julia Users Group.
>
> Dominik
>
>
> Am Dienstag, 13. Mai 2014 15:32:10 UTC+2 schrieb Stefan Karpinski:
>>
>> Wonderful! Would you make a PR to add a link to the communit
Le mardi 13 mai 2014 à 09:34 -0400, Stefan Karpinski a écrit :
> On Tue, May 13, 2014 at 5:38 AM, Milan Bouchet-Valat
> wrote:
>
> IMHO map! isn't very helpful for Sets not because there's no
> order, but because it doesn't replace elements in the same
> memory slot, like
I am interested in utilizing Cuda-Julia for my upcoming work.
For a simple case,
there are 50 decoupled instances which I want to execute in parallel. The
Data generated in each instances are to written in different files. How to
take care of such problem?
I donot have any prior experience of Pa
I can generate the .pgf without having to setup the backend which I think
is the expected behavior. According to the docs:
"Figures can also be directly compiled and saved to PDF with
plt.savefig('figure.pdf') by either switching to the backend..."
So it seems its only needed to save the PDFs... Yo
Given that set replacement is a fundamental mathematical operation (e.g.
it's an axiom of ZFC) I tend to regard an implementation of map as slightly
broken if map( , ) doesn't return a set. I realize though
that unordered collections are unnatural from a computer's point of view.
I take the
Thanks everybody, but I'm still confused about something. Suppose I want
to make my own ! function: how do I go about it?
julia> type testtype v::Bool end
julia> t1 = testtype( true )
testtype(true)
julia> t2 = testtype( false )
testtype(false)
julia> function testchange!( t::testtype, b::Bo
You can't do that – a function call can mutate a value but it cannot modify
what value a variable in the caller's local scope is bound to. There's a post
somewhere about why this is a good thing somewhere that I wrote a while ago;
I'll see if I can dig it up.
> On May 13, 2014, at 1:42 PM, Andr
If you have a machine with 50 CPUs, you could just fire up 50 copies of Julia
and assign each the task of tackling one. If you want to use CUDA, you can do
something similar in principle, but the task of splitting the computations is
much more involved. Julia's CUDA support is still relatively y
Thinking about it, map! could be implemented by creating and filling in a
new Set, then moving the underlying members back to the original Set.
It's kinda kludgy, and wouldn't be any more efficient, but it would allow
for a convenient and uniform interface.
Thoughts?
Andrew, I'll reiterate that
But you could do
julia> function testchange!( t::testtype, b::Bool )
t.v = b
end
testchange! (generic function with 1 method)
julia> t1
testtype(true)
julia> testchange!( t1, false )
false
julia> t1
testtype(false)
Cheers,
Kevin
On Tuesday, May 13, 2014 11:05:36 AM UTC-7,
Wouldn't it be faster to copy all the elements of the set into an array,
empty the set, and then fill the modified values back?
kl. 21:03:47 UTC+2 tirsdag 13. mai 2014 skrev Kevin Squire følgende:
>
> Thinking about it, map! could be implemented by creating and filling in a
> new Set, then movin
Yes, that seems better.
On Tue, May 13, 2014 at 3:16 PM, Ivar Nesje wrote:
> Wouldn't it be faster to copy all the elements of the set into an array,
> empty the set, and then fill the modified values back?
>
> kl. 21:03:47 UTC+2 tirsdag 13. mai 2014 skrev Kevin Squire følgende:
>>
>> Thinking
Right, but it may not be convenient to reset every field in a complex
type. In the interest of speed and clarity it may sometimes be preferable
to reset a variable in toto. It's awkward than a value can be changed
incrementally but not in one line.
On Tuesday, May 13, 2014 3:07:26 PM UTC-4, K
So this would involve adding a map method to base/set.jl?
On Tuesday, May 13, 2014 3:03:47 PM UTC-4, Kevin Squire wrote:
>
> Andrew, I'll reiterate that a pull request would be very welcome. I think
> you would find the Set functionality rather self contained, and the map
> function implementati
Yes, that's right.
On Tue, May 13, 2014 at 3:31 PM, Andrew Dabrowski wrote:
> So this would involve adding a map method to base/set.jl?
>
>
> On Tuesday, May 13, 2014 3:03:47 PM UTC-4, Kevin Squire wrote:
>>
>> Andrew, I'll reiterate that a pull request would be very welcome. I think
>> you woul
Here's my previous explanation of why modifying local variables via
function calls is a bad thing:
https://groups.google.com/d/msg/julia-users/pmgCAuxdBjc/HErxFDmOT0wJ.
On Tue, May 13, 2014 at 3:27 PM, Andrew Dabrowski wrote:
> Right, but it may not be convenient to reset every field in a comple
Note that this is not some unusual or controversial piece of language
design – this is how most languages work.
On Tue, May 13, 2014 at 3:33 PM, Stefan Karpinski wrote:
> Here's my previous explanation of why modifying local variables via
> function calls is a bad thing:
> https://groups.google.
Will the conference target Julia experts with only advanced topics or will
it be appropriate/beneficial to newcomers and prospective ones who are
tempted but perhaps a bit "skittish"?
I would find it useful if there was a little abstract for each
presentation. I understand it might be early fo
I'm not sure that would be better. rehash() will be called as soon as you
start inserting elements, because more than 3/4 of the elements will have
been deleted.
On Tue, May 13, 2014 at 12:20 PM, Stefan Karpinski wrote:
> Yes, that seems better.
>
>
> On Tue, May 13, 2014 at 3:16 PM, Ivar Nesje
So I'm looking at base/set.jl, and I'm almost immediately puzzled by some
syntax.
union!(s::Set, xs) = (for x=xs; push!(s,x); end; s)
What is xs? I might have expected
union!(s::Set, xs...) = (for x in xs; push!(s,x); end; s)
but "for x=xs" I don't get. Can someone explain how this syntax wo
It's the same thing. Matlab uses the = version but only allows ranges on
the right hand side, so it looks like `for k = 1:n` which reads pretty
well. We used to only allow the = form, which is why older code like this
uses = but decided that writing `for x = xs` was really confusing, so we
added `f
Ah, what a relief, thanks.
On Tuesday, May 13, 2014 4:49:31 PM UTC-4, Stefan Karpinski wrote:
>
> It's the same thing. Matlab uses the = version but only allows ranges on
> the right hand side, so it looks like `for k = 1:n` which reads pretty
> well. We used to only allow the = form, which is
I'm trying to wean myself off MATLAB and am trying to figure out how to do
things the julian way by porting some code that fits a Gaussian process.
Something my code does over and over again while fitting the GP is compute
the value of a covariance function - more or less a matrix of pairwise
Without timing it, one potential performance issue is that taking slices of
arrays makes copies rather than views. If you calculate things like column-wise
distances without making copies, you should see a speedup.
But I think you'll need profiling to get the complete answer.
-- John
On May 1
The CPUID code is x86-specific, and needs to be skipped for ARM.
On Tuesday, May 6, 2014 12:11:04 AM UTC-5, Christopher Fusting wrote:
>
> I haven't had a chance to look into this. Inline assembly is failing:
>
> CC src/sys.o
> sys.c: In function ‘jl_cpuid’:
> sys.c:425:5: error: impossible const
I've now realized an even more confusing problem: the julia function
make_K!() that I wrote doesn't seem to actually mutate its third argument
but I can't figure out why. after a call to make_K!() the storage variable
K still seems to be zeroed out. any idea why this is?
On Tuesday, May 13, 2
Since K is an array, you need to do K[:] to talk about its contents. At the
moment, you can rebinding K to new values on each iteration, which won't mutate
the original value.
-- John
On May 13, 2014, at 4:48 PM, Thomas Covert wrote:
> I've now realized an even more confusing problem: the ju
Gotcha - that does fix the problem. How does changing the line
K += Ds[:,:,i] * exp(-2 * theta[i+1]);
to
K[:,:] += Ds[:,:,i] * exp(-2 * theta[i+1]);
differ? Until I tell the function to refer to a specific piece of K, the
function doesn't do any work on K? Still confused.
On Tuesday, May 13,
I have a function which is called from c:
>
>
> function print_key(key_::Ptr{Cwchar_t}, key_length_::Ptr{Cint})
> key_length = unsafe_load(key_length_)
> println("jlkey len: ", key_length)
> key = unsafe_load(key_, key_length)
> println("jlkey: ", key)
> return nothing
> end
>
Ok, worked it out in the end:
function print_key(key_::Ptr{Cwchar_t}, key_length_::Ptr{Cint})
key_length = unsafe_load(key_length_)
key_chars = Char[]
for i = 1:key_length
push!(key_chars, convert(Char, unsafe_load(key_, i)))
end
key = CharString(key_chars)
println(
In general, if you want the best performance
(1) avoid temporary creation
(2) traverse arrays in storage order
Beyond that, any tricks that reduce the operation count can be helpful.
For example, on my machine the following version is 5-6 times faster than your
version:
function my_make_Ds!(da,
bytestring(p::Union(Ptr{Int8},Ptr{Uint8}) [,len::Integer])
Hi all,
I'm implementing BSP trees, and I've run into a style issue which I'm
uncertain about.
For my current purposes, the trees will be holding floats, but I wanted to
write things in a way which allowed other possibilities later. At first, I
made an explicit Leaf type:
*Version 1*
abstract
I ran 2 functions in 2 separate julia sessions, each using a single
CPU. I found the processes' speed reduced to nearly half. Would anyone
explain/confirm?
Can you be a little more specific about what happened? Please share your
hardware information, as well as the code you were running.
On Tue, May 13, 2014 at 8:48 PM, cnbiz850 wrote:
> I ran 2 functions in 2 separate julia sessions, each using a single CPU.
> I found the processes' speed reduc
I guess I was mistaken, sorry.
I print out time elapsed every 1 loops. The drop of speed I noticed
might be due to the fact that some loops are more costly than others,
not that 2 processes slow down.
On 05/14/2014 01:17 PM, Elliot Saba wrote:
Can you be a little more specific about what
> Matlab uses the = version but only allows ranges on the right hand side
Not quite, you can use other "iterables" (not that Matlab has a very formal
definition of the term) in Matlab for loops like arbitrary vectors or cell
arrays or matrices, but it's very particular about looping through by
Cool! Very OT, but I had no idea about this behavior in MATLAB. Suddenly
I'm going to be slightly less annoyed when I have to do xs = (x0:dx:x1)' to
get my x-grid as a column vector.
Of course, Julia still beats this by far =)
// T
On Wednesday, May 14, 2014 7:54:55 AM UTC+2, Tony Kelman wrote
57 matches
Mail list logo
