[Curious] Integer division => fraction

Richard A. O'Keefe ok at cs.otago.ac.nz
Sun Jun 15 23:55:25 UTC 2003


David Farber <dfarber at numenor.com> wrote:
	But I'm still not sure that 3 1/2 is more
	natural for people than 3.5.  Money is almost always represented
	in decimal, and when it isn't it makes me suspicious:  Coke is
	"on sale" at $7 for 2 cases of 12 cans, but Pepsi is "regular
	priced" at $3.39 or $3.49 for 1 case.  Stuff like that fairly
	jumps out at me, but it must not for most other people or they'd
	stop doing it.
	
I'm not quite clear _why_ he says this; it appears to be a very convincing
argument that decimal fractions are NOT natural for people.  Things that
wouldn't sell well at $20 sell quite nicely at $19.99 (even in countries
like Australia and New Zealand where one cent coins are no longer legal
tender, so when you hand over a $20 note you don't actually get any change...)

	>IBM mainframe dialect of Prolog where two numbers might or might not
	>unify depending on whereabouts you asked.)
	
	Well, I agree that it would be nice if context didn't matter,
	but there is no getting around the fact that it frequently does.

You misunderstood.  Depending on "context" in the sense of "what the
programmer's *purpose* is", that's perfectly legitimate.  What I meant
was (are you going to believe this?) the first N arguments of a predicate
used fuzzy unification, but arguments N+1 and on did NOT.  So something
as simple as changing the argument order of a procedure (in a language
where arguments are data structures, not expressions, so this cannot
affect the order of _evaluation_) could change the result you got.

	If my program is doing anything that has to do with money then I
	want decimal numbers--real decimals that handle 0.1 properly.

Which is why Smalltalk has DecimalFractions.  This affects what the
question you ask _is_, not "where you ask".  What you want here is
precisely context *IN*dependent arithmetic, when you are calculating
with money, you DON'T want the result to depend on whether the GUI is
doing its calculations with SmallIntegers or Floats.

	If I am doing signal processing, then I am willing to trade off
	a loss in precision for speed.

Again, this affects what the question you ask _is_, not "where you ask".

	But, just in general, if I ask for 1 divided by 3 I want the
	/right/ answer, not an approximation.
	
	I'll admit that dynamic scoping of computational setting does
	/sound/ scary, but I think it could be pulled off.

Dynamic scoping is very different from having a global Preference.

I have no objection to local binding of things like rounding mode,
provided locality is *enforced* by the compiler and runtime system.
I don't want rounding mode or precision "leaking" when there's an
exception, for example.  (Unfortunately C is missing the fpsetjmp()
and fplongjmp() functions needed to handle exceptions in mode-setting
code safely.)

	You would, of course, have the option of /not/ letting certain
	computations be dynamically influenced, or limiting the extent
	of the influence.

Easy in a compiled language with strong static type checking, where
the compiler knows what the h--- is going on.  Not so easy in Smalltalk,
where the compiler to byte codes is small and fast because it hasn't a
clue.

	>In my defence, I'd like to point out that if you can't tell whether
	>x+y is going to round up, round down, truncate, or round to nearest,
	>you're in exactly the kind of swamp that IEEE arithmetic was supposed
	>to save us from.  While IEEE rounding and precision may be *implemented*
	>as a global mode in the FPU, the intent is that they should be *used*
	>locally; it's part of several ABIs that a function which alters any of
	>the IEEE modes should put them back the way they were before exiting.
	
	Hmmm, as I envision my proposal you would /always/ know whether
	x+y is going to round up, round down, truncate, or round to
	nearest.  If that were not possible, I wouldn't consider the
	proposal workable.
	
So tell us what your proposal is, so that we can envision it too.
I rather like Pascal-SC, which does it by means of having different
operators.  Twisting a little to get into Smalltalk syntax, you could
have	x +< y		(round down)
	x +> y		(round up)
	x +! y		(truncate)
	x +  y		(round to nearest)
Anything which involves the human reader having to look somewhere else
to find out what the mode is is guaranteed to be confusing and error-prone.



More information about the Squeak-dev mailing list