Re: print float number

[Greg Wooledge]

On Tue, Jan 07, 2014 at 10:36:54PM -0700, Bob Proulx wrote:
> lina wrote:
> > How can I print the 0.05, 0.10 ... 1.0 out, with the step of 0.05

Floating point does weird things.  A first approach might look like
this:

  awk 'BEGIN {for (i=0.05; i<=1.0; i+=0.05) printf ("%.2f\n", i)}'

But when I test this, it doesn't print 1.0.  Why?  Because floating
point arithmetic is not precise.  Adding 0.05 a bunch of times must
have given a value slightly over 1.0, which caused the loop to
terminate prematurely.  Results may vary on different machines,
depending on how the floating point numbers are stored internally.

If you want to get the expected number of steps, it's better to do
your counting with integers, and then present an altered view of
the data as output only:

  awk 'BEGIN {for (i=1; i<=20; i++) printf ("%.2f\n", i/20.0)}'

This one gives the expected result.

> Questions should go to the help-b...@gnu.org mailing list.

I've Cc'ed that.

> As to your question there are many ways to solve the problem.  I would
> be inclined to use the GNU seq command.
> 
>   $ seq 0.05 0.05 1.0

Note that seq(1) is nonstandard and won't be present on most machines.
Some BSD systems have jot(1) instead, which has a very different syntax.

(This in addition to suffering from the inherent imprecision of floating
point calculations, as Bob pointed out.)

> A related question about for loops in bash is discussed in this FAQ
> entry.  It isn't exactly your case but you might be interested in
> reading about the examples it provides.
> 
>   http://mywiki.wooledge.org/BashFAQ/018

There's also this page:

http://mywiki.wooledge.org/BashFAQ/022 -- How can I calculate with
floating point numbers instead of just integers?

The important point here is that Bash cannot add, subtract, multiply or
divide -- or even compare -- floating point numbers.  Any solution to
your question is going to require an external command that CAN do these
things (such as awk or seq).  I'd suggest awk as the go-to for this,
because it is a standard tool.

Of course, another answer to your question would be:

  printf %s\\n 0.05 0.10 0.15 0.20 0.25 0.30 0.35 0.40 0.45 0.50 0.55 \
0.60 0.65 0.70 0.75 0.80 0.85 0.90 0.95 1.00

But I'm guessing you don't want to do that.

BUG: "time" command adding to wrong process.

[James Bonfield]

Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib   -g -O2 -Wall
uname output: Linux deskpro102485 2.6.32-41-generic-pae #94-Ubuntu SMP Fri Jul 
6 17:08:20 UTC 2012 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu

Bash Version: 4.1
Patch Level: 5
Release Status: release

Description:
If I have a process running in the background that finishes
while I have a foreground process being timed using the
builtin time command, then the CPU time of the background task
is erroneously added on to the foreground task. This does not
happen if the background task ends after the foreground task.


Repeat-By:
$ cat ~/tmp/loop.c
int main(int argc, char **argv) {
int i, j, x = 0;
int N = atoi(argv[1]);
int M = 100;
for (i = 0; i < N; i++)
for (j = 0; j < M; j++)
x += i*j;
return 0;
}
$ gcc -g ~/tmp/loop.c

$ ./a.out 1000 & time ./a.out 1100
[3] 14577
[3]   Done./a.out 1000

real0m2.512s
user0m4.772s
sys 0m0.008s

$ ./a.out 1200 & time ./a.out 1100
[3] 14579

real0m2.528s
user0m2.520s
sys 0m0.000s
$

Using a subshell avoids the problem:

$ ./a.out 1000 & (time ./a.out 1100)
[3] 14589

real0m2.548s
user0m2.536s
sys 0m0.000s
[3]   Done./a.out 1000

$ (./a.out 1000 &); time ./a.out 1100

real0m2.502s
user0m2.492s
sys 0m0.004s

Is this an issue with process groups?



-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 

Re: BUG: "time" command adding to wrong process.

[Chet Ramey]

On 1/8/14 7:00 AM, James Bonfield wrote:

> Bash Version: 4.1
> Patch Level: 5
> Release Status: release
> 
> Description:
>   If I have a process running in the background that finishes
>   while I have a foreground process being timed using the
>   builtin time command, then the CPU time of the background task
>   is erroneously added on to the foreground task. This does not
>   happen if the background task ends after the foreground task.

This is simply an artifact of how process time accounting is done.  The
time consumed by children of the current process is modified when a child
process exits.  The command timing code just looks at the difference in
the time alloted to the shell process and its children before and after
executing the timed command, and computes the time taken by subtracting
before from after.

