, 2010, at 8:13 PM, Frederick Polgardy wrote:
>
>
>
> > Or [using clojure.set] (empty? (intersection s1 s2)).
>
> > --
> > Science answers questions; philosophy questions answers.
>
> > On Jul 21, 2010, at 4:45 PM, Travis Hoffman wrote:
>
> >> The
*sigh* ... it was a typo. Good catch!
On Jul 21, 10:16 pm, B Smith-Mannschott wrote:
> On Wed, Jul 21, 2010 at 23:45, Travis Hoffman
> wrote:
>
> ...
>
>
>
>
>
> > The second function is suggested as an addition to clojure.set. The
> > "disjoint?&qu
I've found two convenience methods to be of use to me in my project,
and I'm not certain where I ought to share them. So, I thought I'd
share them here, for your consideration. Sorry, I'm a bit of a n00b to
Clojure. :-)
The first I would suggest for inclusion in core.clj; it is very
similar in beh
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
Hello, I've come across the following compiler error in defrecord and
deftype:
java.lang.RuntimeException: java.lang.ClassCastException:
clojure.lang.PersistentList cannot be cast to clojure.lang.Symbol
(test.clj:0)
To generate the error, evaluate the following code:
(ns test)
(defrecord TestRe
I think the first, most important, step is to identify a JVM which is
designed for safety critical systems. The only JVM I know of that has
even bothered to consider SC Java is Atego's (formerly Aonix)
UltraPERC, and I don't think they've qualified it to the level you
seek.
To get qualified for Sa
Thanks for the clarification Stuart! I think I see how to think about
protocols ... and not as an interface, in the java sense. I think it
makes sense to me now.
Love your book, btw!
-Travis
On Jun 21, 12:31 pm, Stuart Halloway
wrote:
> Hi Travis,
>
> The choice of "extend" follows from this r
I notice that there is a "satisfies?" method to determine if something
satisfies a protocol. Also, I see that "extend-protocol" doesn't
actually let one create a protocol which is an extension of another
protocol. Rather, "extend-protocol" really means "implements", in the
Java sense.
When I first
I'm trying to develop a hierarchy (of sorts) of protocols and I'm
coming at it in from a Java Perspective, which I fully understand
might be my problem. In Java, I would do something like this:
interace A {
public void aFoo();
}
interface B {
public void bFoo();
}
interfacece AB extends A, B
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
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
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
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
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
>
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
able place to start.
Cheers,
Travis
On Jun 2, 12:23 am, Konrad Hinsen wrote:
> On 1 Jun 2010, at 20:24, Travis Hoffman wrote:
> I did
> > 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:
>
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
19 matches
Mail list logo
