Prev: use module to pass data between procedures
Next: It Hurts When I Do This -- diversion...
From: Gordon Sande on 22 Apr 2008 08:22
On 2008-04-22 07:09:19 -0300, SimonG <simon(a)whiteowl.co.uk> said:

> On Apr 22, 10:12 am, "FX" <coud...(a)alussinan.org> wrote:
>>> I expected the Intel result but perhaps the standard is ambiguous on
>>> this. Is this a g95 bug?
>>
>> I'd have the same expectation that you have, so I guess there's a
>> bugreport to make (or at least feature request, as lots of other
>> compilers behave the other way).
>>
>>> A second question: how do I enter a '/' character?
>>
>> Well, you have a .co.uk address, so the '/' key should be on the left of
>> your right shift key ;-)
>>
>> Hum, more seriously, you need to change your read's into:
>>
>> read(5,'(a)') buff
>> read(buff,'(f20.0)',err=900) x
>>
>> (Oh, and doing that fixes the issue with g95, apparently.)
>>
>> --
>> FX
>
> Yes, making that change does alter the behaviour - the g95 version
> works as required but the Intel version now interprets '+' as a number
> (as well as '.', ',' and '-'): is that an Intel bug?

Extensions! Treating "+","-" and "." as short forms of zero is a fairly
common extension for numerical input routines. The rationalization is that
the missing digits are being treated as zero. Sometimes it leads to foolish
things like repeated signs being treated as an extra zero. The "," is likely
to be treated as a terminator and results in a missing field of zero. These
extensions appear to be clever (where clever is actually a swear word when
describing software!) but can quickly become very tiring when they result
in obscure lingering wounds to the feet.

Such extensions are surely baggage that Digital/Compaq/Intel has picked up
over time.

> In fact for read(buff,'(f10.0)',err=900) x
>
> input g95 ifort
> + Command:+ Number: 0.
> - Command:- Number: 0.
> * Command:* Command:*
> / Command:/ Command:/
> . Command:. Number: 0.
> , Command:, Number: 0.
>
>
> and for read(buff,*,err=900) x
>
> input g95 ifort
> + Number: 0. Command:+
> - Number: -0. Command:-
> * Command:* Command:*
> / Number: -0. Number: 0.
> . Number: 0. Command:.
> , Number: 0. Number: 0.
>
>
> program ex
> implicit none
> real(8) :: x
> integer :: n, ios
> character(10) :: buff
>
> do
> write(6,'(a)',advance='no') '> '
> read(5,'(a10)') buff
> read(buff,*,err=900) x !!! or read(buff,*,err=900) x
> write(6,'(a,f10.0)') 'Number:',x
> cycle
> 900 continue
> write(6,'(2a)') 'Command:',trim(buff)
>
> end do
>
> end program ex
>
>
> So what is the correct behaviour, surely they can't both be right.
>
>
> Simon Geard


From: Gary Scott on 22 Apr 2008 08:36
Gordon Sande wrote:

> On 2008-04-22 07:09:19 -0300, SimonG <simon(a)whiteowl.co.uk> said:
>
>> On Apr 22, 10:12 am, "FX" <coud...(a)alussinan.org> wrote:
>>
>>>> I expected the Intel result but perhaps the standard is ambiguous on
>>>> this. Is this a g95 bug?
>>>
>>>
>>> I'd have the same expectation that you have, so I guess there's a
>>> bugreport to make (or at least feature request, as lots of other
>>> compilers behave the other way).
>>>
>>>> A second question: how do I enter a '/' character?
>>>
>>>
>>> Well, you have a .co.uk address, so the '/' key should be on the left of
>>> your right shift key ;-)
>>>
>>> Hum, more seriously, you need to change your read's into:
>>>
>>> read(5,'(a)') buff
>>> read(buff,'(f20.0)',err=900) x
>>>
>>> (Oh, and doing that fixes the issue with g95, apparently.)
>>>
>>> --
>>> FX
>>
>>
>> Yes, making that change does alter the behaviour - the g95 version
>> works as required but the Intel version now interprets '+' as a number
>> (as well as '.', ',' and '-'): is that an Intel bug?
>
>
> Extensions! Treating "+","-" and "." as short forms of zero is a fairly
> common extension for numerical input routines. The rationalization is that
> the missing digits are being treated as zero. Sometimes it leads to foolish
> things like repeated signs being treated as an extra zero. The "," is
> likely
> to be treated as a terminator and results in a missing field of zero. These
> extensions appear to be clever (where clever is actually a swear word when
> describing software!) but can quickly become very tiring when they result
> in obscure lingering wounds to the feet.
>
> Such extensions are surely baggage that Digital/Compaq/Intel has picked up
> over time.