It's more difficult to get timing information for other individual
processes, and changing the code to do that would interfere with the
ability to time builtins and other shell commands.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: BUG: "time" command adding to wrong process.

[James Bonfield]

On Wed, Jan 08, 2014 at 10:50:47AM -0500, Chet Ramey wrote:
> It's more difficult to get timing information for other individual
> processes, and changing the code to do that would interfere with the
> ability to time builtins and other shell commands.

Understood. Perhaps it just needs a line in the documentation
suggesting that in complex pipelines it would be advisable to start
subshells for any time commands. Ie "(time foo)" instead of "time
foo".

Regards,

James

-- 
James Bonfield (j...@sanger.ac.uk) | Hora aderat briligi. Nunc et Slythia Tova
  | Plurima gyrabant gymbolitare vabo;
  A Staden Package developer: | Et Borogovorum mimzebant undique formae,
https://sf.net/projects/staden/   | Momiferique omnes exgrabure Rathi. 


-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 

Behavior change/feature : display -p var; where var is a "placeholder" variable

[Peggy Russell]

"Placeholder" variables currently can be displayed if they have an attribute
(iaArn) (1). Could there be a consideration for a behavior change/feature to
display them by name and prefix (2)(3)?

For illustration purposes:

  1) declare -i var; declare -pi
  2) declare -i var; declare -p var 
  3) declare -i var1= var2; declare -p ${!var*}

where the option 'i' above could be 'iaAnr' (1)(2)(3) and with the
additional '-' in (2)(3).

Peggy Russell

bash signal trap bug

[Paweł Gołaszewski]

Hello,

I think I've found bug in signal handling in bash.

Look at 2 scripts:
http://www.blues.gda.pl/SOURCES/show_logs.sh
http://www.blues.gda.pl/SOURCES/show_logs.zsh

Both are identical. "zsh" version works fine, "bash" version doesn't.
After start everything is fine, a can send _one_ HUP signal and it works 
as expected. The next HUP simply doesn't work. Even more: INT signal 
(Ctrl+C) works... like SIGHUP.

$ bash --version
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ zsh --version
zsh 4.3.17 (x86_64-unknown-linux-gnu)


System: linux debian 7.2


It's a little tricky, please let me know if something I should explain.


-- 
pozdr.  Paweł Gołaszewski  jid:bluesjabbergdapl
--
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.

Re: print float number

[lina]

On Wednesday 08,January,2014 01:36 PM, Bob Proulx wrote:
> Hi lina,
> 
> lina wrote:
>> How can I print the 0.05, 0.10 ... 1.0 out, with the step of 0.05
>>
>> Thanks ahead for your suggestions,
> 
> First please do not hijack threads.  You replied to Chris Down's
> message responding to DanielB about "For loop prints two $values
> instead of one" and then changed the subject but your message isn't
> about anything to do with that thread.  If you want to start a new
> thread like you did here please compose a new message.  Please don't
> reply to an existing thread to start a new conversation.

Hi Bob, my fault, I didn't realize this was a wrong way to start a new
conversation, by renaming the Subject and deleted everything inside. How
could they figure out it is from that thread?

> 
> Second is that this is simply a question and not a bug report.
> Questions should go to the help-b...@gnu.org mailing list.
> 
>> How can I print the 0.05, 0.10 ... 1.0 out, with the step of 0.05
> 
> As to your question there are many ways to solve the problem.  I would
> be inclined to use the GNU seq command.

Very helpful, thanks,
> 
>   $ seq 0.05 0.05 1.0
>   0.05
>   0.10
>   0.15
>   0.20
>   0.25
>   0.30
>   0.35
>   0.40
>   0.45
>   0.50
>   0.55
>   0.60
>   0.65
>   0.70
>   0.75
>   0.80
>   0.85
>   0.90
>   0.95
>   1.00
> 
> However seq is somewhat of a troubled command.  It does math with
> floating point and sometimes suffers from the same problems as
> anything that does compter based floating point math with various
> approximation and rounding errors.  You must be careful concerning it
> or odd errors will occur.
> 
> A related question about for loops in bash is discussed in this FAQ
> entry.  It isn't exactly your case but you might be interested in
> reading about the examples it provides.
> 
>   http://mywiki.wooledge.org/BashFAQ/018
> 
> I doubt just printing out these numbers were really your question.  If
> you wrote a message to help-b...@gnu.org and described your task in
> more detail there are many people who would be happy to help you use
> bash effectively.
> 
> Bob
>