I leave it to others to assess the tradeoffs, but: Anything that's done to
better support scientific computing has potential to pay off in the long run
with greater popularity for Clojure. Most, or many scientists work in
universities. Professors have students--lots of students, over time.
On 2 Nov 2015, at 13:11, Grahack wrote:
> I'm resurrecting this thread in case there is something new that happened
> concerning complex numbers that was not logged here.
> So was there some progress made?
>
> I also wanted to add that mixing rationals and complex
I'll just add that core matrix complex doesn't prevent you from using
rationals, as most of the math happens on real/imaginary matrix pairs.
However, any time you try to return a scalar value (not a matrix), it wraps
the result using the alanforr library, so you'd be potentially restricted
there,
I'm resurrecting this thread in case there is something new that happened
concerning complex numbers that was not logged here.
So was there some progress made?
I also wanted to add that mixing rationals and complex wuold be super cool,
like:
(* 1/2 i) => i/2)
--
You received this message
On 2 Nov 2015, at 15:57, Christopher Small wrote:
> I'll just add that core matrix complex doesn't prevent you from using
> rationals, as most of the math happens on real/imaginary matrix pairs.
> However, any time you try to return a scalar value (not a matrix), it wraps
On 28 April 2015 at 05:22, Mikera mike.r.anderson...@gmail.com wrote:
Complex numbers are tricky because:
- They need to be fast in order to be useful for numerical computing. The
obvious implementations that you might create with boxed values,
vectors/maps, multimethods and protocols are
For me, having complex numbers not work seamlessly with other numbers and
core arithmetic ops is not viable. Doing arithmetic ops with any kind of
number is a real (pardon the pun) use case.
If complex numbers are not likely to be supported fully, then maybe it
makes sense to have complex
Hi
Before we try to guess what Rich will or won't think or want, are you
interested in a proof of concept? So we could evaluate performance and
complexity issues before the subject is definitively buried.
What do you think about it?
Plínio
On Wed, Apr 29, 2015 at 12:56 AM, Mikera
Ideally math APIs would be cross-platform #ClojureScript
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first
Let me first say I would definitely like to see complex arithmetic support
in Clojure. Major hole for scientific computing in my opinion. And with the
momentum that Clojure has in ML / data science, I think it's one that needs
patching.
As to you specific point Nik:
For me, having complex
Yes, it would be nice to have this available for cljs as well. With the new
reader literals though, this doesn't preclude having a native java
implementation that gets loaded in the :clj case, and some other
implementation that gets loaded in the :cljs case.
On Wednesday, April 29, 2015 at
It does seem as though there is no way to meet all the criteria, unless the
support for it comes from Java/Oracle. That said, I feel like having a
complex type with reasonable performance is better than having nothing at
all.
What I would like is a complex type that plays well with Clojure's
My two cents:
I started to develop some support to complex numbers in Clojure, but I
don't know if the Core Team/Rich Hickey has any intererest in this subject.
Even it's an unfinished work, I didn't notice any lost of performance so
far.
Regards
Plínio Balduino
On Tue, Apr 28, 2015 at 9:35
To put is simply, it would be nice to have a complex type in Clojure, not
as a separate namespace, but something that is part of the language. It
should interoperate with other Clojure types (like adding a double to a
complex), as well as clojure.core.arithmetic. That's what I meant about
Your messages are a bit confusing. Playing nice with collection functions
would depend on the collection, not on its contents.
Maybe you could elaborate a bit more on what you're trying to accomplish?
If you do not care about performance, you need to decide whether you want
your type to work
Most of Clojure's collections already can hold arbitrary type values inside
of them, with no additional work required, whether those types are built
into Clojure or not. That is because most collections treat all contained
items as Java Object references.
The only exceptions I can think of are
You can do virtually all of that already with the Apache commons Complex
class. Any Java object can be just fine used with map / reduce / filter /
seqs etc.
If you want to avoid Java interop and make things more Clojure-like then
a lightweight wrapper library is all that is needed (my
Not that tricky, really. But there's a lot of repetitive work.
I changed the Clojure readers to understand the a+bi format, created a
ComplexNumber class and changed the class on charge of arithmetic to work
with complex numbers.
So it's possible to make any operation mixing Numbers, Ratios and
I think it's unlikely that Clojure would add a complex number type.
However, it might be possible to open up the system enough that new types
could be created and integrated by others. I think this discussion and
implementation from clojure-dev (about unsigned numbers) is pertinent:
Complex numbers are tricky because:
- They need to be fast in order to be useful for numerical computing. The
obvious implementations that you might create with boxed values,
vectors/maps, multimethods and protocols are likely to be unacceptable for
many use cases
- You still want to be able to
I have been thinking along the lines of mikera and Maik - and it seems like
there is no further progress here? I would like to take a crack at creating
a complex number type, but implemented as a library to Clojure. I am not
sure where to start, and if anyone here has suggestions, I'd be happy
Unless the Java Math library handles complex types already, I don't know of
any way to extend it in a way that would let you get the answer you want
from (Math/abs my-complex-number) in Clojure.
If you want code that gives the correct answers, a library using vectors or
maps for complex numbers
As far as I understand, your example with Math/abs would need to be part of
Java.
You cannot extend the arithmetic operators in Java, and you will not be
able to extend static Java methods like Math/abs.
What you may be able to do is make your custom type play nice with Clojure
operators, like
This is what I suspected. Of course, this is not just for abs, but really
for any mathematical operation. Sqrt, Trig operations etc.
I will study the Ratio type more closely, but note that something like
(Math/abs (/ 22 7)) does not work.
On Monday, April 27, 2015 at 12:45:32 PM UTC-4, Gary
As far as I know, Java Math does not have a complex number type. Some
implementations of a complex number exist (such as Apache Commons Math),
but they create a Complex class that implements Serializeable and a Commons
specific interface.
Modifying clojure.core itself is a bit daunting, and
People frequently make their own modified versions of Clojure without
having their changes made part of the core Clojure distribution. That is
why I said depending upon your goals. If your goal is to try it out and
learn from it, and you don't care whether it becomes part of the standard
Clojure
Just cheerleading: I, for one, would love for Clojure to have complex number
support, however it can be arranged (built-in or through a library).
I sometimes do quantum computing work and this issue has prevented progress on
a couple of projects. I haven't tried to solve the problem myself,
There is really no perfect numerical type:
- primitive doubles are best if you care about performance and reasonably
good precision (but no complex numbers!)
- boxed Doubles are needed in some circumtances, e g. storage in
collections, passing to dynamic code
- something like
I agree that Clojure could really use an imaginary number type.
The best place to start with this might be `clojure.math.numeric-tower` because
it already provides a
`MathFunctions` protocol that defines a square root operation.
Cheers Jan
On 15 Aug 2014, at 19:54, Maik Schünemann
I agree with mikera on this, the standard numeric abstraction have to be
able to fulfill all performance needs.
This definitly excludes multimethods (algo.generic) and
protocols/interface-calls (numeric-tower).
(Imagine multiplying two 5000x5000 matrices and having to go through a
protocol for
Hi,
is there a recommended way to do complex arithmetic in clojure ?
I am interested to see clojure going forward for scientific computing
purposes.
There is already considerable effort going on with core.matrix, incanter,
expresso etc.
But something thad is oddly lacking is support for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The best way to build a complex arithmetic package is probably to work
atop `clojure.algo.generic`. I've done a pair of libraries
(https://github.com/arrdem/imprecise, https://github.com/arrdem/meajure)
based around extending algo.generic with custom
Hi,
On Fri, Aug 15, 2014 at 7:00 PM, Reid McKenzie rmckenzi...@gmail.com
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The best way to build a complex arithmetic package is probably to work
atop `clojure.algo.generic`. I've done a pair of libraries (
33 matches
Mail list logo