On 03/08/2011 04:03 AM, Vit Bartunek wrote:
> Hi there,
>
> seq parametr -w (--equal-width) is not working
>
> Trying to execute command bellow, the parametr seems to be ignored.
> seq --equal-width 1 0 99
Thanks for the report. However, I cannot reproduce it:
$ seq -w 1 0 99 | head
01
01
01
Hi there,
seq parametr -w (--equal-width) is not working
Trying to execute command bellow, the parametr seems to be ignored.
seq --equal-width 1 0 99
Name: coreutilsRelocations: (not relocatable)
Version : 5.97 Vendor: CentOS
Release
Hi Bob, Eric
Thank you for your replies.
>db_23?wrote:
>>?When?LAST?is?equal?to?1,000,000?(seq?1000).?I?got?the?outcome?as
This is my fault. It should be 10,000,000.
>>?the?following.?Numbers?after?999,999?appears?more?than?once,?but?not
>>?at?fixed?times.
>
>Thank?you?for?the?report.??Unf
db_23 wrote:
> When LAST is equal to 1,000,000 (seq 1000). I got the outcome as
> the following. Numbers after 999,999 appears more than once, but not
> at fixed times.
Thank you for the report. Unfortunately seq uses floating point
numbers internally. This has caused some problems in the re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to db_23 on 8/20/2009 9:06 AM:
> Hi
> When LAST is equal to 1,000,000 (seq 1000). I got the outcome as the
> following. Numbers after 999,999 appears more than once, but not at fixed
> times.
1,000,000 is not the same as 1000. W
Hi
When LAST is equal to 1,000,000 (seq 1000). I got the outcome as the
following. Numbers after 999,999 appears more than once, but not at fixed
times.
-
97
98
99
1e+06
1e+06
1e+06
1e+06
1e+06
1e+06
1.1e+06
1.1e+06
1.1e+06
1.1e+06
1.1e+06
1.1
Daniel Dunbar <[EMAIL PROTECTED]> wrote:
> Thanks for the quick reply on the ptx bug.
>
> We have found another minor bug (non-crashing) in seq. An example problem
> input
> is:
> --
> [EMAIL PROTECTED]:src$ ./seq -f %0 1
> ./seq: memory exhausted
> --
>
> The problem is in seq.c:213 (in 6.10 sour
Hi Jim,
Thanks for the quick reply on the ptx bug.
We have found another minor bug (non-crashing) in seq. An example problem input
is:
--
[EMAIL PROTECTED]:src$ ./seq -f %0 1
./seq: memory exhausted
--
The problem is in seq.c:213 (in 6.10 source),
if (! strchr ("efgaEFGA", fmt[i]
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Pádraig Brady <[EMAIL PROTECTED]> writes:
>
>> The attached patch handles this by
>> only counting signficant digits from the operands.
>
> I'd rather use the idea I proposed earlier. Here's an implementation
> of it, which works on all the test cases in y
Pádraig Brady <[EMAIL PROTECTED]> writes:
> Thank you for the explanation and fixing this up.
You're welcome. And thanks for supplying such a fun problem,
(though perhaps I should qualify that by saying it was more fun than
what I should have been working on, which was grading my students'
work.
Micah Cowan <[EMAIL PROTECTED]> writes:
> f making seq act as if it were counting in decimal for fractions,
> instead of binary floating-point, is really something we want to
> consider, then why don't we actually have seq represent fractions in
> decimal, internally?
Yes, that would be better.
Paul Eggert wrote:
> Pádraig Brady <[EMAIL PROTECTED]> writes:
>
>> I haven't time to look at this now,
>> but will soon.
>
> Thanks.
>
>> A couple of points came to mind.
>>
>> Is it OK to look at just 1 value "after" last?
>
> It should not be necessary to look 2 values "after" last. The pro
f making seq act as if it were counting in decimal for fractions,
instead of binary floating-point, is really something we want to
consider, then why don't we actually have seq represent fractions in
decimal, internally? Isn't that the only real way we could possibly
expect seq to "do what the user
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Pádraig Brady <[EMAIL PROTECTED]> writes:
...
>> Aren't you susceptible to whatever rounding
>> printf does internally?
>
> Yes, that's quite true. One can easily construct examples where the
> revised "seq" is mathematically incorrect, due to this problem.
Pádraig Brady <[EMAIL PROTECTED]> writes:
> I haven't time to look at this now,
> but will soon.
Thanks.
> A couple of points came to mind.
>
> Is it OK to look at just 1 value "after" last?
It should not be necessary to look 2 values "after" last. The problem
we're trying to address is the bu
Paul Eggert wrote:
> + /* If we go one past the end, but that number prints the
> + same way "last" does, and prints differently from the
> + previous number, then print "last". This avoids problems
> + with rounding. For example, with the x86 it causes "seq
> +
Pádraig Brady <[EMAIL PROTECTED]> writes:
> The attached patch handles this by
> only counting signficant digits from the operands.
I'd rather use the idea I proposed earlier. Here's an implementation
of it, which works on all the test cases in your patch. In addition,
it works on the wilder co
Pádraig Brady wrote:
> Paul Eggert wrote:
>> Pádraig Brady <[EMAIL PROTECTED]> writes:
>>
>>> OK, how about the attached patch?
>> Better, but it still has problems. For example, on my platform
>> (Debian stable with GCC 4.2.0, x86) the command
>> "seq 0.0 0.1 0.9000" outputs somet
Paul Eggert wrote:
> Pádraig Brady <[EMAIL PROTECTED]> writes:
>
>> OK, how about the attached patch?
>
> Better, but it still has problems. For example, on my platform
> (Debian stable with GCC 4.2.0, x86) the command
> "seq 0.0 0.1 0.9000" outputs something different from
> "se
Pádraig Brady <[EMAIL PROTECTED]> writes:
> OK, how about the attached patch?
Better, but it still has problems. For example, on my platform
(Debian stable with GCC 4.2.0, x86) the command
"seq 0.0 0.1 0.9000" outputs something different from
"seq 0.0 0.1 0.9". The former stops
Pádraig Brady wrote:
> Paul Eggert wrote:
>> Pádraig Brady <[EMAIL PROTECTED]> writes:
>>
>>> This patch makes `seq 0.1 0.1 0.9` output 0.1 to 0.9 inclusive, as expected.
>> I see some problems with that patch.
>>
>> First, it continues to mishandle some similar cases. For example,
>> 'seq 0.1 1e-
Paul Eggert wrote:
> Pádraig Brady <[EMAIL PROTECTED]> writes:
>
>> This patch makes `seq 0.1 0.1 0.9` output 0.1 to 0.9 inclusive, as expected.
>
> I see some problems with that patch.
>
> First, it continues to mishandle some similar cases. For example,
> 'seq 0.1 1e-1 0.9' outputs only 0.1 t
Pádraig Brady <[EMAIL PROTECTED]> writes:
> This patch makes `seq 0.1 0.1 0.9` output 0.1 to 0.9 inclusive, as expected.
I see some problems with that patch.
First, it continues to mishandle some similar cases. For example,
'seq 0.1 1e-1 0.9' outputs only 0.1 through 0.8, i.e. it behaves
differ
This patch makes `seq 0.1 0.1 0.9` output 0.1 to 0.9 inclusive, as expected.
The documentation for the previously required workaround is removed.
Note I changed the Makefile for seq to link $(SEQ_LIBM) rather than $(POW_LIB),
as $(POW_LIB) was empty. Is the configure test correct for pow()? as gcc
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> ...
>>> Another thing I just noticed. I would expect the precision
>>> of all output in the following command to be to 2 decimal places not 1:
>>> $ seq 0.00 0.01 0.90
Jim Meyering <[EMAIL PROTECTED]> writes:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
> ...
>> Another thing I just noticed. I would expect the precision
>> of all output in the following command to be to 2 decimal places not 1:
>> $ seq 0.00 0.01 0.90 | grep "\.[0-9]$"
>> 0.1
>> 0.2
>> 0.3
>> 0.4
>
Andreas Schwab wrote:
> Pádraig Brady <[EMAIL PROTECTED]> writes:
>
>> Yes you could use gmp, but for normal uses of `seq`
>> you could just use appropriate comparisons?
>> How about the following patch, and we can also
>> remove the workaround info from the docs.
>>
>> Pádraig.
>>
>> --- seq.orig
Pádraig Brady <[EMAIL PROTECTED]> writes:
> Yes you could use gmp, but for normal uses of `seq`
> you could just use appropriate comparisons?
> How about the following patch, and we can also
> remove the workaround info from the docs.
>
> Pádraig.
>
> --- seq.orig.c 2007-06-08 07:50:24.0
Pádraig Brady wrote:
> John Cowan wrote:
>> Pádraig Brady scripsit:
>>
>>> The issue and work around are documented in the info page,
>>> but why don't we do the suggestion automatically in code
>>> (using the precision that is automatically worked out already)?
>> That implies using either a fixed
John Cowan wrote:
> Pádraig Brady scripsit:
>
>> The issue and work around are documented in the info page,
>> but why don't we do the suggestion automatically in code
>> (using the precision that is automatically worked out already)?
>
> That implies using either a fixed-point or a decimal-based
Pádraig Brady scripsit:
> The issue and work around are documented in the info page,
> but why don't we do the suggestion automatically in code
> (using the precision that is automatically worked out already)?
That implies using either a fixed-point or a decimal-based floating-point
package. GNU
Pádraig Brady <[EMAIL PROTECTED]> wrote:
...
> Another thing I just noticed. I would expect the precision
> of all output in the following command to be to 2 decimal places not 1:
>
> $ seq 0.00 0.01 0.90 | grep "\.[0-9]$"
> 0.1
> 0.2
> 0.3
> 0.4
> 0.5
> 0.6
> 0.7
> 0.8
> 0.9
Well, at least with t
Pádraig Brady wrote:
> Another thing I just noticed. I would expect the precision
> of all output in the following command to be to 2 decimal places not 1:
>
> $ seq 0.00 0.01 0.90 | grep "\.[0-9]$"
> 0.1
> 0.2
> 0.3
> 0.4
> 0.5
> 0.6
> 0.7
> 0.8
> 0.9
I wouldn't. The documentation is fairly cle
Micah Cowan wrote:
> Patrick Amstutz wrote:
>> Hi,
>>
>> I've the following behavior with the seq function on:
>>
>> Linux version 2.6.18.8-0.3-default ([EMAIL PROTECTED]) (gcc version
>> 4.1.220061115 (prerelease) (SUSE Linux)) #1
>>
>> $ echo `seq 0.0 0.1 0.8`
>> 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8
Micah Cowan scripsit:
> You need to use something more like:
> $ echo `seq 0.0 0.1 0.91`
> 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Or better yet, use `seq 0 9` and prepend the "0." part yourself.
(The Cowan twins strike again!)
--
A witness cannot give evidence of his John Cowan
age un
Patrick Amstutz scripsit:
> $ echo `seq 0.0 0.1 0.8`
> 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8
> $ echo `seq 0.0 0.1 0.9`
> 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8
Welcome to floating-point roundoff errors. The decimal constant 0.1
cannot be exactly represented as a floating-point number on modern
hardware,
Patrick Amstutz wrote:
> Hi,
>
> I've the following behavior with the seq function on:
>
> Linux version 2.6.18.8-0.3-default ([EMAIL PROTECTED]) (gcc version
> 4.1.220061115 (prerelease) (SUSE Linux)) #1
>
> $ echo `seq 0.0 0.1 0.8`
> 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8
> $ echo `seq 0.0 0.1 0.9`
Hi,
I've the following behavior with the seq function on:
Linux version 2.6.18.8-0.3-default ([EMAIL PROTECTED]) (gcc version
4.1.220061115 (prerelease) (SUSE Linux)) #1
$ echo `seq 0.0 0.1 0.8`
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8
$ echo `seq 0.0 0.1 0.9`
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8
Best r
38 matches
Mail list logo
