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. So
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
> the result using the
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, t
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 wuold be super cool,
> like:
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 beca
On 28 April 2015 at 05:22, Mikera 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 likely to be unacceptable f
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 2:06
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 nu
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
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 numb
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
wrote:
> You
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 suggest
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
C
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 th
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
playi
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 AM
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 with
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 g
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 t
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:
https://gro
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, 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
Clojur
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 l
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 V
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 Cl
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 ca
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 t
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 each
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 wrote:
> Hi
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 org.apache.commons
Hi,
On Fri, Aug 15, 2014 at 7:00 PM, Reid McKenzie
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 (
> https://github.com/arrdem/imprecise, https://g
-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
32 matches
Mail list logo
