[sac-user] print function alternatives?

Robert Bernecky bernecky at snakeisland.com
Tue Aug 3 00:00:16 CEST 2010

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

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.


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