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".
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".
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".