Feature Requests

admin

Make requests and suggestions here.

vintzend

John Arscott used to sell some of his TB libraries on his personal website. That website has been taken down AFAIK.

1) Could it be an option and/or arranged to sell those from the TB site? It's been many, many years a new official Toolkit was added, so a new one is quite overdue isn't it? 😉

2) I bought the main GUI library long ago, does anyone know if there were updates at any time?

Just an idea
-- VIncent

admin

Unfortunately I haven't heard from John in quite some time either, but I will reach out and see if I can get back in touch. I'll also look in the archive and see if I have any of his libraries, though I'm doubtful as he did retain ownership of those himself rather than offer them as a joint venture with TB. Anything I can find, I'll offer on the site. Thanks for the suggestion!

Re: main GUI library, the most recent thing I can think of is the FORMS interface builder; if that's what you're referring to there hasn't been an update since the last one to update it to v6.006, which covers 6.007 as well. Let me know if you're referring to something else.

daveR

I purchased Johns libraries when they first came out. The CTX library I have is dated 6/3/2011. 136 kb in size. I think the documentation states version 10. I had hoped they would be extended to include other features.

cjiii

Please tell me how John is doing by offline email at info@cec-services.com, Colin (one of first 250 to learn Dartmouth BASIC in fall of 1964 in prep school in NH)

cjiii

One of the maintainers of TrueBASIC about three years ago mentioned an error in TrueBASIC regarding numeric represeantation, implying the most immediate need for bug fixing.
Please tell me if that was fixed or not, and if not what exactly the error is so I can build a workaround for my numeric processing. (I suspect it emits from a C-coding problem, since all bad programming leads back to C.)

mcc

Hello cjiii,

That "bug" appeared in the TB forum on or about 20Nov15. It appeared to be a genuine numerical bug but sadly I do not remember exactly what was stated in the post, or what the apparently differing numbers were.

It somehow involved the value of 8^1/3. I replied to the post at the time, but unfortunately did not copy the original post which described the problem.

I think it amounted to the round-off "crumbs" resulting from the way values are displayed, if I recall correctly. But somehow there were conflicting values which looked as if it may have actually been some sort of bug. I am sure it has nothing to do with C or C++ because TB was NOT written in C or C++. Once I had some files with some of the original code and it looked to me to be more like machine language type stuff.

Anyway, here is a part of what was in my 22Nov15 post:

"Hmmm. That's the first bug I've ever encountered in True Basic. It's not just "version 6", since the underlying core code for any and all versions is exactly the same. I have Silver 5.33 and Gold 5.5b19, and both give this same anomaly. I'm sure the old DOS version would also behave the same, but I can't run that one now.

Since there is no one who knows how to change/modify the core code, it's not ever going to get fixed. This bug is disturbing.

Anyway, to get an idea of the problem, add the following lines and note that some digital "crumbs" are left over and somehow this may be causing the problem.

print 8^1/3 ! This rounds the value for display
print using "##.##############":8^1/3 ! Now you can see the actual value computed
print ip(8^1/3) ! ip() is doing exactly what it's supposed to do. It works on the actual value, not the displayed value.

print
print,"1-cube root of 1=";1-(1^1/3)
print,"2-cube root of 8=";2-(8^1/3)
print,"3-cube root of 27=";3-(27^1/3)
print,"4-cube root of 64=";4-(64^1/3)
print,"5-cube root of 125=";5-(125^1/3)
print,"6-cube root of 216=";6-(216^1/3)
print,"7-cube root of 343=";7-(343^1/3)
print,"8-cube root of 512=";8-(512^1/3)
print,"9-cube root of 729=";9-(729^1/3)
print,"10-cube root of 1000=";10-(1000^1/3)
print,"11-cube root of 1331=";11-(1331^1/3)
print,"12-cube root of 1728=";12-(1728^1/3)
print,"13-cube root of 2197=";13-(2197^1/3) ! etc

print
LET x1=2^(log2(8)/3)
LET x2=10^(log10(8)/3)
LET x3=exp(log(8)/3) ! which seem to work correctly.
print
print, x1,x2,x3
END
----------------------"
Perhaps some other poster will happen along who remembers more details of this "bug" as it was posted. At any rate, if a real bug it has never caused any problem for me that I am aware of.

Hope this helps, at least a little bit.

Regards,
Mike C.
PS: I note that this forum changes the "caret" used for exponentiation in Basic notation to an actual superscript. You may have to edit the above code in order to actually run it. MC

cjiii

Dear Mike C:

Many thanks. That may explain why the gamma routines in FORTRAN to BASIC barfed on me for calculating the Fischer P in my N-by-M contingency test, originally to raise the exception of division by zero,

My work around was to prefill the arrays used with a non-zero value of 0.00000000001 which did not affect the numeric results so far as I know. I forget why I used 1.e-11, instead of something smaller as your formatting template of 1.e-14 . Maybe it had to do with an accumulated error not noticed until 1.e-11. In other words, a prefill of 1.e-12 would still look like zero to raise an exception. The constants used are up to 16-decimal places. My free source code is published at https://ersatz-systems.com/chi2.source.code.pdf .

(If you inspect the source code and see any programming mistakes, please telll me to fix right away.)

Now I think I kind of know why.

Vty,

Colin