Version: 1.0.0_devel (using KDE 3.3.0, compiled sources) Compiler: gcc version 3.3.2 OS: SunOS (sun4u) release 5.8 I have data files with integers being concatenation of several booleans. To extract individual booleans, I'd like to be able to apply a bitwise AND operator, which is not in the list currently. This is the same kind of request as #85701 and may be the occasion to think about more operators needed (normal AND, OR and possibly bitwise OR ?).
I assume when you say "not in the the list" you are refering to the New Equation editor. The !, &, |, <, <=, >, >=, == operators are all supported but not listed in the combobox in the New Equation editor. They can be simply typed into the equation though. They could be added to the combobox, although the list will start to get longer and so less useful. My preference would be to include only operators with more than 2 characters in this list. The corresponding bitwise operators for &, | are not supported. This may cause some backward compatibility as obviously most people expect &, | to be the bitwise operators and &&, || to be the logical operators.
Nice to know comparison operators are supported, I was thinking I should add a comment to ask for them ;-) But I definitely believe all operators should be in the list as most users will use the list as a reference of what is implemented. Power users will probably type the complete expression directly once they know the syntax, so that the length does not sound too bad to me (as long as it does not become >> 100 !). As for bitwise operators and the fact that & actually means &&, I'd say it would be better to implement bitwise operators (especially as I need them :-)) and rename the standard AND and OR to && and ||. Another option would be to call the bitwise operators ".&" and ".|" like in Scilab/Matlab syntax if I remember it right and leave & and | for the standard ones.
Whatever we do here it has to be backward compatible so that the meaning of existing equations does not change.
That makes sense :-) So, let's use ".&" and ".|" ! I looked at the enode* stuff a bit today, but I'm not familiar with parsers and such stuff, and I think I'll leave it to you to implement this ! And please add all operators to the drop-down list (there has already been another bug report commenting on operators that were implemented but did not appear in the list: 85701; I share the point of view) !
Couple thoughts: -we are not 1.0, so we can break compatibility if we need to. Now is the last chance. -if we are going to have logical and bitwise operators, we really ought to be compatible with some already existant standard. I would vote for C. (ie logical = &&, bitwise = &). Are there any other suggestions? -All vectors are doubles, so adding this this may or may not cause troubles. We need to be careful.
On Tuesday 07 September 2004 17:41, netterfield@astro.utoronto.ca wrote: > -we are not 1.0, so we can break compatibility if we need to. Now is the > last chance. Right, best to do it now. This feature dates back only a few months in CVS anyway. > -if we are going to have logical and bitwise operators, we > really ought to be compatible with some already existant standard. I would > vote for C. (ie logical = &&, bitwise = &). Are there any other > suggestions? I prefer C-style as well. > -All vectors are doubles, so adding this this may or may not > cause troubles. We need to be careful. It's a tricky thing to implement. It doesn't even really make sense in terms of doubles because we are floating-point implementation "independent". The best we can do is convert to long or so I think.
Since I _really_ needed a bitwise AND operator, I changed the behavior of the current & (I know, this is bad but it's just a quick hack until it's properly implemented) and it works well with double arguments cast to (int). If we can forget compatibility at this point, I'd also favor using the more standard C-style.
CVS commit by staikos: Implement more operators and add them to the list: && - logical and & - becomes bitwise and || - logical or | - becomes bitwise or != == and = are equivalent ';' added everywhere in the parser to make it compile with my bison again repaired debugging output CCMAIL: 88950-done@bugs.kde.org M +5 -2 enodefactory.cpp 1.5 M +5 -2 enodefactory.h 1.5 M +83 -19 enodes.cpp 1.15 M +5 -2 enodes.h 1.10 M +849 -631 eparse.c 1.8 [POSSIBLY UNSAFE: printf] M +30 -19 eparse.h 1.6 M +42 -34 eparse.y 1.8 M +55 -0 eqdialog.ui 1.26 M +79 -54 escan.c 1.7 M +8 -0 escan.l 1.7
While we're at it, could we add support for integrals with a syntax like INTEG(vector) yielding a stepwise integration ? Sorry I haven't thought of it earlier, but a colleague of mine reminded me as soon as I showed off the new operators :-) P.S.: [bugzilla question] should I rather open a new report in such a case ?
... and DERIV(vector) = (YValue(n) - YValue(n-1)) / (XValue(n) - XValue(n-1))
On Wednesday 15 September 2004 15:39, Nicolas Brisset wrote: > 21:39 ------- While we're at it, could we add support for integrals with a > syntax like INTEG(vector) yielding a stepwise integration ? Sorry I haven't > thought of it earlier, but a colleague of mine reminded me as soon as I > showed off the new operators :-) > > P.S.: [bugzilla question] should I rather open a new report in such a case > ? Yes please open a new report.
OK, I will create a new report for the INTEG and DERIV operators and close that one.