Or invented...

<snip>
--

Gary Scott
mailto:garylscott(a)sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford
From: Gordon Sande on 22 Apr 2008 10:20
On 2008-04-22 09:36:41 -0300, Gary Scott <garylscott(a)sbcglobal.net> said:

> Gordon Sande wrote:
>
>> On 2008-04-22 07:09:19 -0300, SimonG <simon(a)whiteowl.co.uk> said:
>>
>>> On Apr 22, 10:12 am, "FX" <coud...(a)alussinan.org> wrote:
>>>
>>>>> I expected the Intel result but perhaps the standard is ambiguous on
>>>>> this. Is this a g95 bug?
>>>>
>>>>
>>>> I'd have the same expectation that you have, so I guess there's a
>>>> bugreport to make (or at least feature request, as lots of other
>>>> compilers behave the other way).
>>>>
>>>>> A second question: how do I enter a '/' character?
>>>>
>>>>
>>>> Well, you have a .co.uk address, so the '/' key should be on the left of
>>>> your right shift key ;-)
>>>>
>>>> Hum, more seriously, you need to change your read's into:
>>>>
>>>> read(5,'(a)') buff
>>>> read(buff,'(f20.0)',err=900) x
>>>>
>>>> (Oh, and doing that fixes the issue with g95, apparently.)
>>>>
>>>> --
>>>> FX
>>>
>>>
>>> Yes, making that change does alter the behaviour - the g95 version
>>> works as required but the Intel version now interprets '+' as a number
>>> (as well as '.', ',' and '-'): is that an Intel bug?
>>
>>
>> Extensions! Treating "+","-" and "." as short forms of zero is a fairly
>> common extension for numerical input routines. The rationalization is that
>> the missing digits are being treated as zero. Sometimes it leads to foolish
>> things like repeated signs being treated as an extra zero. The "," is likely
>> to be treated as a terminator and results in a missing field of zero. These
>> extensions appear to be clever (where clever is actually a swear word when
>> describing software!) but can quickly become very tiring when they result
>> in obscure lingering wounds to the feet.
>>
>> Such extensions are surely baggage that Digital/Compaq/Intel has picked up
>> over time.
>
> Or invented...
>
> <snip>

Having seen these clever extensions in other settings I would be more inclined
to believe they were user requests. Or at least a request by sales when a new
sale got hung up on the absense of the extension during the
demonstration phase.

Much easier if the customer can report zero glitches rather than having to
fix some number of their own past clevernesses.


From: glen herrmannsfeldt on 22 Apr 2008 14:38
Gordon Sande wrote:

(snip)

> Extensions! Treating "+","-" and "." as short forms of zero is a fairly
> common extension for numerical input routines. The rationalization is that
> the missing digits are being treated as zero. Sometimes it leads to foolish
> things like repeated signs being treated as an extra zero. The "," is
> likely
> to be treated as a terminator and results in a missing field of zero. These
> extensions appear to be clever (where clever is actually a swear word when
> describing software!) but can quickly become very tiring when they result
> in obscure lingering wounds to the feet.

> Such extensions are surely baggage that Digital/Compaq/Intel has picked up
> over time.

In Fortran 66, blanks were interpreted the same as zeros in formatted
input. Using comma as a field terminator was a DEC extension convenient
for terminal input.

In the days of punched cards, expecting fields to line up in the
appropriate columns made sense. Among others, you could save card
columns with implied decimal point and running the fields together.

That made a lot less sense for terminal input where it was difficult
to get fields in the right columns. The DEC extension allowed something
similar to list directed input.

-- glen

First  |  Prev  | 
Pages: 1 2
Prev: use module to pass data between procedures
Next: It Hurts When I Do This -- diversion...