forums.silverfrost.com

[Little-Acorn]

I've used CNUM several times to convert an integer value such as 517, to a character string containing a 5, a 1, and a 7.

Is there a similar function that can convert a real number such as 3.14 to a character string containing a 3, a period, a 1, and a 4?

And, are there functions that can go the other way? Converting a character string to an integer, or to a real number?

Thank you!

[brucebowler]

Look at "internal writes" (and their counterpart internal reads). They should do all that you need to convert either way between numbers and strings

[Little-Acorn]

[PaulLaidler]

[brucebowler]

[Little-Acorn]

[sparge]

Internal writes are great, BUT they always involve a few lines of code, and those lines of code always entail hard-coded data such as a format. So it's always a fag to implement one. Sometimes I think it would be fun to write a couple of routines that would bundle up all the gubbins into a single call once and for all. Then I wonder why no-one's done it yet and think it must not be as easy as it looks?

[brucebowler]

[sparge]

Well, yes ... but the "simple" case is only simple because it hides away, in its midst, a conscious decision on the part of the programmer as to exactly what the format should be. And the more complex case does not eliminate the need for that conscious decision, it just separates it out, which is a good thing in my book. Part of that decision is based on knowing whether the variable is integer or real or whatever, part of it is based on knowing how big the number is, and part of it is based on how precisely it needs to be represented.

The format ... aye, there's the rub. All the hard stuff either needs extra lines of code, or gets precomputed in the programmers head. Wouldn't it be nice to have a function:

char_variable = based_on_internal_write (variable)

(or even a small set of such functions, one for each numerical data type) that figured out all that stuff on its own?

[brucebowler]

[quote="sparge"]Well, yes ... but the "simple" case is only simple because it hides away a conscious decision on the part of the programmer as to exactly what the format should be.

char_variable = based_on_internal_write (variable)[/quote]

And who figures "exactly what the format should be" in that case other than "the conscious decision on the part of the programmer"?

In the case of the internal write, it's "in your face" what the format is. In your example, there's NO indication of what it might be (nor is there a mechanism to change it if the original programmer "guessed wrong").

[aebolzan]

[sparge]

[brucebowler]

[sparge]

I too work in a scientific environment, and have done for more than 25 years. I would be surprised if anyone making regular use of FORTRAN does not work in a scientific environment. So your "I am here" postcard from the scientific high ground did not have to travel very far.

I am struggling to understand what misperception of yours or mine is getting under your skin so badly and generating such thinly-veiled hostility. I said that the hypothetical function would "compute what the format should be". Can you spot the key word? I even suggested what the first simple step in this computation could be. Somehow you translated this into "some random format specified by something the user has no control over".

With your science background, you ought at least to know what straw man reasoning is, even if you cannot yet recognise your own as such. However, I am surprised that your science background does not help you to see that a function is just as editable and recompilable as a format statement. I am also surprised that you classify a programmer "guessing" a format as scientific.

[brucebowler]

I'm sorry you interpreted my comments as "hostile", they certainly weren't intended to be.

Since it's clear that one of us (it could very well be me) isn't communicating well, I'm going to not say any more on this subject...