One of TCC's best features is the huge amount of precision available for calculations (I brag about it to my programmer friends all of the time). However, it is somewhat of a limitation that these outputs (and inputs) can not be expressed in normal scientific notation (+d.dddd...dE+ddd). The lack of scientific notation for output is not too bad; I wrote a batch file that can be ExecStr'd a long time ago to do that job and it works perfectly (although having to use @ExecStr is a bit of an inconvenience). However, the problem I have now is on input; I want to read and process data that is produced by an executable sometimes using scientific notation (which is reasonable because this executable produces values like 7.3972568E-013), and a routine to translate that back to TCC's "natural" format is not really a trivial thing to do. (I found a solution to my problem by calling an external executable that I wrote a long time a ago to read and process these numbers, but calling that executable hundreds of times is somewhat of a performance hog.) And I have to add that 7.3972568E-013 is a lot more readable than is .00000000000073972568 in my opinion. So my request is simple: Provide a way for TCC to both read and write numbers written in scientific notation.
Done Scientifc notation...
- Thread starter mathewsdw
- Start date
- Aug
- 2,016
- 81
When I have to call an executable many times, I re-write the code into a plugin, and call it as a command or variable function from a plugin. This may be a solution for your situation.
Joe
Joe, thank you for your input, but that's not really possible for me. Number one, that is not what the program in question was written to do nor what it really does; it just happens to accept scientific notation (or any other valid way to express a number) on input and can be made to express it in a (limited!) number of different formats on output without actually having done any processing on it. Therefore turning it into a plugin would be the relatively major task of finding the code in question an stripping it out of the program. Number two, it uses floating point doubles internally, so it's inherently limited to about 15 digits of precision, hardly worthwhile in terms of TCC. Number three, if you're not familiar with me I am dependent on TCC because it offers me a whole number of ways to work around my disabilities; I literally couldn't use this computer without it and I would therefore be dead in the water as the saying goes (I could not survive on my own without this computer). And the end result of my disabilities is that I am no longer competent to write a plugin. And if I was fully competent, I would have just written a batch file that was ExecStr'd to do the conversion (as I did for writing scientific notation on output), but that is pretty beyond my present capabilities.
- May
- 13,121
- 180
A plugin, say @EE[N,expression], that would simply expand @EVAL[expression] and then convert the result to scientific notation with N decimal places, wouldn't be to hard. But then I suppose adding to @EVAL suffixes like (e.g.) "=E6" (cf. "=H", "=2", ...) wouldn't be too hard for Rex. That'd take care of output. I suppose input would be a little more difficult.
But Vince, you've hit the nail on the head! As I think I said, I've had a batch file (that is @ExecStr'd) to do the output conversion for a number of years, and it wasn't all that hard to do. It's the input side (and my programming philosophy is that anything that may be considered a valid number is acceptable; 0.00000001234E20 and 987654.321E-20 would both be OK) that is pretty much beyond my present capabilities.