On Fri, Jun 21, 2024, 10:21 PM Chet Ramey wrote:
> On 6/21/24 3:59 PM, alex xmb sw ratchev wrote:
>
> > > If floating point math support is added to bash, I would expect
> it to
> > > be able to handle floating point literals in these forms as well.
> >
> > I'm not planning to do th
Anybody else with the knowledge to tackle this?
I am not capable of even writing C code correctly.
On Fri, Jun 21, 2024 at 4:22 PM Chet Ramey wrote:
>
> On 6/21/24 3:59 PM, alex xmb sw ratchev wrote:
>
> > > If floating point math support is added to bash, I would expect it to
> > > be
On 6/21/24 3:59 PM, alex xmb sw ratchev wrote:
> If floating point math support is added to bash, I would expect it to
> be able to handle floating point literals in these forms as well.
I'm not planning to do this any time soon.
sorry my forgetness ... why ?
Because if floati
On 6/15/24 9:29 AM, Koichi Murase wrote:
I still feel it would be best if POSIX could be updated to allow the
implementations to extend the interpretation when the conversion by
strtod(3) fails. The current restriction is not an explicit one but
something deduced from the four statements of the
On Fri, Jun 21, 2024, 9:58 PM Chet Ramey wrote:
> On 6/17/24 8:04 AM, Zachary Santer wrote:
> > On Mon, Jun 17, 2024 at 3:48 AM Léa Gris wrote:
> >>
> >> Le 17/06/2024 à 09:17, Koichi Murase écrivait :
> >>> declare -i numvar=${localeFormatted/[!0-9]/.}
> >>
> >> This would break with negati
On 6/17/24 8:04 AM, Zachary Santer wrote:
On Mon, Jun 17, 2024 at 3:48 AM Léa Gris wrote:
Le 17/06/2024 à 09:17, Koichi Murase écrivait :
declare -i numvar=${localeFormatted/[!0-9]/.}
This would break with negative numbers.
I know no other radix separator than comma or dot. If there ar
On Mon, Jun 17, 2024 at 3:48 AM Léa Gris wrote:
>
> Le 17/06/2024 à 09:17, Koichi Murase écrivait :
> >declare -i numvar=${localeFormatted/[!0-9]/.}
>
> This would break with negative numbers.
>
> I know no other radix separator than comma or dot. If there are other
> radix to replace, it can
Le 17/06/2024 à 09:17, Koichi Murase écrivait :
declare -i numvar=${localeFormatted/[!0-9]/.}
This would break with negative numbers.
I know no other radix separator than comma or dot. If there are other
radix to replace, it can be listed in a character class.
Lets say there are locales
2024年6月17日(月) 15:56 Léa Gris :
> Le 16/06/2024 à 23:44, Zachary Santer écrivait :
> Anyway, this could be handled with existing bash string replacement feature:
>
> localeFormatted=3,1415
> declare -i numvar=${localeFormatted/,/.}
Is the radix character in an arbitrary locale ensured to be either
Le 16/06/2024 à 23:44, Zachary Santer écrivait :
How do you propose to take an LC_NUMERIC-formatted floating-point
literal and assign it to a variable with the numeric flag or make use
of it in another type of arithmetic context?
This proposal does not include conversion of locale formatted lit
On Sat, Jun 15, 2024 at 10:56 AM Léa Gris wrote:
>
> On 15/06/2024 à 15:29, Koichi Murase wrote :
> > at which point does the conversion happens
>
> The conversion to LC_NUMERIC format only happens during variable
> expansion outside of a numerical context.
> The numerical context can be explicit
On Sat, Jun 15, 2024, 4:56 PM Léa Gris wrote:
> On 15/06/2024 à 15:29, Koichi Murase wrote :
> > at which point does the conversion happens
>
> The conversion to LC_NUMERIC format only happens during variable
> expansion outside of a numerical context.
> The numerical context can be explicit if t
On 15/06/2024 à 15:29, Koichi Murase wrote :
at which point does the conversion happens
The conversion to LC_NUMERIC format only happens during variable
expansion outside of a numerical context.
The numerical context can be explicit if the assigned variable has a
numeric flag; it is implicit
2024年6月15日(土) 17:24 Léa Gris :
> Indeed printf only knows the string value. But Bash know the variable
> has a numeric flag when doing the value expansion, so it expands it
> using the current LC_NUMERIC locale in this specific case.
Ah, OK. I misunderstood your suggestion somehow differently (suc
Le 15/06/2024 à 02:49, Koichi Murase écrivait :
2024年6月14日(金) 16:18 Léa Gris :
Another elegant option would be to expand the existing variables' i flag
to tell the variable is numeric rather than integer.
Then have printf handle argument variables with the numeric flag as
using the LC_NUMERIC=C
2024年6月14日(金) 16:18 Léa Gris :
> Another elegant option would be to expand the existing variables' i flag
> to tell the variable is numeric rather than integer.
>
> Then have printf handle argument variables with the numeric flag as
> using the LC_NUMERIC=C floating-point format with dot radix poin
Great idea.
On Fri, Jun 14, 2024 at 3:18 AM Léa Gris wrote:
>
> Le 14/06/2024 à 03:41, Martin D Kealey écrivait :
> > On Thu, 13 Jun 2024 at 09:05, Zachary Santer wrote:
> >
> >>
> >> Let's say, if var is in the form of a C floating-point literal,
> >> ${var@F} would expand it to the locale-depe
Le 14/06/2024 à 03:41, Martin D Kealey écrivait :
On Thu, 13 Jun 2024 at 09:05, Zachary Santer wrote:
Let's say, if var is in the form of a C floating-point literal,
${var@F} would expand it to the locale-dependent formatted number, for
use as an argument to printf or for output directly. And
On Thu, 13 Jun 2024 at 09:05, Zachary Santer wrote:
>
> Let's say, if var is in the form of a C floating-point literal,
> ${var@F} would expand it to the locale-dependent formatted number, for
> use as an argument to printf or for output directly. And then ${var@f}
> would go the other way, takin
I think that we should go ahead and do it.
On Wed, Jun 12, 2024, 5:06 PM Zachary Santer wrote:
> On Thu, Jun 6, 2024 at 6:34 AM Léa Gris wrote:
> >
> > Le 06/06/2024 à 11:55, Koichi Murase écrivait :
> >
> > > Though, I see your point. It is inconvenient that we cannot pass the
> > > results of
On Thu, Jun 6, 2024 at 6:34 AM Léa Gris wrote:
>
> Le 06/06/2024 à 11:55, Koichi Murase écrivait :
>
> > Though, I see your point. It is inconvenient that we cannot pass the
> > results of arithmetic evaluations to the `printf' builtin. This
> > appears to be an issue of the printf builtin. I thin
On 6/5/24 2:59 AM, Léa Gris wrote:
Le 05/06/2024 à 17:09, Koichi Murase écrivait :
2024年6月5日(水) 21:41 Zachary Santer :
Bash could potentially detect floating point literals within
arithmetic expansions and adjust the operations to use floating point
math in that case. [...]
ksh and zsh are al
On Wed, Jun 5, 2024 at 4:08 PM Robert Elz wrote:
>
> That's a perfect case for scaled integers - no-one ever deals with
> fractions of cents in this kind of thing (a bank won't ever tell you
> that your balance is $5678.17426 for example, even if the interest
> calculations computed accurately mig
Le 06/06/2024 à 11:55, Koichi Murase écrivait :
Though, I see your point. It is inconvenient that we cannot pass the
results of arithmetic evaluations to the `printf' builtin. This
appears to be an issue of the printf builtin. I think the `printf'
builtin should be extended to interpret both for
2024年6月6日(木) 18:09 Léa Gris :
> Le 06/06/2024 à 10:29, Koichi Murase écrivait :
> > 2024年6月6日(木) 15:59 Léa Gris :
> >> Le 05/06/2024 à 17:09, Koichi Murase écrivait :
> >>> 2024年6月5日(水) 21:41 Zachary Santer :
> Bash could potentially detect floating point literals within
> arithmetic expa
Le 06/06/2024 à 10:29, Koichi Murase écrivait :
2024年6月6日(木) 15:59 Léa Gris :
Le 05/06/2024 à 17:09, Koichi Murase écrivait :
2024年6月5日(水) 21:41 Zachary Santer :
Bash could potentially detect floating point literals within
arithmetic expansions and adjust the operations to use floating point
m
2024年6月6日(木) 15:59 Léa Gris :
> Le 05/06/2024 à 17:09, Koichi Murase écrivait :
> > 2024年6月5日(水) 21:41 Zachary Santer :
> >> Bash could potentially detect floating point literals within
> >> arithmetic expansions and adjust the operations to use floating point
> >> math in that case. [...]
> >
> >
Le 05/06/2024 à 17:09, Greg Wooledge écrivait :
On Wed, Jun 05, 2024 at 09:57:26PM +0700, Robert Elz wrote:
Also note that to actually put floating support in the shell, more is
needed than just arithmetic, you also need floating comparisons in test
(or in bash, in [[ ) and a whole bunch more od
Le 05/06/2024 à 17:09, Koichi Murase écrivait :
2024年6月5日(水) 21:41 Zachary Santer :
Bash could potentially detect floating point literals within
arithmetic expansions and adjust the operations to use floating point
math in that case. [...]
ksh and zsh are already behaving in that way, and if B
Date:Wed, 5 Jun 2024 13:31:20 -0400
From:Saint Michael
Message-ID:
| the most obvious use of floating variables would be to compare
| balances and to branch based on if a balance is lower than a certain
| value
In addition to what Greg suggested, for the very
I think that we should do this in the shell. I mean. It will get done at
some point, in the next decades or centuries. Why not do it now? Let's
compile some C library or allow inline C
On Wed, Jun 5, 2024, 2:12 PM Greg Wooledge wrote:
> On Wed, Jun 05, 2024 at 01:31:20PM -0400, Saint Michael wro
On Wed, Jun 05, 2024 at 01:31:20PM -0400, Saint Michael wrote:
> the most obvious use of floating variables would be to compare
> balances and to branch based on if a balance is lower than a certain
> value
> I use:
> t=$(python3 -c "import math;print($balance > 0)")
> and the
> if [ "$t" == "False
the most obvious use of floating variables would be to compare
balances and to branch based on if a balance is lower than a certain
value
I use:
t=$(python3 -c "import math;print($balance > 0)")
and the
if [ "$t" == "False" ];then
echo "Result <= 0 [$t] Client $clname $clid Balance $balance"
fi
The
Date:Wed, 5 Jun 2024 11:09:45 -0400
From:Greg Wooledge
Message-ID:
| > to convert floats back into integers again, controlling how
| > rounding happens).
|
| Ironically, that last one is the one we already *do* have.
Yes, I know about printf (and while POSIX
2024年6月5日(水) 21:41 Zachary Santer :
> Bash could potentially detect floating point literals within
> arithmetic expansions and adjust the operations to use floating point
> math in that case. [...]
ksh and zsh are already behaving in that way, and if Bash would
support the floating-point arithmeti
On Wed, Jun 05, 2024 at 09:57:26PM +0700, Robert Elz wrote:
> Also note that to actually put floating support in the shell, more is
> needed than just arithmetic, you also need floating comparisons in test
> (or in bash, in [[ ) and a whole bunch more odds and ends that aren't
> obvious until you n
Date:Wed, 5 Jun 2024 08:40:51 -0400
From:Zachary Santer
Message-ID:
| The magnification factor is handled as a
| fractional number - 1.5, 1.75, etc. So, to change the magnification
| factor by increments of 0.25 or 0.5, I had to print an expression into
| b
On Tue, Jun 4, 2024 at 4:01 PM Saint Michael wrote:
>
> >
> > It's time to add floating point variables and math to bash.
>
> It just makes so much easier to solve business problems without external
> calls to bc or Python.
> Please let's overcome the "shell complex". Let's treat bash a real langu
38 matches
Mail list logo
