[sac-user] print function alternatives?

Robert Bernecky bernecky at snakeisland.com
Wed Aug 11 15:24:38 CEST 2010


Let me try again. The I/O itself is
sort of irrelevant. However, if you look at the
history of formatting primitives in languages
like C and Fortran, they began as crude
output drivers, then got fancier and more
complicated as people realized that, e.g,
the result of the formatting was needed, not
by some output device, but by another piece
of code in the program, so we ended up with
pseudo-devices, sprintf(), and the like.

If you want a single primitive that is intended to
combine I/O AND formatting, then the formatter
has to be able to handle all (nearly all) the
formatting of an arbitrary number of arguments.
Historically, this has always resulted in
amazingly ugly primitive functions that are:

  - difficult to understand
  - difficult to use in practice
  - convoluted
  - AND, practically, still fail to
    do the job for all but the most
    simplistic apps.

That is, it is very difficult to design
a formatter that is general enough to cover
most of the requirements of common applications;
you almost always need glue logic for, e.g.,
catenating one part of a report to another.
Canned formatters are rarely up to the task
of creating output in a form that is useful
to an end user. If all you're doing is
formatting one numeric matrix, it's no big
deal, but any formatter can do that.
In general, I think we're better off providing
simple, clean formatting functions, and letting
the user combine those results with catenate, etc.,
then in trying to define an all-singing, all-dancing
formatting language.

I'm also not sure that I buy the requirement
for mixing formatting with I/O, for the
purpose of some perceived savings in
time and/or space. What hard evidence do you
have that this is worth the effort?
And if it is worthwhile, why do you point the
finger at formatting? Perhaps we should make, e.g.,
catenate or with-loops able to mix their output
with an I/O driver...

Bob

