There is the "bitbroadcast" function specifically for this purpose.
On Tuesday, September 29, 2015 at 10:17:03 AM UTC-4, Sisyphuss wrote:
>
> [1;3] .> 2
>
> 2-element BitArray{1}:
> false
> true
>
>
> =
>
> broadcast(>,[1;3],2)
>
> 2-element Array{Int64,1}:
> 0
> 1
>
>
> =
>
> Is the
This is of interest for Vim users only.
I'm about to merge some additional features in julia-vim (this branch:
https://github.com/JuliaLang/julia-vim/tree/blockobj)
They will introduce some additional key mappings in julia files, intended
for moving around blocks (if/end, function/end etc.).
There is currently no way to do what you want, but I'd like to add this
feature. I'm just unsure what the best/simplest API would be.
Cold you open an issue about it in ArgParse.jl
https://github.com/carlobaldassi/ArgParse.jl in the meanwhile?
On Saturday, April 4, 2015 at 11:50:03 PM UTC+2,
fields to local variables?
On Friday, June 13, 2014, Carlo Baldassi carlob...@gmail.com
javascript: wrote:
Sorry for spamming, but after reading the discussion it seems like a
(slightly polished) version of the @extract macro I mentioned above (I know
the name is not great) already
UTC+2, Stefan Karpinski wrote:
Does your @extract macro somehow assign values back to fields at the end
of the scope?
On Fri, Jun 13, 2014 at 5:29 PM, Carlo Baldassi carlob...@gmail.com
javascript: wrote:
The point would be that it's not different, just more concise, so you're
still
variables?
The point would be that it's not different, just more concise,
On Fri, Jun 13, 2014 at 7:07 PM, Stefan Karpinski ste...@karpinski.org
javascript: wrote:
Using a block seems like the right way to handle that.
On Fri, Jun 13, 2014 at 7:04 PM, Carlo Baldassi carlob
Sorry, I haven't had the time to read the whole discussion, but it seems
you may be interested in the @extract macro which can be found at
https://github.com/carlobaldassi/MacroUtils.jl#extract and which I have
written for this exact reason of reducing 1) code obfuscation 2) overhead
3) typing
Yet another small update, since most users might miss this: Vim now has an
optional on-the-fly-as-you-type LaTeX-to-Unicode substitution mode, which
however is off by default (so as to emulate the Julia REPL as closely as
possible).
See the documentation on how to enable it at
Update: the vim plug-in now includes this feature. If you press Tab after a
valid latex sequence, it substitutes it, otherwise it falls-back to
whatever was previously mapped for Tab. Or at least that's what it's
supposed to do.
On Thursday, May 22, 2014 10:03:39 PM UTC+2, Stefan Karpinski
On Thursday, May 22, 2014 9:01:11 PM UTC+2, Bob Nnamtrop wrote:
But julia often does show large screen dumps. Try:
julia h={1=1}; for i=2:10 h[i]=i end; h
Off-topic tip: this kind of thing should be better written like this:
julia h=[i=i for i = 1:10]
Small hint: the easiest way I found to clarify the distinction between
max and maximum, and why it is necessary in the first place, is that
it's the same as that between the + function vs sum, or the *
function vs prod.
(Of course, not checking the region argument in maximum is just a bug, as
But what's your suggestion about typed dict comprehensions?
On Thursday, May 1, 2014 7:11:59 PM UTC+2, Stefan Karpinski wrote:
Is be more in favor of deprecating the (K=V)[k=v] syntax and just using
keyword args like this Dict{K,V}(k=v). Having so many syntaxes for this is
confusing and
It also seems to make sense to me that .+= and friends apply in place.
The only issues I can think about are when relying on the possibility of
mutating the type of the original container, either because of element type
promotion, or shape promotion (broadcasting) or container type promotion
! (Note: I haven't tested that JuMP code).
Miles
On Wednesday, April 9, 2014 11:18:26 PM UTC+1, Carlo Baldassi wrote:
About GLPK.exact it is not possible to get the rational number 3/28
instead of a decimal approximation ?
No, unfortunately. Also, for that to happen/make sense, you'd
Stéphane, sorry for the confusion (I should have made myself clearer
before), but the new version of the blog post is not correct, in that the
difference between 1-X and 1.-X has nothing to do with Int64 vs Float64,
but rather with the difference between the operators `-` (minus) and `.-`
There was a Julia age during which BigInt(3)/BigInt(28) was equal to the
BigRational 3/28, why this feature has been removed ?
I don't think that command ever worked like that actually; in order to get
Rational values, you need to use a double-slash // in stead of a single
slash:
big(3) //
Hi Stéphane, nice post! I have a number of comments and suggestions which
you may find useful. I accompanied these comments with some demo code, you
can find here https://gist.github.com/carlobaldassi/10312215.
A) Generic to Julia
A.1) as Ivar said, you can use Unicode characters if you want;
About GLPK.exact it is not possible to get the rational number 3/28 instead
of a decimal approximation ?
No, unfortunately. Also, for that to happen/make sense, you'd also need to
be able to pass all the *inputs* as exact rational values, i.e. as 1//7
instead of 1/7. This would be possible if
Unfortunately, from insepcting GLPK source code it seems that whether to
use GNU MP or GLPK bignum is decided at compile time. So it appears that
the Windows binaries which are automatically downloaded by the Julia
package are just not compiled with GNU MP. As far as I can tell, the
options
19 matches
Mail list logo
