I am not sure what if this is what you are looking for but the Pretty Diff tool performs a literal text difference without regard to the contents it is comparing. Unfortunately it does illustrate differences in white space, but only after both contents are first minified and then beautified to normalize all the white space if used with one of the supported code options. I am not familiar with the syntax you illustrated in your example, so may need to use the plain text mode of the tool.
A:
Thanks. But this is simply a text compare; there are tons of tools that can do this. I am looking for comparison by numeric value.
system PAUSE
2009-09-23 23:44:12
A:
I'm not aware of such tool but it would be fairly easy to whip up a Perl script to do that for you by combining some fancy floating point regular expression set with a bunch of routines to normalize said regexed floats. I can probably take a swing at it if you need help, but it's a bit time consuming enterprise so I'll be a greedy pig and ask for a useful bounty (although at 60% accept rate, I'm a bit wary of answering anyway - hint hint)
DVK
2009-09-15 22:25:26
Thanks for your offer. Actually I've been looking at writing my own tool for this, but I'm not convinced that regexes are sufficient for comparisons within a specified tolerance.
system PAUSE
2009-09-23 23:38:23
Oh, and please don't put too much stock in the accept rate. For one, that figure doesn't exempt "poll" questions, which have multiple correct answers. And some questions (like this one) are difficult to get a definitive answer in any short timeframe. If I don't get a "Yes, here it is..." in a couple of weeks, I'll assume the answer is "No" and proceed accordingly.
system PAUSE
2009-09-23 23:43:07
If you roll our own, what you want to do is to use Math:: library hierarchy (Math::BigFloat i think) possibly matched with the best floating-point regexp you can find on CPAN or construct yourself - the Perl Regexp book has some nice ones. If you're lucky, Math:: hierarchy has its own parser (have't used it for a while so don't recall).
DVK
2009-09-24 12:29:13
A regexp cannot reasonably be bent to compute tolerances. You need to convert the values to machine floats and compare them.
Ira Baxter
2009-10-03 23:16:17
@Ira - quite right. Thus the "with a bunch of routines to normalize said regexed floats." part of the answer
DVK
2009-10-04 02:56:47
+1
A:
There is this one, which looks very interesting. I'm trying to have it working on my AIX, so I haven't seem it in action yet, but I believe this is what you (and I :-) need
Davide
2009-09-28 20:08:43
Wow! Output is **exactly** what I wanted! Btw, the BeOS version [http://www.bebits.com/app/3784] compiled under Cygwin with no changes.
system PAUSE
2009-09-28 23:44:06
Well, I am still unable to get it working on AIX. On Linux, gcc-3.3.3 compiled it, but it segfault on the first "spiff Sample.1 Sample.2". On a newer machine, gcc-4.2.4 is angry for:spiff.c:178: error: static declaration of ‘_Y_doargs’ follows non-static declarationspiff.c:30: error: previous declaration of ‘_Y_doargs’ was here
Davide
2009-09-29 16:05:53
@Davide: If you're still stuck, maybe you should ask a question about it on some website somewhere. ;-)
system PAUSE
2009-10-02 20:47:32
Sure, but for now I just asked a friend running Cygwin, and it worked :-)
Davide
2009-10-13 17:34:13
+1
A:
See Smart Differencer Tools. These tools compare two source code files according to program structure, as opposed to comparing text lines. To do so, these tools parse the source file according to the language rules, build an AST, and compare trees. The output is in terms of abstract editing changes (insert, delete, move, copy, rename) to program structures (identifiers, expressions, statements, blocks, methods, ...).
As a side effect, the individual language lexemes, such as character, string and numeric literals, are converted to a normal form internal representation. The format of literal is ignored, so it will treat floating point values such as 00.001 and 1e-03 as identical, 0xFF and 255 as identical, and "\n" and "\u000a" as identical. This doesn't include an tolerance fuzz for floating point numbers, but it does ignore thier shape. What this means is the the SmartDifference tools will report two corresponding but slightly different numbers as different, but it will only report the numbers themselves; you'll get something like
<Line 75 col 15-19 1.01
>replace by Line 75 col 15-19 1.02
The matcher presently allows identifiers to be different and treats a consistent identifier renaming across a scope as a single edit rather that a bunch of different edits. The idea of using floating point fuzz to allow matching of near-miss fp numbers is interesting; I'll add it to the possible feature request list.
These tools are production for Java, COBOL and C#. We have preproduction versions for C++ and C; the hard issue is picking up program structures for languages that effectively allow arbitrary editing of the souce via use of macros and preprocessor conditionals.
Ira Baxter
2009-10-02 21:23:36
Definitely a step in the direction I wanted, and pretty darned cool. I'm curious how the "internal representation" can compare floating-point values without a tolerance. I guess if you're constrained to literals (as opposed to calculation results), the tolerance isn't strictly necessary. But wouldn't it be a nifty feature? ;-)
system PAUSE
2009-10-05 15:32:04
@system PAUSE: comparing "internal representations" is easy. Take the binary floating point value, and compare to the other for equality. That isn't different than comparing identifiers or string literals.
Ira Baxter
2009-10-05 15:37:10