Spectral Purity Measurement

[rickman]

On 12/26/2014 11:45 AM, Eric Jacobsen wrote:

On Thu, 25 Dec 2014 18:08:54 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/25/2014 4:32 PM, Eric Jacobsen wrote:
On Thu, 25 Dec 2014 16:08:45 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/25/2014 3:56 PM, Eric Jacobsen wrote:
On Thu, 25 Dec 2014 11:56:15 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/25/2014 10:52 AM, Eric Jacobsen wrote:
On Tue, 23 Dec 2014 18:10:43 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/23/2014 4:48 PM, Eric Jacobsen wrote:
On Tue, 23 Dec 2014 11:06:39 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/23/2014 10:35 AM, Eric Jacobsen wrote:

Many applications don't need separate LUTs to get the required
performance, and even then, or even in the case of complex output, it
can be done without multipliers.

Care to elaborate on this? I'm not at all clear on how you make a LUT
based NCO without LUTs and unless you are using a very coarse
approximation, without multipliers.

Not sure what you're asking. You a need a LUT, but just one in many
cases. Having a dual-ported single LUT is easy in an FPGA and
usually in silicon as well.

What makes a multiplier necessary? I've never found the need, but my
apps are limited to comm.

Maybe we aren't on the same page. The multiplier is there for the fine
adjustment. If you are happy with some -60 or -80 dB spurs one LUT is
fine. But if you want better performance the single LUT approach
requires *very* large tables.

There are a lot of tricks that can be used to keep the table size
down. I've mentioned one already.

And what was that? You have made some 20 or more posts in this thread,
I don't feel like weeding through all of them to find this. Reading
back through this thread it seems like your posts are intended to be
mysterious rather than informative. Every one leaves enough unsaid that
more questions are needed.

I can't divulge trade secrets or proprietary information that doesn't
belong to me. I can, however, hint in directions of benefit. Take
it or leave it.

I have no idea what you are talking about. If you don't have anything
to say, why are you bothering to post?

Why do you care whether I post or not? Feel free to put me in your
kill file if you don't like my posts.

If you aren't interested in having a conversation, why do you bother to
type? Above you said you had already mentioned "one" method already.
Clearly that one is not a trade secret. Care to explain what method you
are referring to?

I did later in the same post.

What same post would that be? I'm not sure what "same" means since the
context is not clear.

I don't even recall the hints.
Or are you forbidden from pointing out what those are?

No, but it seems to me like unnecessary duplication. There are lots
of hints from multiple people scattered throughout the thread, as well
as in some of the literature mentioned previously.

Exactly, scattered in some 50 or so messages. If you have something to
say, why no say it instead of being so vague? Just tell me which
message you are referring to.

So you want me to go back and search through the thread for you? Are
you not capable of doing that? I'm not at all clear why you think
that I should do the search if you're the one that wants the
information.

I'm assuming that you might have more recollection of having made a
post than I do of reading it. I did a scan and I never saw any useful
comments on table reduction. Everything you posted seems to allude to
things but always shies away from actually giving any info.

You said you had already mentioned a way to reduce table size. What was
that?

One way is to store a quarter wave instead of a full cycle. I think
that was mentioned more than once, but here it is again just for you.

Thank you for the response.

Yes, that is table reduction 101. Anyone other than a newbie is aware
of that. I believe *I* was the one who in this thread pointed it out to
someone who said memory is cheap not fully appreciating that memory is
order 2^N is size. Even so it is just a factor of four and does nothing
to change the fact that memory is anything but cheap if you are looking
for high resolution and low distortion. Using MBs of memory to store a
LUT is usually not a good trade off.

What was the technique *you* mentioned as you indicate above?

That was one of them. I mentioned it more than once. In my
experience a 4x reduction in memory can be significant, and the
quarter-wave trick isn't obvious to some people so I didn't make the
assumption that it was.

You're welcome.

Yes, a four fold reduction in size can be useful, but like I said, this
is sine table 101.

Was there anything else of value you have to offer on the topic?

--

Rick

 

[Eric Jacobsen]

