We have developed this revolutionary tech - now starts the hard work!

We wished submit our case to the science and wisdow of the net:

We are a small (talented;-) software company who has developed this
remarkable software technology; namely a new and improve way to do
spectral transform.

The algorithm is faster, more versatile and its output is both more stable
and precise than know algorithms. 

Major points :
1) It runs in O(n)
2) It can compute any DFT or DTFT as a limit case (yes in O(n), yes that
means it can compute true DFT and DTFT in real-time)
3) It can be computed to the nth degree with improve precision for each
degree (CPU time against time precision...)
4) It can be adapted in many ways to the data to transform

So here we have developed this key technology that addresses critical
things like speech recognition, audio & video compression, ... you know,
billion dollar type of things.

It is researched, tested, developed, proven, packed and ready. Are we rich
? Not yet ! Now, ... the hard work starts.

Our little (talented;-) team of engeneer shall now rise, unfold their
penguin suits (u know, we r geeks, those things look odd to us) , and walk
the icy ways of internationnal business. The Capital's punishment I
suppose.

Maybe someday a traveller of those ways will discover our algorithm in the
legacy of our small company dead and rotten body.
Or maybe we will be rich before this time, like it sometimes happens for
artists.

We will see. I'm a wise person, happy to know the future will be revealed
to me in proper time. 

Meanwhile, would anyone have some advise or suggestion for us ?

On Apr 10, 6:50&#4294967295;am, "JustAnAngel" <msamue...@yahoo.com.sg> wrote:
> We wished submit our case to the science and wisdow of the net:
>
> We are a small (talented;-) software company who has developed this
> remarkable software technology; namely a new and improve way to do
> spectral transform.
>
> The algorithm is faster, more versatile and its output is both more stable
> and precise than know algorithms.
>
> Major points :
> 1) It runs in O(n)
> 2) It can compute any DFT or DTFT as a limit case (yes in O(n), yes that
> means it can compute true DFT and DTFT in real-time)
> 3) It can be computed to the nth degree with improve precision for each
> degree (CPU time against time precision...)
> 4) It can be adapted in many ways to the data to transform
>
> So here we have developed this key technology that addresses critical
> things like speech recognition, audio & video compression, ... you know,
> billion dollar type of things.
>
> It is researched, tested, developed, proven, packed and ready. Are we rich
> ? Not yet ! Now, ... the hard work starts.
>
> Our little (talented;-) team of engeneer shall now rise, unfold their
> penguin suits (u know, we r geeks, those things look odd to us) , and walk
> the icy ways of internationnal business. The Capital's punishment I
> suppose.
>
> Maybe someday a traveller of those ways will discover our algorithm in the
> legacy of our small company dead and rotten body.
> Or maybe we will be rich before this time, like it sometimes happens for
> artists.
>
> We will see. I'm a wise person, happy to know the future will be revealed
> to me in proper time.
>
> Meanwhile, would anyone have some advise or suggestion for us ?




Question: When you say it does a DFT in O(n) is that just for a single
frequency? If so, then you are no better than old time tested methods.
If you can handle multiple frequencies in O(n), then you have
something to brag about.

If you have something superior then:
1) Implement your algo and publicly show it does what you claim.
2) apply for a patent on your algo
3) publish your algo and your claims in a per reviewed journal. See if
your claims survive extreme scrutiny.

Clay

JustAnAngel wrote:
> We wished submit our case to the science and wisdow of the net:
> 
> We are a small (talented;-) software company who has developed this
> remarkable software technology; namely a new and improve way to do
> spectral transform.
> 
> The algorithm is faster, more versatile and its output is both more stable
> and precise than know algorithms. 
> 
> Major points :
> 1) It runs in O(n)
> 2) It can compute any DFT or DTFT as a limit case (yes in O(n), yes that
> means it can compute true DFT and DTFT in real-time)
> 3) It can be computed to the nth degree with improve precision for each
> degree (CPU time against time precision...)
> 4) It can be adapted in many ways to the data to transform
> 
> So here we have developed this key technology that addresses critical
> things like speech recognition, audio & video compression, ... you know,
> billion dollar type of things.
> 
> It is researched, tested, developed, proven, packed and ready. Are we rich
> ? Not yet ! Now, ... the hard work starts.
> 
> Our little (talented;-) team of engeneer shall now rise, unfold their
> penguin suits (u know, we r geeks, those things look odd to us) , and walk
> the icy ways of internationnal business. The Capital's punishment I
> suppose.
> 
> Maybe someday a traveller of those ways will discover our algorithm in the
> legacy of our small company dead and rotten body.
> Or maybe we will be rich before this time, like it sometimes happens for
> artists.
> 
> We will see. I'm a wise person, happy to know the future will be revealed
> to me in proper time. 
> 
> Meanwhile, would anyone have some advise or suggestion for us ?
> 
> 
> 

You say " The algorithm is faster, more versatile and its output is both 
more stable and precise than know algorithms. "  This is puzzling 
because the output of the conventional FFT is always stable, and the FFT 
can be computed to any desired precision.  It would appear then that the 
only (but important) advantage of your algorithm is that it is faster.

You can't patent and algorithm; only a product, so you will need to get 
patents on a range of products that rely on your algorithm.  The 
advantage of these products would be that they could use a slower DSP 
processor or FPGA (or fewer of them) compared with the conventional 
approach.

Having a product that is smaller, cheaper and uses less power is 
important, so there may be some money to be made here, depending on the 
amount of improvement. I think everyone here would be interested in some 
comparisons and some numbers from you.

Regards,
John

On Fri, 11 Apr 2008 09:23:52 +1000, John Monro
<johnmonro@optusnet.removethis.com.au> wrote:

>JustAnAngel wrote:
>> We wished submit our case to the science and wisdow of the net:
>> 
>> We are a small (talented;-) software company who has developed this
>> remarkable software technology; namely a new and improve way to do
>> spectral transform.
>> 
>> The algorithm is faster, more versatile and its output is both more stable
>> and precise than know algorithms. 
>> 
>> Major points :
>> 1) It runs in O(n)
>> 2) It can compute any DFT or DTFT as a limit case (yes in O(n), yes that
>> means it can compute true DFT and DTFT in real-time)
>> 3) It can be computed to the nth degree with improve precision for each
>> degree (CPU time against time precision...)
>> 4) It can be adapted in many ways to the data to transform

I have an algorithm that runs in O(1), i.e., 1 clock cycle for any
length N.    Seriously, it is possible to do a length-N transform in a
single clock cycle.  My algorithm has never been implemented, but is
theoretically sound.

And a sliding-window DFT also runs O(n) once initialized.

I'm not sure why I should be excited about your development, since it
doesn't seem to represent anything new (at least not with what you've
described so far).

>> 
>> So here we have developed this key technology that addresses critical
>> things like speech recognition, audio & video compression, ... you know,
>> billion dollar type of things.
>> 
>> It is researched, tested, developed, proven, packed and ready. Are we rich
>> ? Not yet ! Now, ... the hard work starts.
>> 
>> Our little (talented;-) team of engeneer shall now rise, unfold their
>> penguin suits (u know, we r geeks, those things look odd to us) , and walk
>> the icy ways of internationnal business. The Capital's punishment I
>> suppose.
>> 
>> Maybe someday a traveller of those ways will discover our algorithm in the
>> legacy of our small company dead and rotten body.
>> Or maybe we will be rich before this time, like it sometimes happens for
>> artists.
>> 
>> We will see. I'm a wise person, happy to know the future will be revealed
>> to me in proper time. 
>> 
>> Meanwhile, would anyone have some advise or suggestion for us ?
>> 
>> 
>> 
>
>You say " The algorithm is faster, more versatile and its output is both 
>more stable and precise than know algorithms. "  This is puzzling 
>because the output of the conventional FFT is always stable, and the FFT 
>can be computed to any desired precision.  It would appear then that the 
>only (but important) advantage of your algorithm is that it is faster.
>
>You can't patent and algorithm; only a product, so you will need to get 
>patents on a range of products that rely on your algorithm.  The 
>advantage of these products would be that they could use a slower DSP 
>processor or FPGA (or fewer of them) compared with the conventional 
>approach.
>

Patenting an algorithm isn't a problem, at least in the US and in my
experience in many other areas as well.

>Having a product that is smaller, cheaper and uses less power is 
>important, so there may be some money to be made here, depending on the 
>amount of improvement. I think everyone here would be interested in some 
>comparisons and some numbers from you.
>
>Regards,
>John
Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.ericjacobsen.org

