printf

printf

[Oliver Kiddle]

In case anyone was unsure, printf is not entirely finished. I've got a
couple more questions before I do any more on it though.

I have established that the ksh behaviour of -r with -f is not going to
change (they can't be used together). This leaves the possibility of
overloading the -r option to prevent format reuse when combined with
-f. Does anyone have any preference on whether I should overload this
option letter or use a different letter (for which I can't think of a
suitable available letter)?

As Peter suggested a while back, the ideal would be to update
convfloat() and convbase() to be flexible enough to do the outputting.
Currently convfloat() just uses printf(3). Does anyone know of any
established algorithms for converting floats to their ASCII
representations? Or does anyone have any suitable code I could crib? I
expect that something of this sort exists and would be better than
whatever I might re-invent.

I'd like to be able to support the ' (thousand grouping) and I (use
locale format) flags and the a,A,F conversion specifiers. I'd also like
to try to handle this sort of thing better:
    printf '%*s' 100000000 ' ' > /tmp/f
and of course, allow print -f to be used with -s and -z.

Oliver

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

Re: printf

[Peter Stephenson]

Oliver Kiddle wrote:
> As Peter suggested a while back, the ideal would be to update
> convfloat() and convbase() to be flexible enough to do the outputting.
> Currently convfloat() just uses printf(3). Does anyone know of any
> established algorithms for converting floats to their ASCII
> representations? Or does anyone have any suitable code I could crib? I
> expect that something of this sort exists and would be better than
> whatever I might re-invent.

Ideally, you should fcvt(), gcvt() and ecvt(), which handle locales as well
as hiding the details of the conversion.  They are almost certainly widely
enough available to make it worth getting configure to detect them.
Unfortunately, you still need a fallback --- maybe the current set of
fudges using printf(3) is enough for that.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: printf

[Oliver Kiddle]

Peter Stephenson wrote:
> 
> Ideally, you should fcvt(), gcvt() and ecvt(), which handle locales as well
> as hiding the details of the conversion.  They are almost certainly widely
> enough available to make it worth getting configure to detect them.
> Unfortunately, you still need a fallback --- maybe the current set of
> fudges using printf(3) is enough for that.

They don't seem to offer anything which sprintf(3) doesn't already so I
couldn't add the extra features with these. The man page on Linux says
that they are obsolete even.

Also, I don't think we should be handling locales unless asked to with a
flag because it is common for programs to need input which isn't in a
local format.

I could update convfloat() etc to just use sprintf() more easily and
with just as good results. With that, I could support -s and -z but not
the other extras which is why I thought about doing the conversion
entirely manually.

Oliver

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

Re: printf

[Peter Stephenson]

Oliver Kiddle wrote:
> I'd like to be able to support the ' (thousand grouping)

The more I think about this, the more it seems to me that using quotes is
simply going to cause grief (unless I've misunderstood).  Is there any
reason for this rather than the perl version, `_', which isn't going to
conflict with anything?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: printf

[Oliver Kiddle]

Peter Stephenson wrote:
> 
> Oliver Kiddle wrote:
> > I'd like to be able to support the ' (thousand grouping)
> 
> The more I think about this, the more it seems to me that using quotes is
> simply going to cause grief (unless I've misunderstood).  Is there any
> reason for this rather than the perl version, `_', which isn't going to
> conflict with anything?

Ksh and many newer printf(3)s use the single quote but I agree with you
that it is a bad choice.

Is this `_' a new perl feature:
    perl -e 'printf "%_g\n",132643.45'
does not work with 5.0005_03 or am I putting the underscore in the
wrong place. We can always offer a choice of flag character here.

Going back to my questions earlier this week, fcvt() etc are a bad
idea. They don't exist everywhere, on some (BSD) systems, they are in
compat libraries and sprintf is seemingly just as good but more
available.

My idea of writing a function from scratch to format floats was also a
bad idea. I've been referred to http://plan9.bell-labs.com/netlib/fp as
example source. A brief glance was enough to appreciate that it would
be bloat and overkill as well as being not at all easy.

This returns me to using sprintf which should be okay.

The first issue is dealing with very large precisions specified for
floating point variables. To use sprintf, I would potentially have to
allocate a stupidly large amount of memory which I'd prefer to avoid.

Large widths are not an issue - I'll not use sprintf for the widths but
will just call putchar in a loop before or after outputting the
formatted argument. They might cause problems with print -s and -z
though. I could maybe truncate these to the maximum length a command
can be (how do I find that out again?).

One solution for dealing with large precisions would be to put a limit
on the precision. I can't really see why anyone would want something
like '%.10000f' anyway. An easy solution would be to allocate a buffer
for sprintf which is based on the maximum length of any argument and at
least say 100. You don't get any greater precision than about 60 with
doubles anyway. If someone tries '%.101g', they would then get a
warning that such precisions are not supported. Or I could just
truncate the number returned. Any views on these ideas?

To support the ' flag, I'll try a configure test to check for support
in printf(3) and otherwise, insert the separators retrospectively.

The second issue is working out what is going on with locales. Does
basic printf do locales on any platforms? The I flag is glibc 2.2. I'd
like to have the I flag in zsh and locales no used without it so that
users can rely on the output of printf. Unfortunately, every machine I
have access to seems to only have English locale data installed so it
is hard to work out what is happening.

Oliver

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

Re: printf

[Peter Stephenson]

Oliver Kiddle wrote:
> Is this `_' a new perl feature:
>     perl -e 'printf "%_g\n",132643.45'
> does not work with 5.0005_03 or am I putting the underscore in the
> wrong place. We can always offer a choice of flag character here.

Ah, I misinterpreted.  I meant on input:
  perl -e 'print 3_000 + 2_000, "\n"'
But that's up to the math code, probably an easy addition.

> This returns me to using sprintf which should be okay.

That sounds like the best bet.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************