On Fri, 26 Dec 2014 12:05:24 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/26/2014 11:45 AM, Eric Jacobsen wrote:
On Thu, 25 Dec 2014 18:08:54 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/25/2014 4:32 PM, Eric Jacobsen wrote:
On Thu, 25 Dec 2014 16:08:45 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/25/2014 3:56 PM, Eric Jacobsen wrote:
On Thu, 25 Dec 2014 11:56:15 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/25/2014 10:52 AM, Eric Jacobsen wrote:
On Tue, 23 Dec 2014 18:10:43 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/23/2014 4:48 PM, Eric Jacobsen wrote:
On Tue, 23 Dec 2014 11:06:39 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/23/2014 10:35 AM, Eric Jacobsen wrote:

Many applications don't need separate LUTs to get the required
performance, and even then, or even in the case of complex output, it
can be done without multipliers.

Care to elaborate on this? I'm not at all clear on how you make a LUT
based NCO without LUTs and unless you are using a very coarse
approximation, without multipliers.

Not sure what you're asking. You a need a LUT, but just one in many
cases. Having a dual-ported single LUT is easy in an FPGA and
usually in silicon as well.

What makes a multiplier necessary? I've never found the need, but my
apps are limited to comm.

Maybe we aren't on the same page. The multiplier is there for the fine
adjustment. If you are happy with some -60 or -80 dB spurs one LUT is
fine. But if you want better performance the single LUT approach
requires *very* large tables.

There are a lot of tricks that can be used to keep the table size
down. I've mentioned one already.

And what was that? You have made some 20 or more posts in this thread,
I don't feel like weeding through all of them to find this. Reading
back through this thread it seems like your posts are intended to be
mysterious rather than informative. Every one leaves enough unsaid that
more questions are needed.

I can't divulge trade secrets or proprietary information that doesn't
belong to me. I can, however, hint in directions of benefit. Take
it or leave it.

I have no idea what you are talking about. If you don't have anything
to say, why are you bothering to post?

Why do you care whether I post or not? Feel free to put me in your
kill file if you don't like my posts.

If you aren't interested in having a conversation, why do you bother to
type? Above you said you had already mentioned "one" method already.
Clearly that one is not a trade secret. Care to explain what method you
are referring to?

I did later in the same post.

What same post would that be? I'm not sure what "same" means since the
context is not clear.

The same one you were responding to at the time.

I don't even recall the hints.
Or are you forbidden from pointing out what those are?

No, but it seems to me like unnecessary duplication. There are lots
of hints from multiple people scattered throughout the thread, as well
as in some of the literature mentioned previously.

Exactly, scattered in some 50 or so messages. If you have something to
say, why no say it instead of being so vague? Just tell me which
message you are referring to.

So you want me to go back and search through the thread for you? Are
you not capable of doing that? I'm not at all clear why you think
that I should do the search if you're the one that wants the
information.

I'm assuming that you might have more recollection of having made a
post than I do of reading it. I did a scan and I never saw any useful
comments on table reduction. Everything you posted seems to allude to
things but always shies away from actually giving any info.

I mentioned the quarter-wave reduction specifically multiple times.
Sorry you weren't able to glean anything. Not everybody does.

You said you had already mentioned a way to reduce table size. What was
that?

One way is to store a quarter wave instead of a full cycle. I think
that was mentioned more than once, but here it is again just for you.

Thank you for the response.

Yes, that is table reduction 101. Anyone other than a newbie is aware
of that. I believe *I* was the one who in this thread pointed it out to
someone who said memory is cheap not fully appreciating that memory is
order 2^N is size. Even so it is just a factor of four and does nothing
to change the fact that memory is anything but cheap if you are looking
for high resolution and low distortion. Using MBs of memory to store a
LUT is usually not a good trade off.

What was the technique *you* mentioned as you indicate above?

That was one of them. I mentioned it more than once. In my
experience a 4x reduction in memory can be significant, and the
quarter-wave trick isn't obvious to some people so I didn't make the
assumption that it was.

You're welcome.

Yes, a four fold reduction in size can be useful, but like I said, this
is sine table 101.

Was there anything else of value you have to offer on the topic?

You can go back and see what's valuable to you, and I can't anticipate
what will or won't be. You seem to resent having the quarter-wave
trick pointed out to you, so I'm not going to try to guess what you
might or might not find obvious. One of the nice things about usenet
is that the posts a pretty sticky, so you can go back and review if
you want to and take or leave things as you see fit.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

 

[rickman]

On 12/26/2014 1:15 PM, Eric Jacobsen wrote:

