[9fans] hoc output format
Rudolf Sykora
is there any way to control the output format of hoc(1), i.e. e.g. the
number of decimal places printed?
Thanks
Ruda
Alexander Sychev
IFAIK, hoc(1) hasn't got such possibility.
awk(1) can help:
$ hoc -e PI | awk '{printf "%2.2f", $0}'
3.14
--
Best regards,
santucco
Akshat Kumar
(rather, more powerful) for doing
programmed computations (number
crunching, etc.), where hoc(1) is
more of a convenience for basic
calculations.
Best,
ak
Alexander Sychev
code, hoc(1) doesn't do it. So hoc(1) can be used for plain calculation
tasks, not for processing input files with a data.
On Wed, 12 May 2010 22:06:20 +0400, Akshat Kumar
<aku...@mail.nanosouffle.net> wrote:
> I've found that awk(1) is more useful
> (rather, more powerful) for doing
> programmed computations (number
> crunching, etc.), where hoc(1) is
> more of a convenience for basic
> calculations.
>
>
> Best,
> ak
>
> On Wed, May 12, 2010 at 3:41 AM, Alexander Sychev <sant...@gmail.com>
> wrote:
>> Hello!
>>
>> IFAIK, hoc(1) hasn't got such possibility.
>> awk(1) can help:
>>
>> $ hoc -e PI | awk '{printf "%2.2f", $0}'
>> 3.14
>>
>> On Wed, 12 May 2010 14:24:57 +0400, Rudolf Sykora
>> <rudolf...@gmail.com>
>> wrote:
>>
>> --
>> Best regards,
>> santucco
>>
>>
--
Best regards,
santucco
erik quanstrom
> Yes, I'm agree, but with one exception - awk(1) separates a data from a
> code, hoc(1) doesn't do it. So hoc(1) can be used for plain calculation
> tasks, not for processing input files with a data.
both awk and hoc accept standard input
echo 1 + 2 | hoc # (sic, see below)
echo 1 2 | hoc -e '{while(read(x) != 0)y += x' ^ $nl ^ ' print y, "\n"}' -
echo 1 2 | awk '{for(i = 1; i <= NF; i++) x+= $i}END{print x}'
or execute directly from the command line
hoc -e '1 + 2'
awk 'BEGIN{print 1 + 2; exit}'
note that the wierd extra {} are required for hoc. hoc read
requests are satisfied from the same file descriptor as the data.
so the input needs to be exhausted before read runs.
also, the trailing newline on the input is required, since Bgetd()
won't accept '1<EOF>'. this seems like a bug induced by the
fact that charstod has one argument too few. if it also returned
the number of characters consumed, Bgetd could read
int
Bgetd(Biobufhdr *bp, double *dp)
{
double d;
struct bgetd b;
b.b = bp;
b.eof = 0;
> b.nchr = 0;
> d = charstod(Bgetdf, &b, &n);
> if(b.eof || b.nchr != n)
return -1;
Bungetc(bp);
*dp = d;
return 1;
}
- erik
Alexander Sychev
wrote:
> On Thu May 13 03:51:56 EDT 2010, sant...@gmail.com wrote:
>> Yes, I'm agree, but with one exception - awk(1) separates a data from a
>> code, hoc(1) doesn't do it. So hoc(1) can be used for plain calculation
>> tasks, not for processing input files with a data.
>
> both awk and hoc accept standard input
Yes, but for hoc(1) it can be some program, for awk(1) it can be a data
only :-) - that is what I meant :-)
> echo 1 2 | hoc -e '{while(read(x) != 0)y += x' ^ $nl ^ ' print y, "\n"}'
Maybe it makes a sense to add in hoc(1) expression delimiter like a ';'?
--
Best regards,
santucco
erik quanstrom
>
> Maybe it makes a sense to add in hoc(1) expression delimiter like a ';'?
i don't use hoc very often. i tend to use acid. (!)
this is because hoc won't do bit operations and doesn't
accept hex.
i typically do programming calculations and floating point
just isn't the right way to do that.
- erik
Ethan Grammatikidis
On 13 May 2010, at 15:23, erik quanstrom wrote:
>>> echo 1 2 | hoc -e '{while(read(x) != 0)y += x' ^ $nl ^ ' print y,
>>> "\n"}'
>>
>> Maybe it makes a sense to add in hoc(1) expression delimiter like a
>> ';'?
>
> i don't use hoc very often. i tend to use acid. (!)
> this is because hoc won't do bit operations and doesn't
> accept hex.
Acid is nicer than dc or bc for this? I don't do much in the way of
programming calculations at present and usually resort to dc to do
them. Anything more convenient would be appreciated. :)
As for hoc, I'm mostly doing floating-point work where presentation is
irrelevant, so it's quite useful for me, but too often I find myself
preferring to use one of those silly graphical calculator applications
just to cut down on the visual noise.
--
Simplicity does not precede complexity, but follows it. -- Alan Perlis
Gorka Guardiola
I normally use acid for interactive use, but for scripts bc is great,
supports hex,
has C like syntax, can do floating point and it has a big precision.
--
- curiosity sKilled the cat
roger peppe
> i typically do programming calculations and floating point
> just isn't the right way to do that.
it's ok if you stick to 32 bit and don't do divisions.
personally for off-the-cuff command-line calculations
i've been using my own "fc" for years and
years. nothing else quite hits the spot, but
i'm biased.
my reasons: hoc doesn't do bit level ops, has too much syntax that needs
quoting, and if you're quoting, it's awkward (in rc) to insert
environment variables inside the quotes. dc
doesn't take command line arguments,
doesn't do floating point and its output isn't suitable
for as input.
there's a man page for the inferno version of fc here,
in case anyone's interested:
http://www.vitanuova.com/inferno/man/1/fc.html
Rudolf Sykora
I've used hoc in my scripts to prepare some values which are then used
one for a calculation and second for naming a directory after this
value:
v = `{hoc -e $min+$step'*('$i-1')'}
mkdir $v
However, even for min=0 and step=0.05 (if I remember it right) for
some i I get a value like 6.50000000000something, which is annoying to
correct. That was the reason for my original question.
As proposed I will either add awk to format the result or use awk
exclusively in scripts. Nonetheless, maybe some control over the
format in hoc could be handy...
Thanks
Ruda
erik quanstrom
> On 13 May 2010 15:23, erik quanstrom <quan...@labs.coraid.com> wrote:
> > i typically do programming calculations and floating point
> > just isn't the right way to do that.
>
> it's ok if you stick to 32 bit and don't do divisions.
what!?
acid: (1<<36) / 10\Y
0x0000000199999999
acid: 0x0000000199999999*10\Y
0x0000000ffffffffa
works for me.
- erik
erik quanstrom
> supports hex,
> has C like syntax, can do floating point and it has a big precision.
doesn't do bit shifting, masking and whatnot.
if acid were to grace stderr with its prompt, it would
be easy to use in a scripty sort of way, were it not for
acid libraries' habit of printing their names, anyway.
- erik
roger peppe
ok for integer ops if you stick to 32 bit and don't do divisions.
Ethan Grammatikidis
On 13 May 2010, at 16:16, roger peppe wrote:
> On 13 May 2010 15:23, erik quanstrom <quan...@labs.coraid.com> wrote:
>> i typically do programming calculations and floating point
>> just isn't the right way to do that.
>
> it's ok if you stick to 32 bit and don't do divisions.
>
> personally for off-the-cuff command-line calculations
> i've been using my own "fc" for years and
> years. nothing else quite hits the spot, but
> i'm biased.
>
> my reasons: hoc doesn't do bit level ops, has too much syntax that
> needs
> quoting, and if you're quoting, it's awkward (in rc) to insert
> environment variables inside the quotes. dc
> doesn't take command line arguments,
> doesn't do floating point and its output isn't suitable
> for as input.
what do you mean by "its output isn't suitable for use as input"? i'm
just curious, have never used it that way. hum... having asked that
question i tried some operations producing very lare numbers and they
started to be printed with backslash-newlines in them. not nice, but
such a form is suitable for input back to dc.
>
> there's a man page for the inferno version of fc here,
> in case anyone's interested:
> http://www.vitanuova.com/inferno/man/1/fc.html
>
fc does look good for strictly command line use (scripts, perhaps?) i
usually want to fire up a calculator in a window of its own & refer to
it as needed.
erik quanstrom
> sorry, misunderstanding, i meant that (64-bit) floating point is
> ok for integer ops if you stick to 32 bit and don't do divisions.
>
ah! ok. i was wondering about that.
ideally one would have a mp library as go uses
for constants.
- erik
roger peppe
> what do you mean by "its output isn't suitable for use as input"? i'm just
> curious, have never used it that way. hum... having asked that question i
> tried some operations producing very lare numbers and they started to be
> printed with backslash-newlines in them. not nice, but such a form is
> suitable for input back to dc.
i mean that if you print output in hex, for example, the numbers
aren't tagged as such (with an 0x prefix), so you'll get corruption
or an error if you feed them back in without setting the input base
correctly.
> fc does look good for strictly command line use (scripts, perhaps?) i
> usually want to fire up a calculator in a window of its own & refer to it as
> needed.
i find it works nicely inside acme. the reverse polish input means
that if you execute it and get an output, you can just append an
operation to the end to operate on the resulting number, while
still keeping the original expression intact.
when i'm working out off the cuff sums (e.g. for household expenditure),
i'll make a text document which records the items, with little
fc fragments dotted here and there that record the actual
calculations. a poor man's spreadsheet i guess :-)
and it is good in scripts too. to take rudolf sykora's example
from earlier:
> v = `{hoc -e $min+$step'*('$i-1')'}
using fc it looks like this:
v = `{fc $min $step $i 1 - x +}
which i would argue is nicer.
roger peppe
yeah. good idea. i might produce a version that uses that.
you'd lose precision every time you called an external
function (e.g. sin) but that's probably just fine.