ftp.xmission.com/2014.06.ftp.xmission.com.tar/ftp.xmission.com/pub/lists/fractdev/archive/fractdev.200009

Internet Message Format | 2000-09-23 | 17KB

From: "Jonathan Osuch" <[e-mail]>
Subject: SOI
Date: 04 Sep 2000 18:52:27 -0500

Tim,

I've been playing with passes=s, with and without debug=3444, and have found
that at times there is less stack available than the value defined by
minstack=.  I have also been kicked out with a stack overflow error numerous
times.

I don't know if this is related to the problem Puskas has found.  His images
use arbitrary precision math, which might be causing a problem.

Jonathan



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Tim Wegner <[e-mail]>
Subject: Re: SOI
Date: 04 Sep 2000 21:52:38 -0600

Jonathan wrote:

> I've been playing with passes=s, with and without debug=3444, and have found
> that at times there is less stack available than the value defined by
> minstack=.  I have also been kicked out with a stack overflow error numerous
> times.

I haven't had a chance to look at this yet.

SOI is very sensitive to available stack space because it uses
stack like crazy (recursive algorithm). Memory allocated to stack is
adjustable as a link option, but it steals from free near space (if my
memory serves). I went to extraordinary lengths to cut down on
stack use in favor of static far memory. There are some tests of
remaining stack space designed to head off problems but they
aren't reliable. The problem is that the amount of stack space free
is user-dependent, and is affected by things like video drivers.

If and when we cut ourselves off from the medium model, we can
go back to the original SOI sources. Well almost. The original
sources have some tricky optimizations involved loop unrolling, and
don't give a result for each iteration. But this can be handled one
way or another.

> I don't know if this is related to the problem Puskas has found.  His images
> use arbitrary precision math, which might be causing a problem.

SOI doesn't use arbitrary precision, so that explains a lot right
there :-) If Puskas is using arbitrary precision, SOI is guaranteed to
not work.

Once again, the real fun of SOI would be to add arbitrary precision
support so we can plunge into the magnification depths much
faster. But we can't even think about doing this until we have
memory to work withy. It's amazing we do as much as we do under
DOS.

Tim


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Jonathan Osuch" <[e-mail]>
Subject: Re: SOI
Date: 05 Sep 2000 20:38:36 -0500

Tim,

Here is an example.  It crashes when the <tab> key is pressed and one of the
small sections is being drawn (for example, the first square).

test_03            { ; ;
                     ;  Jonathan Osuch
                     ;  Sep 05, 2000 at 20:30:10
                     ; Version 2000 Patchlevel 15
  reset=2000 type=mandel passes=s
  center-mag=-1.02147734604105500/+0.24939377444589350/2133333
  params=0/0 float=y maxiter=7000 inside=0 sound=off
  }



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Jonathan Osuch" <[e-mail]>
Subject: Conflict in extraseg
Date: 10 Sep 2000 18:46:27 -0500

Tim,

I received the following bug report from Puskßs Istvßn jr.

> When in arbitrary precision mode, if I want to save a picture with <b>,
and
> press TAB to check the parameters, then switch back and move the cursor
> between the entry fields, the texts on the menu turn into memory garbage
> when updated.

This is caused by the comment fields (and then CHOICES) using the start of
extraseg (see make_batch_file() in miscovl.c).  As you will recall, the
arbitrary precision routines also use extraseg.  In biginit.c, there is a
define for ENDVID which is currently set to 0.  Setting it to 2048 clears up
this problem.  This is based on a rough estimate of 24 lines X 80 characters
= 1920 + slop to make it a nice number.

The arbitrary precision math can handle this, but are there any instances
that you can think of where the <b> screen might exceed this?

Jonathan



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Tim Wegner <[e-mail]>
Subject: Re: Conflict in extraseg
Date: 10 Sep 2000 19:43:01 -0600

Jonathan asked:

> The arbitrary precision math can handle this, but are there any instances
> that you can think of where the <b> screen might exceed this?

This is possible, and would have to be looked more closely, but a
more likely situation that would cause the symptoms described
would be overlayed data segments being swapped into or out of
memory. It would help to know exactly which text prompts became
garbage. A bit of tweaking might be needed of which variables are
in which segment.

Tim


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Jonathan Osuch" <[e-mail]>
Subject: Re: Conflict in extraseg
Date: 11 Sep 2000 21:04:41 -0500

Tim replied,

> This is possible, and would have to be looked more closely, but a
> more likely situation that would cause the symptoms described
> would be overlayed data segments being swapped into or out of
> memory. It would help to know exactly which text prompts became
> garbage. A bit of tweaking might be needed of which variables are
> in which segment.

Hmm, I don't see any data segment swapping in this case.  But, I could just
be missing it.

I have found a similar problem.  If you have loaded an arbitrary precision
image (so ap is turned on) and then start to load another ap image.  At the
select a video mode screen, press <tab>.  The tab screen should indicate ap
is active.  Exit the tab screen and then page down the video mode screen a
couple of times.  You should see some blank entries and some garbled
entries.

Jonathan



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Jonathan Osuch" <[e-mail]>
Subject: Re: Conflict in extraseg
Date: 12 Sep 2000 20:55:36 -0500

Tim,

If you take a look at the comments at the beginning of biginit.c, there is a
short discussion of ENDVID.  It looks to me like we have two cases where it
isn't safe to let the ap math have all of extraseg.  Leaving ENDVID as it is
defined in fractint.h clears up both these problems.

Is this going to affect the performance of the ap math?  We may want to
explore other solutions.  The one case can be fixed by using a temporary far
buffer.  I haven't looked at the other case that closely.