On Fri, 26 Dec 2014 12:05:24 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/26/2014 11:45 AM, Eric Jacobsen wrote:
On Thu, 25 Dec 2014 18:08:54 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/25/2014 4:32 PM, Eric Jacobsen wrote:
On Thu, 25 Dec 2014 16:08:45 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/25/2014 3:56 PM, Eric Jacobsen wrote:
On Thu, 25 Dec 2014 11:56:15 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/25/2014 10:52 AM, Eric Jacobsen wrote:
On Tue, 23 Dec 2014 18:10:43 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/23/2014 4:48 PM, Eric Jacobsen wrote:
On Tue, 23 Dec 2014 11:06:39 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/23/2014 10:35 AM, Eric Jacobsen wrote:

Many applications don't need separate LUTs to get the required
performance, and even then, or even in the case of complex output, it
can be done without multipliers.

Care to elaborate on this? I'm not at all clear on how you make a LUT
based NCO without LUTs and unless you are using a very coarse
approximation, without multipliers.

Not sure what you're asking. You a need a LUT, but just one in many
cases. Having a dual-ported single LUT is easy in an FPGA and
usually in silicon as well.

What makes a multiplier necessary? I've never found the need, but my
apps are limited to comm.

Maybe we aren't on the same page. The multiplier is there for the fine
adjustment. If you are happy with some -60 or -80 dB spurs one LUT is
fine. But if you want better performance the single LUT approach
requires *very* large tables.

There are a lot of tricks that can be used to keep the table size
down. I've mentioned one already.

And what was that? You have made some 20 or more posts in this thread,
I don't feel like weeding through all of them to find this. Reading
back through this thread it seems like your posts are intended to be
mysterious rather than informative. Every one leaves enough unsaid that
more questions are needed.

I can't divulge trade secrets or proprietary information that doesn't
belong to me. I can, however, hint in directions of benefit. Take
it or leave it.

I have no idea what you are talking about. If you don't have anything
to say, why are you bothering to post?

Why do you care whether I post or not? Feel free to put me in your
kill file if you don't like my posts.

If you aren't interested in having a conversation, why do you bother to
type? Above you said you had already mentioned "one" method already.
Clearly that one is not a trade secret. Care to explain what method you
are referring to?

I did later in the same post.

What same post would that be? I'm not sure what "same" means since the
context is not clear.

The same one you were responding to at the time.

At this point it is pretty clear you are just playing with me and have
nothing to say.

I don't even recall the hints.
Or are you forbidden from pointing out what those are?

No, but it seems to me like unnecessary duplication. There are lots
of hints from multiple people scattered throughout the thread, as well
as in some of the literature mentioned previously.

Exactly, scattered in some 50 or so messages. If you have something to
say, why no say it instead of being so vague? Just tell me which
message you are referring to.

So you want me to go back and search through the thread for you? Are
you not capable of doing that? I'm not at all clear why you think
that I should do the search if you're the one that wants the
information.

I'm assuming that you might have more recollection of having made a
post than I do of reading it. I did a scan and I never saw any useful
comments on table reduction. Everything you posted seems to allude to
things but always shies away from actually giving any info.

I mentioned the quarter-wave reduction specifically multiple times.
Sorry you weren't able to glean anything. Not everybody does.

I just never read your post in this thread where you mentioned that.
That's why I pointed it out to someone who spoke of using the full wave.

You said you had already mentioned a way to reduce table size. What was
that?

One way is to store a quarter wave instead of a full cycle. I think
that was mentioned more than once, but here it is again just for you.

Thank you for the response.

Yes, that is table reduction 101. Anyone other than a newbie is aware
of that. I believe *I* was the one who in this thread pointed it out to
someone who said memory is cheap not fully appreciating that memory is
order 2^N is size. Even so it is just a factor of four and does nothing
to change the fact that memory is anything but cheap if you are looking
for high resolution and low distortion. Using MBs of memory to store a
LUT is usually not a good trade off.

What was the technique *you* mentioned as you indicate above?

That was one of them. I mentioned it more than once. In my
experience a 4x reduction in memory can be significant, and the
quarter-wave trick isn't obvious to some people so I didn't make the
assumption that it was.

You're welcome.

Yes, a four fold reduction in size can be useful, but like I said, this
is sine table 101.

Was there anything else of value you have to offer on the topic?

You can go back and see what's valuable to you, and I can't anticipate
what will or won't be. You seem to resent having the quarter-wave
trick pointed out to you, so I'm not going to try to guess what you
might or might not find obvious. One of the nice things about usenet
is that the posts a pretty sticky, so you can go back and review if
you want to and take or leave things as you see fit.

I have read your posts here and I didn't see you mention the quarter
wave table or anything else specific. Rather you gave thin references
to the fact that "significant" reductions are possible. That's why I
asked and so far you have not been able to explain what you meant or
point to a post. You just keep repeating that you have already said
things. Ok, nuff said.

--

Rick

 

[Bart Fox]

> So where are the places where the CORDIC makes sense?
rickman,
You are annoying with your posts.

Use your imagination.
Nearly every calculator use cordic instead of LUT for trigonometric
functions. Why?
(Please don't answer, it's a rhetorical question.)

Bart

 

[rickman]

On 12/27/2014 4:33 AM, Bart Fox wrote:

So where are the places where the CORDIC makes sense?
rickman,
You are annoying with your posts.

Use your imagination.
Nearly every calculator use cordic instead of LUT for trigonometric
functions. Why?
(Please don't answer, it's a rhetorical question.)

I don't get your post. You say my questions are annoying, and then you
ask a "rhetorical" question as if I am supposed to know the answer. If
I knew the answer, I wouldn't be asking the question myself.

--

Rick

 

[Eric Jacobsen]

On Sat, 27 Dec 2014 01:35:55 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/26/2014 1:15 PM, Eric Jacobsen wrote:
On Fri, 26 Dec 2014 12:05:24 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/26/2014 11:45 AM, Eric Jacobsen wrote:
On Thu, 25 Dec 2014 18:08:54 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/25/2014 4:32 PM, Eric Jacobsen wrote:
On Thu, 25 Dec 2014 16:08:45 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/25/2014 3:56 PM, Eric Jacobsen wrote:
On Thu, 25 Dec 2014 11:56:15 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/25/2014 10:52 AM, Eric Jacobsen wrote:
On Tue, 23 Dec 2014 18:10:43 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/23/2014 4:48 PM, Eric Jacobsen wrote:
On Tue, 23 Dec 2014 11:06:39 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/23/2014 10:35 AM, Eric Jacobsen wrote:

Many applications don't need separate LUTs to get the required
performance, and even then, or even in the case of complex output, it
can be done without multipliers.

Care to elaborate on this? I'm not at all clear on how you make a LUT
based NCO without LUTs and unless you are using a very coarse
approximation, without multipliers.

Not sure what you're asking. You a need a LUT, but just one in many
cases. Having a dual-ported single LUT is easy in an FPGA and
usually in silicon as well.

What makes a multiplier necessary? I've never found the need, but my
apps are limited to comm.

Maybe we aren't on the same page. The multiplier is there for the fine
adjustment. If you are happy with some -60 or -80 dB spurs one LUT is
fine. But if you want better performance the single LUT approach
requires *very* large tables.

There are a lot of tricks that can be used to keep the table size
down. I've mentioned one already.

And what was that? You have made some 20 or more posts in this thread,
I don't feel like weeding through all of them to find this. Reading
back through this thread it seems like your posts are intended to be
mysterious rather than informative. Every one leaves enough unsaid that
more questions are needed.

I can't divulge trade secrets or proprietary information that doesn't
belong to me. I can, however, hint in directions of benefit. Take
it or leave it.

I have no idea what you are talking about. If you don't have anything
to say, why are you bothering to post?

Why do you care whether I post or not? Feel free to put me in your
kill file if you don't like my posts.

If you aren't interested in having a conversation, why do you bother to
type? Above you said you had already mentioned "one" method already.
Clearly that one is not a trade secret. Care to explain what method you
are referring to?

I did later in the same post.

What same post would that be? I'm not sure what "same" means since the
context is not clear.

The same one you were responding to at the time.

At this point it is pretty clear you are just playing with me and have
nothing to say.

No, seriously, it was in the same post. I found it ironic that you
were asking me to explain the method I was referring to, and I had
explained in the post you were responding to at the time.

I don't even recall the hints.
Or are you forbidden from pointing out what those are?

No, but it seems to me like unnecessary duplication. There are lots
of hints from multiple people scattered throughout the thread, as well
as in some of the literature mentioned previously.

Exactly, scattered in some 50 or so messages. If you have something to
say, why no say it instead of being so vague? Just tell me which
message you are referring to.

So you want me to go back and search through the thread for you? Are
you not capable of doing that? I'm not at all clear why you think
that I should do the search if you're the one that wants the
information.

I'm assuming that you might have more recollection of having made a
post than I do of reading it. I did a scan and I never saw any useful
comments on table reduction. Everything you posted seems to allude to
things but always shies away from actually giving any info.

I mentioned the quarter-wave reduction specifically multiple times.
Sorry you weren't able to glean anything. Not everybody does.

I just never read your post in this thread where you mentioned that.
That's why I pointed it out to someone who spoke of using the full wave.

You said you had already mentioned a way to reduce table size. What was
that?

One way is to store a quarter wave instead of a full cycle. I think
that was mentioned more than once, but here it is again just for you.

Thank you for the response.

Yes, that is table reduction 101. Anyone other than a newbie is aware
of that. I believe *I* was the one who in this thread pointed it out to
someone who said memory is cheap not fully appreciating that memory is
order 2^N is size. Even so it is just a factor of four and does nothing
to change the fact that memory is anything but cheap if you are looking
for high resolution and low distortion. Using MBs of memory to store a
LUT is usually not a good trade off.

What was the technique *you* mentioned as you indicate above?

That was one of them. I mentioned it more than once. In my
experience a 4x reduction in memory can be significant, and the
quarter-wave trick isn't obvious to some people so I didn't make the
assumption that it was.

You're welcome.

Yes, a four fold reduction in size can be useful, but like I said, this
is sine table 101.

Was there anything else of value you have to offer on the topic?

You can go back and see what's valuable to you, and I can't anticipate
what will or won't be. You seem to resent having the quarter-wave
trick pointed out to you, so I'm not going to try to guess what you
might or might not find obvious. One of the nice things about usenet
is that the posts a pretty sticky, so you can go back and review if
you want to and take or leave things as you see fit.

I have read your posts here and I didn't see you mention the quarter
wave table or anything else specific. Rather you gave thin references
to the fact that "significant" reductions are possible. That's why I
asked and so far you have not been able to explain what you meant or
point to a post. You just keep repeating that you have already said
things. Ok, nuff said.

I've mentioned several techniques for improving DDS performance
specifically. I didn't go into a lot of detail, but I mentioned a
number of things pretty unambiguously, both before and after the
thread started cross-posting. Maybe you just didn't see them.

I use Forte newsreader, and there's not a simple way to go back and
search which posts in a thread contained what, even if I posted it.
I'm not inclined to do that for you. Sorry. It's there if you, or
anybody, want to look, though.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

 

[rickman]

On 12/27/2014 11:33 AM, Eric Jacobsen wrote:

On Sat, 27 Dec 2014 01:35:55 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/26/2014 1:15 PM, Eric Jacobsen wrote:
On Fri, 26 Dec 2014 12:05:24 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/26/2014 11:45 AM, Eric Jacobsen wrote:
On Thu, 25 Dec 2014 18:08:54 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/25/2014 4:32 PM, Eric Jacobsen wrote:
On Thu, 25 Dec 2014 16:08:45 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/25/2014 3:56 PM, Eric Jacobsen wrote:
On Thu, 25 Dec 2014 11:56:15 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/25/2014 10:52 AM, Eric Jacobsen wrote:
On Tue, 23 Dec 2014 18:10:43 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/23/2014 4:48 PM, Eric Jacobsen wrote:
On Tue, 23 Dec 2014 11:06:39 -0500, rickman <gnuarm@gmail.com> wrote:

On 12/23/2014 10:35 AM, Eric Jacobsen wrote:

Many applications don't need separate LUTs to get the required
performance, and even then, or even in the case of complex output, it
can be done without multipliers.

Care to elaborate on this? I'm not at all clear on how you make a LUT
based NCO without LUTs and unless you are using a very coarse
approximation, without multipliers.

Not sure what you're asking. You a need a LUT, but just one in many
cases. Having a dual-ported single LUT is easy in an FPGA and
usually in silicon as well.

What makes a multiplier necessary? I've never found the need, but my
apps are limited to comm.

