Questions, possible bugs
Submitted by LanceGary on Tue, 09/22/2009 - 13:16.
I'm using FLTK SmallBasic 0.10.5 on Windows Vista (Home Premium edition).
The following small program
a=[2,3;-1,4]
b=inverse(a)
? b
? 4.0/11
yields the following output:
[0.3.63636e+008,-0.2.72727e+008;0.09.09091e+007,0.1.81818e+008]
0.3.63636e+008
There seems to be an extra decimal point entered into these numbers. Is this a bug or something I don't understand?
The some queries.
1. Is it possible to select and copy from the output window? I have been struggling to do this.
2. Where is the log file to which logprint prints? How is this file accessed?
3. Is it possible to set default locations for files to be saved and loaded that will be loaded each session? If so, how is that done?
Lance
Hi Lance, The original
Hi Lance,
The original problem with calculating inverse was a division by zero, causing NaN to be propagated to the final result. The problem now is rounding of intermediate floating point values causing the final result to be skewed. Ideally I think the function needs to be rewritten but I'm a bit out of my depth with this stuff. Maybe someone will come along and help out.
I'll try to answer your other questions:
1. Atm, there is no direct way to cut+paste from the output window. You could output text using the HTML command and then cut+paste, or use logprint, or you could write output to your own file. Do you want to be able to copy output as text or a graphic?
2. The logprint command will write to a file called sb.log usually in the root of the c-drive. I was thinking of changing this to call OutPutDebugString() in windows, then you could see the output in a tool like DebugView. Do you think that would be useful?
3. The session files are located using a series of environment variable lookups until one is found - HOME / TMP / TEMP / TMPDIR, then ".smallbasic" is appended giving the final path. So if you set HOME=c:/home the path will be c:/home/.smallbasic/.
Thanks for your reply. I'm
Thanks for your reply. I'm going to do a little checking when I get chance but I think the problem of the double decimal point occurs in problems other than the inverse function - see the code I originally posted. Below the inverse I had a division problem that also resulted in a double decimal point. As far as I could work out the answers were right except for the repeated decimal point. So I think it is a display problem rather than a maths problem. Anyway I will check with more examples when I get chance.
Thanks again for the reply,
Lance
Testing Division
Here is the result of some tests on the division operator. Notice that some, but not all, of the results have a second decimal point included in them:
logprint "1/100 = ";1/100
logprint "1/90 = ";1/90
logprint "1/81 = ";1/81
logprint "1/73 = ";1/73
logprint "1/50 = ";1/50
logprint "1/32 = ";1/32
logprint "3/32 = ";3/32
logprint "7/30 = ";7/30
logprint "8/32 = ";8/32
logprint "1/21 = ";1/21
logprint "1/11 = ";1/11
logprint "1/10 = ";1/10
logprint "1/9 = ";1/9
logprint "1/8 = "; 1/8
logprint "1/7 = "; 1/7
logprint "1/6 = ";1/6
logprint "1/5 = ";1/5
logprint "1/4 = ";1/4
logprint "1/3 = ";1/3
logprint "1/2 = ";1/2
logprint "1/1 = ";1/1
logprint "0.5/1 = "; 0.5/1
logprint "0.3/1 = "; 0.3/1
logprint "0.4/1 = "; 0.4/1
-------------
Output
1/100 = 0.01
1/90 = 0.01.11111e+007
1/81 = 0.01.23457e+007
1/73 = 0.01.36986e+006
1/50 = 0.02
1/32 = 0.03125
3/32 = 0.09375
7/30 = 0.2.33333e+008
8/32 = 0.25
1/21 = 0.04.76190e+007
1/11 = 0.09.09091e+007
1/10 = 0.1
1/9 = 0.1.11111e+008
1/8 = 0.125
1/7 = 0.1.42857e+008
1/6 = 0.1.66667e+008
1/5 = 0.2
1/4 = 0.25
1/3 = 0.3.33333e+008
1/2 = 0.5
1/1 = 1
0.5/1 = 0.5
0.3/1 = 0.3
0.4/1 = 0.4
...division
Hi!
Same problem (second decimal point) with version 0.10.5 / XP