|
Forum Index : Microcontroller and PC projects : Two syntax questions.
| Author | Message | ||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
I have integer arrays wherein I store event times obtained from TIMER calls. I need to calculate and print a duty cycle, which means I have to divide one integer by another integer to produce a float then convert that float to a string and print it, maybe to a text file. Will this work, can I divide an integer by an integer to produce a float like this? OPTION EXPLICIT OPTION BASE 1 DIM t%(3) = (97080, 200000, 0) 'start, end, elapsed DIM dc ' duty cycle float t(3)=t(2)-t(1) ' 102920 dc = t(3) / t(2) ' 0.5146 print str$(dc,1,4) ' 0.5146 #2. Granpa's basic included a FIELD statement which identified sections of a string buffer filled from a random access file buffer as named variables like this: FIELD [#l<file number>,<field width> AS <string variable> FIELD 1,20 AS N$,lO AS ID$,40 AS ADD$ The FIELD statement is missing from MMbasic. Is it practical to use a string array to substitute for FIELD like this? OPTION EXPLICIT OPTION BASE 1 DIM f$(70) length 1 '1|20 N$, 21|10 ID$, 31|40 ADD$ N$="01234567890123456789" ' length 20 ID$="ABCDEFGHIJ" ' length 10 ADD$="Any old address with 40 characters is OK" ' length 40 PACK(N$,1,20) PACK(ID$,21,10) PACK(ADD$,31,40) DISPLAY END SUB PACK(S$,start%,length%) local i% for i%=0 to length%-1 f$(start%+i%)=mid$(S$,(i%+1),1) next i% END SUB 'PACK SUB DISPLAY local i% for i%=1 to 70 print f%(i%); next i% END SUB 'DISPLAY Has someone had a better idea than this? I don't feel like re-inventing the wheel. Paul in NY |
||||
| erbp Senior Member Joined: 03/05/2016 Location: AustraliaPosts: 195 |
Re Question #1: Yes you can. Your example code will work exactly as your comments show the results you expect. Just make sure you use the forward slash (/) as the divide operator - this specifies floating point division. If you use the back slash (\) it will do integer division and the result in your example will be 0. I will leave someone more familiar with string manipulation to comment on question #2. Cheers, Phil. |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1671 |
Hi Paul, maybe this is helpful. (Works for MM2) Regards Michael (from Germany )PS: I didn't try your code example. To complete this I copy Geoffs code example to this place: causality ≠ correlation ≠ coincidence |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4126 |
In the first example in post #1 there is inconsistency with t and t% which I suspect would be a bug. But the general idea looks fine. The PACK thing looks cumbersome but may well work. My understanding of FIELD is that the Field$ function is vaguely similar but not the same. However, I'm unconvinced that FIELD is really a good thing. (When forced to use it, you do. That's not to say you want to be forced.) John |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Database files are usually composed of fixed length records divided into fixed length sub-fields but there are no delimiters. The FIELD statement provides a way to identify individual sub-fields using variable names. A Database Management System additionally differentiates between persistent field variables which exist in the data file outside of the program, and transient field variables which exist in core (RAM) memory only while the program is running. A DBMS typically points to a specific record number, the location of which is calculated by multiplying the record length by the record number. It then reads the entire record into a RAM buffer and makes the sub-fields available by their defined names. A special command, usually REPLACE, is needed in order to actually write a changed sub-field from the RAM buffer into the disk file. I've been trying to figure out how much of this functionality can be written conveniently in MMbasic. I'm wondering if it would be possible to re-create interpreted dBase III in MMbasic. Between SEEK #fnbr, pos; INPUT$(nbr, #fnbr); EOF(#fnbr); LOC(#fnbr); and LOF(#fnbr) it seems that Geoff has provided all the needed functionality. Paul in NY |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
The code in question is as follows: OPTION EXPLICIT OPTION BASE 1 DIM t%(3) = (97080, 200000, 0) 'start, end, elapsed DIM dc ' duty cycle float t(3)=t(2)-t(1) ' 102920 dc = t(3) / t(2) ' 0.5146 print str$(dc,1,4) ' 0.5146 I thought that once a variable is defined by say DIM a$, b% then subsequent references to it without the type flag like a="abc" : b=2 would point to the correct variable. In other words, you only HAVE to specify the type in the DIM statement, LOCAL statement, or, in the case of a called function in the function definition like FUNCTION C$(a$, b%) where a$ and b% would effectively become local variables within the C$() function but really point back to the variables passed in the call to the function in the parent procedure. (What did that Polack from NY just say?) This also means that you can't have the simultaneous existence of an A$, A%, A! and A# the way you could in MSBasic. All of which leads to an additional question. If you define a function as a given type like C$(a$,b%) will you be able to call it without using the type character like x$=C("a",1). Comments anyone. Paul in NY |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1671 |
hmm, something like Peters "JSON$()" function for the Pi (s. MMBasic Ver 5.4.14)? causality ≠ correlation ≠ coincidence |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
@twofingers -- OK, I give up, what's Peter's "JSON$()" function and where can I find it? Paul in NY |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1671 |
@Paul MMbasic Ver 5.4.14 for Pi (aka Picromite) manual p. 16. Michael http://www.thebackshed.com/forum/forum_posts.asp?TID=9973&KW=Pi-cromite_Manual causality ≠ correlation ≠ coincidence |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
@twofingers -- ah ha, yes FIELD is something like JSON$() except that it works on the non-volatile file contents. The database file is sort of like a long string because it doesn't have any delimiters. I haven't been paying much attention to the work being done on the Pi. The absence of delimiters means that the definition of the repetitive database record has to be encoded into the program that uses it, so that each database file is only accessible by the program that wrote it. This deficiency was solved by Fred Thompson and Jack Hatfield at JPL in the 1960s. They incorporated a definition of the individual database record into a header in the database file, then they wrote an interpreter called JPLDIS which could read the header of any database file and establish the individual variable names representing the fields of the record upon reading the header of any database file. This was released to public domain by JPL in 1973 written in Fortran running on a Univac mainframe. Wayne Ratliff, also at JPL, ported JPLDIS to PTDOS running on an IMSAI 8080 in order to keep track of the office football pool. Wayne Ratliff called this Vulcan, ported it to CP/M and formed Ashton Tate with George Tate and Hal Lashlee. The name was changed to dBase II in short order. In 1984 they released dBase III which was a re-write of dBase II in C. FoxBase and Clipper later evolved from the public domain JPLDIS. Microsoft bought FoxBase and killed it. Computer Associates bought Clipper and killed it. I still can't figure out why! So much for history from the resident geezer. This is way beyond the complexity of what I am trying to do. I will be satisfied if I can make Geoffs excellent random access functions work on a file with the record definition known to the program. Paul in NY |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1671 |
Hi Paul, now I remember ... the old DBase III & Clipper-days! I should have read your text more carefully (I didn't see your 2. post). Thanks a lot for the explanation. Michael causality ≠ correlation ≠ coincidence |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Hi Michael, I'm glad to know there's somebody else around here old enough to remember dBase III. Actually I kind of liked the original IBM ISAM routines that I first saw on a 360 about 1961. That was a revelation! The Indexed Sequential Access Method required the database record definition to be in the program. This provided additional security since you could not easily figure out the structure of a database file or the indexes to it by looking at the data files so if you didn't actually have the program running you couldn't read the data. Paul in NY |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1671 |
Yes, but I guess here at the TBS are many many more of them. It's now 30 years since I programmed in Clipper. Often I thought we should have a database system for MMs ... just to play with. Michael causality ≠ correlation ≠ coincidence |
||||
| BrianP Senior Member Joined: 30/03/2017 Location: AustraliaPosts: 292 |
I'm one! B |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Good grief!! More geezers!! Should we start a contest to see who can honestly remember the Pearl Harbor radio news broadcasts and Roosevelt's "Day of Infamy" speech? Paul in NY Older than dirt. |
||||
| The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |