1. Strange problem
------=_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
-
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
-
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
-
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
-
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
-
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
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
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
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
-
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
-
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
-
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
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
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
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
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
