Bug 134282

Summary: decimal math expression "patch"
Product: [Unmaintained] kdesktop Reporter: Konrad Miller <konrad_miller>
Component: minicliAssignee: David Faure <faure>
Status: CLOSED FIXED    
Severity: wishlist CC: esigra, finex
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Konrad Miller 2006-09-18 16:44:29 UTC
Version:            (using KDE KDE 3.5.2)
Installed from:    SuSE RPMs
OS:                Linux

Bash's $(()) can only do integer arithmetic. I suggest to check for bc and use it instead of $(()), if it is installed.
Comment 1 Konrad Miller 2006-09-18 16:48:03 UTC
This here should do:

QString Minicli::calculate(const QString &exp)
{
   QString result;
   QString cmd = QString("if [ -x \"$(which bc)\" ]; then echo \"%1\" | bc -l; else echo $((%1)); fi").arg(exp);
   FILE *fs = popen(QFile::encodeName(cmd).data(), "r");
   if (fs)
   {
      QTextStream ts(fs, IO_ReadOnly);
      result = ts.read().stripWhiteSpace();
      pclose(fs);
   }
   return result;
}
Comment 2 Konrad Miller 2006-09-18 17:03:11 UTC
"Real numbers in math expression patch", not decimal of course - sorry bout that.
Comment 3 David Faure 2006-09-18 18:03:34 UTC
SVN commit 586065 by dfaure:

Make 1.2+3.4 work in minicli, using bc, based on patch/idea by Konrad Miller.
It has annoyed me a few times that only integers worked due to using $(()) indeed.
BUG: 134282


 M  +6 -2      minicli.cpp  


--- branches/KDE/3.5/kdebase/kdesktop/minicli.cpp #586064:586065
@@ -859,8 +859,12 @@
 
 QString Minicli::calculate(const QString &exp)
 {
-   QString result;
-   QString cmd = QString("echo $((%1))").arg(exp);
+   QString result, cmd;
+   const QString bc = KStandardDirs::findExe("bc");
+   if ( !bc.isEmpty() )
+      cmd = QString("echo %1 | %2").arg(KProcess::quote(exp), KProcess::quote(bc));
+   else
+      cmd = QString("echo $((%1))").arg(exp);
    FILE *fs = popen(QFile::encodeName(cmd).data(), "r");
    if (fs)
    {
Comment 4 David Faure 2006-09-18 18:08:01 UTC
I made the check more kde-like, which might make this work with C shells too,
added quoting to avoid problems with special characters (just in case),
and didn't use bc -l just in case there are versions of bc out there that don't support -l;
doesn't change anything for simple real-numbers-arithmetic anyway, and minicli doesn't
trigger bc if you add a function call anyway...
Thanks for the idea, David.
Comment 5 Konrad Miller 2006-09-18 19:10:57 UTC
Thank you for the fast response :).
Konrad
Comment 6 Konrad Miller 2006-09-19 11:26:24 UTC
If you don't use the -l switch in bc, "real" division doesn't work, btw..

dfi@shadow ~ $ echo "1.5/3" | bc
0

Konrad
Comment 7 Konrad Miller 2006-09-19 11:27:10 UTC
reopen
Comment 8 Konrad Miller 2006-09-19 11:36:36 UTC
You don't need to invoke -l. Setting the bc scale variable works also. But what should it be set to?

dfi@shadow ~ $ echo "scale=2; 1.5/3" | bc
.50

Sorry for spamming so much in here - but this thing bothers me...

Konrad
Comment 9 David Faure 2006-09-20 16:59:12 UTC
On Tuesday 19 September 2006 10:42, Stephan Kulow wrote:
> Am Montag, 18. September 2006 18:01 schrieb David Faure:
> > SVN commit 586065 by dfaure:
> >
> > Make 1.2+3.4 work in minicli, using bc, based on patch/idea by Konrad
> > Miller. It has annoyed me a few times that only integers worked due to
> > using $(()) indeed. BUG: 134282
> >
> I just hope that people don't confuse minicli with a calculator or they will 
> wonder why the finance office refuses their papers :)
> 
> coolo@portia#~>echo "12*0.2" | bc
> 2.4
> coolo@portia#~>echo "12/5" | bc
> 2


Interesting, this is exactly what Konrad miller just mentionned in #134282:
this was the reason he had used "bc -l", which I removed because I didn't know
it did that, and I didn't know if all versions of bc had it.
So it sounds like re-adding -l would be a good idea, to fix the above problem,
except that it leads to "2.40000000000000000000" which is a bit annoying.