Clemens Grelck wrote:
> Robert Bernecky wrote:
>> Formatting higher-order numeric matrices for
>> printing is trivial. However, if you want to
>> plot or display that information, you end up
>> having to do custom formatting that is not
>> amenable to canned formatters.
>>
>> Also, most common industrial applications of formatting
>> involve adding row and column titles, footer and
>> header info, etc.,
> 
> yes.
> 
>> If you try to push this into a single FORMATANDPRINT()
>> function, you end up with something that has to accept
>> an arbitrary number of arguments. Even then, real
>> applications will fall outside the capabilities of
>> such functions, unless you give the formatter/printer
>> the power of a computer language itself. Learning
>> a formatting language on top of computer language
>> generally is not worth it.
> 
> What I don't get is why the absence of printing shall
> simplify the job of formatting. These two issues are
> pretty orthogonal to me. So, software engineering principles
> demand their separation, but resource issues may demand
> their interleaving. Unless the performance issue is irrelevant,
> of course. If you are so sure about this, then my argument is
> irrelevant according to my own line of reasoning.
> 
>  Clemens
> 
>> Clemens Grelck wrote:
>>> I fully agree on the diversity of printing options. My only
>>> concern was to create a character array (!) explicitly, whose
>>> only purpose in life is to be printed. In one way or another
>>> this means copying one buffer into another and substantial
>>> organisational overhead as for instance the character array
>>> needs to be constructed incrementally, etc.
>>>
>>> I agree that from a software engineering point of view separating
>>> formatting issues from I/O issues is desirable.  From a resource
>>> point of view it is not.
>>>
>>> Still formatting is technically orthogonal from the I/O issue and
>>> all problems are the same. I thought about higher-order functions
>>> for providing entire print functions (or formatting functions) as
>>> arguments instead of format strings. But that is a long term issue
>>> and maybe not even worth it for the purpose of nice printing.
>>>
>>>  Clemens
>>>
>>> Robert Bernecky wrote:
>>>> Not necessarily so:
>>>>
>>>> The conversion of a numeric array into a character
>>>> array (Strings can stay at home, please) offers several
>>>> advantages over code that includes output/input:
>>>>
>>>> 1. In real applications, it becomes necessary to combine
>>>>    formatted arrays, as when creating reports:
>>>>
>>>>       name             phone             salary
>>>>       Prof             (+44) 123 345     40 million pazoozas
>>>>       Lowly underling  (+1) 416 555 1212 20 pazoozas
>>>>
>>>>    Each element of the report generally will need custom formatting;
>>>>    the use of a formatting function that produces a character matrix
>>>>    permits the individually formatted columns to be joined with
>>>>    catenation.
>>>>
>>>> 2. Creation of certain sorts of files, such as CSV files, requires
>>>>    that formatted matrix elements be decorated (e.g., with commas
>>>>    separating them, with quotes around character fields, etc.), then
>>>>    have new-line characters appended, and the whole thing then
>>>>    ravelled to a vector, perhaps will trailing blanks removed,
>>>>    if you want to be tidy. This gets messy if you try to combine
>>>>    arbitrary formatting and I/O into the same construct.
>>>>
>>>> I am not sure if higher-order functions help a lot here. For
>>>> example, the commas in CSV files are needed for all but the last
>>>> item in a row. Not sure what you have in mind here.
>>>>
>>>> For real applications, you nearly always end up with custom
>>>> formatting functions anyway, except for the most trivial apps.
>>>>
>>>> Bob
>>>>
>>>> Clemens Grelck wrote:
>>>>> Much better. ;-)
>>>>>
>>>>> What might prove problematic in ArrayFormat is that, if I understand
>>>>> it correctly, an entire array is transformed into a string before that
>>>>> string (normally) is printed to some file descriptor and then removed
>>>>> again.
>>>>>
>>>>> I think this would be a good example for having higher-order 
>>>>> functions,
>>>>> because what you in the end want to do is to map a print function 
>>>>> to each
>>>>> element of an array. And to have this print function user-controlled.
>>>>>
>>>>> A less comprehensive but then much easier and quicker to realise 
>>>>> solution
>>>>> could be to simply expose the format string in the user API. The
>>>>> implementation of the ArrayIO module already has this abstraction 
>>>>> layer.
>>>>> At the moment, the exposed API function calls this one hard-wiring the
>>>>> format string. I think this could be realised within 15 minutes or so.
>>>>>
>>>>>  Clemens
>>>>>
>>>>>
>>>>> Robert Bernecky wrote:
>>>>>> Is this better?
>>>>>>
>>>>>> 0.07
>>>>>> 0.07
>>>>>> 0.0700000000000000067
>>>>>>
>>>>>> rbe at obelix:~> cat crud.sac
>>>>>>
>>>>>> use Array:all;
>>>>>> use StdIO:all;
>>>>>> use ArrayFormat:all;
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>  x = 0.07;
>>>>>>  show(x);
>>>>>>  show(format(x));
>>>>>>  show(format(x,18));
>>>>>>  return(0);
>>>>>> }
>>>>>>
>>>>>> Bob
>>>>>>
>>>>>> Raphael 'kena' Poss wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Op 2 aug 2010, om 18:45 heeft Robert Bernecky het volgende 
>>>>>>> geschreven:
>>>>>>>> In particular, it still uses printf() [...]
>>>>>>>> My intent was to make it use a precise formatter, such
>>>>>>>> as that proposed in "Printing Floating-Point Numbers Quickly and 
>>>>>>>> Accurately", by Robert G. Burger and R. Kent Dybvig.
>>>>>>>
>>>>>>> For your information, many open-source Unices nowadays use the 
>>>>>>> gdtoa library by D. Gay from netlib: 
>>>>>>> http://www.netlib.org/fp/gdtoa.tgz
>>>>>>>
>>>>>>> This uses concepts and algorithms from
>>>>>>>
>>>>>>> T. J. Dekker, "A Floating-Point Technique for Extending the
>>>>>>> Available Precision", Numer. Math. 18 (1971), pp. 224-242
>>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>> "How to Print Floating-Point Numbers Accurately" by
>>>>>>> Guy L. Steele, Jr. and Jon L. White [Proc. ACM SIGPLAN '90, pp. 
>>>>>>> 112-126].
>>>>>>>
>>>>>>> As far as precision goes, this is formally specified. I don't 
>>>>>>> know how it compares to the techniques in Burger & Dybvig, actually.
>>>>>>>
>>>>>>>
>>>>>>> As an option, is it possible to output floats in hexadecimal? 
>>>>>>> This should prevent rounding errors.
>>>>>>>
>>>>>> _______________________________________________
>>>>>> sac-user mailing list
>>>>>> sac-user at sac-home.org
>>>>>> http://lists.sac-home.org/mailman/listinfo.cgi/sac-user
>>>>>
>>>>
>>>
>>
> 



More information about the sac-user mailing list