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 :
>
> I would like to periodically output a progress percentage but don't want
a huge list of numbers cluttering the rest
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:
>
>
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 0.3.
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 n
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
January/Februa
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] .- x[1:end-1]).*(y[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
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 wrote:
> 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 B
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
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 ve
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:
>
>
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, a
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 Wednesday
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, tha
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 a
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 GLPKMa
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 bi
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.
@Tobi
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 sur
Hi Ethan,
I think it would be great if you could come up with a typical example where
the memory sharing is an issue and leads to hard to find bugs. I ask
because I have not seen a lot of questions on this on the mailing list and
the bug tracker.
In practice the convention to use the suffix "!
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 inter
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 11:10:15 PM UTC+2, Cameron McBride wrote:
>
> Or you can use the non-vectorized version and save the overhead of the
> temporary arrays being created by the addition and multiplication steps.
>
There's really no way I can hide that I learnt scientific computing in
The first three results below are what I expected. The fourth result
surprised me:
julia> (0:pi:pi)[end]
3.141592653589793
julia> (0:pi/2:pi)[end]
3.141592653589793
julia> (0:pi/3:pi)[end]
3.141592653589793
The issue is that float(pi) < 100*(pi/100). The fact that pi is not
rational – or rather, that float64(pi) cannot be expressed as the division
of two 24-bit integers as a 64-bit float – prevents rational lifting of the
range from kicking in. I worried about this kind of issue when I was
working on
I am aware of Julia's computational benefits compared to other programming
languages but most important inability is about the libraries, especially
for computer vision problems. Is there any group already dealing to
implement some basic image manipulation functions like in Matlab or do I
need
Thanks for the explanation--it makes sense now. This question arose for me
because of the example presented
in https://groups.google.com/d/msg/julia-users/CNYaDUYog8w/QH9L_Q9Su9YJ :
x = [0:0.01:pi]
used as the set of x-coordinates for sampling a function to be integrated
(ideally over the int
try pyplot or Gaston?
I had a number of issues with older versions of OSX (I used 10.6 until
recently). None of them were Winton.jl per se, but the dependencies. I've
had no problems on 10.9 and all is working well v0.3 for at least the past
month.
Cameron
On Mon, Apr 21, 2014 at 4:40 PM, Andr
I believe it is easy to write a wrapper to call existing C/C++/Python
codes. In fact, that is what most Julia packages does.
On Thursday, April 24, 2014 6:24:08 AM UTC+8, Eren Gölge wrote:
>
> I am aware of Julia's computational benefits compared to other programming
> languages but most importa
pi*(0:0.01:1) or similar should work.
On Wednesday, April 23, 2014 7:12:58 PM UTC-4, Peter Simon wrote:
>
> Thanks for the explanation--it makes sense now. This question arose for
> me because of the example presented in
> https://groups.google.com/d/msg/julia-users/CNYaDUYog8w/QH9L_Q9Su9YJ :
>
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
However, this should be fixable (and in fact I just submitted a PR for it).
I believe that bug only applies to multiplication/division of integer
ranges, but it will certainly be good to have it fixed.
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)
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
>
...whic
(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> (0:pi:
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:
t
Coming from other languages, I find MATLAB's flagrant copy behavior to
be surprising, and very slow. However, it is an interesting choice.
The ! convention specifically declares that a function mutates an
input. Since this is a violation of the previously stated assumption
of many function that th
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 call
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:
47 matches
Mail list logo
