No. I have to admit that I haven't looked at these classes for a long time.
I am glad to hear that sampling is in the distributions.
On Sun, Sep 11, 2011 at 3:09 PM, Phil Steitz wrote:
> Another example comes from the random distributions. The current design
> separates generating values from
Another example comes from the random distributions. The current design
separates generating values from evaluating CDF's even though users think of
those as operations on the same object. Moreover, there is an intricate
lattice of (unique) implementations and interfaces that the user has to
figu
On Sun, Sep 11, 2011 at 2:37 PM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:
> Discussions on this list are sufficiently tense that we probably don't need
> to have a flame war on OO. :-}
>
And I would hate to start that given that I think the discussions go too
long in any case.
> A
Hi Ted.
> Nah... I just meant get some usable code done before the inevitable
> discussion winds down. Discussions about designs in commons math tend to
> follow the pattern of a) proposing an OK design, b) proposing a fine
> improvement, and then c) iterating forever on hair-splitting details.
Nah... I just meant get some usable code done before the inevitable
discussion winds down. Discussions about designs in commons math tend to
follow the pattern of a) proposing an OK design, b) proposing a fine
improvement, and then c) iterating forever on hair-splitting details. The
final result
On 9/10/11 2:51 PM, Gilles Sadowski wrote:
> Hello.
>
> Coming back to this with a simple idea that may hopefully satisfy everyone.
>
> What do you think of having one class that performs all operations by
> directly applying the computational formulae, without worrying about NaN
> or infinities. T
On 9/10/11 3:19 PM, Ted Dunning wrote:
> Sounds great.
>
> Especially if the implementation of the sub-class is deferred until the
> first is completed.
What exactly do you mean by "the first is completed" - reverting
what is in trunk now to eliminate the checks / recodes that it does?
Phil
>
> O
Sounds great.
Especially if the implementation of the sub-class is deferred until the
first is completed.
On Sat, Sep 10, 2011 at 2:51 PM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:
> Hello.
>
> Coming back to this with a simple idea that may hopefully satisfy everyone.
>
> What do y
Hello.
Coming back to this with a simple idea that may hopefully satisfy everyone.
What do you think of having one class that performs all operations by
directly applying the computational formulae, without worrying about NaN
or infinities. This would be represent the complex field, would be simp
I added the file ComplexOctaveTest.java to JIRA MATH-620.
What really will happen, if Inf and NaN values com up I dont know at
this point - the complex signal path is in its infancy at the moment ...
(I currently have no need for that)
Arne
--
On 9/5/11 7:21 AM, Gilles Sadowski wrote:
> On Mon, Sep 05, 2011 at 02:15:30PM +0200, Arne Ploese wrote:
>> To make things clear here some octave (matlab as well) calculation with
>> complex:
>>
>> octave:1> a = Inf + sqrt(-Inf)
>> a = Inf + Infi
>> octave:2> a * a
>> ans = NaN + Infi
>> octave:3>
On Mon, Sep 05, 2011 at 02:15:30PM +0200, Arne Ploese wrote:
> To make things clear here some octave (matlab as well) calculation with
> complex:
>
> octave:1> a = Inf + sqrt(-Inf)
> a = Inf + Infi
> octave:2> a * a
> ans = NaN + Infi
> octave:3> a = Inf + sqrt(-1)
> a = Inf + 1i
> octave:4> a *
To make things clear here some octave (matlab as well) calculation with
complex:
octave:1> a = Inf + sqrt(-Inf)
a = Inf + Infi
octave:2> a * a
ans = NaN + Infi
octave:3> a = Inf + sqrt(-1)
a = Inf + 1i
octave:4> a * a
ans = Inf + Infi
octave:5> a = 1 + sqrt(-Inf)
a =1 + Infi
octave:6> a * a
Sorry answering that late, but I was busy...
So simply I try to write a lib that doing some DSP stuff. I took some
*.m files from the octave signaling package ant converted them to java
(digital filters aka. Butterworth ...) there is a litte bit calculation
needed.
So my problem is: if the com
On 9/4/11 4:50 AM, Luc Maisonobe wrote:
> Hi Gilles,
>
> Le 04/09/2011 12:28, Gilles Sadowski a écrit :
[...]
> The mathematical question is do we view our class as representing
> the extended complex numbers. If we agree that the answer to
> that
> question is yes,
If yo
On 9/4/11 6:01 AM, Gilles Sadowski wrote:
>>> [...]
>> The hit is in the constructor, where every complex instance has to
>> run the code to set the property.
> In fact, not only! If one can trust the mini-benchmark performed with
> "PerfTestUtils", the constructor with the additional flag is 2% sl
On 9/4/11 7:22 AM, Gilles Sadowski wrote:
> Hello Luc.
>
> [...]
>> The mathematical question is do we view our class as representing
>> the extended complex numbers. If we agree that the answer to that
>> question is yes,
> If you say "no", then my understanding is that the "C
Hello Luc.
> >>>[...]
> The mathematical question is do we view our class as representing
> the extended complex numbers. If we agree that the answer to that
> question is yes,
> >>>If you say "no", then my understanding is that the "Complex" class does not
> >>>represent the complex
> > [...]
>
> The hit is in the constructor, where every complex instance has to
> run the code to set the property.
In fact, not only! If one can trust the mini-benchmark performed with
"PerfTestUtils", the constructor with the additional flag is 2% slower.
But using the flag in "divide" makes i
Hi Gilles,
Le 04/09/2011 12:28, Gilles Sadowski a écrit :
[...]
The mathematical question is do we view our class as representing
the extended complex numbers. If we agree that the answer to that
question is yes,
If you say "no", then my understanding is that the "Complex" class does not
repr
> > [...]
> >> The mathematical question is do we view our class as representing
> >> the extended complex numbers. If we agree that the answer to that
> >> question is yes,
> > If you say "no", then my understanding is that the "Complex" class does not
> > represent the complex number concept, un
On 9/3/11 5:06 PM, Gilles Sadowski wrote:
>> The problem is that it is not obvious that INF is "the right answer."
> The real problem is *inconsistency*.
> The current code chooses to consider a point at infinity for some situations
> but not for others. It is thus quite understandable that people
>
> The problem is that it is not obvious that INF is "the right answer."
The real problem is *inconsistency*.
The current code chooses to consider a point at infinity for some situations
but not for others. It is thus quite understandable that people are
wondering what is going on with some limi
On 9/3/11 2:17 PM, Gilles Sadowski wrote:
> On Sat, Sep 03, 2011 at 08:10:59AM -0700, Phil Steitz wrote:
>> On 9/3/11 2:30 AM, Gilles (JIRA) wrote:
>>> [
>>> https://issues.apache.org/jira/browse/MATH-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13
On Sat, Sep 03, 2011 at 08:10:59AM -0700, Phil Steitz wrote:
> On 9/3/11 2:30 AM, Gilles (JIRA) wrote:
> > [
> > https://issues.apache.org/jira/browse/MATH-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096621#comment-13096621
> > ]
> >
> > Gille
On 9/3/11 2:30 AM, Gilles (JIRA) wrote:
> [
> https://issues.apache.org/jira/browse/MATH-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096621#comment-13096621
> ]
>
> Gilles commented on MATH-657:
> -
>
> I've just po
26 matches
Mail list logo
