I love the display system
https://github.com/one-more-minute/Blink.jl/blob/master/src/graphics/system.jl
in Blink. This makes much more sense than the current display stack
mechanism. First, it lets you show things on different (even multiple)
displays. Second, classification of output as Tabular,
Thanks! Forgot I'm on a 64-bit environment.
Tony Kelman於 2015年1月6日星期二UTC+8下午12時31分05秒寫道：
Yes, actually. If you're on a 64 bit machine, then the integer literal 0
is an Int64. So int64(0) - 0x12345678 promotes and does the subtraction in
Int64. -0x12345678 wraps around to the unsigned
Hi all,
Sorry for joining the game late, I have been very busy in the past few
days.
First of all, I am very excited to learn that RCall.jl is now alive at
JuliaStats. To resolve the confusion between the package names of my
original package and the one hosted on JuliaStats, I renamed
Raised https://github.com/JuliaLang/julia/issues/9617
Cheers
Lex
On Monday, January 5, 2015 6:00:46 PM UTC+10, ele...@gmail.com wrote:
Think its taking 2p+1 as a malformed hex float literal
Cheers
Lex
On Monday, January 5, 2015 5:44:38 PM UTC+10, Ronald L. Rivest wrote:
I'm using Julia
On Mon, Jan 5, 2015 at 3:41 AM, Ronald L. Rivest rivest@gmail.com
wrote:
I fear that numeric literal coefficients may introduce more hazards than
its economy of notation justifies... ??
I'm somewhat inclined to agree. It's a really nice syntax, but there are so
many exceptions now that
Hi, I'm beginning a migration off MATLAB and was looking for a similar
look/feel IDE as the MATLAB and Octave GUI. I installed the Juno package
and it looks good but... I am looking for where you enter commands and see
vaiables in the workspace. So far I only see a text editor. Any help?
Juno works a little differently to Matlab – evaluation is done within the
editor itself. If you right click an expression (like 2+2) and select
evaluate you should see the result come up next to it. (You can also use
Ctrl-Enter, which is a bit quicker)
Do you see a tutorial? One should come up on
You might want to consider submitting a pull request over on GitHub to
include the examples you think would be helpful:
https://github.com/JuliaLang/julia/blob/master/doc/manual/types.rst
(I agree that the part about tuples might not be very helpful for someone
without quite a bit of
Hi Ivo
You're more than welcome to contribute to the documentation yourself
https://github.com/JuliaLang/julia/blob/master/CONTRIBUTING.md#improving-documentation
to
help clarify anything you found confusing.
Regarding your second point, open() does not return a named type it returns
a tuple
I suppose I should add that Julia doesn't really have a named tuple, the
closest is an immutable constant type which is covered later in the manual.
On Monday, 5 January 2015 10:35:28 UTC, Sean Marshallsay wrote:
Hi Ivo
You're more than welcome to contribute to the documentation yourself
On Monday, January 5, 2015 7:03:21 PM UTC+10, Arch Call wrote:
On Julia version 3.4, the variable P also yields the same kind of error.
Yes Hex float accepts upper or lower case P its the same issue.
Cheers
Lex
On Monday, January 5, 2015 2:44:38 AM UTC-5, Ronald L. Rivest wrote:
I'm
I now see the description of hex float notation in section 4.2 (Floating
Point Numbers) of the manual (0.4.0-dev), which includes using p as
binary exponent notation. I think that the error message could be improved,
at a minimum. But there are problems with the current syntax that will
cause
You can have only two DArrays and use localpart() to get the local parts of
the arrays on each worker and work off that.
With a single iteration the network overhead will be much more than any
gains from distributed computation - it depends on the computation of
course.
Currently, DArrays work
On Julia version 3.4, the variable P also yields the same kind of error.
On Monday, January 5, 2015 2:44:38 AM UTC-5, Ronald L. Rivest wrote:
I'm using Julia 0.3.4 command line.
Entering
p = 1; 2p+1
gives an error:
*julia p = 1; 2p+1*
*ERROR: syntax: malformed expression*
Le dimanche 04 janvier 2015 à 19:30 -0800, Greg Plowman a écrit :
I'm not sure how general this behaviour is with respect to other
types, but I have observed the following with a simple composite type:
When summing a 1-element array of a simple composite type, the return
is a reference to
Think its taking 2p+1 as a malformed hex float literal
Cheers
Lex
On Monday, January 5, 2015 5:44:38 PM UTC+10, Ronald L. Rivest wrote:
I'm using Julia 0.3.4 command line.
Entering
p = 1; 2p+1
gives an error:
*julia p = 1; 2p+1*
*ERROR: syntax: malformed expression*
Congrats as well. I look forward to seeing your writeup.
Simon
On Sunday, 4 January 2015 17:35:46 UTC, Arch Robison wrote:
FYI, I won 2nd place in the recent Al Zimmerman programming contest
Delacorte
Numbers http://trdb.org/Contest/DelacorteNumbers/Standings, using only
Julia and a
Hello colleague,
On Sunday, January 4, 2015 6:33:24 PM UTC+1, Jameson wrote:
Gtk3 hasn't changed that much in this area -- it is still incorrect to
call gdk_window_get_device_position friends from event handlers.
Could you please provide a reference for this?
I was reading the Gtk2
another strange definition from a novice perspective: close(x1) is
not defined. close(x1[1]) is.
close() is defined for a stream, not a tuple (stream, process).
julia is the first language I have
seen where a close(open(file)) is wrong.
FWIW, I believe that there was concern that the
How to Perform a K-means Clustering in matlab and use it to select
acluster head ???
You can also open a REPL connected to Juno
http://junolab.org/docs/terminal.html very easily. It's still a little
more awkward than an integrated console could be but it's often useful.
On 5 January 2015 at 13:37, yu...@altern.org wrote:
Usually I have a second file open that I use like a
Perhaps this is a good reason to change behaviour such that e is no longer
a constant: it has always seemed bit odd to use a valuable latin singleton
in this way. We could use a unicode script e (U+212F) instead, as suggested
by wikipedia:
* julia 3e+1*
* 30.0*
*julia 3e + 1*
* 9.154845485377136*
Perhaps this is a good reason to change behaviour such that e is no longer
a constant: it has always seemed bit odd to use a valuable latin singleton
in this way. We could use a unicode script e (U+212F)
On Mon, Jan 05 2015, Simon Byrne simonby...@gmail.com wrote:
* julia 3e+1*
* 30.0*
*julia 3e + 1*
* 9.154845485377136*
Perhaps this is a good reason to change behaviour such that e is no longer
a constant: it has always seemed bit odd to use a valuable latin
Looks awesome, huge congrats!
Please tell us here when you've written that paper.
On Sunday, January 4, 2015 6:35:46 PM UTC+1, Arch Robison wrote:
FYI, I won 2nd place in the recent Al Zimmerman programming contest
Delacorte
Numbers http://trdb.org/Contest/DelacorteNumbers/Standings, using
Hello Julians,
I have a shiny late Christmas present for you, complete with Julia-themed
wrapping.
Blink.jl https://github.com/one-more-minute/Blink.jl wraps Chrome to
enable web-based GUIs. It's very primitive at the moment, but as a proof of
concept it includes BlinkDisplay, which will display
On Monday, January 05, 2015 03:17:12 PM Paul Analyst wrote:
Thx, Tim,
I have solution but is 2 questions:
1. Whay must be line: /fid[mygroup/A]=rand(2)/ ?
That line just means 'create a variable called A inside a group called
mygroup, and assign it a value of rand(2)'. If you don't need that
On Monday, 5 January 2015 13:48:31 UTC, Tamas Papp wrote:
I think that using Unicode (outside ASCII) for numeric literals would be
more trouble than it is worth (typing, visually distinguishing them from
other similar-looking characters, etc). I feel that even if a language
supports
This looks great!
Is it possible to do further improve do notation with something like:
using JLTest
testcase(Mytest Tests) do # testcase name is optional
#Some code
x = 0
#Function to be called before each test (optional)
setUp() do
x += 1
end
#Function to be
I'm trying to figure out promotions and noticed a few possible quirks -
perhaps these are bugs, as I can't figure out the logic. I realize float16
is a work in progress but I really like the data type as my datasets are
large.
julia a=rand(Float16,1) # define a float16 variable
Oh man. I hope this gets sorted out. I don't think this is a very pretty
situation. p = 1; 2p+1 should do what you expect it to do.
For what it's worth, it always struck me is as odd that dropping the * for
multiplication is allowed. Is it worth dropping this instead of the p, e
notation?
Christoph
Hi, here is a comparison of Julia and C++ for simulating a random walk
https://github.com/jlapeyre/ranwalk-Julia-vs-Cxx.
It is the first Julia program I wrote. I just pushed it to github.
--John
On Monday, January 5, 2015 12:43:16 AM UTC-5, Jiahao Chen wrote:
This is how I used GZip.jl in the tests for the MatrixMarket package
In the present case, seems like it would be easier to do:
data = GZip.open(fname) do greadcsv(g)
end
Hi Mike,
Tried it a couple of times, but run into below error, in REPL.
Regards,
Rob J. Goedman
goed...@mac.com
julia Pkg.add(Blink)
INFO: Upgrading Blink: v0.1.2 = v0.1.3
INFO: Building Blink
% Total% Received % Xferd Average Speed TimeTime Time Current
Maybe its not so bad if you just always include * where it should be, i.e.
p = 1; 2*p+1 works fine.
On Mon, Jan 5, 2015 at 10:55 PM, Christoph Ortner
christophortn...@gmail.com wrote:
For what it's worth, it always struck me is as odd that dropping the * for
multiplication is allowed. Is it
It may be in part the implementation of the RNG. I think it is also in
part whether the abstraction is optimized away.
Notice that Julia v0.3 is faster than v0.4. This is probably randbool() vs.
rand(Bool).
On Monday, January 5, 2015 4:50:56 PM UTC+1, Isaiah wrote:
Very neat. Just in case
It's the same with 'f', i.e. 1f+1 gives 10 and 1f + 1 an error (if f is not
defined, else a different result again).
And if someone introduces 'g' for engineering notation, there will be an
exception for this letter, too.
By the way, has the bug x = 10; x.1 returning 1.0 been handled in 0.4?
Related issue: #5942
https://github.com/JuliaLang/julia/issues/5942
On Mon Jan 05 2015 at 10:06:54 AM Mark B 2460...@gmail.com wrote:
I'm trying to figure out promotions and noticed a few possible quirks -
perhaps these are bugs, as I can't figure out the logic. I realize float16
is a work
On Monday, January 05, 2015 09:52:28 PM Paul Analyst wrote:
dset = d_create( F, datatype(Float64), dataspace(10,10))/
You're missing the `fid`. You have to tell it where (which file, or which
group)
you want to create that dataset.
--Tim
Splitting expressions inside of array syntax is space sensitive as well:
julia [1 + 2]
1-element Array{Int64,1}:
3
julia [1 +2]
1x2 Array{Int64,2}:
1 2
Of course this bothers me too, but it's another example of
space-sensitivity..
On Mon, Jan 5, 2015 at 5:42 PM, Hans W Borchers
Hi there,
What is the recommended way to allocate size of an array of a custom type?
a=MyType[10] gives me a conversion error. What do I miss here?
Also does push!() comes with significant performance penalty compared to
[]operator?
Thank you,
Kuba
Style guides are not syntax rules. Every body writes n+1 at times.
Is there any other place in Julia where putting spaces (or not putting
spaces)
around arithmetical operators makes a difference?
Would this be allowed by the general Julia philosophy?
Will it not lead to errors very difficult to
You can always call scikit learn from Julia using PyCall. Not sure how
satisfying that would be for what you had in mind though.
On Mon, Jan 5, 2015 at 3:22 PM, Tom Fawcett tom.fawc...@gmail.com wrote:
Fellow humans,
I realize there are various machine learning algorithms implemented in
Yes, we should try to restrict parsing of hex float literals more if
we're going to keep them. The `p` should only be special after
0xd.d...
In fact, I didn't notice before that this is actually a simple bug in
the parser. `2p+1` gives an internal error. That needs to be fixed in
any case.
On
Oh, right. I now see the same behavior in Matlab. Never went into this trap
-- probably because I was always using commas in array constructions.
Unfortunately (for me), there is a difference with these two spellings in
Julia.
On Monday, January 5, 2015 11:47:25 PM UTC+1, Stefan Karpinski
On Monday, 5 January 2015 20:13:51 UTC, Jeff Bezanson wrote:
Hex float literals are a different story. It's an understatement to
say they are VERY rarely used, and that most programmers don't need
them and have never heard of them. They also don't currently work
under MSVC (issue #6349).
I would also be sad to see hex literals go, and I've found the binary
literals quite nice. Octal literals can go jump in a lake (the only real
use case is for specifying permissions).
On Mon, Jan 5, 2015 at 5:34 PM, Simon Byrne simonby...@gmail.com wrote:
On Monday, 5 January 2015 20:13:51 UTC,
A word of legal caution: Tim, I believe some (all?) of your SuiteSparse
code is GPL and since Julia is MIT (although not all libraries are), we can
look at pseudocode but not copy GPL code while legally keeping the MIT
license on Julia's standard library.
Also, thanks so much for helping with
Oopps my bad - the conversion error makes sense - the 10 is an Int.
Would it be better then to use zeros() or a list comprehension here?
Zeros default type is Float64 so going through an intermediate type may be
expansive for large arrays...
Heh, I think i have found the answer. It turned out that the list
comprehensions were doing pretty good job. The slowdown I was getting was due
to my inability of using rand function.
On Mon, Jan 5, 2015 at 1:26 PM, Tim Holy tim.h...@gmail.com wrote:
In the absence of being able to actually construct the change, I like the idea
of tagging things that need fixing. You can do that just by editing the
document to say This needs to be clarified in the following way:. It's not a
On Monday, January 05, 2015 08:15:03 AM Hans W Borchers wrote:
By the way, has the bug x = 10; x.1 returning 1.0 been handled in 0.4? It's
still there in 0.3.
Nope. If you haven't filed an issue already, please do.
--Tim
On Monday, January 5, 2015 2:32:00 PM UTC+1, Simon Byrne wrote:
*
The (unregistered) [RCall](https://github.com/JuliaStats/RCall.jl) package
is an initial cut at the interface. I am not happy with all the names that
I chose and welcome suggestions of improvements. For some reason I was
unable to create an R module within the RCall module, as Stefan
Very nice. Would this problem benefit even more from multithreading?
On Sun, Jan 4, 2015 at 12:35 PM, Arch Robison arch.d.robi...@gmail.com
wrote:
FYI, I won 2nd place in the recent Al Zimmerman programming contest Delacorte
Numbers http://trdb.org/Contest/DelacorteNumbers/Standings, using
Already there: #6770
On Mon, Jan 5, 2015 at 4:27 PM, Tim Holy tim.h...@gmail.com wrote:
On Monday, January 05, 2015 08:15:03 AM Hans W Borchers wrote:
By the way, has the bug x = 10; x.1 returning 1.0 been handled in 0.4? It's
still there in 0.3.
Nope. If you haven't filed an issue already,
You can use Array(MyType, n) to allocate a length-n uninitialized array of your
type.
julia version 0.4.0-dev+2496
Program:
println(-0x12345678)
println(0-0x12345678)
println(int32(0-0x12345678))
println(int32(-0x12345678))
Output:
3989547400
-305419896
-305419896
ERROR: InexactError()
in include at ./boot.jl:248
in include_from_node1 at loading.jl:128
in process_options at
Thanks, Jacob, this is what I was looking for.
-Tom
On Mon, Jan 5, 2015 at 5:48 PM, Jacob Quinn quinn.jac...@gmail.com wrote:
I know there's been a lot of discussion [here](
https://github.com/JuliaStats/Roadmap.jl/issues/11) in the past, though
not very recently. I would imagine there would
The following works for me:
module RCall
module R
import ..RCall
export foo
function foo()
RCall.bar()
end
end # R
export R
function bar()
println(hello, handsome!)
end
end
Now, I can do
using RCall
R.foo()
hello, handsome!
I didn’t manage to get it
I just got the following in the REPL:
julia module Foo
type Bar{T} end
end
signal (11): Segmentation fault
unknown function (ip: -716631494)
jl_get_binding at /opt/julia-0.4/usr/bin/../lib/libjulia.so (unknown line)
jl_get_global at /opt/julia-0.4/usr/bin/../lib/libjulia.so
I know there's been a lot of discussion [here](
https://github.com/JuliaStats/Roadmap.jl/issues/11) in the past, though not
very recently. I would imagine there would be even more willing to
participate in pushing things forward at this point (myself included). I'd
say chiming in there would most
I'm trying to figure out how (and under what circumstances) one would use
Nullable. That is, it seems that it might be valuable when you don't know
whether the value/object exists (sort of like Python's None, I guess), but
then something like Nullable(3) == 3 returns false, and that sort of
Nvm, I forgot to export bar from the outer module; doing that, using works
just as well as import, and you don't need to fully qualify (exported)
names in the outer module, just as usual.
// T
On Tuesday, January 6, 2015 1:31:12 AM UTC+1, Tomas Lycken wrote:
The following works for me:
True, but yes, not very satisfying.
It seems like there's a good intersection of Julia people with machine
learning people. I was thinking there might already be an effort underway
to develop a native ML framework for Julia. Since I'm an ML person I'd
like to get involved. But I'm new to Julia
Since Tim wrote the code (presumably?), couldn't he give permission to
license it under MIT? (Assuming he was okay with that, of course!).
Cheers,
Kevin
On Mon, Jan 5, 2015 at 3:09 PM, Stefan Karpinski ste...@karpinski.org
wrote:
A word of legal caution: Tim, I believe some (all?) of your
I believe that it is University of Florida that owns the copyright and they
would lose licencing revenue. I would love it too if we could have these
under the MIT licence, but it may not be a realistic expectation.
Looking at the paper is the best way to go. Jiahao has already produced the
pseudo
What is the command you're running to get this output? Also, what does
this have to do with ipopt? Can you go through your steps out loud for us,
so we can follow along?
-E
On Mon, Jan 5, 2015 at 6:09 PM, Clas Jacobson clasajacob...@gmail.com
wrote:
I installed Ipopt and it seems to run fine.
I do think that even just getting the API right will take a while, and writing
Julian wrappers around scikits will be useful.
I do think that even just getting the API right will take a while, and writing
Julian wrappers around scikits will be useful.
Yes, multithreading would have been helpful. I had a table that was up to
about 2 MByte per thread, and 8 hardware threads on the machine. With only
8 MByte of outer-level cache, running all 8 hardware threads with separate
processes meant having 8 copies of the table, and thrashing cache badly.
Go Illini! :)
On Monday, January 5, 2015 1:35:46 AM UTC+8, Arch Robison wrote:
FYI, I won 2nd place in the recent Al Zimmerman programming contest
Delacorte
Numbers http://trdb.org/Contest/DelacorteNumbers/Standings, using only
Julia and a quad-core MonkeyStation Pro
I wonder if the threading branch is already useful for such stuff.
-viral
On Tuesday, January 6, 2015 9:43:27 AM UTC+5:30, Arch Robison wrote:
Yes, multithreading would have been helpful. I had a table that was up to
about 2 MByte per thread, and 8 hardware threads on the machine. With
This is similar to the FFTW situation, where the license is held by MIT.
-viral
On 06-Jan-2015, at 8:14 am, Viral Shah vi...@mayin.org wrote:
I believe that it is University of Florida that owns the copyright and they
would lose licencing revenue. I would love it too if we could have these
Yes, actually. If you're on a 64 bit machine, then the integer literal 0
is an Int64. So int64(0) - 0x12345678 promotes and does the subtraction in
Int64. -0x12345678 wraps around to the unsigned integer 0xedcba988 which is
greater than typemax(Int32). So the value is too large to represent as
Hi guys,
How does one figure out where allocation of memory occurs? When I use
the @time macro it tells me there's a lot of memory allocation and
deallocation going on. Just looking at the code I'm at a loss: I can't see
the reasons for it there.
So, what are the tips and tricks for the
I think I see what's happening here. Ipopt.jl's documentation makefile
(https://github.com/JuliaOpt/Ipopt.jl/blob/master/doc/Makefile) looks like
it was copied from an old version of base Julia's
(https://github.com/JuliaLang/julia/blob/ee461cc2829b9dab3e25dd574c9057d5e998b28b/doc/Makefile),
I installed Ipopt and it seems to run fine. I am trying to build the
documentation on a Mac OS X and get the following:
make: *** No rule to make target `stdlib/*.rst', needed by `helpdb.jl'.
Stop.
Any clues here? I have sphinx on my machine.
The only reason I can think of is that a copy may be costly for certain
types, and it's not needed in most cases since the summation will create
a new value in the general case. But as you noted this is not true when
the array only contains one element. So it looks like the most
Does this mirror the functionality in Rif.jl? I don’t know enough about the
subtleties of the two packages, but it seems like there are multiple efforts
towards calling R, and it would be great to combine them somehow.
https://github.com/lgautier/Rif.jl
My reasoning for Nullable{T} is that it is type stable. Taking your
example, None and Int would be different type objects, introducing a type
instability and potential performance penalty. But Nullable{T} is always
type Nullable{T} and get(Nullable{T}) is always type T. Allowing
Nullable{T}
Usually a language handles this problem by making the constants such as p
and e as reserved. Thus you can't create a new variable with those names
and since they are constant you can't assign to them without raising an
error.
--Pete
I doubt that rand(Bool) is any slower, since randbool() calls rand(Bool).
It is worth filing this as a performance regression.
-viral
On Monday, January 5, 2015 9:41:45 PM UTC+5:30, lapeyre@gmail.com wrote:
It may be in part the implementation of the RNG. I think it is also in
part
The BLAS will certainly make a difference, but OpenBLAS is reasonably good.
I also wonder what is happening in our \ polyalgorithm. The profile
suggests the code is trying Cholesky decomposition, but it really shouldn't
since the matrix is not symmetric. If I just do the lufact(), which
This is really cool. Looking forward to the paper!
-viral
On Sunday, January 4, 2015 11:05:46 PM UTC+5:30, Arch Robison wrote:
FYI, I won 2nd place in the recent Al Zimmerman programming contest
Delacorte
Numbers http://trdb.org/Contest/DelacorteNumbers/Standings, using only
Julia and a
My take on this is that 3e+1 has become a standard notation for
numbers in programming languages. I'm comfortable having that as an
exception to the concise multiplication syntax.
Hex float literals are a different story. It's an understatement to
say they are VERY rarely used, and that most
As of now, you can use SharedArray. Eventually, once we have a good
threading model, we want to multi-thread the entire array library, but that
is quite some ways away.
-viral
On Sunday, January 4, 2015 3:22:29 PM UTC+5:30, paul analyst wrote:
Suppose the array is located in memory. There
On Monday, January 5, 2015 12:13:51 PM UTC-8, Jeff Bezanson wrote:
We might be able to find a more scalable syntax for different types of
numbers. For example the syntax x@000 is available; `@ then digit` is
always a syntax error currently.
Compared to a custom string literal (e.g.
Fellow humans,
I realize there are various machine learning algorithms implemented in
Julia. Is there anything like a machine learning framework, similar to
scikit-learn, under development?
Of course, Julia already has many of the capabilities of Numpy Scipy so
that's most of the way.
I meant randbool() in v0.3, where it was a more direct call, not randbool()
in v0.4.
Anyway, I just found the problem and patched it. Adding one '@inline' now
makes rand(Bool) in v0.4
about as fast as randbool() in v0.3.
Should I open an issue (bug report), or just make a PR ?
On Monday,
Thanks. Do create a PR.
-viral
On 06-Jan-2015, at 1:53 am, lapeyre.math1...@gmail.com wrote:
I meant randbool() in v0.3, where it was a more direct call, not randbool()
in v0.4.
Anyway, I just found the problem and patched it. Adding one '@inline' now
makes rand(Bool) in v0.4
about
That does sound like a glitch in the \ algorithm, rather than in
UMFPACK. The OpenBLAS is pretty good.
This is very nice in Julia:
F = lufact (d[M]) ; F \ d
That's a great idea to have a factorization object like that. I have a
MATLAB toolbox that does
the same thing, but it's not a built-in
The writemime methods and the display system are largely orthogonal – the
display system concerns itself with routing output to a suitable display
device (terminal, Blink window, whatever) while writemime simply provides
the implementation. In other words, I'm only really focused on the
`display`
Yes, sometimes saving one character is a big deal. It also allows
editors to color them as numbers. But this is a minor point. For
something as marginal as hex float literals, custom string literals
are fine.
On Mon, Jan 5, 2015 at 3:21 PM, Jason Merrill jwmerr...@gmail.com wrote:
On Monday,
The cause for this thread is mainly a lexical analyzer bug for hex
notation. Except for the error in #9617, I'm fine with the current behavior
and syntax even with the semi e-ambiguity if you want the scientific
notation literal, use no spaces. This is only ambiguous because Julia
permits a
On Mon, Jan 5, 2015 at 12:55 PM, Peter Mancini pe...@cicayda.com wrote:
Usually a language handles this problem by making the constants such as p
and e as reserved. Thus you can't create a new variable with those names
and since they are constant you can't assign to them without raising an
julia abstract Foo
julia type SubFoo : Foo
x
end
julia func(bar::Type{Foo}) = println(bar)
func (generic function with 1 method)
julia f=SubFoo(1)
SubFoo(1)
julia func(typeof(f))
ERROR: `func` has no method matching func(::Type{SubFoo})
What do I need to replace Type{Foo}
func{T:Foo}(bar::T)
should do what you want, I think
On 5 January 2015 at 18:28, Samuel Colvin samcol...@gmail.com wrote:
julia abstract Foo
julia type SubFoo : Foo
x
end
julia func(bar::Type{Foo}) = println(bar)
func (generic function with 1 method)
julia f=SubFoo(1)
Great thanks a lot, now working.
--
Samuel Colvin
s...@muelcolvin.com,
07801160713
On 5 January 2015 at 18:32, Jacob Quinn quinn.jac...@gmail.com wrote:
I believe it should actually be:
func{T:Foo}(bar::Type{T}) ...
On Mon, Jan 5, 2015 at 11:30 AM, Mike Innes mike.j.in...@gmail.com
I believe it should actually be:
func{T:Foo}(bar::Type{T}) ...
On Mon, Jan 5, 2015 at 11:30 AM, Mike Innes mike.j.in...@gmail.com wrote:
func{T:Foo}(bar::T)
should do what you want, I think
On 5 January 2015 at 18:28, Samuel Colvin samcol...@gmail.com wrote:
julia abstract Foo
julia
1 - 100 of 131 matches
Mail list logo