echo "scale=2; 12/5" | bc
says 2.40, but I wonder why bc doesn't have a mode where it simply removes
the useless trailing zeros... Well, we could do it in code of course...
Comment 10 kris 2006-09-20 17:03:28 UTC
On Wednesday, 20. September 2006 16:59, David Faure wrote:
> echo "scale=2; 12/5" | bc
> says 2.40, but I wonder why bc doesn't have a mode where it simply removes
> the useless trailing zeros... Well, we could do it in code of course...


The -l option also includes the advanced bc functions (mathlib), and does so 
on all platforms.

The modification of scale= (precision) is just a side effect of -l.

Kris
Comment 11 David Faure 2006-09-20 18:41:03 UTC
SVN commit 586801 by dfaure:

OK with a scale set, divisions work, and only them display lots of zeros, a+b and a-b don't so this is ok imho.
BUG: 134282


 M  +1 -1      minicli.cpp  


--- branches/KDE/3.5/kdebase/kdesktop/minicli.cpp #586800:586801
@@ -862,7 +862,7 @@
    QString result, cmd;
    const QString bc = KStandardDirs::findExe("bc");
    if ( !bc.isEmpty() )
-      cmd = QString("echo %1 | %2").arg(KProcess::quote(exp), KProcess::quote(bc));
+      cmd = QString("echo %1 | %2").arg(KProcess::quote(QString("scale=8; ")+exp), KProcess::quote(bc));
    else
       cmd = QString("echo $((%1))").arg(exp);
    FILE *fs = popen(QFile::encodeName(cmd).data(), "r");
Comment 12 Konrad Miller 2006-09-20 18:48:22 UTC
I don't know if you want to hear this, but bash can do this...
i=$(echo "12/5" | bc -l) &&  i="${i//%0*/}" && echo "${i//%\./.0}"

The first expression removes trailing zeros, the second adds a 0 if the last
caracter is a '.'.

HTH,
Konrad
Comment 13 David Faure 2006-09-21 10:00:55 UTC
> The first expression removes trailing zeros

... including those that are not after a decimal point ;)

> i=$(echo "120" | bc -l) &&  i="${i//%0*/}" && echo "${i//%\./.0}"

12

Anyway, I could remove the trailing zeros in C++, I'm just surprised that bc doesn't do it,
and I also don't think it will be a big issue; I personally only ever used minicli for + and -,
divisions don't happen that often in real life, or a real calculator ends up being useful then.
Comment 14 Stephan Kulow 2006-09-21 13:20:27 UTC
Am Mittwoch, 20. September 2006 16:58 schrieb David Faure:
> On Tuesday 19 September 2006 10:42, Stephan Kulow wrote:
> > Am Montag, 18. September 2006 18:01 schrieb David Faure:
> > > SVN commit 586065 by dfaure:
> > >
> > > Make 1.2+3.4 work in minicli, using bc, based on patch/idea by Konrad
> > > Miller. It has annoyed me a few times that only integers worked due to
> > > using $(()) indeed. BUG: 134282
> >
> > I just hope that people don't confuse minicli with a calculator or they
> > will wonder why the finance office refuses their papers :)
> >
> > coolo@portia#~>echo "12*0.2" | bc
> > 2.4
> > coolo@portia#~>echo "12/5" | bc
> > 2
>
> Interesting, this is exactly what Konrad miller just mentionned in #134282:
> this was the reason he had used "bc -l", which I removed because I didn't
> know it did that, and I didn't know if all versions of bc had it.
> So it sounds like re-adding -l would be a good idea, to fix the above
> problem, except that it leads to "2.40000000000000000000" which is a bit
> annoying.
>
> echo "scale=2; 12/5" | bc
> says 2.40, but I wonder why bc doesn't have a mode where it simply removes
> the useless trailing zeros... Well, we could do it in code of course...


I guess scale=2 will be fine

Greetings, Stephan
Comment 15 FiNeX 2009-01-02 20:33:18 UTC
Bug closed. Kdesktop is no more mantained.
Comment 16 esigra 2009-01-02 21:33:54 UTC
Why do you change a lot of bug's status from RESOLVED to CLOSED? (What exactly is the difference? They still have a "resolution" so it makes sense that they are RESOLVED.) And what do you mean with "Kdesktop is no more mantained."? I thought that Kdesktop is an important part of a current KDE release?
Comment 17 FiNeX 2009-01-02 21:43:03 UTC
The difference is that "CLOSED" means that the problem is completely solved and no further actions will be taken on that issue.

KDesktop is an important part of KDE, right, but the mantainer/developer doesn't works on it anymore. He agreed with me to close them.

If the problem is important to be solved:
1) it shouldn't be had marked as FIXED
2) it should be checked if KDE 4 has the same problem
3) if both suffer of the same problem, it could be opened a new bug report against KDE 4.