On Thu, 10 Apr 2008 05:50:49 -0500, "JustAnAngel"
<msamuel75@yahoo.com.sg> wrote in comp.dsp:

> We wished submit our case to the science and wisdow of the net:

The net may well have wisdow, it certainly has no wisdom.

   [snip]

> Meanwhile, would anyone have some advise or suggestion for us ?

Yes, two suggestions.

1.  Learn to write using proper grammar, punctuation, and
capitalization.

2.  Learn to use a spell checker.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

Eric Jacobsen wrote:
> I have an algorithm that runs in O(1), i.e., 1 clock cycle for any
> length N.    Seriously, it is possible to do a length-N transform in a
> single clock cycle.  My algorithm has never been implemented, but is
> theoretically sound.
> 
> And a sliding-window DFT also runs O(n) once initialized.
> 
> I'm not sure why I should be excited about your development, since it
> doesn't seem to represent anything new (at least not with what you've
> described so far).


I think there is a characteristic that distinctly splits engineers into 
two groups:

- Some think everything they do is brilliant, innovative, and 
groundbreaking. These people think they should be able to patent 
everything they do.

- Some think "If I came up with this, I'm sure a hundred other people 
have already done so". These people live in fear of the techniques they 
are using being in someone else's patent.

The latter group tends to be correct far more often than the former. :-)

Regards,
Steve

Thanks you all for your comments, they are very much appreciated and
helpful.

First I realize while what I wrote made perfect good sense to me when I
wrote it, it may in fact have not been very precise. 

> I think everyone here would be interested in some comparisons
> and some numbers from you.
That’s fair:

1) Speed
Let say we have a 32k audio stream as input, and we want a transform for
freqs ranging from 64hz to 4160hz in 8hz steps at each input sample.

M = input samples = 32.768 
N = output frequencies = 512

FFT with window runs in M x [O(NlogN) + O(N)] ~= 32.768*1.899 =
62.226.432
Our algo runs in M x O(N) = 32.768*512 = 16.277.216

2) Signal stability
FFT output is not stable. First it flickers, that’s why first thing is
to apply a window to get rid of the hard lines on a spectrogram (and this
trick does cost in precision). Then FFT output is full of downward peaks, V
shaped peaks, ‘be-headed’ peaks, and so forth. This is especially true
for low power signals or fast shifting signals (Such as human speech with
intonation). 

3) Output precision
A major problem with FT (and spectral analysis in general) is the more you
localize in frequency space the less you can localize in time space. E.g.
if you use FFT over 256 input speech samples, you’ll get good
approximation of where freq happen in the input but bad localization of
freq in the output. Using 1024 input samples, you know better the freqs in
the output, but then you know less where they happen in the input.

Our algo can be computed to some given degree. (Complexity increase
linearly, i.e. O(k*N) for degree k). For each degree the time/freq
precision will be about doubled (a fair approximation for lower degrees)
and signal stability will increase (less flickering and so forth).

4) Versatility
Our algo is not bound to an input sample window. If you like to compute 32
frequencies with fancy distribution from a 256 input sample it is very well
possible. Response factor can be set at will, so if you like better
localization in frequency domain for lower hz and better localization in
time for higher hz it is also possible. (the discreet time FT or short term
FT idea – the algo can compute any DTFT config as a limit case)

5) In real (and complex) life
From our testing, the most useful config for audio data is the 4th. Using
the example before, if you like to compute every unit freq from 25hz to
5025hz on real-life speech data:

M = input samples = 32.768
N = output frequencies = 5.000
K = algo degree = 4

FFT with window would run in M x [O(NlogN) + O(N)] ~= 32.768*23.495 =
769.884.160
Our algo runs in M x O(K*N) = 32.768*20.000 = 655.360.000

For our algo any output config can be used, response time can be chosen
freely, and the time/frequency ratio will be about 8 time better than FFT.
At 4th degree output signal is already very well behaved and easy to
filter.

As you can see our algo does a lot more than FFT for less.

>You say " The algorithm is faster, more versatile and its output is both
more stable and precise than know algorithms. " This is puzzling
I guess this points it out, maybe we lack of producing a compelling
presentation of our algorithm. Something that clearly represent its
merits.

