While on a field trip, I decided to make a few card games and generated a randomization of the numbers 52. However, I run into a problem that I can only think that must be caused by the TI-OS.

What happens is that I use code similar to:


Code:


L1 is a randomization of the numbers 1, 2, 3, ..., 52.

When ever I run something like this, it always seems to produce error domain (even if I just use a list of the numbers 1 to . However, when I take the actual value of the 1+32fpart(L1(I)/4), and write that out (as a numeral, not a variable), it works. It does not work if I store the value to a variable.

Any reasons this could happen? I think I posted a similar thing about this a while ago, but I didn't have a clue what was happening then.

unless I'm mistaken, fpart( is the decimal value, not the integer value. As far as I know, you can't take a substring with a value that has a decimal. Are you sure you didn't intend for that to be ipart(?

Yes, I am sure. Note that 32fpart(x/4) can only take on the values 0, 8, 16 and 24.

Like I said, if I take the actual value generated by the calculator and use that, it works. It does not work if I try to make it calculate that during the program.

Well if that returns 0, sub( will return a domain error.

No, because it is 1+32fpart{L1(I)/4).

Also, It seemed to work for some certain values, but not others. Like it worked for 1-4 but would not work on 5 when just testing with a list of 1-8 (I never tested 6-.

It worked just fine for me. (L1 was 1-52 in sequential order) Not sure why it isn't working for you... (tested on TI-84+SE)

I've had similar errors in the past. If I'm not mistaken, it has to do with bad rounding in the 15th and 16th places of floating point numbers. Even though multiplying that by 32 would theoretically get rid of the decimal, the calc needs a perfect integer and screws up somewhere. Try iParting the whole argument. What happens then?

haveacalc is correct - it's a precision rounding error. Use ipart.

Aye, for about half an hour one day I was trying to use sine and cosine with pixels and kept getting a domain error till I checked what A and B were and was like.. I wonder if the decimal is skrewing it... to bad there is no ERR: DECIMAL lol. I thought by domain it meant off the edge of the screen =/

OK, thanks. I was thinking it had something to do with rounding, but it didn't show up on the screen when I took the actual value, so I wasn't sure.

It now works, when I added the iPart section.

Now, I really wish that texas instruments had decided to support multiple types of variables (i.e. integer, real, etc) .

Still, you wouldn't think that something that is dividing by 4 would produce an error (only 2 maximum decimal points), although it might have been the 13 it messed up on, I don't remember.