real number values won't work in rbase

[breck53]

Just got the vdos to run my rbase at least to the point that everything looks correct on the surface, ie menus and modules all look like they work.  I decided to do some tests and tried an old program I wrote in late 80's.  It converts real # to text so 10.52 writes out as ten & 52/100 (for checks).  I just happened to try this because I wanted to test printing function.  A table with only 2 colums (valu=real & word amt ) is used to break down a number to its parts.  The real  # portion was scrambled and values gone.  I tried replacing but it would scramble in little while again and again.  I checked a column in another table that was defined as real, scrambled also.  I did a little test ; set a var to real , set it to a value (10) and then show it and it shows as 0.E18, same as the values in the real columns in the 2 tables I checked (actually 0.E17 or 18).  In book it says real values are stored in binary form and those with more than 6 digits are shown in scientific notation (for example 9.0E +32).  Any ideas on how to fix real numbers or any fix.  Thank   using rbase for dos , running in win 10 64 bit.  I got out a win 32 bit and ran the same program and it worked fine, no flaws, and I've run that program for 40 years with no problems, so the problem is not in the program but something with real values.

[Jos]

Using a FPU (floating point) to store and calculate fixed precision values was always a pain in the ass.
For instance 1/2*2 could compute to not exactly 1. So a program (or the library used) implements correcting routines to deal with that.

It gets more complicated: A real FPU uses internally 80 bits. A simulated one 64 bits, with less precision.
Shouldn’t have a real impact since a program also uses at most 64 bit to store those values.
But internal 80-bit computing, translating to 64-bit values versus all 64-bit can affect the fixed precision values.

Next complication: Some early FPU’s were buggy, and a program (or library) could also implement correction routines for that.

Last complication: At some moment a program has to display what a floating point value is in human readable text.
That’s certainly no easy task. The FPU however provides for a function that translates a floating point to a BCD packed one.
The latter can easily be converted to readable text. But requires preparation to deal with precision issues.
Like multiplying the floating point value with for instance 1,000 upfront, use the most significant part, and consider this translation at displaying the fixed precision value.

vDos already mostly counteracts previous issues. For instance by rounding off floating point values that come extremely close to fixed precision values.

By mere change I got this week a report values not displaying correctly in one column by a program.
Doesn’t mean the values themselves are incorrect.

Without anything to go into, I focused on a somewhat similar issue with dBase IV.
Fixed the rather stupid corrections of that, like dividing a value by 2, then multiplied twice by the root of 2 (its value provided by dBase IV, not calculated by the FPU).
That certainly mostly doesn’t compute to the original value.

That additional vDos fixes did it for dBase IV, though no real idea for your program. Those could however share the same FPU library?

Jos

[breck53]

thank you for that, Jos. I didn't really expect anything. I have been working on it for hours now and there is a major bug. dbase IV was supposed to be very closely correlated to Rbase at the time. I had a program which has no real way of converting a currency value to a real value, it was always a program I wanted to fix because the only way around the problem was to redefine the column from currency to real, take the values, and redefine it back. It worked with no problems up through win10 32 bit but (just by unluck) I happened to use that program to try and test the print capabilities. I just spent 5 hours trying to get abound the problem and now remember why I let it be a sloppy solution 30 years ago. It works with no bugs in win 10 32 but when I redefine that column in 64 it scrambles all my real values in that database, and I just figured out what was happening. If you have any ideas I'm all ears. It's a real bummer because the program works super fast and besides that one bug everything else seems to work great. I haven't gotten to the printing yet. Going to quit tonight because I'm disgusted. Thank you very much.

[Jos]

It hasn’t been confirmed yet that the recent modifications to the emulated FPU fixed the original reported issue of incorrect displayed values in one column.
I sent two days ago a vDos.exe by wetransfer to test, and it hasn’t been downloaded yet.
I could send you the same one to have a look if it also applies to Rbase.
Mind that vDos.exe is only for testing and cannot be used to replace version 2021.05.01, you would have to wait for the next vDos release, prognosed for May 1st.

Jos

[breck53]

That would be fantastic. Overnight I slept on it and it came to me how to solve the problem of the conversion. It's so simple I feel embarrassed to admit it. If I take a currency value, divide by 1 and then set it to a real variable, then I don't have to redefine the column and can avoid what I believe is the causative agent of the glitch. The glitch only seems to occur when I redefined the column within my program. I worked for many hours doing work with real numbers along with adding them to columns and manipulating the data in the columns and everything worked great until I redefined the columns. Strangely, I have noticed that if I close the computer down and come back later the values in most of the columns reappear. If I didn't make a subsequent change to the column after the values disappeared then they return. (?) In the meantime I will fix my program so that that sloppiness is resolved, I had notes to myself to fix that program for about 35 years, and I never got around to it. It worked up through win 10 32 bit so I just let it go. But Yes, I would like to try the fix. I had tried to set up my programs in virtual box first and that was clunky, slow and buggy. I then went to winevdm and had it working on a basic level when I came across vdos and decided to try that. In about a day I had it up and running and it seems to be very fast, efficient, and clean, compared to the others. Rbase and dBase were major competitors at the time and many of the features in Rbase are specifically designed to work with dbase so I would bet if the fix works in dbase it will also work in Rbase. Thanks for all your help. _Breck