Maybe we aren't on the same page. The multiplier is there for the fine
adjustment. If you are happy with some -60 or -80 dB spurs one LUT is
fine. But if you want better performance the single LUT approach
requires *very* large tables.

There are a lot of tricks that can be used to keep the table size
down. I've mentioned one already.

And what was that? You have made some 20 or more posts in this thread,
I don't feel like weeding through all of them to find this. Reading
back through this thread it seems like your posts are intended to be
mysterious rather than informative. Every one leaves enough unsaid that
more questions are needed.

I can't divulge trade secrets or proprietary information that doesn't
belong to me. I can, however, hint in directions of benefit. Take
it or leave it.

I have no idea what you are talking about. If you don't have anything
to say, why are you bothering to post?

Why do you care whether I post or not? Feel free to put me in your
kill file if you don't like my posts.

If you aren't interested in having a conversation, why do you bother to
type? Above you said you had already mentioned "one" method already.
Clearly that one is not a trade secret. Care to explain what method you
are referring to?

I did later in the same post.

What same post would that be? I'm not sure what "same" means since the
context is not clear.

The same one you were responding to at the time.

At this point it is pretty clear you are just playing with me and have
nothing to say.

No, seriously, it was in the same post. I found it ironic that you
were asking me to explain the method I was referring to, and I had
explained in the post you were responding to at the time.

I have no idea which post you are referring to. Context is long lost
and you keep saying the "same post".

I don't even recall the hints.
Or are you forbidden from pointing out what those are?

No, but it seems to me like unnecessary duplication. There are lots
of hints from multiple people scattered throughout the thread, as well
as in some of the literature mentioned previously.

Exactly, scattered in some 50 or so messages. If you have something to
say, why no say it instead of being so vague? Just tell me which
message you are referring to.

So you want me to go back and search through the thread for you? Are
you not capable of doing that? I'm not at all clear why you think
that I should do the search if you're the one that wants the
information.

I'm assuming that you might have more recollection of having made a
post than I do of reading it. I did a scan and I never saw any useful
comments on table reduction. Everything you posted seems to allude to
things but always shies away from actually giving any info.

I mentioned the quarter-wave reduction specifically multiple times.
Sorry you weren't able to glean anything. Not everybody does.

I just never read your post in this thread where you mentioned that.
That's why I pointed it out to someone who spoke of using the full wave.

You said you had already mentioned a way to reduce table size. What was
that?

One way is to store a quarter wave instead of a full cycle. I think
that was mentioned more than once, but here it is again just for you.

Thank you for the response.

Yes, that is table reduction 101. Anyone other than a newbie is aware
of that. I believe *I* was the one who in this thread pointed it out to
someone who said memory is cheap not fully appreciating that memory is
order 2^N is size. Even so it is just a factor of four and does nothing
to change the fact that memory is anything but cheap if you are looking
for high resolution and low distortion. Using MBs of memory to store a
LUT is usually not a good trade off.

What was the technique *you* mentioned as you indicate above?

That was one of them. I mentioned it more than once. In my
experience a 4x reduction in memory can be significant, and the
quarter-wave trick isn't obvious to some people so I didn't make the
assumption that it was.

You're welcome.

Yes, a four fold reduction in size can be useful, but like I said, this
is sine table 101.

Was there anything else of value you have to offer on the topic?

You can go back and see what's valuable to you, and I can't anticipate
what will or won't be. You seem to resent having the quarter-wave
trick pointed out to you, so I'm not going to try to guess what you
might or might not find obvious. One of the nice things about usenet
is that the posts a pretty sticky, so you can go back and review if
you want to and take or leave things as you see fit.

I have read your posts here and I didn't see you mention the quarter
wave table or anything else specific. Rather you gave thin references
to the fact that "significant" reductions are possible. That's why I
asked and so far you have not been able to explain what you meant or
point to a post. You just keep repeating that you have already said
things. Ok, nuff said.

I've mentioned several techniques for improving DDS performance
specifically. I didn't go into a lot of detail, but I mentioned a
number of things pretty unambiguously, both before and after the
thread started cross-posting. Maybe you just didn't see them.

I use Forte newsreader, and there's not a simple way to go back and
search which posts in a thread contained what, even if I posted it.
I'm not inclined to do that for you. Sorry. It's there if you, or
anybody, want to look, though.

Yes, it's there... on the Internet. Anyone can find that!

--

Rick