I have a job which requires me to read back output files from a Fortran
program into Smalltalk to do further manipulation. Unfortunately Fortran
output in scientific (i.e. exponent) notation does not satisfy Smalltalk
rules for number formatting, firstly because it usually uses upper case E
for the exponent, secondly because it inserts a sign for the exponent
whether it is positive or negative. I have added a loose method to String:
which does the job, but seems rather clunky. Can anyone see a neater way of
doing it? Does anyone else think Smalltalk is rather pernickety to reject
the upper case E and the plus sign? - Fortran input will happily accept
> which does the job, but seems rather clunky. Can anyone see a neater way
> of doing it? Does anyone else think Smalltalk is rather pernickety to
> reject the upper case E and the plus sign? - Fortran input will happily
> accept Smalltalk numbers.
Dolphin's numerical I/O is poor. There is no reason on God's Earth why it
should expect to read/write numbers in Smalltalk format when "talking" to the
That said, doing it "right" would be fraught with difficulties. For a start
there is the mess with localisation (for which I recently posted a solution).
But, more generally, there is the problem that different programming
communities have different ideas about how machine-oriented (i.e. "portable" as
opposed to localized) numbers should appear. For instance, for me with my
background as a C programmer, 0xFFFF looks an entirely natural way to represent
a binary value. An assembler programmer would have different ideas. I don't
know about Fortran but I presume it uses a different hex format too.
Yet another problem is whether Integer class>>fromString: should accept any of
"1000.0", "1000.0001", "1.23e100" (integer valued, despite the decimal point),
and so on. The current implementation would answer a Float in all those
cases -- which seems wrong too.
The end result is that a full solution probably requires parser objects
independently of the Number classes (c.f. java.text.NumberFormat in Java)
rather than making ad-hoc use of the generic methods provided by the Number
So, while I wouln't (at all) mind seeing the Number>>fromString: (and friends)
split away from the Smalltalk parsing function, and thus made more general and
forgiving, whilst also allowing them to be more specific (to the specific
number type), I don't think that would solve this kind of problem in general.
Which is probably why it has never happened.
Bottom line, as I see it, is write your own proper parser for your target
format, or hack something simple together as a minimal workaround...
I have a FORTRANNumberParser class based on SqNumberParser i recently
developed for Squeak. (google for squeak-dev thread 'Fun with Number
readFrom: What should we do ?').
And with small work, you would easily obtain a CNumberParser handling
I don't know how to make an attachment via google groups, so just tell
me if you are interested, i will put it on my web site.
Peter Kenny a écrit :
> "Chris Uppal" wrote:
> > Bottom line, as I see it, is write your own proper parser for your target
> > format, or hack something simple together as a minimal workaround...
> Thanks Chris - I guess my method comes into the hack category! Just wanted
> to be sure I wasn't overlooking something obvious.
> "nicolas cellier" <[hidden email]> wrote
> | I have a FORTRANNumberParser class based on SqNumberParser i recently
> | developed for Squeak. (google for squeak-dev thread 'Fun with Number
> | readFrom: What should we do ?').
> | I don't know how to make an attachment via google groups, so just tell
> | me if you are interested, i will put it on my web site.
> Thanks Nicolas. My hack seems to work OK for me, but it would be interesting
> to see what a more systematic treatment looks like. Please put it up.
> Peter Kenny