Re: Truncation and round off

In

http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-February/100365.htmlnicolas


nicolas cellier ncellier at ifrance.com wrote
Sun Feb 5 02:00:17 CET 2006

at length about truncation and roundoff libraries and
that squeak's is incomplete compared with others.

I'd like to add that this incompleteness is part of a
problem morphic has in displaying graphics. See:

http://bugs.impara.de/view.php?id=2453

Summary 0002453:
[Bugs] What is the extent of a truncated rectangle?

The basic problem was that truncation and rounding did
not mix well with rectangles. Particularly when
rectangels were mixing with rendering Transformation
morphs.

Part of the solution would be to have more choices
particular ceiling and floor options for rectangles
(an by extention Points.) I was headed in that
direction as  I attempted fixes to the errors. If a
set of vocabularies exist that would also make squeak
more compatable with other smalltalks and we have all
the necessary permissions to include them. Then I say
squeak could use them. The sooner the better.


Yours in service, -- Jerome Peace

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

Hi jerome

do you have solutions for the problem you mention?

Stef

On 5 févr. 06, at 04:05, Peace Jerome wrote:

I perfectly understand that you need to round the rectangle toward interior or
exterior.

Base VW is not better than Squeak, both have trivial st-80  implementation
that will also round topLeft and bottomRight to nearest.

I think you'll have to invent the messages or look elsewhere.

Putting a constraint like:
 aRectangle truncated extent = aRectangle extent truncated
whatever the coordinate transform is does not sound easy: maths say it is
simply impossible even without a rotation (unless rectangle sides are 3*n and
4*n).

But I do not see why you need to do rounding in intermediate steps.
Isn't rounding deferred until rendering and intermediate coordinates kept
Fraction or Float ?

> Putting a constraint like:
>  aRectangle truncated extent = aRectangle extent truncated
> whatever the coordinate transform is does not sound easy: maths say it is
> simply impossible even without a rotation (unless rectangle sides are 3*n
> and 4*n).
Oops, i'm confusing extent and diagonal (extent r)

>

I have a first extension to propose in cs attachment about rounding.

I will then stop on truncation and round off, in fact this was just an example
to better understand in which way i can be usefull and how decisions are
taken.

nicolas cellier wrote:
> Putting a constraint like:
>  aRectangle truncated extent = aRectangle extent truncated
> whatever the coordinate transform is does not sound easy: maths say it is
> simply impossible even without a rotation (unless rectangle sides are 3*n and
> 4*n).

Huh? And why would that be? The correct solution for that sort of
truncation is obviously:

Rectangle>>truncated
   ^Rectangle origin: self origin truncated extent: self extent truncated

I see nothing that suggests there would be any difficulty.

Cheers,
   - Andreas

Hi Stef,

Its currently a work in progress. More study. More
analysis and code tracing.

I was very pleased when I found this simply because
its a good bug find. So I posted it to mantis along
with others that deal with the same can of worms.

Squeak actually has two different types of rounding
problems. This one and then a general tendency for
people to prematurely round SOURCE rectangles. Since
these are deep in the guts of what lets squeak draw,
caution is called for.

The user story I've be working on is that Morphs
should be beautiful and as their creator intended them
to look; draw themselves fully and stably and not
leave glitches when they move.

For this one the solution lies in using floor and
ceiling and what I call encompassed and compressed on
rectangles. Or maybe as Andreas mentioned focusing on
the extent point of the rectangle. The question is in
the code where is it appropriate to use which method.

If the opprotunity of the other post hadn't come up, I
would have waited before posting this to squeakdev.

I encourage and brave bug trackers who look into this
to post their findings to the mantis list.




>Truncation and round off
>stéphane ducasse ducasse at iam.unibe.ch
>Sun Feb 5 14:09:10 CET 2006 wrote:
>
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-

>> February/100365.htmlnicolas
>>
>>
>> nicolas cellier ncellier at ifrance.com wrote
>> Sun Feb 5 02:00:17 CET 2006
>>
>> at length about truncation and roundoff libraries
and
>> that squeak's is incomplete compared with others.
>>
>> I'd like to add that this incompleteness is part of
a
>> problem morphic has in displaying graphics. See:
>>
>> http://bugs.impara.de/view.php?id=2453
>>
>> Summary 0002453:
>> [Bugs] What is the extent of a truncated rectangle?
>>
>> The basic problem was that truncation and rounding
did
>> not mix well with rectangles. Particularly when
>> rectangels were mixing with rendering
Transformation
>> morphs.
>>
>> Part of the solution would be to have more choices
>> particular ceiling and floor options for rectangles
>> (an by extention Points.) I was headed in that
>> direction as  I attempted fixes to the errors. If a
>> set of vocabularies exist that would also make
squeak
>> more compatable with other smalltalks and we have
all
>> the necessary permissions to include them. Then I
say
>> squeak could use them. The sooner the better.
>>
>>
>> Yours in service, -- Jerome Peace
>>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com