+Lee Stewart Posted November 4, 2012 Author Share Posted November 4, 2012 (edited) Floating Point Library--- Regarding formatted output of floating point numbers: The FPL allows for a field width of 14 characters, including the sign and decimal point, but excluding the E-notation field (E-field) if E-notation output is specified. The exponent in the E-field may be specified to be 2 or 3 digits. This means the E-field will add 4 or 5 characters to the output string's width, e.g., "E+12" or "E+012". The number of characters to the left of the decimal point, including 1 character for the sign, must be specified. The number of decimal characters, including the decimal point, must be specified. Showing a '+' instead of a space for a positive number may be specified. The specifications for formatted output also allow for an option called "explicit sign". I Have not found that this option affects the output in any way. It is not even required to effect the output of '+', even though the specifications say otherwise. In the TI-99/4A, a floating point number in radix 100 (base 100 or centimal) format can have 7 significant centimal digits in the mantissa. This means that it can have 14 decimal digits, 2 for each centimal digit. When a floating point number is entered, it is always normalized to have a non-zero first centimal digit. This means that any given decimal entry may have 1 or 2 of the first non-zero digits in the first centimal byte of the mantissa. It appears from my research that the entry of an even number of decimal digits as the integer portion of the number will be stored with the first 2 digits in the first byte of the mantissa. An odd number will result in only 1. With the possibility of 14 significant decimal digits, it puzzles me that the designers of the FPL did not allow for the output of all of those digits instead of limiting it to just 12. Anyway, I am down to deciding how to write the Forth words and what to name them for the above possible output combinations. Any suggestions are welcome. The possible fixed formats with first-thought names in "()" are Fixed point ( FF. ) Fixed point with '+' ( FF+. ) E-notation ( FFE. ) E-notation with '+' ( FFE+. ) Extended E-notation ( FFX. ) Extended E-notation with '+' ( FFX+. ) Each of the above would require the left and right fields on the stack. Of course, I could write just one word that takes some kind of format indicator. I was steering away from a mask that does not help the programmer remember what it's for. Maybe I should just throw examples out there to get suggestions for modification. This worked rather well for the FP compares. I'm finished rambling for the moment... ...lee Edited November 4, 2012 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 5, 2012 Author Share Posted November 5, 2012 (edited) Floating Point Library--- Ok, here are the FP formatted output words: \ fixed format display routines: \ intLen places to left of decimal point, including sign \ fracLen places to right of decimal point, including decimal point \ mask includes bits to be ORed with FAC+11 = 1 for sign and E-notation options : fixFmt. ( ds:intLen fracLen mask -- fs: n -- ) \ display the top fp number in fixed decimal format fps>fac \ top of fp stack to _fac 1 OR _fac 11 + C! \ fixed format output + sign and E-notation options _fac 13 + C! \ digits to right of and including decimal point _fac 12 + C! \ digits to left of decimal point, including sign $0012 goFPL \ convert fp number to string at _fpstr fixSP \ restore scratch-pad memory _fpstr COUNT TYPE ; \ display it : FF. ( intLen fracLen -- | n ) \ display fixed format fp value n 0 fixFmt. ; : FF+. ( intLen fracLen -- | n ) \ display format fp value n with '+' %110 fixFmt. ; : FFE. ( intLen fracLen -- | n ) \ display E-notation fixed format fp value n %1000 fixFmt. ; : FFE+. ( intLen fracLen -- | n ) \ display E-notation fixed format fp value n with '+' %1110 fixFmt. ; : FFX. ( intLen fracLen -- | n ) \ display extended E-notation fixed format fp value n %11000 fixFmt. ; : FFX+. ( intLen fracLen -- | n ) \ display extended E-notation fixed format fp value n with '+' %11110 fixFmt. ; These all appear to work quite well. I should soon post the whole package for others to fiddle with. ...lee Edited November 5, 2012 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 5, 2012 Author Share Posted November 5, 2012 Floating Point Library--- Regarding formatted output of floating point numbers: ... With the possibility of 14 significant decimal digits, it puzzles me that the designers of the FPL did not allow for the output of all of those digits instead of limiting it to just 12. ... ...lee I think I just figured this out. The limitation is imposed without regard to the type of number (integer, fixed point, floating decimal), probably, to simplify the limitation calculation. You can actually get 14 digits displayed in one situation, viz., a 14-digit positive integer output with 14 0 FF. will display all 14 digits with no decimal point and no space for the sign. With E-notation, the max is effectively 13-digit output with 0 14 FFE. because one position is taken by the required decimal point. I guess it all makes sense. I would just like to be able to get all 14 digits (if they're significant) when I want them. It's probably not worth the effort to mess with the ALC just to satisfy my whim, however! Maybe I'll write my own free-format 14-digit output so we can see the entire number as it exists in the 8 bytes where it is stored. ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 6, 2012 Share Posted November 6, 2012 Lee, Can you recall what the issue with LOAD/CLOAD was, and if possible, state the steps needed to reproduce the issue? Thanks Looking forward to getting my hands on the FP code Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 6, 2012 Author Share Posted November 6, 2012 Lee, Can you recall what the issue with LOAD/CLOAD was, and if possible, state the steps needed to reproduce the issue? Thanks I was going to quote some of the verbiage from our PM exchange on the subject, but it's too long. It's in our "Floating Point & Transcendentals Source" PM thread. I also noticed another odd behavior somewhere in the LOAD , CLOAD , --> execution: I LOADed block 36, which I had replaced with code to load block 48 ( #3LOAD ), Load the FPL object code, Clear out the loader, Move FPLLNK to where the removed loader used to be, Change block file (BLOCKS_FPL) to the one I'm temporarily using for the FPL and, Finally, load the FPL I got an error that an odd word couldn't be found. It turns out that my FPL blocks' last block (16) ended mid-block and LOAD was continuing from that location in block 16 of the original BLOCKS file! The problem seemed to go away if I jammed the last executable TF word right up against the end of the last line in both blocks (block 36 of BLOCKS and block 16 of BLOCKS_FPL). Looking forward to getting my hands on the FP code I'll PM it to you in a little while. ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 6, 2012 Share Posted November 6, 2012 Thanks for the info, I'll now start looking at this problem in earnest. It may require extensive re-writing/factoring of the compiler and associated words (INTERPRET and WORD in the main). Sigh. In the meantime, here is a new build which fixes a few more issues that I found, including an issue I found with loading blocks (though unrelated, it was associated with loading blocks that had not been flushed). It also adds the new words UNSIGNED VTYPE and EVALUATE. Details in the release note. UNSIGNED can be used to replace the hard coded address in ASM>CODE - see block 30 on the attached. Also, on the blocks disk, a text file loader! (Block 50). It can compile Forth source code directly from blocks text files. On a real TI, these would be DV80 files written with your favourite text editor. On a PC with classic99, you just save your text file (with a .txt extension) directly into one of the DSK folders of classic99, and classic99 will feed it to TF as a DV80 file. TF then just compiles what it sees. The text file compiler is a massive 238 bytes TF-V1.2-06-Nov-2012.zip V1.2-ReleaseNote.pdf BLOCKS.zip Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 6, 2012 Author Share Posted November 6, 2012 (edited) @Willsy... Thanks for all this! H-m-m-m...What happened to ABORT in this build? Loading the E/A#3 loader throws an error claiming " ABORT not found ...". ...lee Edited November 6, 2012 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 6, 2012 Share Posted November 6, 2012 Woops... Hang on a minute!... Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 6, 2012 Share Posted November 6, 2012 :dunce: The link field in VTYPE jumped over ABORT. Woops! TF-6-NOV-2012-II.zip Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 6, 2012 Author Share Posted November 6, 2012 :dunce: The link field in VTYPE jumped over ABORT. Woops! TF-6-NOV-2012-II.zip Ah-h-h! That's much better! ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 7, 2012 Author Share Posted November 7, 2012 (edited) Floating Point Library--- @Willsy... I had to change the TF definition of FNEGATE because it fails under certain circumstances. If the first 13 significant digits are 9s and the 14th digit is anything other than 0 or the exponent is the maximum legal exponent, with the definition as : FNEGATE FDUP FDUP F+ F- ; the negation doesn't work most of the time. : FNEGATE >F 0 FSWAP F- ; or : FNEGATE FPSADDR 8 - DUP @ NEGATE SWAP ! ; handles it nicely. The first definition has to be moved after the definition of >F because we're using it in FNEGATE . Which of the new definitions for FNEGATE is faster? ...lee Edited November 8, 2012 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 8, 2012 Share Posted November 8, 2012 Hi Lee, I believe the second definition is much faster as it doesn't manipulate the floating point stack and doesn't invoke any floating point functions. Why does my original definition fail sometimes? Is it an accuracy/ resolution issue? Certainly, if we were talking about integers here I'm sure it would work! Strange! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 8, 2012 Author Share Posted November 8, 2012 (edited) Mark... With the 14th digit involved, I think it's a rounding issue. Before returning, the FP routines look at the 9th byte to see whether rounding is necessary, but I did not pin it down definitively. The problem with the max exponent may be related because the intermediate sum would exceed the max exponent. However, I'm not certain of that one, either. Also, NEGATE won't work in one instance, -32768; but, because it's just that one instance, it's probably reasonable to expect the programmer to remember it. ...lee Edited November 8, 2012 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 8, 2012 Author Share Posted November 8, 2012 (edited) <duplicate post> Edited November 8, 2012 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 8, 2012 Author Share Posted November 8, 2012 (edited) Floating Point Library--- I propose that the following words be added to the FP library: : .F$ ( -- ) \ display floating point stack in hex, 8 bytes/line _fpsc 0> IF TRUE ZEROS ! _fpstack DUP _fpsc 8 * + SWAP DO CR I 8 + I DO I @ $. 2 +LOOP 8 +LOOP ." <--TOP" CR FALSE ZEROS ! ELSE ." Empty " THEN ; : F$. ( -- ) \ display all 8 bytes of floating point number on top of stack in hex fpsc-- TRUE ZEROS ! fpsaddr DUP 8 + SWAP DO I @ $. 2 +LOOP FALSE ZEROS ! ; : FPCLEAR ( -- ) \ clear floating point stack 0 TO _fpsc ; What do you think? I wanted to use FP! for FPCLEAR for consistency with SP! , but it probably is not a good idea to allow folks to redefine the start of the FP stack on the fly, yet. ...lee Edited November 8, 2012 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted November 9, 2012 Share Posted November 9, 2012 Sooo, how close are we to the final TF version? Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 9, 2012 Share Posted November 9, 2012 Lee, I think if you think it's useful, then go ahead and add it! If folk only want a subset then they remove stuff themselves. That's Forth. I personally probably wouldn't use it much. I'd only use it for curiosity - to see the byte representation of an FP value. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 9, 2012 Author Share Posted November 9, 2012 (edited) Sooo, how close are we to the final TF version? Do you mean the FP package or TF itself? If the former, I believe its pretty much done. I'm working on the documentation. If you mean the latter, @Willsy will need to weigh in. ...lee Edited November 10, 2012 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 15, 2012 Author Share Posted November 15, 2012 Floating Point Library-- Some changes and additions: Renamed SQR to SQRT. Renamed INT to FLOOR, i.e., greatest integer not greater than the number, because that's what it is, really. Added CEIL to leave the ceiling integer of the FP number on top of the FP stack, i.e., the least integer not less than the number. Added TRUNC to leave the integer part of the FP number on top of the FP stack. Added FRAC to leave the fractional part of the FP number on top of the FP stack. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 15, 2012 Author Share Posted November 15, 2012 Floating Point Library-- Added FABS, returns absolute value of top FP number. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 15, 2012 Author Share Posted November 15, 2012 Floating Point Library-- Nearly time to post! Next week at the latest---maybe sooner! ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 15, 2012 Author Share Posted November 15, 2012 <duplicate post> Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted December 5, 2012 Author Share Posted December 5, 2012 I'm obviously a little late on the posting of the Floating-Point Library. The holidays are partly to blame, but I have some other issues that need resolution before I can move forward. Not long, though! ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted December 16, 2012 Author Share Posted December 16, 2012 Floating Point Library-- Sorry it's taking me so long to finish with the Floating-Point Library. @Willsy has dramatically increased the speed of much of TurboForth V1.2; but, in the process, I needed to change how the FPLTF ALC works and rewrite much of the high-level TF code for the floating-point words. I believe I am finished with the FPLTF changes (only 66 bytes larger); but, the high-level TF rewrite will take a bit longer. This is due partly to writing some (most?) of it in TF assember. ...lee Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted December 23, 2012 Share Posted December 23, 2012 Floating Point Library-- Sorry it's taking me so long to finish with the Floating-Point Library. @Willsy has dramatically increased the speed of much of TurboForth V1.2; but, in the process, I needed to change how the FPLTF ALC works and rewrite much of the high-level TF code for the floating-point words. I believe I am finished with the FPLTF changes (only 66 bytes larger); but, the high-level TF rewrite will take a bit longer. This is due partly to writing some (most?) of it in TF assember. ...lee Hi Lee, any chance the FPL will be usable outside of Forth? Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.