Kyle Wheeler <kyle-wcalc-yahoo@...> schrieb:

> Hmm, well, I tend to like not being restrictive, and I also like
> maintaining the existing behavior. In Wcalc 1.x, this was implemented
> as the C % operator, so I'd like to keep it that way. On the other
> hand, I can see a valid need for something more interesting, like the
> "rem" operator in Ada. Perhaps I should add your method as the
> implementation of that operator...?

Actually, if I'm reading the ADA reference manual correctly, the REM
operator does exactly what your algorithm does (A REM B keeps the sign
of A) while the MOD operator does the same as mine (A MOD B keeps the
sign of B; I was mistaken when I claimed my algorithm would always pick
the positive result).

There's one drawback to the C behaviour of % (and the ADA REM
operator): The sign of the divisor isn't regarded at all, i.e. A % B ==
A % -B. We could use the alternative set of results in case B was
negative, and the users could still easily reproduce the current
behaviour using A % abs(B).

Proposed algorithm:

     mpfr_div(output, first, second, GMP_RNDN);
     if (MPFR_SIGN(first) >= 0)
         mpfr_floor(output, output);
     else
         mpfr_ceil(output, output);
     mpfr_mul(output, output, second, GMP_RNDN);
     mpfr_sub(output, first, output, GMP_RNDN);

Cheers,
Ingo

On Thursday, June 29 at 10:00 AM, quoth Ingo van Lil:
>> mpfr_set_ui(temp, 0, GMP_RNDN);
>> mpfr_div(temp, first, second, GMP_RNDN);
>> mpfr_rint(temp, temp, GMP_RNDZ);
>> mpfr_mul(output, temp, second, GMP_RNDN);
>> mpfr_sub(output, first, output, GMP_RNDN);
>
>What's the first line good for?

Hmm, not much, come to think of it.

>> Although after reading about it, I'm not sure. So, the problem is
>> how to deal with negative numbers. For example, should -340 % 60 be
>> -40 or -20?
>
>-20 is not an option. The question is: When performing the integer
>division of -340 and 60, do you round the result by discarding the
>fractional part (-5, leaving you with a remainder of -40) or by picking
>the next-lower integer number (-6, leaving you with a remainder of
>+20). It's getting even more complicated if the divisor is negative:
>340/-60 could be either -5 (remainder 40) or -6 (remainder -20).
>So, unless both the dividend and the divisor are positive we have to
>pick one of two equally valid modulo results (one positive, one
>negative). We have four possible ways to do this:
>
>1. Always use the positive one; that's what my algorithm does:
>
>-340 % 60 == 20; 340 % -60 == 40; -340 % -60 == 20
>
>2. Use the one that's got the same sign as the dividend; that's what
>your algorithm does and what the C99 standard requires:
>
>-340 % 60 == -40; 340 % -60 == 40; -340 % -60 == -40
>
>3. Use the one that's got the same sign as the divisor, always leaving
>you with a modulo result between 0 and the divisor:
>
>-340 % 60 == 20; 340 % -60 == -20; -340 % -60 == -40
>
>4. Use the sign of the quotient, i.e. give the negative result if
>either the dividend and the divisor are negative, and use the
>positive result in case both are:
>
>-340 % 60 == -40; 340 % -60 == -20; -340 % -60 == 20
>
>I like the fourth solution, but I'm not yet sure how to implement it
>most simple. If we want to be C99 conformant, we should stick with your
>solution.

Hmm, well, I tend to like not being restrictive, and I also like
maintaining the existing behavior. In Wcalc 1.x, this was implemented
as the C % operator, so I'd like to keep it that way. On the other
hand, I can see a valid need for something more interesting, like the
"rem" operator in Ada. Perhaps I should add your method as the
implementation of that operator...?

~Kyle
--
I created a cron job to remind me of the Alamo.
                                                      -- Arun Rodriguez

Kyle Wheeler <kyle-wcalc-yahoo@...> schrieb:

>> + 	    // a % b == a - floor(a/b) * b
>> + 	    mpfr_div(output, first, second, GMP_RNDN);
>> + 	    mpfr_floor(output, output);
>> + 	    mpfr_mul(output, output, second, GMP_RNDN);
>> 		    mpfr_sub(output, first, output, GMP_RNDN);
>
> Hmm. What is currently in CVS is this:
>
>            mpfr_set_ui(temp, 0, GMP_RNDN);
>            mpfr_div(temp, first, second, GMP_RNDN);
>            mpfr_rint(temp, temp, GMP_RNDZ);
>            mpfr_mul(output, temp, second, GMP_RNDN);
>            mpfr_sub(output, first, output, GMP_RNDN);

What's the first line good for?

> Although after reading about it, I'm not sure. So, the problem is how
> to deal with negative numbers. For example, should -340 % 60 be -40
> or -20?

-20 is not an option. The question is: When performing the integer
division of -340 and 60, do you round the result by discarding the
fractional part (-5, leaving you with a remainder of -40) or by picking
the next-lower integer number (-6, leaving you with a remainder of
+20). It's getting even more complicated if the divisor is negative:
340/-60 could be either -5 (remainder 40) or -6 (remainder -20).
So, unless both the dividend and the divisor are positive we have to
pick one of two equally valid modulo results (one positive, one
negative). We have four possible ways to do this:

1. Always use the positive one; that's what my algorithm does:

       -340 % 60 == 20; 340 % -60 == 40; -340 % -60 == 20

2. Use the one that's got the same sign as the dividend; that's what
     your algorithm does and what the C99 standard requires:

       -340 % 60 == -40; 340 % -60 == 40; -340 % -60 == -40

3. Use the one that's got the same sign as the divisor, always leaving
     you with a modulo result between 0 and the divisor:

       -340 % 60 == 20; 340 % -60 == -20; -340 % -60 == -40

4. Use the sign of the quotient, i.e. give the negative result if
     either the dividend and the divisor are negative, and use the
     positive result in case both are:

       -340 % 60 == -40; 340 % -60 == -20; -340 % -60 == 20

I like the fourth solution, but I'm not yet sure how to implement it
most simple. If we want to be C99 conformant, we should stick with your
solution.

Cheers,
Ingo

On Wednesday, June 28 at 08:05 PM, quoth Ingo van Lil:
>+ 	    // a % b == a - floor(a/b) * b
>+ 	    mpfr_div(output, first, second, GMP_RNDN);
>+ 	    mpfr_floor(output, output);
>+ 	    mpfr_mul(output, output, second, GMP_RNDN);
> 		    mpfr_sub(output, first, output, GMP_RNDN);

Hmm. What is currently in CVS is this:

             mpfr_set_ui(temp, 0, GMP_RNDN);
             mpfr_div(temp, first, second, GMP_RNDN);
             mpfr_rint(temp, temp, GMP_RNDZ);
             mpfr_mul(output, temp, second, GMP_RNDN);
             mpfr_sub(output, first, output, GMP_RNDN);

Although after reading about it, I'm not sure. So, the problem is how
to deal with negative numbers. For example, should -340 % 60 be -40 or
-20? The Math Forum
(http://mathforum.org/library/drmath/view/52343.html) seems to suggest
that both are essentially equally good answers.

Does anyone here have a preference?

~Kyle
--
Once again the conservative sandwich-heavy portfolio pays off for the
hungry investor!
                                                            -- Zoidberg

Daniele <scrows@...> schrieb:

> $ time wcalc "2^56 % 57"
> ^C
>
> real    0m15.002s
> user    0m14.635s
> sys     0m0.003s
> $
>
> the standard operator takes too much time to calculate the
> solution (I never waited for its solution),

Heh, right. Counting up to 2^56 in 57-steps might take a while. ;-)

> can anything be done to solve this issue?

Sure. Patch attached.

Cheers,
Ingo

I wanted the remainder of a division with big numbers, this is what
I've done:

$ time wcalc "2^56 - floor(2^56 / 57)*57"
  = 4

  real    0m0.004s
  user    0m0.001s
  sys     0m0.003s
$ time wcalc "2^56 % 57"
^C

  real    0m15.002s
  user    0m14.635s
  sys     0m0.003s
$

the standard operator takes too much time to calculate the
solution (I never waited for its solution), can anything be
done to solve this issue?

Cheers,
Daniele

--
   GPG Fingerprint: 7B1F 0815 BB7D CF35 1018  EEAB 4B97 6382 F151 402D
                               -
   GPG Key [ID: 0xF151402D] available @ pgp.mit.edu
			 -------------
RIP is irrelevant.  Spoofing is futile.  Your routes will be aggregated.
		 -- Alex Yuriev

2.2 is released!

This, as you may be able to tell from the larger version bump, includes some
spiffy new features. Perhaps the most nifty for GUI users will be persistent
variables. The most nifty for CLI users will probably be the \explain and \store
commands. That said, there's plenty of other smaller features and bugfixes that
have been accumulating in CVS that I just had to make a new release.

The list of the salient changes is up on the download page as usual. Enjoy!
http://w-calc.sf.net/download.php

~Kyle
--
Freedom is the right to be wrong, not the right to do wrong.
                                                   -- John G. Riefenbaker

Damn, it has sure been a while... I just realized today that it's been 18 months
since I went out with a special lady last, but I'm pretty happy to     be
heading out tonight.      I've had a bit of trouble finding ANY decent women
lately so I joined up at this place a couple of weeks ago
http://www.dontwaitjoinnow.info/fnfb . And so far been doing pretty well, just
chatting to a few girls near me on Webcam and via the mail system on the place,
but this is the first one I've lined up. So anyway, wish me luck guys!!

2.1.2 is released!

This is, like 2.1.1, primarily a bugfix release. The biggest bugfix is in file
I/O -- there was some funky behavior going on there, but it's fixed now. The
rest of the fixes are relatively minor. Drawers work again (oops!), and the
funky resizing behavior is gone for good (I think). Also, the areasinh menu
display in the GUI is corrected.

In case you're curious, here's what I think has been causing the funky resize
behavior: the inspector drawer. It seems that windows are required to be bigger
than the drawers that may be attached to them, and while the main window is 171
pixels across, the inspector drawer defaulted to 200 pixels across. Getting it
narrow enough to completely eliminate the weird resizing behavior made it
next-to-useless, so I made it a separate window. Hope that doesn't irritate too
many folks. It means I need to update the screenshot page... but I'm lazy. :)

Anyway, have fun!

~Kyle
--
I couldn't give you something mediocre even if that's all you asked for.
                            -- Michelangelo, in The Agony and the Ecstasy

On Tue, Nov 08, 2005 at 02:52:19PM -0500, Kyle Wheeler wrote:
> Should be fixed. This looks like an encoding thing I'm gonna have to
> fiddle with by myself. Thanks for the heads up.
Ok, now it works, thanks.

Cheers,
Daniele

--
   GPG Fingerprint: 7B1F 0815 BB7D CF35 1018  EEAB 4B97 6382 F151 402D
                               -
   GPG Key [ID: 0xF151402D] available @ pgp.mit.edu
			 -------------
BOFH excuse #231:
We had to turn off that service to comply with the CDA Bill.

On Tuesday, November  8 at 08:07 PM, quoth crowolo:
>Hi,
>I can't view wcalc website with firefox 1.0.7, I get this error in both
>homepage and download page:
>
>XML Parsing Error: undefined entity Location:
>http://w-calc.sourceforge.net/ Line Number 56, Column 8: <td>&nbsp;</td>
>-------^

Really? Hrm... it verifies as XML 1.0 Strict:
http://validator.w3.org/check?uri=http%3A%2F%2Fw-calc.sourceforge.net&charset=%2\
8detect+automatically%29&doctype=Inline

<grumble>stupid firefox</grumble>

Should be fixed. This looks like an encoding thing I'm gonna have to
fiddle with by myself. Thanks for the heads up.

~Kyle
--
To invent, you need a good imagination and a pile of junk.
                                                         -- Thomas Edison

Hi,
I can't view wcalc website with firefox 1.0.7, I get this error in both
homepage and download page:

XML Parsing Error: undefined entity Location:
http://w-calc.sourceforge.net/ Line Number 56, Column 8: <td>&nbsp;</td>
-------^

I never got problems before now, I didn't upgrade my browser.

Bye,
Daniele

--
   GPG Fingerprint: 7B1F 0815 BB7D CF35 1018  EEAB 4B97 6382 F151 402D
                               -
   GPG Key [ID: 0xF151402D] available @ pgp.mit.edu
			 -------------
Some people claim that the UNIX learning curve is steep, but at least you
only have to climb it once.

2.1.1 is released!

This is primarily a bugfix release—several bugs were found in the UTF-8 and
internationalization support (thanks Marco Thill!), plus I found one or two
other errors with variable handling (this was a mistake I added back when I
added all the OpenBSD compiler fixes) and un-abbreviated integers. With luck,
this version should last a while, knock on wood.

In other news, Wcalc is listed on MPFR's web page!

Anyway, enjoy -- if you find any bugs, please let me know.

~Kyle
--
It is easier to be critical than to be correct.
                                                     -- Benjamin Disraeli

2.1 is released!

This version is primarily a bug-fix version, though there are a few
small features. The biggest bug that got squashed: a bug that made the a
variable not always get updated properly. Also, this version supports
UTF-8 on both the command-line and the GUI.

I have some packaging news as well! Wcalc is now a package in Debian testing.
Thanks Danielle Sempione! Also: I know the package in fink is very, very old.
I've built newer .info files for them, but they can't go into fink's archive
until fink gets it's GMP and MPFR libraries into a useable state (currently in
fink, MPFR both requires and conflicts with GMP—if this changes, let me know!)

In any case, enjoy!
http://w-calc.sourceforge.net/download.php

~Kyle
--
If Jack Valenti had been around at the time of Gutenberg he would have
organized the monks to come and burn down the printing press.
                                          -- ITAA president Harris Miller

On Tuesday, August 30 at 01:57 PM, quoth Ingo van Lil:
>On 30 Aug 2005, Kyle Wheeler wrote:
>
>> Anyway - have at ye! Let me know about any problems you run into.
>
>Yep, haven't yet managed to compile it. What version of mpfr did you
>use? I have the most recent gmp version (4.1.4) installed and wcalc
>complains about several undeclared functions (e.g. mpfr_get_si,
>mpfr_equal_p and mpfr_mul_si). Plus, mpfr_urandomb returns void, so
>not ignoring the function result (as in scanner.l, lines 158 and 163)
>isn't allowed.

I ran into that too when trying to compile it on my OpenBSD machine
(only gmp is in ports, not mpfr, sadly). But, if you install mpfr 2.1.1,
from http://www.mpfr.org, it should work correctly.

>Oh, and help.c has to include limits.h, because MPFR_PREC_MAX maps to
>(ULONG_MAX>>1). No idea why mpfr.h doesn't include it itself.

Hmmm. This *should* be fixed by installing the latest MPFR, I think. In
the latest MPFR headers, MPFR_PREC_MAX maps to:

     ((mpfr_prec_t)((!(mpfr_prec_t)0)>>1))

Which is better and more cross-platform anyway -- not all Unixes
conveniently define ULONG_MAX for you (the same goes for UINT32_MAX,
which you'll notice I had to explicitly detect). Why "stdint.h" isn't
*standard*, I have no idea.

~Kyle
--
Once again the conservative sandwich-heavy portfolio pays off for the
hungry investor!
                                                              -- Zoidberg

On 30 Aug 2005, Kyle Wheeler wrote:

> Anyway - have at ye! Let me know about any problems you run into.

Yep, haven't yet managed to compile it. What version of mpfr did you
use? I have the most recent gmp version (4.1.4) installed and wcalc
complains about several undeclared functions (e.g. mpfr_get_si,
mpfr_equal_p and mpfr_mul_si). Plus, mpfr_urandomb returns void, so
not ignoring the function result (as in scanner.l, lines 158 and 163)
isn't allowed.
Oh, and help.c has to include limits.h, because MPFR_PREC_MAX maps to
(ULONG_MAX>>1). No idea why mpfr.h doesn't include it itself.

         Cheers,
             Ingo

It's out, it's great, and I'm feeling confident that it will make a lot
of people pretty pleased. The major new feature now is support for
arbitrary precision -- you can reliably calculate, for example, the
factorial of 100. There are a bunch of other tweaks, all of them good.

The pre-compiled OSX version seems to work only on 10.4 systems for
now... I hope to figure out backwards compatability at some point, but I
don't know how big an issue it is.

Anyway - have at ye! Let me know about any problems you run into.

~Kyle
--
Only the fool hopes to repeat an experience; the wise man knows that
every experience is to be viewed as a blessing.
                                                          -- Henry Miller

On Wed, Sep 01, 2004 at 01:15:30AM -0000, sakuisan2001 quoth:
> is there a feature in wcalc emulates 10key?
>
> like this:
> -> 50
>  + 5
>  = 55
>
> not this:
> -> 50+5
>  = 55

Not really.

In the GUI (MacOS X-only) there's a "simple calculator" mode that
provides something like that. (I don't get the attraction, myself, but I
don't do a lot of number crunching.) Wcalc is primarily a line-oriented
calculator with *some* persistent state---in other words, each line is
treated as a complete mathematical statement. Part of the problem of
doing a 10-key calculator emulation is input files---how do they get
formatted? How does one know that a new line is part of a new
calculationor part of the previous? Not insurmountable, obviously, but
not trivial either---especially when one thinks about detecting which is
which (some sort of a declarative flag at the beginning maybe?). That,
and there doesn't seem to be much demand for that.

~Kyle

--
I am always ready to learn although I do not always like to be taught.
-- Winston Churchill

is there a feature in wcalc emulates 10key?

like this:
-> 50
  + 5
  = 55

not this:
-> 50+5
  = 55

Wcalc 1.7 is out!

Several bugs have been fixed, and there's now a "simple" calculator
mode (by request).

For details, check the website!

~Kyle
--
A deep unwavering belief is a sure sign that you're missing something.

Hello All,

A fellow named Ingo van Lil has been helping me recently with finding
and fixing bugs in Wcalc. It occured to me that our conversation
probably ought to be on the list, just to help make sure any design or
feature decisions work for everyone involved, and to solicit help and
comment on the problems.

On Sat, Aug 30, 2003 at 03:42:37AM +0200, Ingo van Lil quoth:
> It wasn't meant to replace your current parser, it was just an example
> how to assign different precendece to one operator depending on the
> context.

Yeah, I know... this is a problem that I think will require much more
fiddling.

> I'm currently trying to create a simpler parser that can do implicit
> multiplication, but I'm not really successful. It compiles without
> reporting any conflicts and it shows the correct result in most cases,
> but it fails (parse error) if I use more than one factorial operator
> (e.g. 5!!). It probably tries to parse the exclamation marks as 'NOT'
> operators and then finally wonders at not finding any operand to apply.

Good luck! It took me lots of rewrites and some hard thinking to get the
parser as far as I've gotten it... but if you get something a little
simpler or a little less ambiguous, I'm all ears.

> > > Strange discussion. I can't really follow Jerry's way of thought in his
> > > sentence "IMHO, if you type 5* and then another * it should calculate
> > > 25".
> >
> > I didn't follow his logic either. It might have been a GUI-only thought
> > of his... I'm not sure. I may try getting rid of it, and recoding it to
> > do what he thinks it ought to in the GUI. What do you think?
>
> I don't know how the GUI works, but I could imagine hitting the '*' key
> n-times being interpreted as "x^n". In the same way multiple '/' strokes
> could be interpreted as n-th root. Sounds like a nice feature.

Yes indeed! I'll see what I can do about that one... getting the buttons
to do fun things beside simply insert characters into the expression is
a little involved, but I'll work on it.

> > Oh, another thought that occurred to me... should we continue this
> > conversation on the Wcalc mailing list, just to encourage people to
> > comment?
>
> Sure, why not? Just reply to the list next time (and maybe put some
> explaining words for the other subscribers in front of it).

Done.

> By the way, I found yet another small (and probably easy to fix) bug:
>
> -> foo=2
> foo = 2.000000
> -> 4foo
> = 42
>
> and worse:
>
> -> bar=-4
> bar = -4.000000
> -> 2 bar
> = -2

Ahhh... I knew flatten() was going to bite me someday. Okay, I fixed it
in CVS. Basically, instead of inserting the value/string of the variable
into the expression, it now inserts it inside of parenthesis. End
result: should work as expected now.

~Kyle
--
Anyway, have fun. And don't bother reporting any bugs for the next few days. I
won't care anyway.
-- Linus Torvalds, when kernel 2.4 came out

Hello all,

I've been fixing bugs in Wcalc almost exclusively the past few days.
Managed to track down some pretty long-standing bugs (e.g. sometimes the
parser doesn't reset itself after an error right away), and fix them.
Now I've come to a bit of a decision point.

There's a conflict between binary or and absolute value. I originally
wanted |-4| to be 4, but by the same token, I want to be able to
calculate 12|4. Does anyone on this list have any particular opinions on
this?

Some options:

+ banish |-4|, and replace it with either [-4], abs(-4), or both
     Pro: simple, C-like, fixes some abiguity
     Con: brackets mean we can't use them for matrixes in the future, and
          abs() is not exactly intuitive
+ banish 12|4, and replace it with some other symbol
     Pro: preserves commonsense absolute value stuff
     Con: commonsense absolute value stuff is inherently ambiguous (what
          is |-4|-3|-2| ? is it |-4| * -3 * |-2| or is it
          | -4 * |-3| * -2 |?), and I can't think of an easy binary-or
          operator.

Any suggestions/opinions? (I have a tendency to go for #1)

~Kyle
--
UNIX was not designed to stop you from doing stupid thinkgs, because that would
also stop you from doing clever things.
-- Doug Gwyn

Wcalc 1.6.2 is out! There was a bit of a bug in the recursion
detection, still. This version should have it fixed.

There were a few other longer-standing bugs that got found at the same
time, all of which were fixed. For details, check the website.

~Kyle
--
I have great faith in fools; my friends call it self-confidence.
-- Edgar Allen Poe

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey everyone!

Time for a new version! No big news this release. Fixed the recursion
detectionn (it was very broken in 1.6), and added some useful stuff like
irandom (random integers) and binary operators. I expanded the man page
to include all the commands, constants, and functions. You can get it
from the usual places - have fun! Let me know if you run into trouble.

As a side-note, I submitted wcalc to fink for the OSX users among us, so
you can get auto-updates that way (doesn't include the GUI version).

~Kyle
- --
To create a good joke, you must first have a good laugh, and then think
backwards.
- -- Australian Bush Talk
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iD8DBQE/RN0tBkIOoMqOI14RAtWEAKDW76XTrjb5vRrMW0HqfztwQH4vrQCfQwZa
UitcSDYOa+i2rZTNILEaP84=
=J2kn
-----END PGP SIGNATURE-----

Hey everyone!

There are some big additions to this version, and I'm pretty proud of
it. First and foremost: FILES! So many people have asked me to get it
to load and save files since I started this project, and now, finally,
it does! It doesn't use MML or anything (yet) because that's a little
more complicated than once I thought, but otherwise, it works quite
nicely.

The other biggie, for me personally, was the recursion detection in
active variables. Wasn't hard, just never got around to it until now.

Yet another big one for those of us who use the command-line version a
lot, Wcalc now uses a ~/.wcalcrc to save practically every preference
it knows about! There's a simple rc file with the source, if you want
to take a look. It should be pretty straight forward.

Also, FINALLY, I fixed the window-resize issues. I know, it's been
truly bizarre behavior up until now. And to be perfectly honest, I
still haven't a clue why. I essentially recreated the window exactly
the way I made it to begin with, and this time it behaved more as
expected (it still has weirdness issues - but behind-the-scenes
weirdness issues, so you don't have to deal with it, but I do!). I'm
not as big a fan of this whole nib thing as I once was . . . but it's
ok.

There are several other minor additions and fixes in this version.
Check the download page for a more complete list. Now, I should really
get back to my school work...

Cheers,
~Kyle
--
You can't always judge by appearances: the early bird may have been up
all night.
-- Anonymous

Hey all!

Wcalc 1.5.2 is out!

This contains a bunch of minor features and a bugfix. I fixed
internationalization stuff, added the ability to limit the length of
the history, added the ability to clear the history and veriable lists,
fixed a crasher in the error-reporting routine, etc. The thing I spent
the most time on was getting it to work with automake/autoconf, which
makes the CLI much easier to compile on other Unixes. Oh, and I
alphabetized the unit lists in the conversion dialog box.

Everybody already knows where to go to get the new version!
http://w-calc.sf.net/download.php

~Kyle
--
To create a good joke, you must first have a good laugh, and then think
backwards.
-- Austrailian Bush Talk

Hey everyone!

This is just a quick note to let you know that I finally moved Wcalc to
SourceForge's servers - here: http://w-calc.sf.net/ That also means
Wcalc is now licensed under the GPL, so you can take a look at the
source code if you want to (all suggestions welcome).

I also was wondering if Wcalc should have the new brushed steel
appearance or not... What do you think?

~Kyle
--
Asking whether machines can think is like asking whether submarines can
swim.

Hey all!

Wcalc 1.5.1 is out!

Not too many new features this time out. There's a way to list
variables from the command-line, and a way to turn off precision guards
if you work with high-precision numbers (greater than 2.2e-16 or so).
Also, this is the first version to sport Jaguar compatibility. The
Apple PackageMaker doesn't make packages that are compatible with
versions of the OS previous to 10.2, though... not sure what's up with
that. If someone wants the command-line version available for earlier
versions of the OS, I'll try to make it available. If not, I won't
bother.

I'll post this version to VersionTracker tomorrow, if nobody notices
anything particularly wrong with it (there *shouldn't* be, but...).

~Kyle
--
The one important thing I have learned over the years is the difference
between taking one's work seriously and taking one's self seriously.
The first is imperative and the second is disastrous.
-- Margot Fonteyn

Thanks Kyle, I'll check it out soon!!

Ciao,

Jerry

<quote who="Kyle Wheeler">
> Hey Everyone!
>
> It's out! 1.5!
>
> There's active variables, there's unit conversions, there's all sorts of
>  new goodies. Let me know how you like it!
>
> http://www.nd.edu/~kwheeler/wcalc/wcalc.html
>
> ~Kyle
>

Hey Everyone!

It's out! 1.5!

There's active variables, there's unit conversions, there's all sorts of
new goodies. Let me know how you like it!

http://www.nd.edu/~kwheeler/wcalc/wcalc.html

~Kyle
--
You can only find truth with logic if you have already found truth
without it.
-- G. K. Chesterton