I'm still working on it. I was waiting for 1.2 to branch, and to for
some other changes to the basic types to happen. Really, I just need a
little free time and a kick-in-the-pants!
I'll try to get it done this week.
-Travis
On Jul 20, 11:09 am, Mike Benfield wrote:
> The lack of complex number
I'm still working on it. I've been waiting for the 1.2 release to
branch, and also for the other work on the basic types to settle down.
Also, I need a little free time. I'll try to get back to it this week.
-Travis
On Jul 20, 11:09 am, Mike Benfield wrote:
> The lack of complex numbers is keepi
2010/6/7 Mark Engelberg :
> Yes, but in (some versions of) Scheme, (sqrt -1) yields i.
>
> Representing complex numbers and just doing math between two complex
> numbers is not the problem. Retrofitting Clojure math so that all
> operations work on the entire numeric tower, allowing you to
> seaml
The lack of complex numbers is keeping me on the fence about Clojure.
I could (and partially have) implement them in Clojure itself, but
this is not as satisfying as having them built in with reader syntax
and so on. I don't have the will right now to learn enough about
Clojure internals and how t
Thanks. It's always interesting to see different notations.
On Jun 15, 4:49 pm, Travis Hoffman wrote:
> We Electrical Engineers are quite annoying in this regard, but
> historically, there is much variation out there: Python uses "j",
> MATLAB accepts i or j. Apache Commons allows the user to spe
We Electrical Engineers are quite annoying in this regard, but
historically, there is much variation out there: Python uses "j",
MATLAB accepts i or j. Apache Commons allows the user to specify the
specific character to use, but defaults to "i" I believe. Eventually,
I would suggest this be a local
Mathematicians traditionally use i and engineers traditionally use j to
represent the square root of -1. Travis undoubtedly wanted to keep both
happy.
--
Eric Krohn
> Sorry I may have missed the reason for this earlier: What's the
> reason for allowing both 'i' and 'j' to indicate the imaginar
On 15 June 2010 23:26, Carson wrote:
> Sorry I may have missed the reason for this earlier: What's the
> reason for allowing both 'i' and 'j' to indicate the imaginary part?
> Is the intention to also later have 'k' to support quaternions? Just
> curious. Thanks.
"j" is used by electrical engi
Sorry I may have missed the reason for this earlier: What's the
reason for allowing both 'i' and 'j' to indicate the imaginary part?
Is the intention to also later have 'k' to support quaternions? Just
curious. Thanks.
Carson
On Jun 14, 10:12 am, Travis Hoffman
wrote:
> I've almost completed
On Jun 14, 7:12 pm, Travis Hoffman wrote:
> I'm a n00b with git (but experienced with cvs and svn); I'm still
> trying to figure out how to push my local git repository changes to
> the fork I created on github. Can anyone help me there?
>
> The fork on git-hub is:
>
> git://github.com/travis-a-h
I've almost completed a Complex (and Imaginary) basic type in a fork
of clojure. It turns out that it was a bit more effort that I had
originally indicated. I'll save the implementation details for the
clojure-dev group, but here is a quick run-down of the "interface",
such as it is:
1.) Added two
> I'd happily join a "Clojure maths interest group" to work on such problems!
According to this survey math and data analysis occupies 39% of
Clojure's Problem Domain. In other words a lot of other Clojure
developers are interested in this too.
http://muckandbrass.com/web/display/~cemerick/2010/
On 09.06.2010, at 05:56, Andrzej wrote:
>> The point here is not simply to add a literal notation, but to
>> integrate complex type handling into the math functions. Bifurcating
>> the math functions is a horrible idea.
>
> Exactly. Speaking for myself again, I use complex numbers (much) more
>
On Wed, Jun 9, 2010 at 2:43 AM, ataggart wrote:
>
>> For non-literals the notation would need to support this:
>>
>> (* (my-complicated-algo x)+(my-other-complicated-algo y)i (another-
>> algo z)i)
>
> You're conflating notation with operation.
I wouldn't even bother with reader notation. Both (c
[context tossed due to top posting.]
On Tue, 8 Jun 2010 14:12:52 -0700 (PDT)
Jason Smith wrote:
> Why not just treat is as a vector, do vector math operations on it,
> and be done with it? 1+2j is equivalent to [1 2]. 1+2j represents a
> 2-D vector, does it not? Not only does this handle imag
Well, I don't find the question to be irrelevant. It makes me think
about a couple issues:
1.) Should Complex and Imaginary extend java.lang.Number?
2.) What do we do with the standard Java math functions?
3.) Is 'i' by itself, valid input as a number?
First, I do not propose that just "i" or "j"
Steven,
I see your point, however, if we look (again) at Ratio for insight:
user=> (+ (+ 1 2)/(+ 3 4) 5)
java.lang.ClassCastException: clojure.core$_SLASH_ cannot be cast to
java.lang.Number (NO_SOURCE_FILE:0)
The sort of notation for non-literals you suggest would be required
would actually not
Why not just treat is as a vector, do vector math operations on it,
and be done with it? 1+2j is equivalent to [1 2]. 1+2j represents a
2-D vector, does it not? Not only does this handle imaginaries, but
higher forms, such as [1 2 3 4]. The beauty of Lisp is that once you
accept the basic synta
On Tue, 8 Jun 2010 10:27:28 -0700 (PDT)
Steven Devijver wrote:
> On 8 jun, 16:38, Mike Meyer 620...@mired.org> wrote:
> >
> > Why? It isn't supported for rationals or exponents. Or are you
> > claiming that because we support "3/4" we should also support
> >
> > (* (my-complicated-algo val)/(my-
On 8 jun, 19:43, ataggart wrote:
> On Jun 8, 6:33 am, Steven Devijver wrote:
>
> > On 8 jun, 05:47, Daniel wrote:
>
> > > These notation arguments are compelling.
>
> > I'm not convinced. The notation would only work for literals
>
> Correct.
>
> > For non-literals the notation would need to s
On Jun 8, 6:33 am, Steven Devijver wrote:
> On 8 jun, 05:47, Daniel wrote:
>
> > These notation arguments are compelling.
>
> I'm not convinced. The notation would only work for literals
Correct.
> For non-literals the notation would need to support this:
>
> (* (my-complicated-algo x)+(my-o
On 8 jun, 16:38, Mike Meyer wrote:
>
> Why? It isn't supported for rationals or exponents. Or are you
> claiming that because we support "3/4" we should also support
>
> (* (my-complicated-algo val)/(my-other-complicated-algo exp)
> 1/(another-complicated-algo exp2))
>
> with similar problems
On Tue, 8 Jun 2010 06:33:25 -0700 (PDT)
Steven Devijver wrote:
> On 8 jun, 05:47, Daniel wrote:
> > These notation arguments are compelling.
> >
>
> I'm not convinced. The notation would only work for literals, and how
> often would one write literal complex numbers?
>
> For non-literals the no
On 8 jun, 05:47, Daniel wrote:
> These notation arguments are compelling.
>
I'm not convinced. The notation would only work for literals, and how
often would one write literal complex numbers?
For non-literals the notation would need to support this:
(* (my-complicated-algo x)+(my-other-compl
These notation arguments are compelling.
On Jun 5, 8:17 pm, Travis Hoffman wrote:
> Konrad,
>
> > Thanks, I'll look at that...
>
> I should warn that my changes don't quite seem to be working, there's
> something running amuck in the code yet that I'm still working on
> debugging, but the core is
Personally, I thinks it would be much more elegant to have a direct
notation. It could be argued that the Ratio type could also be
implemented without a special Ratio type, but where's the fun in that?
Consider:
(* 3.4+7i 15i)
vs
(complex-multiply (construct-complex 3.4 7) (construct-complex 0
Yes, but in (some versions of) Scheme, (sqrt -1) yields i.
Representing complex numbers and just doing math between two complex
numbers is not the problem. Retrofitting Clojure math so that all
operations work on the entire numeric tower, allowing you to
seamlessly manipulate complex and non-comp
For what it's worth, I found that working with complex numbers in
clojure doesn't require specialist types or notation at all:
(defn complex-times [[a_re a_im] [b_re b_im]] [(- (* a_re b_re) (*
a_im b_im)) (+ (* a_re b_im) (* a_im b_re))])
(defn complex-plus [[a_re a_im] [b_re b_im]] [(+ a_re b_r
For what it's worth, I think something like 3+5i is perfectly
reasonable as the + is not an operation, but part of the notation for
a single value, just as the + is not an operation in 1.234e+14. The
more troubling concern is whether the imaginary component should be
suffixed with an i or a j. ;)
Konrad,
> Thanks, I'll look at that...
I should warn that my changes don't quite seem to be working, there's
something running amuck in the code yet that I'm still working on
debugging, but the core is a bit mystifying.
> > Also, it seems more elegant to me to be able to simply write a complex
>
On 5 Jun 2010, at 04:09, Travis Hoffman wrote:
First off, thanks for the advice, steps and link! Secondly, the link
to my fork is:
git://github.com/travis-a-hoffman/clojure.git
Thanks, I'll look at that...
I did notice your Complex implementation in clojure-contrib, and I
especially appreci
I also took a look at Apache Commons Math:
http://commons.apache.org/math/
It seems to be quite good, unencumbered and actively developed, but I
haven't been able to (easily) find any recommendations or comparisons
of the available libraries.
Maybe the first step for a math group is to evaluate
Hi Konrad,
First off, thanks for the advice, steps and link! Secondly, the link
to my fork is:
git://github.com/travis-a-hoffman/clojure.git
I did notice your Complex implementation in clojure-contrib, and I
especially appreciated the effort in the generalizations. I'm a total
n00b to Clojure an
On 2 Jun 2010, at 02:38, Daniel wrote:
This touches upon another subject though: Clojure lacks a good math
library (though Liebke might kill me for that).
Incanter is great but it's not a math library in the sense of what you
propose. I'd say you have a chance to survive :-)
Has anybody th
On 1 Jun 2010, at 20:24, Travis Hoffman wrote:
I was curious what it would take to add a complex number type to
Clojure Core. If anyone else is curious, it doesn't take much:
1.) Add clojure.lang.Complex
2.) Add a Pattern and code to match, parse and create complex numbers
in LispReader (parses
Good deal. There's complex number support in contrib but this is
probably a much better way to go about it.
This touches upon another subject though: Clojure lacks a good math
library (though Liebke might kill me for that). Clojuratica is good
too but not nearly fast enough for general use. Has
I was curious what it would take to add a complex number type to
Clojure Core. If anyone else is curious, it doesn't take much:
1.) Add clojure.lang.Complex
2.) Add a Pattern and code to match, parse and create complex numbers
in LispReader (parses number of the form 1.0+0.0i)
3.) Add ComplexOps c
37 matches
Mail list logo