Jonathan



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Tim Wegner <[e-mail]>
Subject: Re: Conflict in extraseg
Date: 12 Sep 2000 21:06:26 -0600


> Is this going to affect the performance of the ap math?  We may want to
> explore other solutions.  The one case can be fixed by using a temporary far
> buffer.  I haven't looked at the other case that closely.

Arbitrary precision has a simple minded memory allocation
scheme based on a stack. Reducing the amount of extraseg
available reduces how many variables can be created. Alternatively,
since the size of variables depends on precision, it reduces the
highest possible precision. This is probably not a big deal,
especially for the mandelbrot which doesn't fdreate a lot of variables.

Tim


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Jonathan Osuch" <[e-mail]>
Subject: Incrementing version number
Date: 17 Sep 2000 15:36:40 -0500

Tim,

I am going to need to add backwards compatibility for a feature that Iain
Stirling has sent me.  Thus, the need to increment the version number.  My
next patch would then be 2001P00.

OTOH, I can add the backward compatibility without incrementing the version
number but then the changed feature won't be available until the next
official release.

The feature I'm referring to is the inside=fmod option.  Iain has
implemented it as an outside= option and sent me the diff.  What he also did
was to change the calculation of the magnitude to reflect the bailout test
being used.  So instead of the magnitude always being sqr(new.x)+sqr(new.y),
it changes with the bailout test.  This makes a big difference on the image.

Opinions, options, ideas?

Jonathan



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Jonathan Osuch" <[e-mail]>
Subject: Re: Conflict in extraseg
Date: 18 Sep 2000 21:17:52 -0500

Tim,

While I was pondering the use of ENDVID and extraseg, it occurred to me that
since the ap math uses all of extraseg, any of the screen prompts which use
extraseg should corrupt the ap math data.  This would only be seen with an
extremely deep zoom.  The ap math data would need to take up over 22400
bytes!  This wasn't seen when ENDVID was defined in biginit.c because only
temporary variables were being corrupted.

Jonathan



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Tim Wegner <[e-mail]>
Subject: Re: Incrementing version number
Date: 19 Sep 2000 23:12:04 -0600

Jonathan wrote:

> I am going to need to add backwards compatibility for a feature that Iain
> Stirling has sent me.  Thus, the need to increment the version number.  My
> next patch would then be 2001P00.

I don't mind incrementing the version number. Do whatever makes
sense to you.

Tim


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Jonathan Osuch" <[e-mail]>
Subject: Parser constants
Date: 22 Sep 2000 20:53:50 -0500

Tim & George,

The following two formulae illustrate a problem that recently appeared on
the Fractint bug list.  They should produce the same image, but the parser
optimization is flipping the bad image.  Using debug=322 (turn off parser
optimizations) corrects the problem.

bad_image {; Jim Muth  Don't try this at home.
 a=1, z=(-1/0.95)^(-1/9.9):
 z=a*(10*(z^(-1.1))+0.95*(z^(-11)))+1/pixel,
 |z| < 500
}

good_image {; Jim Muth  This either.
 a=(1,0), z=(-1/0.95)^(-1/9.9):
 z=a*(10*(z^(-1.1))+0.95*(z^(-11)))+1/pixel,
 |z| < 500
}

The only difference is changing the a=1 to a=(1,0).  This problem seems
familiar.

Jonathan



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: George Martin <[e-mail]>
Subject: Parser constants
Date: 23 Sep 2000 12:52:27 -0400

Jonathan,

This problem doesn't ring any bells for me. I'll look at it, but can't ge=
t
to it for a couple of days.

George =


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Jonathan Osuch" <[e-mail]>
Subject: Next patch, version 20.1.0
Date: 23 Sep 2000 20:52:22 -0500

Tim,

I've uploaded the diff, executable and a source sync for version 20.1.0.

Here's the text from the documentation:

Version 20.1.0\
Incremented the version number to accommodate backwards compatibility for
the inside=fmod option.

Fixed the assignment of hotkeys to video modes so that the fractint.cfg
file is no longer corrupted.  Made the showdot= feature reset with <INS>
if it is entered using the <g> screen.  Added a check for the video size
before invoking the palette editor.  Too small a size would crash Fractint.

Fixed an extraseg conflict which occurred with arbitrary precision when
the <tab> key was used with various screens open (x,y,b).  This conflict
also occurred when loading an ap math image at the video selection screen.
Cleaned up some of the ap math initialization code.

Fixed an obscure bug that left memory allocated when an unfinished image
was being reloaded, but a video mode was not selected (escape was pressed).

Added outside=fmod option.  This is an extension of the inside=fmod option.
The magnitude used for the comparison is now based on the same calculation
as
is used for the bailout test.  This feature was contributed by Iain
Stirling.
There is a problem with the mandel fractal type when outside=fmod is used
with inside=bof6x and bailoutest=real, imag, or manr.  This is likely due
to changes made in the code so that bof images could be reproduced.  Select
a different fractal type that produces the default mandel image to explore
using these parameters.

Added outside=tdis option.  This colors the pixels according to the total
distance traveled by the orbit.  This feature was suggested by Steve
Robinson
on the Fractint Wish List.

Modified the inside and outside prompts on the <x> screen.  They are now
split into two separate prompts.  One for entering a color number and the
other for changing the option.  The left and right arrow keys can now be
used to change the inside and outside options.

Fixed a bug that was causing a crash when mathtolerance= was used and
fractal types ifs, ifs3d, or lsystem were selected.

Increased the minimum stack requirement for passes=s (SOI) to eliminate
crashes when the tab key was pressed.

Jonathan



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"