Re: MOD function does not work! So be warned!
Actually the answer to my question is that there is no such thing as an integer in xTalk. Any string which could be a number which seems to act like an integer is a binary real which has an exact decimal representation during computation. You can't define a range for an integer if your language does not have the concept of type. What I was trying to say is that an integer to a lot of people is a whole number in the range of +/- infinity. If they add zero to a large integer and the result is another large integer they are upset. Just like those people who summed ten tenths and didn't get one. This isn't a large problem in the since that most xTalk programmers aren't going to be writing programs where they will encounter these situations. The large problem I see is if an xTalk were ones first language one would be ignorant of computer numerics. michael Rob Cozens of [EMAIL PROTECTED] wrote the following on 4/6/02 10:32 AM One problem is what is an integer? I would define an integer as any non-decimal number within the range of numbers supported by the interpreter. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Sunday, April 7, 2002, at 07:24 AM, Michael D Mays wrote: Actually the answer to my question is that there is no such thing as an integer in xTalk. Any string which could be a number which seems to act like an integer is a binary real which has an exact decimal representation during computation. You can't define a range for an integer if your language does not have the concept of type. If an implementation did use an integer type for a particular range and then switched to floating point outside that range, how would we ever know? What I was trying to say is that an integer to a lot of people is a whole number in the range of +/- infinity. If they add zero to a large integer and the result is another large integer they are upset. Just like those people who summed ten tenths and didn't get one. Yes! Most of us learn what an integer is early in mathematics education. The computer language concept of integer type is related, but is not the same; it is computer jargon. This isn't a large problem in the since that most xTalk programmers aren't going to be writing programs where they will encounter these situations. I have to defer to your judgment on this. I wonder though, whether this is the case because those who tried went on to other applications or other environments after becoming frustrated. I can imagine, though, a little stack to keep up with expense reports that reports after a couple months that reimbursements do not equal out-of-pocket expenses. The large problem I see is if an xTalk were ones first language one would be ignorant of computer numerics. This is why I would prefer to see limitations described in terms of numerals. Or, if that cannot be done, then a safe zone and behavior within it described in simple terms using numerals (referring to number of digits and so on). Anything outside that safe zone is for advanced users and can be described in technical jargon. (What I would really prefer is numbers virtually based completely on numerals.) As typical in any field, those of us who have paid the price to learn trade knowledge think it is easy and the right place to build concepts. Moreover, sometimes we tend to think of those things as the right way to think about the world. Or rights of passage into the priesthood. Or, you can't stay innocent forever, you will have to learn about the real world eventually. Or, when you get really good, you can graduate to C. A script writer should be able to concentrate on a particular problem domain using commonly held knowledge. At times that problem domain does involve computer numerics as in writing scripts to input or output data that involves those. Those concepts belong only in those commands and functions and options that involve those. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
One problem is what is an integer? I would define an integer as any non-decimal number within the range of numbers supported by the interpreter. http://groups.yahoo.com/group/xtalks/ Thank you, Michael. I'm waiting confirmation of my subscription as I write this. -- Rob Cozens CCW, Serendipity Software Company http://www.oenolog.com/who.htm And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
Rob Cozens of [EMAIL PROTECTED] wrote the following on 4/4/02 9:59 AM Or is the real issue here the failure of HyperTalk, MC, RR documentation writers to add a line indicating only non-decimal arguments are legal? The HC documentation just says numbers, implying one could legally script something like 999.999 mod 333.333. xTalks are purported to be 'typeless'. But they aren't. The engine which drives the engine is a binary machine. Is one one, 1 or 1.0? It depends upon the context. What this means in effect is that the rules for typing in xTalk are more complex than the rules for typing in a 'typed' language. 99.9 and maybe a few more 9s of the time this doesn't matter or the automatic typing rules work the way we think they should. xTalk scripters are a prior ill equipped to deal with numbers. When HyperTalk became PPC native, the precision to which numbers were calculated decreased by two or three orders of magnitude. And as you point out, where in any xTalk documentation does anyone talk about numbers. Only the HyperCard documentation talks about SANE and number precision. But even that discussion leaves one sadly lacking. And when Apple released the PPC version of HyperCard, the documentation was not updated for the new PPC numerics. Caveat emptor.:( michael ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
xTalks are purported to be 'typeless'. But they aren't.
Michael, et al,
Yes, and this mod issue is the result.
I can hear the conversation among Winkler, Atkinson, and other early
HC team members:
What do we do about the mod operator? It's an integer operator in
every other programming language; but if we restrict it to integers,
we'll have to explain to people the differences between real numbers
integers...that might get them to thinking they're programming and
scare them away. So let's just accept decimals. After all, there is
nothing in the generic definition of 'remainder' that requires the
dividend or divisor to be integers. :{`)
From the Rev dictionary:
The mod operator evaluates to the remainder left over when one
number is divided by another.
From Funk Wagnalls, remainder : In division, the excess of the
dividend over the product of the divisor by the integral part of the
quotient. Therefore remainder = dividend -
(divisor*trunc(quotient)). Trunc(quotient) = trunc(dividend/divisor)
= dividend div divisor; so remainder = dividend - (divisor *
(dividend div divisor))
That looks a lot like:
function myMod zaValue,zaBase
return zaValue-((zaValue div zaBase)*zaBase)
end myMod
which I previously posted as being correct for integer values. I
rewrote Ian's original to call myMod instead of mod. The results
were the same.
I think Xtalk should follow normal programming convent and have mod
reject non-integer values. I'm ready to initiate a discussion on the
topic on the Xtalk List, if someone would please send me subscription
instructions.
--
Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.com/who.htm
And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee.
from The Triple Foole by John Donne (1572-1631)
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
One problem is what is an integer? Is 123456789112345678 an integer? Yes. No. Maybe put 123456789112345678+0 on a PPC Mac results in 123456789112345680 If we were C programmers we would know that this is the 'correct' answer. But we are merely lowly xTalkers and we wonder where the seven went. ;) If I would have done this 12 years ago on any Mac my results would have been 123456789112345678 I don't know what our brethren in the windows world get. But it could be different. (I get the same answer with Virtual PC running 2000.) http://groups.yahoo.com/group/xtalks/ michael Rob Cozens of [EMAIL PROTECTED] wrote the following on 4/5/02 11:00 AM I think Xtalk should follow normal programming convent and have mod reject non-integer values. I'm ready to initiate a discussion on the topic on the Xtalk List, if someone would please send me subscription instructions. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Friday, April 5, 2002, at 10:00 AM, Rob Cozens wrote: I think Xtalk should follow normal programming convent and have mod reject non-integer values. The definition from Knuth's _Fundamental Algorithms_ is this: x mod y = x - y * floor( x/y ) if y is not 0 x mod 0 = x where x and y are real numbers (All programmers over 40 are required to give a reverent Ahhh at the mention of this work.) Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Friday, April 5, 2002, at 05:24 PM, Dar Scott wrote: I think Xtalk should follow normal programming convent and have mod reject non-integer values. The definition from Knuth's _Fundamental Algorithms_ is this: x mod y = x - y * floor( x/y ) if y is not 0 x mod 0 = x where x and y are real numbers Of course, that is not a programming language in itself. But these are... Pascal (Jensen Wirth)integer X integer -- integer MODULA-2 (Wirth) integer X integer -- integer PostScript (Adobe) integer X integer -- integer Common Lisp (Steele)number X number -- number Tcl (Ousterhout)real X real -- real (fmod()) C(Harbison Steele) double X double -- double (fmod()) Mathematica (Wolfram) number X number -- number LabView number X number -- number (QR) (Some of these have slightly differing meanings.) I don't think we can say there is a convention. If the Revolution mod function works as expected for two positive whole numbers (less than 15 digits), what do we care if it does something useful for other numbers? Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
The someone else was me, and since another writer made a similar point about my comment I should clarify that I did not make it in relation to Rev (and hence the documentation makes no such statement) but to the MOD function as it was initially implemented (so far as I know) in the languages of 25+ or even 35+ years ago. I was talking about distant antecedents rather than current usage. David, et al: FWIW, I just looked through my old programming manuals and found all three versions of Pascal (UCSD, Turbo, Think) define mod as an integer operation. The Turbo Pascal manual specifically identities real arguments to mod as an error. -- Rob Cozens CCW, Serendipity Software Company http://www.oenolog.com/who.htm And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
MOD is working. = is working. Michael, MOD is NOT working: anyNumber mod 5 CANNOT = 5. -- Rob Cozens CCW, Serendipity Software Company http://www.oenolog.com/who.htm And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
It's not 5 Rob its 4.999... . It only looks like 5 because the default numberFormat rounds it to 5. If you set the numberFormat to a high enough precision you will see that the number which is else rounded to the default numberFormat and displayed in the message box is not 5. anyIntegerNumber MOD 5 is never 5. certainRealNumbers MOD 5 can look like 5 when rounded. The default numberFormat wraps the MOD function with a round function which rounds 4.999... to 5. michael Rob Cozens of [EMAIL PROTECTED] wrote the following on 4/4/02 9:08 AM MOD is working. = is working. Michael, MOD is NOT working: anyNumber mod 5 CANNOT = 5. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
RE: MOD function does not work! So be warned!
I'd do it myself, but I've never had a need to do mod with non-integers. Nor have I, Glen. In fact, my recollection is no programming language I've used except Xtalk dialects even allowed decimal values to be passed to mod. The thread was initiated by Ian Summerfield. I included his handler in a subsequent post on this thread. FYI, per the Transcript dictionary, beginning with v1.1 the mod operator can be applied to arrays. -- Rob Cozens CCW, Serendipity Software Company http://www.oenolog.com/who.htm And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
It's not 5 Rob its 4.999. Michael, et al: OK, I'll accept that...and add numbskull of the day to my title of resident foole. -- Rob Cozens CCW, Serendipity Software Company http://www.oenolog.com/who.htm And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Thursday, April 4, 2002, at 01:59 , Rob Cozens wrote: snip A final note: Someone else mentioned the mod operator is supposed to be used with integers, so anyRealValue mod anyBase is non-sequitur. I didn't see anything in the documentation restricting the use of mod to integers; OTOH, I can't recall having a practical need for the mod of a non-integer in 25+ years of programming. Rob The someone else was me, and since another writer made a similar point about my comment I should clarify that I did not make it in relation to Rev (and hence the documentation makes no such statement) but to the MOD function as it was initially implemented (so far as I know) in the languages of 25+ or even 35+ years ago. I was talking about distant antecedents rather than current usage. OTOH, if we wish to use a comparison where the significant result is an integer then isn't it natural to ensure we are dealing with an integer? [This is a rhetorical question :-)] Changing the last line of your example to put (var1 = var2) ((round(var1) mod 5)= (round(var2) mod 5)) does this. I am of the view that the MOD function works no worse than I might expect it to on a computer, if less well than I would prefer. I don't like surprises of this nature either but that is one reason I act to avoid them. regards David -- Rob Cozens CCW, Serendipity Software Company http://www.oenolog.com/who.htm And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
Rob Cozens of [EMAIL PROTECTED] wrote the following on 4/3/02 9:59 AM on testMod put 249 into var1 put var1 into var2 add 1.0 to var1 repeat 10 add 0.1 to var2 end repeat put (var1=var2)((var1 mod 5)=(var2 mod 5)) end testMod On the Mac with PPC numerics as I understand it 249 and 1 are represented exactly as is the sum of 249+1. 249 - 01001 + 1 - 1 =250 - 01010 - var1 249 - 01001 + 0.1 - 0.00011001100110011001100110011 ... + 0.1 - 0.00011001100110011001100110011 ... + 0.1 - 0.00011001100110011001100110011 ... + 0.1 - 0.00011001100110011001100110011 ... + 0.1 - 0.00011001100110011001100110011 ... + 0.1 - 0.00011001100110011001100110011 ... + 0.1 - 0.00011001100110011001100110011 ... + 0.1 - 0.00011001100110011001100110011 ... + 0.1 - 0.00011001100110011001100110011 ... + 0.1 - 0.00011001100110011001100110011 ... =249.9*- 01001.0 ... - var2 *249.99... var1var2 add this line to the beginning of the above script set the numberFormat to 0. and append this to the penultimate line. var1var2 Now the result is true false 250 249.94315658113919199 MOD returns the remainder left when one number divides into another. So we are asking for 01001.00011001100110011001100110011 ... / 0101 - a remainder vs 01010 / 0101 - no remainder = on some systems wants an exact match. Not so using PPC numerics. They only need to round to within 15 decimal digits or so (There two decimal orders of rounding for Dar:). Which the above two numbers do. If you would have ran the loop to 1000 and adjusted your parameters for 100 instead of 1 you would have found false false MOD is working. = is working. MOD is strictly a binary comparison. = does rounding trying to conform to our decimal perception of the universe.:) michael ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
Ian wrote, put .1 * adjustment into increment On Sunday, March 31, 2002, at 03:06 PM, Dar Scott wrote: The problem is completely avoided. In general no. In the special case of mod 550, maybe. I'm wrong. Well, 99%. You are right, Ian. A very large class of computations will work OK by using signed whole numbers (less than 15 digits). You will want to make sure you don't let the error of a fraction sneak in. Revolution numbers represent integers (in the math sense) up to about 15 digits exactly. I apologize for the confusion. (A simple mental exercise: Imagine some arbitrary non-zero decimal number. Imagine that you convert it to binary. Imagine that you shift the binary point to the left, counting the bits you pass. Shift it to just to the right of the left-most bit that is a 1. Imagine that you cut off the portion to the right of the binary point beyond some number of bits corresponding to mantessa of the floating point number. Note that no ones are dropped off.) Y' know, a number improvement based on Ian's idea would be a lot more feasible than my idea of exact numerals (and applying numberFormat to calculations). Sorry about the error. As the great philosopher Michael Mays said, What numbskull posted this?! Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
It is not the loop, it is addition. Dar, et al: I think there's more to it than that: In on testMod put 249 into var1 put var1 into var2 add 1.0 to var1 repeat 10 add 0.1 to var2 end repeat put (var1=var2)((var1 mod 5)=(var2 mod 5)) end testMod The first test always resolves to true...only the second test yields a false result. -- Rob Cozens CCW, Serendipity Software Company http://www.oenolog.com/who.htm And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
Richard Gaskin of [EMAIL PROTECTED] wrote the following on 3/31/02 10:00 AM Interestingly, when you type put 5 mod 5 (or 255 md 5 or other number divisible by five that fails when inside a loop) into the Message Box the result is 0. Stranger still, if you rewrite the line like this so that the loop var is evaluated outside of the rest of the statement: do put loop tab loop mod 5 return after msg ...you get 0. The reason it works in the msg box is because you are using a different number. Inside the loop the number is 254.99988631316227838397 not the 255 you typed. If you set the numberFormat large enough you will see that loop is never 255. And also your do statement in the loop will fail. The situation is that when you convert .1 to binary and add it to 255 it is actually adding a binary number whose value is a little less than the value of decimal .10. .1 has no exact binary representation. if the increment were some inverse power of two everything would 'work' the way we expect it to. When you were using the do statement you are forcing loop to be converted to a string at the precision of the default numberFormat (since you didn't set it to anything else). This string is 255. When you increase the precision of the numberFormat to max precision the string is 254.99988631316227838397. michael ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Sunday, March 31, 2002, at 11:54 AM, Rob Cozens wrote: I think there's more to it than that: ... put (var1=var2)((var1 mod 5)=(var2 mod 5)) I think you are right. on mouseUp set the numberFormat to 0.# put (1+.001) linefeed after field Report put (1+.001) = 1 linefeed after field Report end mouseUp --- 1.00111 true Equality between numbers seems to either have a tolerance, round/truncate digits or round/truncate internal bits. (Mathematicians would concerned about the first; the tolerance method means = is not an equivalence relation and transitivity goes out the window.) Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
Dar Scott of [EMAIL PROTECTED] wrote the following on 3/31/02 11:49 AM It is not the loop, it is addition. Every Revolution number (a priori) has a potential error. This accumulates. (I say a priori because some numbers, can be represented exactly.) It is not a bug. This is just the way MOD and decimal numbers which are represented as binary numbers work. It is not just a Revolution problem. The error does not accumulate. Try summing a million .10. There is no accumulation. Run this handler. on mouseUp set the numberFormat to \ 0.### put .10,.100012,.100013 into inc repeat with j=1 to 3 put item j of inc into incc put 0 into a repeat with i=1 to 10 add incc to a put a into a put 0.i into ii put ii a into line i+(j-1)*10 of fld 1 end repeat end repeat end mouseUp michael ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Friday, March 29, 2002, at 01:16 AM, David Vaughan wrote: A solution (use round when it must be integer, raise to the power 1 when it must be floating point and concatenate with empty for a string) is straightforward enough and rarely needed. I don't think I understand how to use this. Case in point: put (8 empty) (33 empty) -- true These numeral values compare as numbers. I can't make them be strings. I realize there is a lot of heritage behind this, but I would have been happier to discover I could not tell there was any representation other than strings. ...to discover that arithmetic has a simple numeral-to-number-to-(limited)-numeral semantics. I would have been please to learn something like, Numerals with less than 20 digits represent numbers. An arithmetic function on numerals returns an exact representation of the result if it can be represented in 20 or less digits, otherwise ... It is kind of strange to find that there are some x such that B x = B236 is true but x = 236 is false. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Friday, March 29, 2002, at 01:16 AM, David Vaughan wrote: concatenate with empty for a string OK. I found a good example that puts that to use. Here a floating point that does not equal 236 (but evaluates to 236 when needed as a string) is converted to a string and then (virtually, if not really) back to a number for comparison. on mouseUp put 235.00 into var repeat for 100 times put var + 0.01 into var end repeat Put (empty var) = 236.00 into field Report end mouseUp This reports true, but if (empty var) was replaced with var, this would report false. I still find it weird that there are x such that (empty x) = x is false. How am I going to explain this to a bunch of little kids? Dar ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Friday, March 29, 2002, at 02:06 AM, David Vaughan wrote: Case in point: put (8 empty) (33 empty) -- true These numeral values compare as numbers. I can't make them be strings. um... true. You actually have to append a space, not empty. There's one for me. LOL. I tried spaces on either end. They still compare as representing numbers. But that other example I found. That is a good place to concatenate empty. I think the problem is that when an alternate representation of a number is converted to a string, the string is not always a numeral of the number represented. A value in that case has sort of a split personality. dar ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
[I sent this message the first time from the wrong account. If it comes through twice, sorry--mdm] The MOD function works. The ROUND function might not. Decimal 0.1 when converted to binary is actually slightly greater than decimal 0.1. Set the numberFormat to something very precise and you will see that .1 is really 0.1555111512312578 When you keep adding increment eventually you reach a point where the sum of all those 5.5e-19ths (if I counted right) become significant to the MOD function. I think David Vaughan has said all this already but it is a very important point. But the round is NOT the way to go on mouseUp put 1 +.1 into aa put aa into line 1 of fld 1 set the numberFormat to \ 0.## put aa into line 2 of fld 1 put round(aa,1) into line 3 of fld 1 end mouseUp fld 1 is 1.1 1.1000888178419700125 1.0998667732370449812 I don't see it in MetaCard 2.2.3 (line 2 and 3 are the same in 2.2.3) but the results are the same as above in MC2.4.1. I think this might be a BUG. If you want to be testing as is in this example increments of tenths, I something like set the numberFormat to 0.# and add the line put loop into loop to your repeat clause. michael Ian Summerfield of [EMAIL PROTECTED] wrote the following on 3/28/02 9:53 PM The code I give here might look inefficient, the code comes from a large project, so there are reasons for doing it this way! It's just taken me several hours to figure out why my code wasn't working, and it turns out to be a bug in Revolution. Revolution 1.1.1b2 (OS X 10.1.3) seems to think 5 mod 5 = 5 whereas it is zero. Try this code: on mouseup put 235 into startPoint put 255 into endPoint put 0.1 into increment put empty into msg put startPoint into loop repeat while loop=endPoint put loop loop mod 5 return after msg add increment to loop end repeat end mouseup It will output to the message box a list of numbers. The loop counter is on each line followed by a space and the loop mod 5. Here's my output: 235 0 correct 235.1 0.1 235.2 0.2 235.3 0.3 SNIP 240 5 wrong and impossible 240.1 0.1 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
MOD function does not work! So be warned!
The code I give here might look inefficient, the code comes from a large project, so there are reasons for doing it this way! It's just taken me several hours to figure out why my code wasn't working, and it turns out to be a bug in Revolution. Revolution 1.1.1b2 (OS X 10.1.3) seems to think 5 mod 5 = 5 whereas it is zero. Try this code: on mouseup put 235 into startPoint put 255 into endPoint put 0.1 into increment put empty into msg put startPoint into loop repeat while loop=endPoint put loop loop mod 5 return after msg add increment to loop end repeat end mouseup It will output to the message box a list of numbers. The loop counter is on each line followed by a space and the loop mod 5. Here's my output: 235 0 correct 235.1 0.1 235.2 0.2 235.3 0.3 SNIP 240 5 wrong and impossible 240.1 0.1 240.2 0.2 240.3 0.3 SNIP 244.9 4.9 245 5 wrong and impossible 245.1 0.1 245.2 0.2 245.3 0.3 SNIP 250 5 wrong and impossible 250.1 0.1 250.2 0.2 250.3 0.3 SNIP 254.9 4.9 255 5 wrong and impossible ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Friday, March 29, 2002, at 02:53 , Ian Summerfield wrote: The code I give here might look inefficient, the code comes from a large project, so there are reasons for doing it this way! It's just taken me several hours to figure out why my code wasn't working, and it turns out to be a bug in Revolution. Revolution 1.1.1b2 (OS X 10.1.3) seems to think 5 mod 5 = 5 whereas it is zero. on mouseup put 235 into startPoint put 255 into endPoint put 0.1 into increment put empty into msg put startPoint into loop repeat while loop=endPoint put loop loop mod 5 return after msg add increment to loop end repeat end mouseup ian Interesting bug. I changed your startpoint and endpoint to 4.9 5 with no bug and 4.8 5 with the bug. Changing the critical line to put loop round(loop) mod 5 return after msg disposes of the error so I it seems to be a trailing digits error in real arithmetic rather than a logical bug as such. 5 mod 5 of course always produces 0. cheers David ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Thursday, March 28, 2002, at 09:06 PM, David Vaughan wrote: Interesting bug. I changed your startpoint and endpoint to 4.9 5 with no bug and 4.8 5 with the bug. Changing the critical line to put loop round(loop) mod 5 return after msg disposes of the error so I it seems to be a trailing digits error in real arithmetic rather than a logical bug as such. 5 mod 5 of course always produces 0. This is discouraging. I typed .2 + .2 + .2 + .2 + .2 = 10 into the message window and got false. I assume by real you mean floating point, as typically implemented by computer hardware, a number with a binary point. I don't see anything in the documentation as numbers being sometimes implemented as floating point. I wouldn't mind this if it is transparent. As long as a value looks and acts like a string, I don't care how it is stored internally. As far as rounding, without evidence to the contrary one would have to assume that numbers are rounded to a decimal point rather than to a binary point. (Numbers don't have to be represented in decimal for a decimal point to be maintained, but they often are.) The implication is that applications that need a decimal point need to have lots of special code. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Friday, March 29, 2002, at 03:43 , Dar Scott wrote: On Thursday, March 28, 2002, at 09:06 PM, David Vaughan wrote: Interesting bug. I changed your startpoint and endpoint to 4.9 5 with no bug and 4.8 5 with the bug. Changing the critical line to put loop round(loop) mod 5 return after msg disposes of the error so I it seems to be a trailing digits error in real arithmetic rather than a logical bug as such. 5 mod 5 of course always produces 0. This is discouraging. I typed .2 + .2 + .2 + .2 + .2 = 10 into the message window and got false. So did I but my discouragement was alleviated by typing .2 + .2 + .2 + .2 + .2 = 1 !!:-) I assume by real you mean floating point, as typically implemented by computer hardware, a number with a binary point. I don't see anything in the documentation as numbers being sometimes implemented as floating point. I don't know about the documentation but I mean with a sign, mantissa and exponent rather than BCD or integer. You can force this format, I believe, by taking an integer and raising it to a power, e.g. put 4^1 into x makes x a floating point number in the terms I suggest. If the number were BCD then I would not expect the failure Ian discovered, any more than you would for integer. Mod, incidentally, is (or was) intended as an integer function rather than one for real (floating point) numbers. I wouldn't mind this if it is transparent. As long as a value looks and acts like a string, I don't care how it is stored internally. As far as rounding, without evidence to the contrary one would have to assume that numbers are rounded to a decimal point rather than to a binary point. (Numbers don't have to be represented in decimal for a decimal point to be maintained, but they often are.) The implication is that applications that need a decimal point need to have lots of special code. Not really. Treat it as one of string, integer or floating point (s, m, e) and BCD or binary point can take care of themselves. Incidentally, we are still working on that comparative challenge you set us, Dar. cheers David Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Thursday, March 28, 2002, at 10:15 PM, David Vaughan wrote: This is discouraging. I typed .2 + .2 + .2 + .2 + .2 = 10 into the message window and got false. So did I but my discouragement was alleviated by typing .2 + .2 + .2 + .2 + .2 = 1 !!:-) How embarrassing!! Dar ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Friday, March 29, 2002, at 04:48 , Dar Scott wrote: On Thursday, March 28, 2002, at 10:15 PM, David Vaughan wrote: This is discouraging. I typed .2 + .2 + .2 + .2 + .2 = 10 into the message window and got false. So did I but my discouragement was alleviated by typing .2 + .2 + .2 + .2 + .2 = 1 !!:-) How embarrassing!! Dar No worries and it was worth a chuckle. Actually, I did indeed copy your code into the message box exactly as you had it, got false, then experimentally typed in put .8 + .2 = 10 and finally noticed just before I hit the enter key... ;-) David Dar ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Thursday, March 28, 2002, at 10:15 PM, David Vaughan wrote: Mod, incidentally, is (or was) intended as an integer function rather than one for real (floating point) numbers. The doc says nothing about this. I'm disappointed that we are reduced to talking about int and real, programmer jargon. Mathematically, depending on usage, mod is defined over real (in the math sense). The implication is that applications that need a decimal point need to have lots of special code. Not really. Treat it as one of string, integer or floating point (s, m, e) and BCD or binary point can take care of themselves. I don't understand. I don't know of types in Revolution (except string vs array). Suppose I want to keep up with money. If I understand the implications of Ian's experiment, my books might not balance. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Thursday, March 28, 2002, at 11:04 PM, David Vaughan wrote: No worries and it was worth a chuckle. Actually, I did indeed copy your code into the message box exactly as you had it, got false, then experimentally typed in put .8 + .2 = 10 and finally noticed just before I hit the enter key... ;-) Here is a better example: on mouseUp put 235.00 into var repeat for 100 times put var + 0.01 into var end repeat Put var (var = 236.00) into field Report end mouseUp This puts 236 false into the field. This works as hoped (for cent arithmetic): on mouseUp put 235.00 into var repeat for 100 times put round(var + 0.01,2) into var end repeat Put var (var = 236.00) into field Report end mouseUp Dar ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: MOD function does not work! So be warned!
On Friday, March 29, 2002, at 05:00 , Dar Scott wrote: The doc says nothing about this. I'm disappointed that we are reduced to talking about int and real, programmer jargon. The implication is that applications that need a decimal point need to have lots of special code. Not really. Treat it as one of string, integer or floating point (s, m, e) and BCD or binary point can take care of themselves. I don't understand. I don't know of types in Revolution (except string vs array). Suppose I want to keep up with money. If I understand the implications of Ian's experiment, my books might not balance. Rev is not a strongly typed language but I never expected that _all_ issues of data types would disappear. A solution (use round when it must be integer, raise to the power 1 when it must be floating point and concatenate with empty for a string) is straightforward enough and rarely needed. Incidentally, MS Excel fails the following test mod(12.3,1.23) = 0 where rev gets it right so MC is not alone in having issues with mod (Excel produces a residual of about 1e-15; not zero). Further, some languages will, I believe, say that -340 mod 60 is 20 or -20 (arguable) where the MC engine fairly rationally says -40 so that is another one to consider. I have had to compel the data type once or twice in HC and the same stack(s) in RR but a general awareness of the possibility is usually sufficient not to get caught by it. A bit like deliberately over-using parentheses to make sure the compiler understands you; just being safe. Perhaps some notes could be added to the documentation to raise this awareness for all. regards David Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
