Omnimaga
Calculator Community => TI Calculators => TI-BASIC => Topic started by: meishe91 on October 06, 2010, 04:59:28 am
-
Ok, so I started working on my own version of a calendar generator, just for the fun of it. But when I get to my display routine something happens and I can't figure out why it's happening :( It really is not making any sense to me and I can't explain this.
The code section is this:
Text(H,12F-9,E
H=14
F=4
E=1
It just doesn't make sense to me because Text(H,39,E and other things without a variable in the second argument work fine. Anyone know?
-
It works for me, weird. Maybe it's a bug in your version of the OS? I'm using a TI-83 Plus OS 1.19, btw.
-
That's what I figured, that it should work. Ugh. This is bugging me now. This has never happened before :(
-
Are you sure that the variables are those numbers? Try putting an iPart() around the variables?
-
Ah, maybe they somehow got saved as complex numbers? Just an idea.
-
Either way, what is the problem? Like that is the error?
-
Well each time I get the domain error I always check what U (well now it is U instead of F) and it returns four. But I did put the iPart( around it and it seems to have fixed it ???
-
If you're calculating F inside a program, vars often have 0.00000000000001 or something inaccuracy, especially when it's calculated after a bunch of operations. It's horrible to debug x.x I've actually given up several projects before before I found that bug. Stupid TI-OS :(
-
Well I use round(#,0 in it but that should just return the integer part of a number, without any decimal places.
-
It didn't work after round(#,0? O.o That's weird.
-
No, it all works. I'm just saying that if you're right about it tacking on a negligible decimal point that is the only place I could see it coming from.
-
Yeah, and the homescreen automatically rounds so that you always are looking at these horrible numbers like 23.000000000008 all the time
-
Press [Math] [0] (hold [up] after this if need be) and make the equation the vars you want (H, F, and E). Press [enter] then [down]. Enjoy learning about the variables in their entirety! ;D
-
Hey thats a much faster version of what i do! I usually put them into a list and view them in the List editing menu :P
-
Wait, what is that supposed to do exactly?
Also, is iPart( the only solution to this? I thought round( would solve it all but I guess not :(
-
round() is the better solution, but i just wanted to see if that was what was causing the error :) round() does what you want, iPart() doesnt quite, but it at least takes out the error.
-
Why would round( be better in this case?
-
Because if you do some math and get a decimal that is 7.9999999999999999, iPart() will give you 7, and round() will give 8.
-
Well since the numbers are "whole" (or supposed to be and appear to be) there isn't a place where you'll get that. I have round( earlier in a the program though to take care of that issue you said though. I mean this whole issue has been about this number is supposed to be whole but apparently has a decimal place that doesn't show or something.
-
round( should always take care of it, though. Could you maybe post the code? There might be something else interfering with it.
-
round( should always take care of it, though. Could you maybe post the code? There might be something else interfering with it.
That's what I assumed but ya. Hold on.
Edit:
The code that was giving the error was:
7fPart((round(7fPart(Z/7),0)+28(M>2)+31sum(M>{1,3,5,7,8,10})+(M≥2)iPart(Z/4)+30sum(M>{4,6,9,11}))/7→U
All I did to fix that was put a iPart( in the front of that and it works, though it shouldn't be necessary (in theory).
-
Yeah the code could really help in this case, seems likes a specific instruction that is adding in the decimal
-
I posted the code in that previous post. It seems I did it before I saw you posted.
-
I'd assume it's the first 7fPart(. The round( doesn't take care of that.
EDIT: Just move the round( to the beginning (and take care of the syntax, of course).
EDIT2: In other words, do this:
round(7fPart((7fPart(Z/7)+28(M>2)+31sum(M>{1,3,5,7,8,10})+(M≥2)iPart(Z/4)+30sum(M>{4,6,9,11}))/7),0)→U
EDIT3: I haven't tested it, though.
-
Well it shouldn't matter because those just return the moduli of the equations. So they should be whole numbers.
-
Yeah, but the 7fPart( could produce another rounding error. That's why you need round(, anyway.
Not sure if I understand you correctly...
-
Try this code:
0->A
0->B
1/3->C
Repeat getKey
A+C->A
B+1->B
End
Disp int(B/3),int(A
-
Well it works now with doing what you said so it's fine. But if I understand modulus correctly it has to be a whole number (I believe) and all MfPart(A/M does is return the moduli where M is the modulus and A is the number that you're getting the moduli from (ya, some of that grammar is probably incorrect but that's because I don't know much about what is what when it comes to modulus and such). So it should be a whole number. But it works now so no worries. Thanks guys :)
@Z
What is that code supposed to do and who is supposed to try it?
-
Well, just for clarification, MfPart(A/M isn't a system routine to find the modulus. It does exactly what you see there: it divides A by M, and takes the fPart, which is some random decimal. Multiplying it by M doesn't always produce a whole number because of the calc's stupid rounding errors. It's like that trick where
Disp 1+E99-E99
produces a 0.
-
Ya, I know. But it's supposed to. But ya, it was just pissing me off because it wasn't showing there was a decimal place at all when I checked the value. So I had no idea what was going on. But thanks.
-
Never mind, my code failed. :(
-
What was it supposed to do?
-
Fail. :(
No, it was to demonstrate floating point rounding errors. It was simple enough that it didn't work. It should work now. :) (Edited)
-
Yeah, the calc only shows 11 digits of accuracy, while it really holds 14 :)
-
Isn't the error only in the decimal places? Like if you have a fourteen digit number shouldn't it retain those?
-
Yeah. But the point is fPart( often leaves that extra bit of inaccuracy which isn't displayed. They're a pain to debug x.x
-
Ya, I know, was just making sure :) Thanks again guys.
-
Yeah. But the point is fPart( often leaves that extra bit of inaccuracy which isn't displayed. They're a pain to debug x.x
That reminds me this topic (http://ourl.ca/3801). Is it the same thing?
-
It seems to be...