Re: metacard Digest, Vol 69, Issue 1
Me too. Well, actually, 100%. I never use the Rev IDE to program in. Indeed, the only thing I use it for is to execute Jacqueline's metacard_setup stack to licence the engine for MC IDE! On 6-Oct-09, at 11:00 AM, metacard-requ...@lists.runrev.com wrote: For a number of - maybe very personal - reasons I do roughly 95 % percent of my development in the Metacard IDE. Wilhelm Sanke -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
RE: Still here
I, too, prefer the MC IDE, as do the students in the lab, despite my best efforts to get them to start with the Rev IDE (assuming that they will prefer what they first learn, and that my preference is the bias of my original MC learning). Nope, within a few months, I find them using the MC IDE. When I ask why, the response is typically along the lines of that quoted below: it doesn't get in your way. Of course, we rarely build standalones, although that may change as revlets take off. On 18-Aug-09, at 11:00 AM, metacard-requ...@lists.runrev.com wrote: You are not alone in your preference, Shari. I'm sure that the Rev IDE is very clever (and I still use it to build standalones); I just like the an IDE that doesn't mess with the engine, customPropertySets and my head. /H -Original Message- Still here. Still prefer the MC IDE. Had to reinstall it from scratch and for a minute thought I was going to have to post a Help Me but finally figured it out and am up and running again. Thank you that we still have the choice! Shari -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: metacard Digest, Vol 61, Issue 2
Same on Mac OS X On 2-Nov-08, at 11:00 AM, [EMAIL PROTECTED] wrote: Send metacard mailing list submissions to metacard@lists.runrev.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.runrev.com/mailman/listinfo/metacard or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of metacard digest... This is the Metacard mailing list. Today's Topics: 1. Re: MC IDE 3.0 (Hugh Senior) -- Message: 1 Date: Sat, 1 Nov 2008 18:43:04 - From: Hugh Senior [EMAIL PROTECTED] Subject: Re: MC IDE 3.0 To: metacard@lists.runrev.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Thank you, Klaus. Anyone else noticed that their script editor fontSize keeps reverting back to 13 under win32? Perhaps resolved in v3.0.0 /H I just uploaded the new MC IDE 3.0! -- ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard End of metacard Digest, Vol 61, Issue 2 *** ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Just too strange
Metacardians, This is just so strange. Metacard IDE version: 2.8.4, Engine version 2.8.1, Build number 470. Leopard (OS X 10.5) on a dual-intel Macbook. All buttons, etc. of the IDE look normal (i.e., rounded-3D), and the defaults have the throbbing blue. As do pre-created buttons in my stacks. If I copy and paste an existing standard, defaulted button, it retains its throbbing blue rounded shape. But, I can't *create* any such buttons---they always come out as rectangles with no blue throbbing. Clicking on those that already were and the new ones I try to create show identical properties across the board for both. How can this be? The Rev IDE shows no such strange behaviour. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -Dr. John R. Vokey ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
metacard IDE devotees
The recent discussion over one user's less than happy switch to the Rev IDE from that of Metacard leads me to add my little bit of history. I have tried and tried the Rev IDE, and even beta-tested for the original (see the lengthy thank-you list in Rev), and I have praised Runtime Revolution to all and sundry, such that many if not all of my colleagues now own licences, as do all of my ex-students (who use nothing else). But, I use the MC IDE, even when they, especially my students, do not. They, especially my students, consider me to be an IDE curmudgeon, and they may be right, but I just don't ``grok'' the Rev interface. Mind you, I complained bitterly about the original MC IDE when it didn't adhere strictly to the HC interface, so you can see my general take on things (indeed, on the few occasions when I do still whip something up in HC---it is like coming home: perfect in every way, except oddly smaller). I also purchased at least one of the other IDEs, and had the same feeling of too much sh..., er, too many windows and palettes and menus and clicks and who knows what for little gain. So, for Klaus and Richard and all the other devotees and maintainers of the MC IDE, I thank you, thank you, thank you. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -Dr. John R. Vokey ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: metacard Digest, Vol 36, Issue 17
As a Canadian Scot, I take serious offence at this comment: Bagpipes by definition are always in tune; it is the ignorant listeners who aren't. Besides, I heard the Romans left because of the advent of the accordian... Now, as a one time player of same, that is an instrument deserving of opprobrium. On 21-Sep-06, at 9:20 PM, [EMAIL PROTECTED] wrote: I also read somehwere that the Romans introduced the bagpipes to Scotland, but left before they taught people how to tune them. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -Dr. John R. Vokey ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Auto MC setup stuff
Sorry, Richard, I did mean to reply in the affirmative: a one-click solution for setting up MC would be welcome. On 31-Aug-06, at 11:00 AM, [EMAIL PROTECTED] wrote: It would be interesting to learn of anything you find there that's attractive. MC is getting old, and the more they make radical changes to the engine the harder it is to set up. We can easily fix the setup stuff, but as my last question here was asking who wants a simpler setup and it went unreplied perhaps there's my answer on how much interest there is in this at all. Then again, we read of many complaints about the Rev IDE on the main list, and Galaxy/Consellation has quite a few followers, so it would seem there would be room for an open source alternative -- maybe. Rev-based IDEs address an ultra-tiny market that's already fragmented as it is. I still can't get much work done in Rev, and I hear most of my clients curse as they use it, but if there's only three or four of us still using MC it does rather raise questions about the effort. I keep trying Rev, and I always end up back in MC for any real work. Undoubtedly, at least some of my discomfort with Rev and preference for MC is simple familiarity differences, but I suspect are large part is general preference for simplicity and ``less is more''. But then, I don't build standalones, I just create and use stacks where the integration of the IDE and the stacks is paramount. ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: The Microsoft office approach to xTalk programming
Funny! BTW, although `Vokey' is an old English name (and unduly common in Newfoundland), my mother was a Scot, but she only tried make her children eat haggis *once*. We all survived, although memory of the experience still gives me shivers. I still think, however, that the RR interface violates the Scottish engineering tradition (which, as we all know, could repair a starship with two sticks, a rock, and expletives with a heavy burr), and would offend the likes of my dead, Glaswegian grandfather! ;-) On Nov 18, 2003, at 10:00 AM, [EMAIL PROTECTED] wrote: Luckily for us the people at RR eat their own haggis rather than Microsoft's standardised, slightly inferior oven-ready version - and, what is more, they do allow us to muck around with a considerable amount of the haggis: which, frankly, most companies (including Uncle Bill's) won't let us do without slapping legal injunctions on us and so forth. -- John R. Vokey ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MetaCard/Revolution Evangelism
I agree wholeheartedly with everything Wilhelm Sanke wrote in his recent post about the functionality of MC vs. RR. I, too, still use MC preferentially, as do my colleagues and students. Its interface is clean, fast, and easily extensible. In contrast, RR is cluttered, confusing and slow, and less easily modified (without breaking something else). I know that it is improving in the sense that many bugs have been fixed and slow code accelerated, but I still think the whole interface needs a rethink. It currently has more in common with MS Word and Photoshop than hypercard---and that is not a compliment. I am also appalled that certain aspects of the code (e.g., standalone builder) are ``protected''---that's anathema for xTalks. Don't misunderstand me here: I still proselytise MC/RR, and will continue to do so. I just find many of the current directions (e.g., the loss of the starter kit, ``protected'' code) ominous. -- John ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
indexing slow-down (i.e., speeding up programs)
Here's my task: I've got two LARGE text files, one a spelling dictionary (from Excalibur) and the other a dictionary of lexical frequencies (i.w., item and frequency); there over 113,000 unique words (as lines) in the first, and about a million different entries (as separate lines) in the second, many not regular words (e.g., dates, numbers, etc.); furthermore, in the second, the same word is listed multiple times depending on use (e.g., ``rose'' as a noun and ``rose'' as a verb). I want to extract the lexical frequency (ignoring use type) of each of the words in the first from the second, including assigning a frequency of zero for those from the first not found in the second. Fortunately, both are already alphabetised, so as I move sequentially through the first, I can simply start searching from where I last left off in the second, summing over multiple use listings of the same word. So far so good. I use the ``repeat for each ... in ... '' construct for the first dictionary, and a variable pointer for the second that I advance as I find each word from the first (I call a simple function that skips over non-words and advances the pointer, returning the line of the next word in the lexical dictionary). Both text files are read into memory at the start of the routine (which takes less than a second using the'' url file://...'' command (way to go, metacard!). Here's my problem: initially, the routine takes much less than 1 second per hundred words (which, when multiplied by the number of words remaining to index, results in an estimate of some small fraction of an hour to do the whole task). However, it rapidly (as an exponential function) slows down, so that by the time it reaches the middle of the alphabet (M), it takes many minutes per 100 words, and an ever-increasing time estimate for the remaining items (now over 60 hours!). Clearly, either the ``repeat for each'' command for the first dictionary or the ``get line pointer...'' for the second (or both) get(s) slower and slower as I progress through the dictionaries, presumably because to do one or the other (or both), metacard counts carriage returns from the beginning of the dictionary. I've tried: deleting the items from the front of the lexical dictionary as I've searched them, so that each new search starts at line 1 of the edited list [i.e., put line pointer to (the number of lines of dict2) of dict2 into dict2)], but that slows it down even more (presumably because metacard needs to count crs to find the number of the last line each time). I've tried various machinations of offset(,,skip) using the skip variable as an absolute pointer, but it also appeared to make things slower presumably because it counts chars from the start of the dictionary. I guess I could divide dict2 (or dict1) into many small segments, moving to each successive segment as the previous one was exhausted, but I was hoping for something more elegant. What I need are *absolute* pointers (preferably a memory address, or a pointer or a handle to such), rather than the relative (to the beginning of the list) pointers given by the line (and possibly ``for each'') construct. Arrays presumably would work (but doesn't metacard then have to search the indices to resolve the array reference?), and reading the million length file into the array just sets the problem back one step. Any suggestions would be appreciated. As I receive the list in digest form, if you have a scathingly brilliant idea, please send a copy of it directly to my email address. TIA -- John R. Vokey, Ph.D. |\ _,,,---,,_ Professor /,`.-'`'-. ;-;;,_ Department of Psychology and Neuroscience |,4- ) )-,_. ,\ ( `'-' University of Lethbridge '---''(_/--' `-'\_) ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: metacard digest, Vol 1 #552 - 2 msgs
On Tuesday, March 18, 2003, at 10:03 AM, WA wrote: Hi again, If Mr J. Vokey is right about the permutations Mr E. Engle really wants then things could have looked like this: on mousUp put perm(fld in) into fld out end mouseUp function perm factors put the length of factors into x put char 2 to -1 of (10 ^ x) into a repeat with i = 1 to 2 ^ x - 1 put baseConvert(i, 10, 2) into b put char 1 to x - the num of chars in b of a b into b repeat with j = 1 to x if char j of b = 1 then put char j of factors after thecollector end repeat put thecollector cr after theresult put into thecollector end repeat sort theresult sort lines of theresult by number of chars in each return theresult end perm Have a nice night, WA I like it: nice use of the decimal to binary conversion to implement my algorithm (i.e., 1/0 flags to indicate presence/absence of a given letter). Unfortunately, as with my version, it is not recursive, as was originally asked for. Furthermore, it requires the baseConvert function, not available in most other XTalks, including hypertalk, and it was in the hypercard list that I first saw the request. -- John R. Vokey, Ph.D. |\ _,,,---,,_ Professor /,`.-'`'-. ;-;;,_ Department of Psychology and Neuroscience |,4- ) )-,_. ,\ ( `'-' University of Lethbridge '---''(_/--' `-'\_) ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
That find command
All, I'm baffled. I know other commands, such as offset, are faster and more useful, but I was trying to use the metacard (2.4.3, Mac OS X 10.2.3) find command and discovered that for some reason it doesn't work, or at least I can't get it to work. I finally stripped it down to a simple stack with two fields, test and out, with test containing 3 lines consisting of, respectively, , , and . Executing the following simple stack script from the message box (using any of the variations, including string) fails to work (i.e., nothing but the return is placed in the field out). on testit find in fld test put the foundline into fld out find string in fld test put return the foundline into fld out end testit Worse yet, I started this failed exploration, after a colleague reported to me that successive finds in a script would only search *forward*. For example, although find , followed by find , would (in his stack on his computer) successfully find both, find followed by find would find only . I said he was nuts, and began the experiment that resulted, eventually, in the simple failed test above. Any ideas? -- John R. Vokey, Ph.D. |\ _,,,---,,_ Professor /,`.-'`'-. ;-;;,_ Department of Psychology and Neuroscience |,4- ) )-,_. ,\ ( `'-' University of Lethbridge '---''(_/--' `-'\_) ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: the large file challenge
To be fair: most of metacard is coded in metatalk; it is a boot-strapped language, much like many of the TILs (threaded interpreted languages) of yesteryears (e.g., forth, apl). On Thursday, November 14, 2002, at 10:01 AM, [EMAIL PROTECTED] wrote: | MC, as well, is also coded in C, so in many interpreted languages (bash, | perl, MC) while the script itself is interpreted, much of the real work is | done by compiled code. -- John R. Vokey ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: metacard digest, Vol 1 #80 - 4 msgs
Thanks Philip. That indeed does seem to be the problem. Thanks for the suggested fix as well. On Sunday, January 27, 2002, at 10:12 AM, Philip Chumbley wrote: To illustrate the situation in one dimension, if a line is 99 pixels wide, its centerpoint is at 50 with 49 pixels before and 49 pixels after the centerpoint. But if the line is 100 pixels wide, the centerpoint is actually at 50 1/2. Since you can't center the line on a half pixel, the line would be shifted slightly right or left from true center (depending whether you round up or truncate the number) so the image is now offset. If you now make the line 99 pixels wide again it will stay centered in the same place but switching it back to 100 pixels wide again will shift it once again. If the half-way points are rounded up (ie. 50 1/2 -- 51), the effect would be that a line would drift to the left or an image to the upper left. To correct for that, simply read the location of the first image into a variable (oldLoc) and include a line saying: set the loc of image myImage to oldLoc after setting the filename. Be aware that you may see the image jump slightly. If that is unacceptable, make the image invisible, set the fileName to the new name, set the loc to the oldLoc , and then make it visible. In my application I use two images. While viewing one, I set the file name of the invisible one and reposition it and then hide one and show the other. Hope this helps. Philip Chumbley -- John R. Vokey, Ph.D. |\ _,,,---,,_ Professor /,`.-'`'-. ;-;;,_ Department of Psychology and Neuroscience |,4- ) )-,_. ,\ ( `'-' University of Lethbridge '---''(_/--' `-'\_) ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Puzzling image drift
I have a stack that presents a series of disk-based images by replacing the file name of the image object on the card. The images are not the same size, and over images the object appears to drift up and to the left. As this effect does not happen with identically-sized images, I suspect it has something to do with how MC determines the location of new image when replacing the previous one of a different size. I had assumed that the loc (top-left) of an image object was fixed, and all subsequent images would be displayed using that loc, but apparently not. So, what gives? MC 2.4.1, Mac OS 10.1.2. John R. Vokey ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
[Metacard] capturing the return key in a field
Ok, I give up. What's the secret? This should be obvious and simple, but I can't get any of the alternatives to work. I have a simple field that collects responses when given the focus, and I want to prevent the user from typing a return into the field. However, none of keyDown, rawKeyDown, etc. seem to do it. In the ref stack, it is implied for all that all I have to do is *not* pass the key if it is return and all should be fine, but regardless of what I do ***even if I pass nothing from the handler*** a return is still entered into the field. What gives? For example, the handler in the field scipt: on rawKeyDown x end rawKeyDown *still* puts a return in the field! I am more than a little baffled, not to say frustrated. Metacard PPC 2.4. -- Life results from the non-random survival of randomly varying replicators. -- Richard Dawkins John R. Vokey ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
[Metacard] RE: capturing the return key in a field
Never mind. Re-starting metacard solved the problem, although I have no idea how that could possibly help. -- It has become almost a cliché to remark that nobody boasts of ignorance of literature, but it is socially acceptable to boast ignorance of science. -- Richard Dawkins John R. Vokey, Ph.D. Professor Department of Psychology and Neuroscience University of Lethbridge -- From: John Vokey [EMAIL PROTECTED] Date: Mon, 26 Nov 2001 15:04:11 -0700 To: [EMAIL PROTECTED] Subject: capturing the return key in a field Ok, I give up. What's the secret? This should be obvious and simple, but I can't get any of the alternatives to work. I have a simple field that collects responses when given the focus, and I want to prevent the user from typing a return into the field. However, none of keyDown, rawKeyDown, etc. seem to do it. In the ref stack, it is implied for all that all I have to do is *not* pass the key if it is return and all should be fine, but regardless of what I do ***even if I pass nothing from the handler*** a return is still entered into the field. What gives? For example, the handler in the field scipt: on rawKeyDown x end rawKeyDown *still* puts a return in the field! I am more than a little baffled, not to say frustrated. Metacard PPC 2.4. -- Life results from the non-random survival of randomly varying replicators. -- Richard Dawkins John R. Vokey ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Digest metacard.v004.n377
on 6/28/01 8:23 PM, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: member(commentTag).text=member(myParent.myComments).text.line[theLine] Do we love the dot notation, or do we not? ;-) Regards, Scott 'We' do not. At least, not me. I find it ugly and hard to read. -- 6. Stanislaus Smedley, a man always on the cutting edge of narcissism, was about to give his body and soul to a back alley sex change surgeon to become the woman he loved. -- Top 10 winner of the Bulwer Lytton Contest, wherein one writes only the first line of a bad novel. John R. Vokey, Ph.D. Chair (for 1 more day) Department of Psychology and Neuroscience University of Lethbridge Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Re: pointer tool - author mode
on 4/24/01 9:53 AM, Wilhelm Sanke at [EMAIL PROTECTED] wrote: What I am suggesting, however, is to have a static or author mode as a *normal standard feature* of Metacard that is available to anyone - even to a beginner that tries to find out how Metacard works by looking at the scripts of the demo stack. I am also suggesting to connect this feature with the pointer tool, so that it is automatically invoked each time you want to do some authoring, creating an object, changing a script etc. It is presumably more user-friendly to have to use one control instead of two (and having to look where in the menu the second control has been placed). I propose to combine the suppress messages button with the pointer tool in Revolution, too Such a feature request of course may not have first priority, but if there is no compelling reason against a combination of the pointer tool and an author mode, it could be realized. Regards, Wilhelm Sanke No. No. No. And, again, no. There should not be an author (a.k.a. edit) mode in MC. That was/is (at least one of) the major problems with Supercard. It violates the underlying metaphor: anything one does anywhere, anytime in MC (and hypercard) can generate messages that can (but need not) be responded to. So, even editing a script of an object is still just typing characters into a field of some stack --- as it should be. MC is modeless, as it should be. What's next, a clamour for separate edit, compile, link modes, and paper tape to save the programs on? -- 5. Although Sarah had an abnormal fear of mice, it did not keep her from eking out a living at a local pet store. -- Top 10 winner of the Bulwer Lytton Contest, wherein one writes only the first line of a bad novel. John R. Vokey, Ph.D. Chair Department of Psychology and Neuroscience University of Lethbridge Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Re: multiple regression [not metacard]
on 2/2/01 1:15 AM, [EMAIL PROTECTED] wrote: Regarding John's comments on multiple regression: 1. Matrix algebra is not necessary, and for purposes such as stepwise multiple linear regression will actually get in the way. -In your opinion, what type of statistics are better suited for matrix algebra? Multiple regression, ANOVA, ANCOVA, PCA, etc., where there is no stepwise selection of variables. 2. I have a little treatise I wrote on stepwise multiple linear regression in meta/hypercard, including the relevant meta/hypertalk code. -In this stack, you stated that the simple multiple regression routines used here are based on two simple, but elegant routines that are at the heart of virtually any multiple regression package commercially available: the recursive SSCP algorithm and the Sweep algorithm. As I understand , logistic regression is just a transformation of the dependent variable to the log odds ratio, after which the usual regression procedures are followed. Can your stack/routines be modified to perform logistic regression? ie. determine Coefficients and Standard Errors...Odds Ratios and 95% Confidence Intervals... In a word, yes, although I would preferentially use a maximum likelihood rather than a least-squares algorithm for logistic regression (i.e., multiway frequency analysis). mike -- "The danger in writing science fiction is that, like masturbation, if you do too much of it you may begin to mistake it for the real thing." -- Robert Park John R. Vokey, Ph.D. Chair Department of Psychology and Neuroscience University of Lethbridge Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Multiple Regression in meta/hypercard and meta/hypertalk
on 1/31/01 12:48 PM, [EMAIL PROTECTED] wrote: On 1/27/01, 9:15:22 AM, [EMAIL PROTECTED] wrote regarding Re: statistics: Does anyone have any Metatalk statistical functions to determine 1.correlation coefficients(Pearson and/or Spearman), 2.multiple and logistic regression? mike Pearson's, Spearman's, Point Biserials, and contingency correlation coefficients aren't too hard. Multiple regression will require someone with a working knowledge of matrix algebra on a lot of time on his or her hands, but it is doable within MetaTalk, though ou may be better off saving data in text format, then importing it into SPSS or SAS. If anyone is interested, I'll contribute my 2 cents. Pearson's, Spearman's, Point Biserials, and the contingency coefficient (for 2x2 tables) are all the same statistic: applying the standard Pearson cross-products formula to the data in each case will produce *exactly* the same result as would the special-case (computational convenience) formulae. Matrix algebra is not necessary, and for purposes such as stepwise multiple linear regression will actually get in the way. I have a little treatise I wrote on stepwise multiple linear regression in meta/hypercard, including the relevant meta/hypertalk code. An example mc stack containing it all may be downloaded from: http://home.uleth.ca/~vokey/software/regression.sit: -- "The sun oozed over the horizon, shoved aside darkness, crept along the greensward, and, with sickly fingers, pushed through the castle window, revealing the pillaged princess, hand at throat, crown asunder, gaping in frenzied horror at the sated, sodden amphibian lying beside her, disbelieving the magnitude of the frog's deception, screaming madly, "You lied!" -- Winner of the Bulwer Lytton Contest, wherein one writes only the first line of a bad novel. John R. Vokey, Ph.D. Chair Department of Psychology and Neuroscience University of Lethbridge Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Re: Digest metacard.v004.n086
on 11/29/00 8:59 AM, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: I just noticed I got infected by merryxmas and even know where from. Someone in the know or someone who knows someone in the know with these script viruses should definitely write a Vaccine for Metacard. The guy who sent me the infected stack should have warned me before not after! Regards, Andu I wish I had received *some* warning: everything on all my computers is/was infected with the merry xmas virus---including my back-up CDs. I don't *know* that it is from something I downloaded from people on this list, but I certainly suspect it! At any rate, I agree: let's produce a vaccine for metacard. -- John R. Vokey, Ph.D. Chair Department of Psychology and Neuroscience University of Lethbridge Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
built in matrix-algebra routines
on 11/17/00 1:50 AM, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: Scott Raney [EMAIL PROTECTED]wrote: I second the motion: we are already planning to add some features in this area for the next release and a list of the most useful matrix operations to have built in would be very handy for planning purposes. 1) matrix multiplication, inversion, transposition, addition, subtraction, normalize, but also commands to work arithmetically on elements, and to extract columns, rows, sort columns, rows, etc.. 2) eigendecomposition (i.e., eigenvalue and eigenvector extraction, as with the "eig" routine in Matlab)), and singular value decomposition (SVD). -- Tom Szasz once quipped [approximately]: When I talk to God, it's called prayer; but when God talks to me, it's called schizophrenia! John R. Vokey, Ph.D. Chair Department of Psychology and Neuroscience University of Lethbridge Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
matrix algebra and stats routines
Of all the matrix routines to be built-in, among the most useful would be the computation of eigenvectors and eigenvalues. Better yet, of course, would be generalised, singular value decomposition (SVD). With SVD and a good matrix inversion routine built-in, the remaining routines (and full, multivariate stats computations) could easily be coded as simple scripts without much of a performance hit. on 11/12/2000 4:28 PM, "Monte Goulding" [EMAIL PROTECTED] wrote: OK I'll sent the stats library as soon as I put it all together. MetaCard corp. has proved itself to me as a company that will do it's best to accomodate users requests so try emailing [EMAIL PROTECTED] if you have specific algorithmns you would like to see as part of the engine. PS It sounds like you won't be learning much about stats functions from me but the prob F approximation was pretty hard to find (most references to this function actualy calculate it the long way which is extremley complicated with only very minor improvements in accuracy. Regards Monte -- This was too good not to pass along... My wife recently gave an intro stat quiz which some questions on tables showing whether or not a convicted murder was given a death penalty, broken down by the race of the perpetrator and race of the victim (Data are on page 187 of Moore McCabe's book). The final question asked students to discuss how the data provided an example of Simpson's paradox. You've probably guessed it by now -- she had one student who wrote a long paragraph about OJ Simpson's legal difficulties as a black man being accused of murdering a white woman. Will future generations of statistics students automatically thinks that this is the Simpson in Simpson's paradox? - Robin Lock John R. Vokey, Ph.D. Chair Department of Psychology and Neuroscience University of Lethbridge Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
