On Thursday, 28 August 2014 16:48:31 UTC+2, R. Fourquet wrote:
Sorry, I had some errors in this next bit.
myfun(a :: Union(EuclideanPoly, Poly))
It should have been
myfun{T : Union(EuclideanPoly, Poly)}(a :: T)
The first version is perfectly ok and more idiomatic in this case.
On Thursday, 28 August 2014 18:13:10 UTC+2, R. Fourquet wrote:
or to constrain argument types, e.g.
myfun{T}(a::Poly{T}, b::Poly{T}) = a+b # a and b must be Polys of the
same type
which is better expressed as :
myfun{P:Poly}(a::P, b::P) = a+b
Thanks. I've figured this one out
In my code I actually have
myfun{T : Ring}(a::Poly{T}, b::Poly{T})
a lot. Is there a shorthand for this?
I don't think so. According to
https://github.com/JuliaLang/julia/issues/6984, it may be possible to
have the following in the future:
myfun{P:Poly{:Ring}}(a::P, b::P)
--
You received
Sorry, I had some errors in this next bit.
myfun(a :: Union(EuclideanPoly, Poly))
It should have been
myfun{T : Union(EuclideanPoly, Poly)}(a :: T)
The first version is perfectly ok and more idiomatic in this case. You
said earlier:
So typically function signatures will look like
or to constrain argument types, e.g.
myfun{T}(a::Poly{T}, b::Poly{T}) = a+b # a and b must be Polys of the same
type
which is better expressed as :
myfun{P:Poly}(a::P, b::P) = a+b
So a better example:
myfun{T}(a::Poly{T}, b::Monomial{T}) = ...
--
You received this message because you are
A : B either tells you if a type A is of abstract type B or if abstract
type A is of abstract type B.
So, whether or not you use RingElement or Ring depends on whether you
consider an element of ZZ to be a ring element or whether you think the
integers ZZ form a ring.
With the machine
On Monday, 25 August 2014 09:48:12 UTC+2, Pierre wrote:
A : B either tells you if a type A is of abstract type B or if abstract
type A is of abstract type B.
So, whether or not you use RingElement or Ring depends on whether you
consider an element of ZZ to be a ring element or whether
Thanks again for the explanations. I realize that there were many things
about Julia/Nemo which I had misunderstood. Let me explain a little, so I
can (i) embarrass myself a little more, and (ii) perhaps give an indication
of common mistakes, for anyone who would write a tutorial about
At this point, the fact that abstract types could be instantiated was seen
as a limitation compared to OOP. And somehow, it is. Except at the same
time, the type system does many new things.
typo : read could NOT be instantiated.
--
You received this message because you are subscribed
On Mon, Aug 25, 2014 at 6:02 AM, Bill Hart goodwillh...@googlemail.com wrote:
Hmm. Some more explaining is necessary.
On Monday, 25 August 2014 12:04:16 UTC+2, Pierre wrote:
Thanks again for the explanations. I realize that there were many things
about Julia/Nemo which I had misunderstood.
On Monday, 25 August 2014 20:14:01 UTC+2, Robert Bradshaw wrote:
On Mon, Aug 25, 2014 at 6:02 AM, Bill Hart goodwi...@googlemail.com
javascript: wrote:
Hmm. Some more explaining is necessary.
On Monday, 25 August 2014 12:04:16 UTC+2, Pierre wrote:
Thanks again for the
On Monday, 25 August 2014 17:42:46 UTC+2, Pierre wrote:
Julia is OOP!
If it is,
It is.
how do you do the following in Julia: define a class (i'm using Python
parlance) Foo
type Foo
data1::T1
data2::T2
end
with some attributes,
is_infinite(::Type{Foo}) = yes
Le 25/08/2014 23:26, Bill Hart a écrit :
You want to be able to inherit fields, but that highlights the difference
between Julia and the traditional OOP perspective. In the traditional
perspective the focus is on the data. In the Julia paradigm, the focus is
on the behaviour, i.e. the functions.
On Mon, Aug 25, 2014 at 1:24 PM, Bill Hart goodwillh...@googlemail.com wrote:
Correct. But classes are essentially objects in Python because
everything is
an object, pretty much. This really muddies the water. Better to think
of
classes and objects as being separate concepts.
I, for
On Tuesday, 26 August 2014 00:40:34 UTC+2, Robert Bradshaw wrote:
On Mon, Aug 25, 2014 at 1:24 PM, Bill Hart goodwi...@googlemail.com
javascript: wrote:
Correct. But classes are essentially objects in Python because
everything is
an object, pretty much. This really muddies the
On Tuesday, 26 August 2014 02:19:25 UTC+2, Bill Hart wrote:
On Tuesday, 26 August 2014 00:40:34 UTC+2, Robert Bradshaw wrote:
On Mon, Aug 25, 2014 at 1:24 PM, Bill Hart goodwi...@googlemail.com
wrote:
Correct. But classes are essentially objects in Python because
everything is
Stoopid google.
On Tuesday, 26 August 2014 02:48:11 UTC+2, Bill Hart wrote:
I am still curious how you would express that
UnivariatePolynomialRing{QQ} : EuclideanDomans but the same doesn't
hold for UnivariatePolynomialRing{ZZ} in Julia.
So it doesn't get lost in all that noise. Here
On Mon, Aug 25, 2014 at 5:19 PM, Bill Hart goodwillh...@googlemail.com wrote:
On Tuesday, 26 August 2014 00:40:34 UTC+2, Robert Bradshaw wrote:
On Mon, Aug 25, 2014 at 1:24 PM, Bill Hart goodwi...@googlemail.com
wrote:
Correct. But classes are essentially objects in Python because
On Tuesday, 26 August 2014 02:55:25 UTC+2, Robert Bradshaw wrote:
On Mon, Aug 25, 2014 at 5:19 PM, Bill Hart goodwi...@googlemail.com
javascript: wrote:
On Tuesday, 26 August 2014 00:40:34 UTC+2, Robert Bradshaw wrote:
On Mon, Aug 25, 2014 at 1:24 PM, Bill Hart
Oh how very silly of me. As soon as I pressed enter I figured out the right
way to do this.
abstract Ring
abstract EuclideanDomain : Ring
abstract Field : EuclideanDomain
type Poly{T : Ring} : Ring
end
type ZZ : EuclideanDomain
end
type QQ : Field
end
PolynomialRing{T : Ring}(::Type{T}) =
As evidence of my claims that Julia is technically capable of doing generic
programming faster than you can do it in C, I offer Fateman benchmark times
for various systems.
Julia 0.3 was released today and gives a nice speedup over 0.2, hence the
better times for Julia.
Fateman benchmark
I thought we would have another argument about real numbers this morning,
but I see the topic has changed back to Julia. And I have to say that I
find the Nemo project very interesting, in spite of the over-aggressive
publicity it is receiving here.
You don't often get to see a new piece of
On Friday, 22 August 2014 11:49:20 UTC+2, Pierre wrote:
I thought we would have another argument about real numbers this morning,
but I see the topic has changed back to Julia. And I have to say that I
find the Nemo project very interesting, in spite of the over-aggressive
publicity it
Thanks for the examples. However, given that in Julia you can re-define
about everything (cf your example with the function extracting elements
from a list, replaced by print 'test' ), surely you could change, say,
the behaviour of the function / upon loading the Nemo module? (without
mention
On Friday, 22 August 2014 14:10:10 UTC+2, Pierre wrote:
Thanks for the examples. However, given that in Julia you can re-define
about everything (cf your example with the function extracting elements
from a list, replaced by print 'test' ), surely you could change, say,
the behaviour of
One interesting thing I should mention is that loading Julia in bare module
mode and redefining all the basic operators and so on does not break all of
Julia's libraries. They all continue to operate as normal.
This was quite a surprise to me when I first found out, but all those
modules have
On 8/21/14, 18:08, Bill Hart wrote:
In theory, I can do generic programming in Julia that is faster (at
runtime) than you can do in *any* C compiler. And I don't just mean a
little bit. I mean a lot. I don't even think the Julia people fully
realise this yet (I might be wrong about that, I don't
On Saturday, 23 August 2014 04:26:10 UTC+2, jason wrote:
On 8/21/14, 18:08, Bill Hart wrote:
In theory, I can do generic programming in Julia that is faster (at
runtime) than you can do in *any* C compiler. And I don't just mean a
little bit. I mean a lot. I don't even think the Julia
On Saturday, 23 August 2014 06:09:00 UTC+2, jason wrote:
On 8/21/14, 11:36, Bill Hart wrote:
You can define the A.b syntax in Julia if you should so desire. It's
essentially just another kind of method overload in Julia.
And then, it supports A.tab giving a list of all the things
On 2014-08-21, Bill Hart goodwillh...@googlemail.com wrote:
--=_Part_5_2037022158.1408650350021
Content-Type: text/plain; charset=UTF-8
Julia can already call Python functions (and I don't mean in some
theoretical, technical sense, I mean very practically via an interface
designed
On Thursday, 21 August 2014 23:08:18 UTC+2, Dima Pasechnik wrote:
On 2014-08-21, Bill Hart goodwi...@googlemail.com javascript: wrote:
--=_Part_5_2037022158.1408650350021
Content-Type: text/plain; charset=UTF-8
Julia can already call Python functions (and I don't mean in some
On Friday, 22 August 2014 00:08:20 UTC+2, Bill Hart wrote:
My cursory look into Julia only poped out JIT stuff, not a real
complier...
Static compilation is coming to Julia. But not because it will speed
things up. It already has all the speed of an optimising compiler at the
Another thing that I think is terribly important is that the entire
technology stack, LLVM, all its libraries and packages, its console, the
IJulia web interface and Julia itself, all work out of the box on Windows
64, natively, not as a Cygwin app (they use MinGW64/MSYS2 to build Julia).
And
I just found time to actually read the links posted by the OP on Graydon
Hoare's history of programming language development, culminating in Julia.
Oh I wish I could write like that! The guy is clearly a genius of immense
proportions.
I truly, truly wish that the computer algebra and number
34 matches
Mail list logo