> 1) Implement your algo and publicly show it does what you claim.
Done, the thing is developed and ready. We can prove all claims anytime.

> 2) apply for a patent on your algo
> 3) publish your algo and your claims in a peer reviewed journal. See if
your claims survive extreme scrutiny.
Maybe here lies the hard work we mentioned. It works, our computers are
convinced. We have built a head to head app running our algo and FT. What
we write here is backed up by what we see just here on our screens, so we
know we don’t make foolish assumptions or say what we cannot prove.
But here stops our ‘expertise’. We could try to patent it, but how to
make sure we make the right claims, the right way. That someone won’t
come just right afterward change two lines and make a new ‘improved’
patent that render ours worthless. We have no experience in this. Same for
a peer reviewed journal. It is one thing to make the darn thing work, an
entire different story to describe it in algorithmic or mathematical terms
and prove A+B it is optimal and so forth.

We are not scientist, just talented software people who made something
that works very well. 

How those guys can make it?

Thanks,
Ange

PS:
> 1. Learn to write using proper grammar, punctuation, and
capitalization.
> 2. Learn to use a spell checker.
Thank you Jack, I am learning, English is for me a 3rd tongue. But have no
worries, I don't intent to write a book ;-)

Thanks for responding to my suggestion: "I think everyone here would be 
interested in some comparisons and some numbers from you."  You write:

> That’s fair:
> 
> 1) Speed
> Let say we have a 32k audio stream as input, and we want a transform for
> freqs ranging from 64hz to 4160hz in 8hz steps at each input sample.
> 
> M = input samples = 32.768 
> N = output frequencies = 512
> 
> FFT with window runs in M x [O(NlogN) + O(N)] ~= 32.768*1.899 =
> 62.226.432
> Our algo runs in M x O(N) = 32.768*512 = 16.277.216
> 

Unfortunately this does not make sense.  For a start, O(N) is not a 
number and M x O(N) is meaningless. Did you mean O(M x N)?  Even so, you 
still don't get a number as a result.

Regards,
John

Hi,

  One suggestion I have.

  1. Implement the same algo in hardware. Take any one route.
     a. FPGA
     b. ASIC
     c. DSP's like ADI, TI

  2. See if there are improvements on these fronts:

     a. Area
     b. Speed (This is your claim).
     c. Power dissipation.

  Speed improvements can often be gotten from duplication in hardware
  or approaches like pipelining. So gains in one area
  is compensated by losses in others.

  Your cost function should have all three factors (area, speed
  and power dissipation). Then only your algo makes a product sense 
  and thus applying for patent and making dollar sense.

  you may want to sign an NDA with someone who can help you implement
  and test the same algo in h/w. 

Regards
Bharat Pathak

Arithos Designs
www.Arithos.com

DSP design consultancy and Training company.



  

>> M = input samples = 32.768 
>> N = output frequencies = 512
>> 
>> FFT with window runs in M x [O(NlogN) + O(N)] ~= 32.768*1.899 =
>> 62.226.432
>> Our algo runs in M x O(N) = 32.768*512 = 16.277.216

> Unfortunately this does not make sense. For a start, O(N) is not a 
> number and M x O(N) is meaningless. Did you mean O(M x N)? Even so, you

> still don't get a number as a result.

Txs John, I realize that. The purpose was to show in the formula where and
how the complexity of the algorithm compares to FFT.

Just remove the O() to make it proper :

FFT with window runs in M * ( N*log(N) + N ) ~= 32.768*1.899
Our algo runs in M * N = 32.768*512

And the numbers are in 'unit operation' in the sense of algorithm
complexity.

> Bharat says:
> One suggestion I have.
> 1. Implement the same algo in hardware. Take any one route.

Unfortunately we know very little about HW design. There might be
interesting prospect out of the algorithm for HW implementation, I don't
know.

I guess what we are looking for is business partners that will be able to
market the tech and develop it beyond our expertise. HW is certainly an
area to explore. 

Then if Eric Jacobsen comes by this thread sometimes it would be nice if
you could react on 
> We could try to patent it, but how to make sure we make the right 
> claims, the right way. That someone won’t come just right afterward
> change two lines and make a new ‘improved’ patent that render ours
> worthless.

from our last post.

Txs