|Anonymous | Login||09-27-2020 16:19 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0007324||[Squeak] Kernel||minor||always||03-28-09 01:29||01-05-13 21:20|
|Summary||0007324: Fractions do not give useful access to denominator and numerator|
Currently Fraction implements denominator and numerator as
What about if you actually want to access the denominator of a fraction?
Everything in squeak is an object...
...in a community of messages.
Dealing with fractions or more likely
fractions/integers I would like to have access to useful information like the actual denominator.
And I would like the messages to return accurate and correct results
2 reciprocal + 2 reciprocal denominator
prints answers totally unexpected and nonsensical.
4 reciprocal + 4 reciprocal denominator
even though the latter is unequivocally a fraction.
Well the method warns me that is to be expected and that that the methods are private.
But is it a reasonable use case?
private language should not usurp useful words that can have interesting public meaning.
it would be easy enough to use privateDenominaor and privateNumerator leaving the more common words to implement their more common meaning.
Worse of course is asking an integer for its denominator creates an error rather than providing a reasonable answer like 1.
So questions from my curiosity.
1) What are the use cases for Fractions.
2) can we make denominator and numerator public and make other numbers or at least integers polymorphic with Fractions in that respect?
(0013076 - 937 - 1042 - 1042 - 1042 - 1042 - 1042)
mind the parentheses Jerome...
(2 reciprocal + 2 reciprocal) denominator
Some dialect do implement numerator/denominator protocol for integers.
Wonder if it is ANSI ???
The fact that Squeak could live without the protocol all these years is not a proof but an indication that the public API is not mandatory.
If it is a protocol required by ANSI or by several valuable packages, no doubt we should add it to the kernel.
(Teaching math to children in etoy could be a valuable reason too...)
But then, beware when you say nonsensical and unexpected...
What do you expect for (2/4) denominator ?
I say 12, because it happens to be (6/12).
Of course, you may prefer 4 because it is what you entered anyway.
But then for (10 reciprocal + 6 reciprocal) denominator ? Hmm ?
Isn't the reduction to a canonical form an answer that makes sense ?
You print it, (2/4) -> 1/2, so 2 is a good answer, more than any other.
(0013077 - 1510 - 1709 - 1709 - 1709 - 1709 - 1709)
Thanks for pointing out the obvious error.
of course (2 reciprocal + 2 reciprocal) denominator
is what I meant.
Evaluating the math leaves us with an integer. Thus you get
the other bug because denominator is not defined for integers.
So my basic point remains.
>The fact that Squeak could live without the protocol all these years is not a proof but an indication that the public API is not mandatory.
This is a "But we've always done it this way" argument. It does not sway me.
I've come across many bugs in squeak that limit it and the language it wishes to be. Squeak has a small community of users. They have become used to working around some very severe limitations. They have learned not to complain.
You must see that too. Because you are one of the exceptions.
Others have learned to avoid squeak and leave the community. This is sad too.
My example was mischief. Thanks for getting me back on the right path.
The question is should squeak have useful messages for denominator and numerator?
It seems to me something you would want in a language that has fractions and
infinite precision integers.
Right now, I know if I am using squeak I need to steer clear of fractions or expressions that return them as results. Because it will screw things up if I ever pass them to bitblt for example.
This to me represents a severe limitation of the language. A worthy locus for bug tracking and repair.
Yours in curiosity and service, --Jerome Peace
(0014285 - 1151 - 1277 - 1277 - 1277 - 1277 - 1277)
This was integrated in Squeak 4.3, so the issue can be closed:
Time: 7 September 2011, 10:36:43.543 pm
Consider an Integer as a special kind of Fraction (from behavioral POV, not from hierarchical POV), ans as such answer true to #isFraction and answer self to #asFraction.
This is a logical consequence of having Fraction with a unit denominator automatically reduced to Integer.
Two pre-requisites to this change are:
- letting Integer be polymorphic with Fraction by responding to #numerator and #denominator
- and don't letting senders of #asFraction rely on the class of the result being a Fraction (which was the case of some coercion message only).
These requirements should be fullfiled by update-nice.196.mcm.
A side effect of this change is to speed up a bit mixed arithmetic like (1/2)+1, but not 1+(1/2).
A second side effect is that (1@2) asNonFractionalPoint will now convert coordinates to floating point.
There is no other sender of #isFraction or #asFraction affected by the change in the trunk image.
|03-28-09 01:29||wiz||New Issue|
|03-28-09 01:29||wiz||Relationship added||child of 0007323|
|04-03-09 19:26||nicolas cellier||Note Added: 0013076|
|04-04-09 20:25||wiz||Note Added: 0013077|
|01-05-13 21:20||nicolas cellier||Note Added: 0014285|
|01-05-13 21:20||nicolas cellier||Status||new => closed|
|01-05-13 21:20||nicolas cellier||Resolution||open => fixed|
|01-05-13 21:20||nicolas cellier||version||=> 4.3|
|01-05-13 21:20||nicolas cellier||Additional Information Updated|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
51 total queries executed.|
36 unique queries executed.