1. Strange problem
- Posted by Lewis Townsend <keroltarr at HOTMAIL.COM> Mar 19, 2000
- 500 views
------=_NextPart_000_1aedea56_dc2ffcb$5c03de36 Hello, Help. I have been working on a program all day today. I'm up a stump. I get an error about a subscript zero but it isn't. At least I can't tell what the problem is. Every subscript evaluates to a positive integer as far as I can tell. I even did some file output to test it. I isolated the code that makes the problem. Here it is. Please debug it for me or at least tell me what might be wrong. I'm beginning to wonder if it might be a interpreter problem. I hope it's just me. TIA, Lewis Townsend keroltarr at hotmail.com http://geocities.com/keroltarr/ ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com ------=_NextPart_000_1aedea56_dc2ffcb$5c03de36 Content-Transfer-Encoding: 8bit
2. Re: Strange problem
- Posted by Everett Williams <rett at GVTC.COM> Mar 18, 2000
- 459 views
- Last edited Mar 19, 2000
Lewis Townsend wrote: >include misc.e > >global constant > POSITION = 4, > LEFT = 4.1, > TOP = 4.2, > DEMINSIONS = 5, > WIDTH = 5.1, > HEIGHT = 5.2, > objects = { > {1,0,{},{ 0, 0},{639,479}, 1,1,1}, > {1,0,{},{10,10},{459,459},-1,1,1} > } > >global function Get (integer obj, atom att) > if length (objects) < obj or obj = 0 then > puts (1, "Error: " & sprint (obj) & " is an invalid object handle!\n") > elsif length (objects [obj]) < att then > puts (1, "Error: " & sprint (att) & " is an invalid object handle!\n") > elsif not integer (att) then > return objects [obj] [floor (att)] [((att - floor (att)) * 10)] -->ERROR > else > return objects [obj] [att] > end if >end function > >object view >view = 2 >constant vp = {Get (view,WIDTH),Get (view, HEIGHT)} >? {Get(view,LEFT), Get(view,TOP)}) Neither WIDTH nor HEIGHT are either integers or atoms, but floats because they are declared with a decimal. I am not sure what that means for their use as atoms in the function Get(), but it can't be nice. In this particular case, it doesn't matter, because (att-floor(att)) will always be 0 if att has already been rounded to an integer by being stuffed into an atom. I think that is your problem. Everett L.(Rett) Williams rett at gvtc.com
3. Re: Strange problem
- Posted by Everett Williams <rett at GVTC.COM> Mar 18, 2000
- 462 views
- Last edited Mar 19, 2000
Everett Williams wrote: > >Neither WIDTH nor HEIGHT are either integers or atoms, but floats because >they are declared with a decimal. I am not sure what that means for their >use as atoms in the function Get(), but it can't be nice. In this particular >case, >it doesn't matter, because (att-floor(att)) will always be 0 if att has already >been rounded to an integer by being stuffed into an atom. I think that is >your problem. > In one sense, this appears to be an Euphoria error, in the sense that the float nature of the constant is not being maintained( if I am correct) when it is assigned to an atom in the function. In another sense, it just points out a contradiction that the use of floats causes in Euphoria. Decimal arithmetic does not have to use floats. Floats are sometimes faster and more efficient, but they almost always lose significance as compared to direct decimal calculations according to the rules of arithmetic. I would bet that if you called att an object that the problem would go away. Everett L.(Rett) Williams rett at gvtc.com
4. Re: Strange problem
- Posted by Joel Crook <joel at MAIL.K-A.COM> Mar 18, 2000
- 470 views
- Last edited Mar 19, 2000
At 02:05 AM 03/19/2000 +0000, you wrote: >Hello, >Help. I have been working on a program all day today. I'm up >a stump. I get an error about a subscript zero but it isn't. >At least I can't tell what the problem is. Every subscript >evaluates to a positive integer as far as I can tell. I even >did some file output to test it. I isolated the code that >makes the problem. Here it is. Please debug it for me or at >least tell me what might be wrong. I'm beginning to wonder if >it might be a interpreter problem. I hope it's just me. > >TIA, > >Lewis Townsend >keroltarr at hotmail.com >http://geocities.com/keroltarr/ >______________________________________________________ >Get Your Private, Free Email at http://www.hotmail.com > return objects [obj] [floor (att)] [1+((att - floor (att)) * 10)] -->ERROR { {1,0,{},{ 0, 0},{639,479}, 1,1,1}, {1,0,{},{10,10},{459,459},-1,1,1} ^ } | I changed the line to read: return objects [obj] [floor (att)] [1+((att - floor (att)) * 1)] -->ERROR I get the result {10,10} att-floor(att) is .1 which you are trying to turn into a 1 by multiplying by 10 but I suspect that Euphoria is expecting is an integer -- sure enough In the manual I found: "Non-integer subscripts are rounded down to an integer" so Euphoria is seeing that last element number as [0] and not [1]
5. Re: Strange problem
- Posted by Everett Williams <rett at GVTC.COM> Mar 18, 2000
- 499 views
- Last edited Mar 19, 2000
Joel Crook wrote: >> > return objects [obj] [floor (att)] [1+((att - floor (att)) * 10)] -->ERROR > >{ > {1,0,{},{ 0, 0},{639,479}, 1,1,1}, > {1,0,{},{10,10},{459,459},-1,1,1} > ^ > } | >I changed the line to read: > return objects [obj] [floor (att)] [1+((att - floor (att)) * 1)] -->ERROR > >I get the result {10,10} > >att-floor(att) is .1 which you are trying to turn into a 1 by multiplying >by 10 but I suspect that Euphoria is expecting is an integer -- sure enough >In the manual I found: > >"Non-integer subscripts are rounded down to an integer" so Euphoria is >seeing that last element number as [0] and not [1] Okay, just for fun, let us assume that it works the way you say. There is one caveat. The reason why 10 times .1 does not give us back 1 is that the float that is created from 4.1 is slightly less than 4.1, and therefore the equation gives us back a number that is slightly less than 1...then by the manual, it is rounded down to 0. The rounding may not be dependable at 4.2 or 4.3 or ... The error is in the conversion from base 10 decimal to binary floating point. I have not confirmed this, but until I actually tested it, I would not trust your adding of 1 to the result. Sometimes the conversion might give a number just slightly larger than the decimal and then the result will be 1 too large. I would love for someone to tell me that it always converts to the largest float smaller than the original number. I did not find that assurance in the manual. RDS...time to tell us how you do it. Everett L.(Rett) Williams rett at gvtc.com
6. Re: Strange problem
- Posted by Everett Williams <rett at GVTC.COM> Mar 18, 2000
- 465 views
- Last edited Mar 19, 2000
Everett Williams wrote: >Okay, just for fun, let us assume that it works the way you say. There is >one caveat. The reason why 10 times .1 does not give us back 1 is that >the float that is created from 4.1 is slightly less than 4.1, and therefore the >equation gives us back a number that is slightly less than 1...then by the >manual, it is rounded down to 0. The rounding may not be dependable at >4.2 or 4.3 or ... The error is in the conversion from base 10 decimal to >binary floating point. I have not confirmed this, but until I actually tested >it, >I would not trust your adding of 1 to the result. Sometimes the conversion >might give a number just slightly larger than the decimal and then the >result will be 1 too large. I would love for someone to tell me that it always >converts to the largest float smaller than the original number. I did not find >that assurance in the manual. RDS...time to tell us how you do it. > Sometimes I am a little slow, but I do finally get there. In a case where the system truncates rather than rounds, the normal solution is to add .5 except in this case where we are not sure that the conversion is always less than the original decimal number. Given the answer to that question is yes, then adding .5 solves the problem. Only a lot of very exacting testing or an answer from RDS will solve the question for sure. Everett L.(Rett) Williams rett at gvtc.com
7. Re: Strange problem
- Posted by Irv Mullins <irv at ELLIJAY.COM> Mar 19, 2000
- 478 views
On Sat, 18 Mar 2000, > Everett Williams wrote: > > In one sense, this appears to be an Euphoria error, in the sense that the > float nature of the constant is not being maintained( if I am correct) when > it is assigned to an atom in the function. In another sense, it just points > out a contradiction that the use of floats causes in Euphoria. Decimal > arithmetic does not have to use floats. Floats are sometimes faster and > more efficient, but they almost always lose significance as compared to > direct decimal calculations according to the rules of arithmetic. I would > bet that if you called att an object that the problem would go away. How much were you betting? A lot, I hope, as I always wanted to be independently wealthy. :) Irv
8. Re: Strange problem
- Posted by Irv Mullins <irv at ELLIJAY.COM> Mar 19, 2000
- 488 views
On Sat, 18 Mar 2000, Rett Williams wrote: > > Neither WIDTH nor HEIGHT are either integers or atoms, but floats because > they are declared with a decimal. I am not sure what that means for their > use as atoms in the function Get(), but it can't be nice. In this particular > case, > it doesn't matter, because (att-floor(att)) will always be 0 if att has > already > been rounded to an integer by being stuffed into an atom. I think that is > your problem. Bzzzt! An atom _is_ a float. Storing something there does not round it in any way. This is easily proven by either 1. writing a program: constant n = 4.1 atom a a = n ? a prints 4.1 Or, 2, consulting the manual: "Atoms can have any integer or double-precision floating point value. They can range from approximately -1e300 (minus one times 10 to the power 300) to +1e300 with 15 decimal digits of accuracy." Regards, Irv
9. Re: Strange problem
- Posted by Everett Williams <rett at GVTC.COM> Mar 19, 2000
- 484 views
Irv Mullins wrote: >On Sat, 18 Mar 2000, >> Everett Williams wrote: >> >> In one sense, this appears to be an Euphoria error, in the sense that the >> float nature of the constant is not being maintained( if I am correct) when >> it is assigned to an atom in the function. In another sense, it just points >> out a contradiction that the use of floats causes in Euphoria. Decimal >> arithmetic does not have to use floats. Floats are sometimes faster and >> more efficient, but they almost always lose significance as compared to >> direct decimal calculations according to the rules of arithmetic. I would >> bet that if you called att an object that the problem would go away. > >How much were you betting? >A lot, I hope, as I always wanted to be independently wealthy. :) > Momentary mental hiccup. It looks like a bet one "I told you so" and lost it, but I got it right back. You are eminently correct, but as was noted in later posts, the main culprit is the binary nature of our floats. Round pegs, square holes. I still don't have an answer to my question about the creation of floats. If I can remember some 20 year old conversations on this subject, their are some points where decimals convert exactly to binary float. This "could" throw off rounding routines using the old add .5 trick. What is even more interesting is that your print routines are a reconversion of that same binary float that may or may not suffer from rounding problems of it's own. Without access to the actual code that does the various conversions, or at least the mathematical algorithm for that code, it will be damn difficult to determine. That is why this casual internal "float" between decimal and binary formats makes Euphoria a disaster for any kind of high resolution math and in some cases for much lower resolutions. Of course the problem isn't limited to Euphoria. People who care about such things use libraries of decimal integer math routines that never convert to non-integer binary formats. The old IBM mainframes had the packed decimal instructions that COBOL used extensively. I know of no modern equivalent of that instruction set outside of those mainframes. Rounding routines can have a sufficiently ugly effect on arithmetically correct routines without the extra complication of the conversions. Everett L.(Rett) Williams rett at gvtc.com
10. Re: Strange problem
- Posted by Lewis Townsend <keroltarr at HOTMAIL.COM> Mar 20, 2000
- 474 views
- Last edited Mar 21, 2000
Rett, >Sometimes I am a little slow, but I do finally get there. In a case where >the >system truncates rather than rounds, the normal solution is to add .5 >except in this case where we are not sure that the conversion is always >less than the original decimal number. Given the answer to that question is >yes, then adding .5 solves the problem. Only a lot of very exacting testing >or >an answer from RDS will solve the question for sure. > >Everett L.(Rett) Williams >rett at gvtc.com It doesn't matter if the value is a tiny bit below or above the desired number the following function will always round it to the nearest integer... I think. This is untested so I may have some syntax errors but I think the logic is sound. Please let me know if it isn't. Please note also that my problem is now solved, thanks to you and others. function int_round (atom a) integer sign sign = 1 if a < 0 then sign = -1 end if return floor (a + .5 * sign) end function I suppose one could write a recursive version of this to work with sequences. later, Lewis Townsend keroltarr at hotmail.com http://geocities.com/keroltarr/ ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
11. Re: Strange problem
- Posted by Robert Craig <rds at ATTCANADA.NET> Mar 20, 2000
- 484 views
- Last edited Mar 21, 2000
Lewis Townsend writes: > function int_round (atom a) > integer sign sign = 1 > if a < 0 then > sign = -1 > end if > return floor (a + .5 * sign) > end function > > I suppose one could write a recursive version of this to > work with sequences. All you need is: function int_round(object a) return floor(a+0.5) end function This rounds off to the nearest integer. It works for atoms and sequences, negative numbers etc. > I for one would almost rather recieve an error > or a warning than allow subscripts be non-integers. I mainly allowed non-integers because disallowing them would hurt performance slightly. Performance of subscripting is very important to most programs. > My main confusion was that when I print()ed the results of > the expressions it said 1 instead of .9999999999. Is that > because of the 10 digit cutoff? Yes. It *rounds* to 10 digits, but doesn't print trailing 0's. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
12. Re: Strange problem
- Posted by Everett Williams <rett at GVTC.COM> Mar 20, 2000
- 473 views
- Last edited Mar 21, 2000
Robert Craig wrote: >> My main confusion was that when I print()ed the results of >> the expressions it said 1 instead of .9999999999. Is that >> because of the 10 digit cutoff? > >Yes. It *rounds* to 10 digits, but doesn't print trailing 0's. That is why most systems choose to truncate rather than round. Truncation produces a printout much closer to the truth than rounding. Rounding, as in this case, can conceal the fact that a calculation will not work because of the actual underlying number. I would suggest that the rounding be removed and truncation be used in the next release...at all levels. It should be faster, and it would solve the other noted problems. Same should apply for prints of float32 or float64. They should trunc(to zeros if necessary) at the last possible significant digit, even if more digits are requested than are significant. Everett L.(Rett) Williams rett at gvtc.com
13. Re: Strange problem
- Posted by Lewis Townsend <keroltarr at HOTMAIL.COM> Mar 21, 2000
- 461 views
Hello, >All you need is: > >function int_round(object a) > return floor(a+0.5) >end function > >This rounds off to the nearest integer. >It works for atoms and sequences, negative numbers etc. But I thought that floor() rounded "toward zero". If so, then: floor (-0.9 + 0.5) = 0 right? Or does it always round "down"? >I mainly allowed non-integers because disallowing them >would hurt performance slightly. Performance of subscripting is >very important to most programs. I agree there. later, Lewis Townsend keroltarr at hotmail.com http://geocities.com/keroltarr/ ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
14. Re: Strange problem
- Posted by Lewis Townsend <keroltarr at HOTMAIL.COM> Mar 21, 2000
- 436 views
Rett, you wrote: >That is why most systems choose to truncate rather than round. >Truncation produces a printout much closer to the truth than >rounding. Rounding, as in this case, can conceal the fact that >a calculation will not work because of the actual underlying number. >I would suggest that the rounding be removed and truncation be >used in the next release...at all levels. It should be faster, and it >would solve the other noted problems. Same should apply for >prints of float32 or float64. They should trunc(to zeros if necessary) >at the last possible significant digit, even if more digits are requested >than are significant. Now I agree that truncation might be better than floor()ing in some cases but I don't see how it is ever better than rounding except in the speed department. later, Lewis Townsend keroltarr at hotmail.com http://geocities.com/keroltarr/ ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
15. Re: Strange problem
- Posted by Matthew Lewis <MatthewL at KAPCOUSA.COM> Mar 21, 2000
- 468 views
No, it returns the greatest integer less than or equal to the argument. Hence, the term floor. Typically some sort of int() statement would do what you're thinking of, which is to simply truncate any fractional portion of a number. Matthew W Lewis > -----Original Message----- > From: Lewis Townsend atoms and sequences, negative numbers etc. > > But I thought that floor() rounded "toward zero". > If so, then: > floor (-0.9 + 0.5) = 0 > right? Or does it always round "down"?
16. Re: Strange problem
- Posted by Everett Williams <rett at GVTC.COM> Mar 21, 2000
- 442 views
On Tue, 21 Mar 2000 16:04:46 GMT, Lewis Townsend <keroltarr at HOTMAIL.COM> wrote: >Rett, you wrote: > >>That is why most systems choose to truncate rather than round. >>Truncation produces a printout much closer to the truth than >>rounding. Rounding, as in this case, can conceal the fact that >>a calculation will not work because of the actual underlying number. >>I would suggest that the rounding be removed and truncation be >>used in the next release...at all levels. It should be faster, and it >>would solve the other noted problems. Same should apply for >>prints of float32 or float64. They should trunc(to zeros if necessary) >>at the last possible significant digit, even if more digits are requested >>than are significant. > >Now I agree that truncation might be better than floor()ing in >some cases but I don't see how it is ever better than rounding >except in the speed department. In this case, truncation prints what is actually there. Rounding prints a piece of meta-data that is fine as a final output, but useless as information about the state of the mathematical object that is in a variable for further use. Actually, for accurate math, truncation happens first, then rounding if the number is longer than can be used or is significant in the particular calculation. The only time that rounding would come before truncation is in the case where the number self-truncates...that is to say, the calculation comes out to a finite resolution or a resolution within the representational limits of the particular system. Rounding should never happen by default. The actual rule is that truncation should happen at one digit past the point to which you wish to round as long as that last digit is significant. By the way, floor() is a truncation function. Everett L.(Rett) Williams rett at gvtc.com