Hi, John.
No, I didn't. I didn't find it and it seems to be not what i need:
no method quadgk(Array{Float64,1}, Array{Float64,1})
quadgk(f,a,b,...) expects a function as its first argument but I mean the
case when y = f(x), but i don't have f, e.g. obtained experimental data, so
x and y are 1-D
I would like to periodically output a progress percentage but don't want a
huge list of numbers cluttering the rest of the outputs. How can this be
accomplished?
print(hello)
print(\rworld)
This doesn't work because \r adds a new line.
Not on my machine
julia print(hello);print(\rworld!)
world!
Which operation system and which version of Julia are you running?
2014-04-23 10:00 GMT+02:00 RecentConvert giz...@gmail.com:
I would like to periodically output a progress percentage but don't want
a huge list of numbers cluttering
Julia Version 0.2.1
Commit e44b593* (2014-02-11 06:30 UTC)
Platform Info:
System: Windows (x86_64-w64-mingw32)
Windows 7
I can confirm this behavior under 0.3 prerelease on windows. The following
works however
julia print(hello);print(\b\b\b\b\bworld!)
world!
I think this should be filed as an issue at
https://github.com/JuliaLang/julia
Am Mittwoch, 23. April 2014 10:35:09 UTC+2 schrieb RecentConvert:
Julia
print(hello);print(\b\b\b\
b\bworld!)
This works in the basic terminal but *not* in Julia Studio.
Julia Studio is an entirely different issue as they might have implemented
their own REPL (terminal).
The issue should be reported here:
https://github.com/forio/julia-studio/issues.
Am Mittwoch, 23. April 2014 11:39:48 UTC+2 schrieb RecentConvert:
print(hello);print(\b\b\b\
b\bworld!)
Pkg.add(ProgressMeter)
--Tim
On Wednesday, April 23, 2014 01:00:50 AM RecentConvert wrote:
I would like to periodically output a progress percentage but don't want a
huge list of numbers cluttering the rest of the outputs. How can this be
accomplished?
print(hello)
print(\rworld)
Is the Julia nightlies update every day as it used to do around
January/February? I don't receive updates for a long time now, and I want
to investigate whether it is a failed Xubuntu upgrade that killed the
Sources, or the package really don't update.
Thanks
versioninfo()
Julia Version
Awesome! Did not know that.
Am Mittwoch, 23. April 2014 12:22:25 UTC+2 schrieb Tim Holy:
Pkg.add(ProgressMeter)
--Tim
On Wednesday, April 23, 2014 01:00:50 AM RecentConvert wrote:
I would like to periodically output a progress percentage but don't want
a
huge list of numbers
I think you are running Xubuntu Raring, which reached end of life, and
so they stopped building nightly for that OS. I am on Trusty and am
getting the nightly for Saucy.
On 04/23/2014 06:26 PM, Földes László wrote:
Is the Julia nightlies update every day as it used to do around
The trapezoidal rule (http://en.wikipedia.org/wiki/Trapezoidal_rule) would
probably be almost trivial to implement.
function trapz{T:Real}(x::Vector{T}, y::Vector{T})
if (length(y) != length(x))
error(Vectors must be of same length)
end
sum( (x[2:end] .-
I noticed that the do keyword behaves weirdly when trying to use it on a
single line, e.g. in the REPL:
When the do keyword is used to create a function with one or more
arguments everything works fine.
julia map([1,2,3]) do x 1+x end
map([1,2,3]) do x 1+x end
3-element Array{Int64,1}:
2
3
Oops: https://github.com/JuliaLang/julia/issues/new – that's what I get for
entering URLs by hand.
On Wed, Apr 23, 2014 at 10:09 AM, Stefan Karpinski ste...@karpinski.orgwrote:
Would you mind opening an issue about it?
https://github.com/JuliaLang/issues/new
On Wed, Apr 23, 2014 at 8:46
Would you mind opening an issue about it?
https://github.com/JuliaLang/issues/new
On Wed, Apr 23, 2014 at 8:46 AM, Klaus-Dieter Bauer
bauer.klaus.die...@gmail.com wrote:
I noticed that the do keyword behaves weirdly when trying to use it on a
single line, e.g. in the REPL:
When the do
Ok, so I've got not hits on this question. Let me try to make it more concrete:
Is there a command which can tell me the variables `a` and `b` in the following
commands are refering to the same space in memory:
a = rand(2,2)
b = vec(a)
The command is(a,b) returns false. The documentation for
On Wednesday, April 23, 2014 12:11:50 PM UTC-4, Ethan Anderes wrote:
Ok, so I've got not hits on this question. Let me try to make it more
concrete:
Is there a command which can tell me the variables `a` and `b` in the
following commands are refering to the same space in memory:
a =
Thanks Steven. That helps. So I can infer that no two variables can share
overlapping memory without their pointers being the same?
No, that is not necessarily true. For example, a subarray could point
somewhere inside the array, and most objects don't have a pointer method.
The easiest assumption (which is probably also typically correct) is that
the output of all functions share part of the memory of its inputs.
Therefore,
Still, if you're using Arrays, then under typical conditions there is
absolutely no overlap between a and b unless pointer(a)==pointer(b). You can
violate that yourself if you want to (using pointer_to_array), but in such
circumstances you presumably know what you are doing.
--Tim
On
Ok, I'm trying to reconcile Jameson's suggestion to generally assume an
overlap, and Tim's to expect no overlap with arrays if pointer(a) !=
pointer(b). Doesn't this imply that pointer(input) == pointer(output) a typical
array function? With subarray's I fully expect sharing memory, just by the
Jameson said if you're using subarrays, you can't count on it; I said if
they're both arrays, then you can rely on it (unless you've done something
sneaky). So depending on the types, either could be true.
In my personal opinion, the risk of memory sharing is quite a lot lower, in
practice,
While Julia shares a lot with Matlab in terms of syntax, there are several
differences. So I cannot see being different a drawback.
For me it is more important that Julia scales well to large projects and
using array views can help reducing the memory consumption in several
situations. But you
Right, it works. Thank you.
If I don't call GLPKMathProgInterface, does JuMP use an internal solver ?
Le mardi 22 avril 2014 23:25:07 UTC+2, Carlo Baldassi a écrit :
Note that you can still use GLPK.exact with JuMP, you just need to add
change the m=Model() line to this:
using
Hi All,
I am a new Julia-user and meet a problem when I transfer the Matlab code
to Julia. I always get the error:type non-boolean (BitArray(1)) used in
boolean context. Can anyone help me check the code and solve this problem?
The codes have been attached.
I am using the julia-0.3.0-win64
Thanks everyone... it's super helpful to read your comments.
@Tim: ok, that makes sense and is clear. I think I was worried the language
would have a jumble of commands (not just in those categories you list) which
subtly fused variables in memory. Your comment helps me reason about it.
In general, Julia is much more picky about what types of things can be used
in if statements and or || conditions than Matlab is. They must be
Bools in Julia, whereas Matlab tries to convert things to a scalar logical
value.
Crazily enough, one of the things that Matlab converts to a scalar
In Matlab, arrays of booleans can be used in conditionals and are, I
believe, considered true if all the values in them are true and false
otherwise. In Julia only actual boolean values (true or false) can be used
in conditionals. You're using a 1-d boolean array somewhere in a
conditional. Not
On Wednesday, April 23, 2014 3:40:02 PM UTC-4, Stéphane Laurent wrote:
If I don't call GLPKMathProgInterface, does JuMP use an internal solver ?
If a solver isn't specified, JuMP (actually MathProgBase) will search for
an available solver and pick one by default. JuMP does not have an
Or you can use the non-vectorized version and save the overhead of the
temporary arrays being created by the addition and multiplication steps.
function trapz{T:Real}(x::Vector{T}, y::Vector{T})
local len = length(y)
if (len != length(x))
error(Vectors must be of same length)
On Wednesday, April 23, 2014 10:50:57 PM UTC-4, Steven G. Johnson wrote:
On Wednesday, April 23, 2014 10:17:23 PM UTC-4, Simon Kornblith wrote:
pi*(0:0.01:1) or similar should work.
Actually, that may not work because of
https://github.com/JuliaLang/julia/issues/6364
...which of
(Simon, you may also be amused to learn that Google thinks that your post
is written in Latin and offers to translate it. Mirabile dictu!)
I think it's correct because the next value in the range would exceed PI.
If you try 0:pi/101:pi, you would get 3.14 again.
On Thursday, April 24, 2014 5:59:10 AM UTC+8, Peter Simon wrote:
The first three results below are what I expected. The fourth result
surprised me:
julia
Hi Tobias:
My 'hard to find bug' statement should really have read 'hard to find bug from
a newbie perspective'. These bugs would be obvious to someone familiar with
basic programming. My numpy example is too big to give now but here is a simple
metropolis hasting markov chain short example:
Jameson:
Yes, the Matlab choice is slow and doesn't scale, but it's very easy to reason
about. I think it was instructive for me to try and think of a real life bug
that realized my worries. I came to realize that most of the code where I was
using vec() was embedded in a chain of function
Thanks, Simon, that construct works nicely to solve the problem I posed.
I have to say, though, that I find Matlab's colon range behavior more
intuitive and generally useful, even if it isn't as exact as Julia's.
--Peter
On Wednesday, April 23, 2014 7:17:23 PM UTC-7, Simon Kornblith wrote:
36 matches
Mail list logo
