Re: TIB: Digital Assignment Book: CAN IT BE DONE?
[Prev][Next][Index][Thread]
Re: TIB: Digital Assignment Book: CAN IT BE DONE?
The Kellers wrote:
>
> The endless debate on what is the best way to program, from the top
> down or from the bottom up?
>
> If you know you will need certain features in the end, it is probably
> a better idea, IMHO, to put them in at the beginning and incorporate
> them right away when programming. Otherwise you find yourself
> constantly rewriting the same code with infinite little variations. So
> this would correspond to the 'top down' method.
>
> The bottom up method would be to write the program, then add the stuff
> you want, change little stuf here and there...
>
> Personnaly, I usually use the 'bottom up' method unless I know exactly
> what I want when i start writing the prog(in any language). For me,
> that doesn't happen often, but it seems to be the case here.
>
> You will save more time in the long run if, before you even start
> coding, you figure out exactly what you are going to do (and make sure
> it is possible). Figure out how to store the data, how it will be
> accessed and modified by the user, how customizable everything will
> be, what subroutines you will need, etc.
>
> Philipp Keller
>
> ----- Original Message -----
> From: <ALURGEE@aol.com>
> To: <ti-basic@lists.ticalc.org>
> Sent: 13 February 1999 19:44
> Subject: Re: TIB: Digital Assignment Book: CAN IT BE DONE?
>
> >
> >My school has 9 seperate classes and 8 period days (except every 3rd
> wednesday
> >when school ends at noon and there are 5 periods)..and every Monday
> and
> >Tuesday there is an extra period for an assembly..so that makes 9
> periods...
> >
> >In short, I am sure every school has it's own variation of the
> infamous block
> >schedule. Therefore, I think the DAB (digital assignment book)
> should end up
> >being user personalized but only after all the major programming
> tasks have
> >been completed. Worrying about the abitility to pin-point the number
> of
> >classes will only slow the process down. We must work on the macro
> scale and
> >then begin working on a micro level if this program will satsfy the
> general
> >TI-User population.
> >
> >In a message dated 2/13/99 6:00:04 PM Eastern Standard Time,
> JIF578@aol.com
> >writes:
> >
> >> great idea!! I wish somehow it would work on my ti-85, also I would
> want a
> >> choice between 7 and 4 classes with the block scheldeules in my
> school next
> >> year
> >>
> >
I like to build things as they go along, too. If I want the program to
do something some way, then I try to make it do that right from the
start. Otherwise I've found that the entire thing gets really ugly,
especially if you have things that need to set in various places to
accomplish one task. It just gets to be too much if you start changing
things later and then you realize that somewhere in the middle you
forgot to change the way G increases or the way F decreases or something
like that. It can sure take a lot of trouble shooting when that
happens. Anyway....
I think that a pretty good product could be created in BASIC. I say
this mostly because I don't know any ASM, but I want to come up with
something workable. I think that the best bet for storing most of the
data will be to use strings. They are the most memory friendly.
However, they are annoyingly difficult and slow to rearrange and mess
with. However, lists are not. The closest thing that I have ever done
to something like this was a Rolodex type phone directory. It allowed
entry of a name (up to sixteen characters [the width of the 83 screen])
and it required an 8 character phone number (the eighth character was
the hyphen). The user could entire as many different entries as memory
allowed. After an entry was inputed the program scanned all the
entries, very quickly, searching for any duplicates. If one was found,
then user could either create a second entry or just leave the one. If
no duplicate was found, the program would insert the new entry in
alphabetical order in with all the other entries. Then, of course, the
next time you looked at the display of entries the new one would be in
the correct spot. One the display there was a little > sign on the left
that would show which entry you were on, and the top line on the screen
showed "xx of yy" where xx was the number of the entry you were on, and
yy was the total number of entries. One of the other neat things about
the display was that you could jump to the top of any given letter of
the alphabet. So, if you wanted to jump to the top of the J's, all you
had to do was press J. This was very quick because of the type of
search algorithm. Instead of just checking each entry after the next to
see if it was there yet, it would check the middle entry. If the middle
entry was greater than the desired one, then you could automatically
eliminate latter half of the entries without actually having to check
them. Likewise, if the middle entry was smaller than the desired one,
you could eliminate the first half without having to check them. This
process was repeated untill you eventually got to the one you wanted.
Anyway, other options from the main screen included being able to search
by name, search by number, delete specific entries, add new entries
(duh!), display entries, reset the phone book, and quit. The reason for
the reset option was because I wanted the program to be self contained.
For example, the program used a few special lists and str6. If you
someone transfered the program to a friends calc and forgot, or just
didn't realize, to transfer the lists as well, then it wouldn't work.
However, when they select 'reset' the program automatically sets
everything that it will need. Anyway, the program itself was only 3329
bytes. There were also 2 lists that took up 13+9(number of entries)
each. Lastly, the program used strings 1,3,and 6. String 3 was 39
bytes, and the other two started at 9 bytes each, and went up depending
one the number of entries. Well, I've kind of rambled about this long
enough. If anyone wants more specifics about how the program actually
works, just let me know. I guess the point of all this is to show that
you can use lists and strings effectively to keep the memory low, and
you can also have things sort in alphabetical order.
Jody Snider
jody1@alaska.net
References: