[9fans] hoc output format

[9fans] hoc output format

[Rudolf Sykora]

Hello everyone,

is there any way to control the output format of hoc(1), i.e. e.g. the
number of decimal places printed?

Thanks
Ruda

Re: [9fans] hoc output format

[Alexander Sychev]

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.sykora@gmail.com> wrote:

> Hello everyone,
>
> is there any way to control the output format of hoc(1), i.e. e.g. the
> number of decimal places printed?
>
> Thanks
> Ruda


-- 
Best regards,
   santucco

Re: [9fans] hoc output format

[Akshat Kumar]

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 <santucco@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.sykora@gmail.com>
> wrote:
>
>> Hello everyone,
>>
>> is there any way to control the output format of hoc(1), i.e. e.g. the
>> number of decimal places printed?
>>
>> Thanks
>> Ruda
>
>
> --
> Best regards,
>  santucco
>
>

Re: [9fans] hoc output format

[Alexander Sychev]

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.

On Wed, 12 May 2010 22:06:20 +0400, Akshat Kumar  
<akumar@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 <santucco@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.sykora@gmail.com>
>> wrote:
>>
>>> Hello everyone,
>>>
>>> is there any way to control the output format of hoc(1), i.e. e.g. the
>>> number of decimal places printed?
>>>
>>> Thanks
>>> Ruda
>>
>>
>> --
>> Best regards,
>>  santucco
>>
>>


-- 
Best regards,
   santucco

Re: [9fans] hoc output format

[erik quanstrom]

On Thu May 13 03:51:56 EDT 2010, santucco@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

	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

Re: [9fans] hoc output format

[Alexander Sychev]

On Thu, 13 May 2010 17:24:47 +0400, erik quanstrom <quanstro@quanstro.net>  
wrote:

> On Thu May 13 03:51:56 EDT 2010, santucco@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

Re: [9fans] hoc output format

[erik quanstrom]

> > 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.

i typically do programming calculations and floating point
just isn't the right way to do that.

- erik

Re: [9fans] hoc output format

[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

Re: [9fans] hoc output format

[Gorka Guardiola]

On Thu, May 13, 2010 at 4:23 PM, erik quanstrom
<quanstro@labs.coraid.com> 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.
>
> i typically do programming calculations and floating point
> just isn't the right way to do that.
>

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

Re: [9fans] hoc output format

[erik quanstrom]

> 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.

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

Re: [9fans] hoc output format

[roger peppe]

On 13 May 2010 15:23, erik quanstrom <quanstro@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.

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

Re: [9fans] hoc output format

[erik quanstrom]

On Thu May 13 11:28:29 EDT 2010, rogpeppe@gmail.com wrote:
> On 13 May 2010 15:23, erik quanstrom <quanstro@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

Re: [9fans] hoc output format

[roger peppe]

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.

On 13 May 2010 16:31, erik quanstrom <quanstro@labs.coraid.com> wrote:
> On Thu May 13 11:28:29 EDT 2010, rogpeppe@gmail.com wrote:
>> On 13 May 2010 15:23, erik quanstrom <quanstro@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
>
>

Re: [9fans] hoc output format

[erik quanstrom]

On Thu May 13 12:05:13 EDT 2010, rogpeppe@gmail.com wrote:
> 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

Re: [9fans] hoc output format

[roger peppe]

On 13 May 2010 17:06, erik quanstrom <quanstro@labs.coraid.com> wrote:
> On Thu May 13 12:05:13 EDT 2010, rogpeppe@gmail.com wrote:
>> 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.

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.

Re: [9fans] hoc output format

[Ethan Grammatikidis]

On 13 May 2010, at 16:16, roger peppe wrote:

> On 13 May 2010 15:23, erik quanstrom <quanstro@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.

--
Simplicity does not precede complexity, but follows it. -- Alan Perlis

Re: [9fans] hoc output format

[roger peppe]

On 13 May 2010 16:54, Ethan Grammatikidis <eekee57@fastmail.fm> wrote:
> 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.

Re: [9fans] hoc output format

[Rudolf Sykora]

On 13 May 2010 16:23, erik quanstrom <quanstro@labs.coraid.com> 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.
>
> i typically do programming calculations and floating point
> just isn't the right way to do that.
>
> - erik
>
>

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