Molecular Mass, compressing lists

[Ed H]

Those who have been frequented this forum for a while have probably seen my program for finding the molecular mass of a chemical compound. One annoyance I had about the old programs was that it required a ~1000 byte list to store the atomic mass of every element, and that list had to be transferred separately from the program. This is an improved version that contains the list compressed in the beginning of the program.

In my opinion, this program is already very well optimized, taking up a total of 1282 bytes, but I'm fairly sure I can compress the list smaller. The list takes up about 600 bytes in the program. I'm looking for a way to do it better.

Anyway, check it out. Here's some screens of the program:
[attachment=2903:screen1.gif]

[attachment=2904:screen2.gif]

[attachment=2906:screen3.gif]
(lol)

[attachment=2902:MOLCMASS.8xp]

[ztrumpet]

That looks really good. Will that help me later this year in Chemistry?

[calcdude84se]

Given that there is no true pattern to the numbers, it wouldn't be easy to compress it. I can't think of a lot of compression techniques, and most are assembly. I take it you want to keep your program pure BASIC. You might be able to compress in pure BASIC, but it would be slow and the total program size would probably be larger than what it is now.

As a side note, awesome program! :biggrin:

[Ed H]

[thornahawk]

[ah-blabla]

[Ed H]

[TI-newb]

Hmm. this looks awsome: And just for an idea? (this will definetly affect speed) You can always just put the number of Neutrons on the List.. and have a For( to get the numbers out.. (<- Sorry, doesnt explain much does it.. il explain in more detail)

If im correct, its Protons + Neutrons = Atomic Mass? So if u stored only the Neutrons to the List, you know the Protons go UP by one every single.. element.. So what u do to get it out is have the element #(supplied by the user?) + the Neutrons. (This will only save bytes when u reach the low 3 digit numbers..)

So yeah, just pointing out ideas, and since i dont know how your getting the inputs of names, and recognizing them. i cant really give u any solid ideas.


In my brain, i was thinking of doing

Repeat (the number of protons) = (the number the guy picked) (then i realized you might as well just put.. (the number the guy picked) -> X or something)

so yeah, idk if speed will be affected. and you can still do the earlier optimizations you stated.

[ztrumpet]

[quote name='TI-newb' post='138750' date='Nov 18 2009, 10:22 PM']If im correct, its Protons + Neutrons = Atomic Mass? So if u stored only the Neutrons to the List, you know the Protons go UP by one every single.. element.. So what u do to get it out is have the element #(supplied by the user?) + the Neutrons. (This will only save bytes when u reach the low 3 digit numbers..)[/quote]
You are correct and that's a great idea! That's a very good way to store the masses.

[Ed H]

[TI-newb]

I guess =D, but u can still just make a slightly smaller list by doing..
:1->X
:Repeat X=Dim(L1
:L1(X)-X->L2(X
:X+1->X
:End

If im not wrong, this will get the Neutrons into list2, and u can make list2 into list1 again, or whatever. (and i trust u know the Rcl button)(if you dont know what the Rcl button is, just press Rcl, and then put L2.. or L1, and it will insert it into the prgm u are currently in.)

EDIT: Some people dont have the Lower Case lettering, and in some cases, dont know where to get them (ME!), can u tell us.. or attach a file that allows lower cases? =D thanks. and i find ur string recognition cool, ive only really played around with lists.

[Eeems]

To get lowercase, just use either DCS, Mirage, or Celtic III to turn it on. Also if you search it up on ticalc, there are many different programs that will turn it on/give you a string filled with them.

[thornahawk]

So you're suggesting he store info on isotopes (which can be as few as three and as many as thirty-six) and their natural abundances, and then just calculate the atomic mass? That sounds more complicated y'know... :)

Again, unless you take number of isotopes and abundances in account, you don't arrive at the currently accepted atomic weights just by adding up proton an neutron weights, sorry.

thornahawk

[DrDnar]

Actually, approximating a data set with a function and then storing the difference is a real compression technique used in FLAC. A compression ratio of 1.7 is already pretty good, and about average for FLAC-encoded media. It looks like deflate (used in ZIPs) could reduce that to 450 bytes (350 if you compress your compressed data). Note that deflate would require an assembly program to properly decompress. While you could do it in BASIC (using base-10), you wouldn't be able to get the bit-level compression, and there'd be a lot of overhead. For a BASIC program, your solution is pretty smart. Perhaps you can improve the polynomial to improve compression.

That's also probably the best compression technique for an assembly program. If you used deflate to compress the data, you'd need to write a semi-complicated decoder, which would take up space, and is slow. For your technique, the assembly program could store the actual numeric data in BCD, halving the size. However, the decompression would still need to invoke the TIOS floating point routines (unless you used some crazy integer math) to decompress, so it wouldn't even be much faster.

[Ed H]

[DrDnar]

I personally wouldn't bother. BASIC provides excellent access to the TIOS's math function. It might be a little slow in this case, but it's not a real issue. Text input has its troubles in assembly. The biggest advantage would be that you could extract each compressed datum on-the-fly (scanning the table is fast), instead of caching the decompressed data, like you do. For the sort of small molecules students work with in basic chemistry, this would indeed be faster.

Fixed-point could be possible, but you'd have to write some math routines for yourself. I don't think 3-byte offsets will work; there isn't enough resolution. You'll also have to write a 24- by 8-bit multiply. As an upshot, you wouldn't have to scan the array to find the data. It could work. If you really wanted to use this as an introduction to assembly, go for it. Also, it's mantissa, not mass.


Graph your data. Anything stand out? Especially around, say, element 60?

[thornahawk]

D'nar,

Ed did mean "masses" in his post, it looks. To the number of significant figures retained, multiplying all those atomic masses by 10⁵ would give integers.

Anyway, here's a nice atomic mass versus atomic number plot:



thornahawk

[Ed H]

[quote name='Dr. D'nar' post='138940' date='Nov 23 2009, 11:03 PM']I personally wouldn't bother. BASIC provides excellent access to the TIOS's math function. It might be a little slow in this case, but it's not a real issue. Text input has its troubles in assembly. The biggest advantage would be that you could extract each compressed datum on-the-fly (scanning the table is fast), instead of caching the decompressed data, like you do. For the sort of small molecules students work with in basic chemistry, this would indeed be faster.

Fixed-point could be possible, but you'd have to write some math routines for yourself. I don't think 3-byte offsets will work; there isn't enough resolution. You'll also have to write a 24- by 8-bit multiply. As an upshot, you wouldn't have to scan the array to find the data. It could work. If you really wanted to use this as an introduction to assembly, go for it. Also, it's mantissa, not mass.


Graph your data. Anything stand out? Especially around, say, element 60?[/quote]

What I imagined was compressing the data in 3-byte integers, but doing the calculations on 4-byte integers. The atomic masses follow a very strong linear trend, and 3-byte offsets are sufficient to store all the masses.

What I'm most worried about is interpreting the input string (which I would probably just pull from Ans, being reluctant to write an input routine). This seems like it would be difficult.

Anyway, thank you for that catch on element 60 - I had the mass stored as 114.242, when it should be 144.242. I'm not sure how I didn't notice this earlier.

Hmm, it seems to me I should probably open up a topic in the ASM forum, as the course of this topic has shifted from the original BASIC program.