vrf Chord Programming

Hi Al,
      There are several solutions I could think of depending on your
requirements including timing resolution and accuracy such as

data acqusition card constantly running and monitoring the level

data acquisition unit ( such as the Agilent 34970 ) which time-stamps data
as it is acquired

Mike Watts

_______________________________________________________________________

  Michael Watts, Consultant                                 PO Box 92
  on the web: www.PreciselySo.Co.UK                      Exeter,Devon
  e-mail: MJWC@PreciselySo.Co.UK                              England     
  tel: +44 7714 339 729                                       EX4 2YY
_______________________________________________________________________

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@agilent.com". 
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

Hi vrf... a weird test related problem this...

I need to find the actual time that a pulse goes high on a scope.

(eg, the pulse went high at 10:24.32pm)

the propogation delay between scope, gpib, vee and the PC would be too
long, so essentially I need to know if anyone knows of a scope (or any
other piece of equipment) which will log the actual time of a pulse
occuring..

Any suggestions wouldbe gratefully received...

Al.


---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@agilent.com". 
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

> I don't think he devoted enough cycles to your original post.

Now there's a first, aye?

> but how to continue it on to the next step

Yup - he explained that after I didn't catch on at first.

> The odds of choosing an unused index gets extremely slim
> towards the end of the selection cycle for a large array.

Exactly. Many thanks for carrying it on.

A friend of mine does almost exactly the same sort of thing for gaming
machines. The odds of winning prize x must comply with local law (so it's
not a rip-off), while still maintaining profitability for the game owner.
It's not an easy line to walk!

> If anyone knows a better way to do this, preferably without
> a loop, please chime in.

Another item on the to do list! God that list is long. This really is a
great first VEE programming project. The solutions get better and better the
farther you take it.

> but look at the support you have available on the VRF! 

AAMOF, he explicitly mentioned that: "I'm now a believer in VRF." It's
really great to be able to turn to this huge room full of experts of all
kinds and say, "you know, I'm sure this bit here isn't quite right..."
-SHAWN-



---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@agilent.com". 
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

> I don't think he devoted enough cycles to your original post.

Now there's a first, aye?

> but how to continue it on to the next step

Yup - he explained that after I didn't catch on at first.

> The odds of choosing an unused index gets extremely slim
> towards the end of the selection cycle for a large array.

Exactly. Many thanks for carrying it on.

A friend of mine does almost exactly the same sort of thing for gaming
machines. The odds of winning prize x must comply with local law (so it's
not a rip-off), while still maintaining profitability for the game owner.
It's not an easy line to walk!

> If anyone knows a better way to do this, preferably without
> a loop, please chime in.

Another item on the to do list! God that list is long. This really is a
great first VEE programming project. The solutions get better and better the
farther you take it.

> but look at the support you have available on the VRF! 

AAMOF, he explicitly mentioned that: "I'm now a believer in VRF." It's
really great to be able to turn to this huge room full of experts of all
kinds and say, "you know, I'm sure this bit here isn't quite right..."
-SHAWN-



---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@agilent.com". 
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

This sounds like one of those np hard problems given the number of chords
may get larger and larger, but I think this is finite although hard.  Any
way, given a finite set of chords you may test the set for the following:

The chord can be ordered, that is, you can sort them by a size criteria.
You could enumerate over the notes and the string length, something like
that.

If they can be ordered then it is possible to define a distance between
each.

If it is possible to develop a mathematic that can map the set onto the
integers, note ONTO, would greatly simplify.  Then you could just randomize
a set of integers.

At any rate you could save the set of chords within a set, choose a random
distance, say from the smallest to the largest, pick the nearest chord that
is a member of the set, use it, delete it from the set and continue, if the
chord is not a member then continue.  Note you could also switch among
nearest, next larger, or previous smaller, etc.

So define a way to define the distance of one chord from another.  This way
you pick from a point within the set and you randomize the point locater.
This will also work for multiple dimensions.


Rufus

-----Original Message-----
From: Mike Groves [mailto:mike@grovesnet.org]
Sent: Thursday, January 27, 2005 8:07 AM
To: VRF
Subject: [vrf] RE: Chord Programming

Greetings Jeff and welcome to the world of VEE!

In Shawn's multitasked lifestyle, I don't think he devoted enough cycles to
your original post. I think your question wasn't how to get your example
program running, but how to continue it on to the next step, which involves
the random selection of chords out of a large array of possibilities, until
they have all been selected.

There are certainly many ways to tackle any problem, but I do not think you
want to randomly select entries out of an array, keep track of which ones
have been used, and reject any that have been selected before, in hopes of
eventually selecting every element of the array. The odds of choosing an
unused index gets extremely slim towards the end of the selection cycle for
a large array.

Here's my approach to your problem. I created an array out of a linear ramp
of integers (like you did) then performed a sort using a random set of reals
that were linked to the original integers. I did this using Coords. "X"
coordinate held the integer array, and the "Y" held the random reals.
After sorting on the "Y" coordinate, the "X" was extracted only now they are
in a random order. Basically, it is just a random permutation of 1:N. (If
anyone knows a better way to do this, preferably without a loop, please
chime in.)

On a side note, the help files in MATLAB describe a thingy called RandPerm
that does EXACTLY what I want. The problem is, it's not available in the
function selector and if you try to use it in VEE it complains it doesn't
recognize it.
So why is it in the help files??

Back to the problem at hand.  Once the array was shuffled, you could just
deal from the top of the deck and solve for each chord in order, knowing A)
they are in a random order and B) you will never hit a duplicate. The only
problem is it takes a long time to randomize a very large array using a loop
to create the set of random reals. I don't know any other way, but once it's
created, the rest runs along with out any additional delays.

I setup the logging alphanumeric display to better observe the results.
Removing it will increase the execution speed in solving for chords. Of
course, what you do with the set of chords you end up with is up to you.

I hope this helps. As you will find out, there are LOTS of ways to program
VEE. Everyone eventually will find a style that works for them. My programs
tend to be on the minimal side, but you do it the way you are comfortable.
Mastering VEE will certainly take some time, but look at the support you
have available on the VRF! 

Cheers,
Mike Groves


-----Original Message-----
From: J R [mailto:logicofwings@yahoo.com]
Sent: Tuesday, January 25, 2005 7:07 PM
To: VRF
Subject: [vrf] Chord Programming


Hi all -

I'm a newbie to VRF and VEE Pro in general, so I was wondering if any of you
out there would be willing to take the time to show me the error of my ways?

I'm working on a program for a research foundation that will parse 'chords'
and play them randomly from a pool without repeating the same ones until all
possibilities are exhausted. The part I'm having trouble with is the "A[R] =
A[N]" formula that would supposedly keep the same combinations from coming
up repeatedly; where does it go, and how do you keep the errors from
appearing? The program is attached, so you may freely open it and look under
the hood. Feel free to send a corrected version back if you like (might be
easier on you than a lengthy explanation, though a little of that, too,
would help - I am interested in mastering VEE above all else.)

If anyone can help out, I'd be most appreciative.
Thanks much in advance,


Jess Rhodes
AERA



---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@agilent.com". 
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

Thanks Warren! I tried different combinations of randomizing an
entire array, but somehow missed that. That definitely executes
much faster than looping. VRF to the rescue!

Another way to approach this would be to solve for the entire
set of available chords and store them in an array, then recall
one at a time in a pseudo random order. This would take more time
and memory up front, but you could play each chord a little faster
than solving for them on the fly. All depends on what you intend
to do with the random chords and how quickly you need each one.

(I just hope this wasn't a college homework assignment that we
just collectively cranked out a solution for. <wink> I seem to
recall a similar problem coming across the VRF many years ago.)

Cheers,
Mike

BTW, anyone figure out why RandPerm (and other functions) are
available in the MATLAB help section, but are not available to
be used in VEE? Is this perhaps the MATLAB Function Reference
from the full version and not just VEE's subset of functions?

-----Original Message-----
From: Pickles, Warren [mailto:Warren.Pickles@tycoelectronics.com]
Sent: Thursday, January 27, 2005 6:31 AM
To: VRF
Subject: [vrf] RE: Chord Programming


Instead of randomizing the array using a loop, try VEE's
randomize(x,low,high) function. 

> The only problem is
> it takes a long time to randomize a very large array using
> a loop to create the set of random reals. I don't know any
> other way, but once it's created, the rest runs along with
> out any additional delays.



---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@agilent.com". 
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".