Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #48655 > unrolled thread

Mandelbrot Set

Back to article view | Back to comp.lang.forth

Contents

  Mandelbrot Set hughaguilar96@gmail.com - 2016-07-01 11:52 -0700
    Re: Mandelbrot Set hughaguilar96@gmail.com - 2016-07-01 12:35 -0700
      Re: Mandelbrot Set Pablo Hugo Reda <pabloreda@gmail.com> - 2016-07-01 12:40 -0700
        Re: Mandelbrot Set hughaguilar96@gmail.com - 2016-07-01 12:57 -0700
          Re: Mandelbrot Set Pablo Hugo Reda <pabloreda@gmail.com> - 2016-07-01 13:22 -0700
        Re: Mandelbrot Set josv@planet.nl - 2016-07-01 23:58 -0700
      Re: Mandelbrot Set hughaguilar96@gmail.com - 2016-07-03 10:17 -0700
        bug in VFX disassembler? hughaguilar96@gmail.com - 2016-07-04 17:51 -0700
          Re: bug in VFX disassembler? Cecil Bayona <cbayona@cbayona.com> - 2016-07-04 23:25 -0500
            Re: bug in VFX disassembler? hughaguilar96@gmail.com - 2016-07-04 22:48 -0700
              Re: bug in VFX disassembler? rickman <gnuarm@gmail.com> - 2016-07-05 02:02 -0400
                Re: bug in VFX disassembler? lawrencedo99@gmail.com - 2016-07-06 00:46 -0700
                  Re: bug in VFX disassembler? Ron Aaron <rambamist@gmail.com> - 2016-07-06 10:48 +0300
                    Re: bug in VFX disassembler? lawrencedo99@gmail.com - 2016-07-06 19:56 -0700
                  Re: bug in VFX disassembler? rickman <gnuarm@gmail.com> - 2016-07-06 11:33 -0400
                    Re: bug in VFX disassembler? lawrencedo99@gmail.com - 2016-07-06 19:57 -0700
                      Re: bug in VFX disassembler? rickman <gnuarm@gmail.com> - 2016-07-07 00:45 -0400
                        Re: bug in VFX disassembler? lawrencedo99@gmail.com - 2016-07-06 23:42 -0700
                          Re: bug in VFX disassembler? rickman <gnuarm@gmail.com> - 2016-07-07 03:14 -0400
                    Re: bug in VFX disassembler? Cecil Bayona <cbayona@cbayona.com> - 2016-07-06 22:32 -0500
                      Re: bug in VFX disassembler? lawrencedo99@gmail.com - 2016-07-06 21:08 -0700
                        Re: bug in VFX disassembler? hughaguilar96@gmail.com - 2016-07-07 00:22 -0700
                          Re: bug in VFX disassembler? Cecil Bayona <cbayona@cbayona.com> - 2016-07-07 02:34 -0500
                            Re: bug in VFX disassembler? hughaguilar96@gmail.com - 2016-07-07 00:40 -0700
                            Re: bug in VFX disassembler? Julian Fondren <julian.fondren@gmail.com> - 2016-07-07 01:23 -0700
                          Re: bug in VFX disassembler? rickman <gnuarm@gmail.com> - 2016-07-07 03:39 -0400
                            Re: bug in VFX disassembler? hughaguilar96@gmail.com - 2016-07-07 00:50 -0700
                              Re: bug in VFX disassembler? rickman <gnuarm@gmail.com> - 2016-07-07 10:27 -0400
            Re: bug in VFX disassembler? "HAA" <someone@microsoft.com> - 2016-07-07 14:38 +1000
          Re: bug in VFX disassembler? "HAA" <someone@microsoft.com> - 2016-07-07 17:01 +1000
            Re: bug in VFX disassembler? hughaguilar96@gmail.com - 2016-07-07 00:04 -0700
              Re: bug in VFX disassembler? "HAA" <someone@microsoft.com> - 2016-07-07 17:39 +1000
    Re: Mandelbrot Set "WJ" <w_a_x_man@yahoo.com> - 2016-07-02 06:07 +0000
      Re: Mandelbrot Set mhx@iae.nl - 2016-07-02 00:12 -0700
      Re: Mandelbrot Set Paul Rubin <no.email@nospam.invalid> - 2016-07-02 00:58 -0700
    Re: Mandelbrot Set humptydumpty <ouatubi@gmail.com> - 2016-07-20 03:46 -0700
      Re: Mandelbrot Set hughaguilar96@gmail.com - 2016-07-20 07:22 -0700
        Re: Mandelbrot Set Coos Haak <chforth@hccnet.nl> - 2016-07-20 17:02 +0200
          Re: Mandelbrot Set hughaguilar96@gmail.com - 2016-07-20 08:20 -0700
            Re: Mandelbrot Set humptydumpty <ouatubi@gmail.com> - 2016-07-20 08:58 -0700
              Re: Mandelbrot Set humptydumpty <ouatubi@gmail.com> - 2016-07-20 09:02 -0700
              Re: Mandelbrot Set hughaguilar96@gmail.com - 2016-07-20 09:35 -0700
              Re: Mandelbrot Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-21 13:18 +0000
                Re: Mandelbrot Set humptydumpty <ouatubi@gmail.com> - 2016-07-21 09:04 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#48863 — Re: bug in VFX disassembler?

On Thursday, July 7, 2016 at 3:32:56 PM UTC+12, Cecil - k5nwa wrote:
> ... commercial applications were not allowed.

Trouble is, what does “commercial” mean? <https://www.techdirt.com/articles/20090602/2322205106.shtml>

It might not mean what you want it to mean <https://www.techdirt.com/articles/20140326/11405526695/german-court-says-creative-commons-non-commercial-licenses-must-be-purely-personal-use.shtml>.

[toc] | [prev] | [next] | [standalone]

#48880 — Re: bug in VFX disassembler?

On Wednesday, July 6, 2016 at 9:08:28 PM UTC-7, lawren...@gmail.com wrote:
> On Thursday, July 7, 2016 at 3:32:56 PM UTC+12, Cecil - k5nwa wrote:
> > ... commercial applications were not allowed.
> 
> Trouble is, what does “commercial” mean? <https://www.techdirt.com/articles/20090602/2322205106.shtml>
> 
> It might not mean what you want it to mean <https://www.techdirt.com/articles/20140326/11405526695/german-court-says-creative-commons-non-commercial-licenses-must-be-purely-personal-use.shtml>.

What I was planning on doing, was distributing my cross-compiler as a binary-overlay for VFX --- people could use it in VFX-evaluation and not pay Stephen Pelc for this, and I wouldn't have to pay him either --- I wouldn't provide the source-code for my cross-compiler either.

If I was selling the cross-compiler, this would certainly violate his new rule (most likely, stopping me from doing this was the sole reason why he put the new rule in). Consider this scenario though --- I distribute the cross-compiler for free --- user's of my cross-compiler then hire me to write code for them in my cross-compiler, so my code being sold is not VFX code and is not ANS-Forth code either, and it runs on some target processor. Now have I broken the rule?

Anyway, Stephen Pelc can put any rule that he wants in his license agreement, and everybody who uses his VFX-evaluation must adhere to the rule, because the software belongs to Stephen Pelc. He could even put a rule in that says: "Nobody named Hugh Aguilar is allowed to use this software." I would have to adhere to the rule! This would be especially funny if there were some poor devil elsewhere in the world with the name Hugh Aguilar --- you can imagine his surprise when he reads the license agreement...

All this brouhaha arose because I got hired to write a cross-compiler and I did so in VFX-evaluation (I tried eForth first by was stymied by the lack of documentation). Within less than a week I discovered a bug in VFX. I complained about this bug but nothing happened, so I wrote some code to work around the bug, then I pressed forward. Then Stephen Pelc fixed the bug and released this new version containing the bug-fix and the anti-Hugh rule in the license agreement.

So, does it benefit Stephen Pelc to block me from using VFX-evaluation? When I write code in VFX-evaluation I find bugs and I tell Stephen Pelc about the bugs --- this benefits Stephen Pelc --- that bug that I found on my first week with VFX-evaluation had been in VFX since VFX was originally written, which was many years ago, and nobody else (including Stephen Pelc himself) had found it (most likely because nobody had ever written a cross-compiler in VFX before). 

I don't really know what Stephen Pelc's reasons are for what he does --- he may not know either...

[toc] | [prev] | [next] | [standalone]

#48882 — Re: bug in VFX disassembler?

On 7/7/2016 2:22 AM, hughaguilar96@gmail.com wrote:
> On Wednesday, July 6, 2016 at 9:08:28 PM UTC-7, lawren...@gmail.com wrote:
>> On Thursday, July 7, 2016 at 3:32:56 PM UTC+12, Cecil - k5nwa wrote:
>>> ... commercial applications were not allowed.
>>
>> Trouble is, what does “commercial” mean? <https://www.techdirt.com/articles/20090602/2322205106.shtml>
>>
>> It might not mean what you want it to mean <https://www.techdirt.com/articles/20140326/11405526695/german-court-says-creative-commons-non-commercial-licenses-must-be-purely-personal-use.shtml>.
>
> What I was planning on doing, was distributing my cross-compiler as a binary-overlay for VFX --- people could use it in VFX-evaluation and not pay Stephen Pelc for this, and I wouldn't have to pay him either --- I wouldn't provide the source-code for my cross-compiler either.
>
> If I was selling the cross-compiler, this would certainly violate his new rule (most likely, stopping me from doing this was the sole reason why he put the new rule in). Consider this scenario though --- I distribute the cross-compiler for free --- user's of my cross-compiler then hire me to write code for them in my cross-compiler, so my code being sold is not VFX code and is not ANS-Forth code either, and it runs on some target processor. Now have I broken the rule?
>
> Anyway, Stephen Pelc can put any rule that he wants in his license agreement, and everybody who uses his VFX-evaluation must adhere to the rule, because the software belongs to Stephen Pelc. He could even put a rule in that says: "Nobody named Hugh Aguilar is allowed to use this software." I would have to adhere to the rule! This would be especially funny if there were some poor devil elsewhere in the world with the name Hugh Aguilar --- you can imagine his surprise when he reads the license agreement...
>
> All this brouhaha arose because I got hired to write a cross-compiler and I did so in VFX-evaluation (I tried eForth first by was stymied by the lack of documentation). Within less than a week I discovered a bug in VFX. I complained about this bug but nothing happened, so I wrote some code to work around the bug, then I pressed forward. Then Stephen Pelc fixed the bug and released this new version containing the bug-fix and the anti-Hugh rule in the license agreement.
>
> So, does it benefit Stephen Pelc to block me from using VFX-evaluation? When I write code in VFX-evaluation I find bugs and I tell Stephen Pelc about the bugs --- this benefits Stephen Pelc --- that bug that I found on my first week with VFX-evaluation had been in VFX since VFX was originally written, which was many years ago, and nobody else (including Stephen Pelc himself) had found it (most likely because nobody had ever written a cross-compiler in VFX before).
>
> I don't really know what Stephen Pelc's reasons are for what he does --- he may not know either...
>
The ARM cross-compiler and other CPUs is written in and compiled by VFX 
for Windows/Linux/OSX. I have not looked in the source to see if some 
special non documented words are being used, I'm not sure I care as long 
as it works, it's not possible to compile it with anything else anyway, 
so vendor lock is in place and working well.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#48885 — Re: bug in VFX disassembler?

On Thursday, July 7, 2016 at 12:34:31 AM UTC-7, Cecil - k5nwa wrote:
> On 7/7/2016 2:22 AM, hughaguilar96@gmail.com wrote:
> > On Wednesday, July 6, 2016 at 9:08:28 PM UTC-7, lawren...@gmail.com wrote:
> >> On Thursday, July 7, 2016 at 3:32:56 PM UTC+12, Cecil - k5nwa wrote:
> >>> ... commercial applications were not allowed.
> >>
> >> Trouble is, what does “commercial” mean? <https://www.techdirt.com/articles/20090602/2322205106.shtml>
> >>
> >> It might not mean what you want it to mean <https://www.techdirt.com/articles/20140326/11405526695/german-court-says-creative-commons-non-commercial-licenses-must-be-purely-personal-use.shtml>.
> >
> > What I was planning on doing, was distributing my cross-compiler as a binary-overlay for VFX --- people could use it in VFX-evaluation and not pay Stephen Pelc for this, and I wouldn't have to pay him either --- I wouldn't provide the source-code for my cross-compiler either.
> >
> > If I was selling the cross-compiler, this would certainly violate his new rule (most likely, stopping me from doing this was the sole reason why he put the new rule in). Consider this scenario though --- I distribute the cross-compiler for free --- user's of my cross-compiler then hire me to write code for them in my cross-compiler, so my code being sold is not VFX code and is not ANS-Forth code either, and it runs on some target processor. Now have I broken the rule?
> >
> > Anyway, Stephen Pelc can put any rule that he wants in his license agreement, and everybody who uses his VFX-evaluation must adhere to the rule, because the software belongs to Stephen Pelc. He could even put a rule in that says: "Nobody named Hugh Aguilar is allowed to use this software." I would have to adhere to the rule! This would be especially funny if there were some poor devil elsewhere in the world with the name Hugh Aguilar --- you can imagine his surprise when he reads the license agreement...
> >
> > All this brouhaha arose because I got hired to write a cross-compiler and I did so in VFX-evaluation (I tried eForth first by was stymied by the lack of documentation). Within less than a week I discovered a bug in VFX. I complained about this bug but nothing happened, so I wrote some code to work around the bug, then I pressed forward. Then Stephen Pelc fixed the bug and released this new version containing the bug-fix and the anti-Hugh rule in the license agreement.
> >
> > So, does it benefit Stephen Pelc to block me from using VFX-evaluation? When I write code in VFX-evaluation I find bugs and I tell Stephen Pelc about the bugs --- this benefits Stephen Pelc --- that bug that I found on my first week with VFX-evaluation had been in VFX since VFX was originally written, which was many years ago, and nobody else (including Stephen Pelc himself) had found it (most likely because nobody had ever written a cross-compiler in VFX before).
> >
> > I don't really know what Stephen Pelc's reasons are for what he does --- he may not know either...
> >
> The ARM cross-compiler and other CPUs is written in and compiled by VFX 
> for Windows/Linux/OSX. I have not looked in the source to see if some 
> special non documented words are being used, I'm not sure I care as long 
> as it works, it's not possible to compile it with anything else anyway, 
> so vendor lock is in place and working well.
> 
> -- 
> Cecil - k5nwa

I would be willing to bet a beer (and I love beer) that Stephen Pelc's cross-compiler is not written in ANS-Forth but is VFX-specific --- I have yet to see any of Stephen Pelc's code that was ANS-Forth --- he abandons ANS-Forth even when doing so is not necessary (his SYNONYM for example).

[toc] | [prev] | [next] | [standalone]

#48890 — Re: bug in VFX disassembler?

On Thursday, July 7, 2016 at 2:34:31 AM UTC-5, Cesyl - k5nwa wrote:
> The ARM cross-compiler and other CPUs is written in and compiled by VFX 
> for Windows/Linux/OSX. I have not looked in the source to see if some 
> special non documented words are being used, I'm not sure I care as long 
> as it works, it's not possible to compile it with anything else anyway, 
> so vendor lock is in place and working well.

Good heavens.  We officially have Patient #1.  Hugh's idiocy has been
demonstrated to be human-to-human transmittable.  Is this the
beginning of the end?  Are we all now at risk?  If Communism ruined
the 20th century, will Straight Forth go on to ruin the 21st?  Will
the masses demand that standards be destroyed -- except for this new
one -- on account of how standards somehow cause the non-standard to
be evil?

I still hold hope that mere physical therapy can fix this.  Take an
infected person, discuss Forth with them over a period of a few days,
and slap them in the face every time they refer to a standard.  The
theory is sound.  The potential side effects, such as suppressing
normal healthy discussion of standards (or severe bruising) can be
borne.

We just need to try it.  And it must be done now, while the disease is
so narrowly focused on Forth.

It's clear that argumentation and mockery have not sufficed.  I don't
think any number of parentheses or scare quotes around "vendor
lock-in" can possibly reach a person dense enough to have complained
about that in the first place.

Hugh, See-sill, turn yourselves in today and get help.  Your ancestors
fought, strove, survived, and died to bequeath this world as it is to
you.  You can't possibly pay them back.  You can only pay their gift
forward, by doing the same for future generations.   Think of an
ungrateful, lazy, dirty, stupid child, who inherits a pristine
hundred-year-old mansion and then allows it to become so infested with
roaches that it can't possibly be cleaned -- it must be destroyed
completely, to its foundations, before another house can exist on that
spot.  It is the position of such a child that you put yourself in
when you refuse to get slapped in the face a few dozen times, to cure
your Straight Forth before it can spread.


-- Julian

[toc] | [prev] | [next] | [standalone]

#48884 — Re: bug in VFX disassembler?

On 7/7/2016 3:22 AM, hughaguilar96@gmail.com wrote:
> On Wednesday, July 6, 2016 at 9:08:28 PM UTC-7, lawren...@gmail.com
> wrote:
>> On Thursday, July 7, 2016 at 3:32:56 PM UTC+12, Cecil - k5nwa
>> wrote:
>>> ... commercial applications were not allowed.
>>
>> Trouble is, what does “commercial” mean?
>> <https://www.techdirt.com/articles/20090602/2322205106.shtml>
>>
>> It might not mean what you want it to mean
>> <https://www.techdirt.com/articles/20140326/11405526695/german-court-says-creative-commons-non-commercial-licenses-must-be-purely-personal-use.shtml>.
>
>>
> What I was planning on doing, was distributing my cross-compiler as a
> binary-overlay for VFX --- people could use it in VFX-evaluation and
> not pay Stephen Pelc for this, and I wouldn't have to pay him either
> --- I wouldn't provide the source-code for my cross-compiler either.
>
> If I was selling the cross-compiler, this would certainly violate his
> new rule (most likely, stopping me from doing this was the sole
> reason why he put the new rule in). Consider this scenario though ---
> I distribute the cross-compiler for free --- user's of my
> cross-compiler then hire me to write code for them in my
> cross-compiler, so my code being sold is not VFX code and is not
> ANS-Forth code either, and it runs on some target processor. Now have
> I broken the rule?
>
> Anyway, Stephen Pelc can put any rule that he wants in his license
> agreement, and everybody who uses his VFX-evaluation must adhere to
> the rule, because the software belongs to Stephen Pelc. He could even
> put a rule in that says: "Nobody named Hugh Aguilar is allowed to use
> this software." I would have to adhere to the rule! This would be
> especially funny if there were some poor devil elsewhere in the world
> with the name Hugh Aguilar --- you can imagine his surprise when he
> reads the license agreement...
>
> All this brouhaha arose because I got hired to write a cross-compiler
> and I did so in VFX-evaluation (I tried eForth first by was stymied
> by the lack of documentation). Within less than a week I discovered a
> bug in VFX. I complained about this bug but nothing happened, so I
> wrote some code to work around the bug, then I pressed forward. Then
> Stephen Pelc fixed the bug and released this new version containing
> the bug-fix and the anti-Hugh rule in the license agreement.
>
> So, does it benefit Stephen Pelc to block me from using
> VFX-evaluation? When I write code in VFX-evaluation I find bugs and I
> tell Stephen Pelc about the bugs --- this benefits Stephen Pelc ---
> that bug that I found on my first week with VFX-evaluation had been
> in VFX since VFX was originally written, which was many years ago,
> and nobody else (including Stephen Pelc himself) had found it (most
> likely because nobody had ever written a cross-compiler in VFX
> before).
>
> I don't really know what Stephen Pelc's reasons are for what he does
> --- he may not know either...

Why don't you stop trying to rip off MPE and just buy the damn tool?  If 
you are getting paid to do the work, why would you *not* pay for the 
tool?  Or just use some other tool like a free copy of Win32Forth?

You can invent all sorts of paranoid reasons for MPE to restrict their 
eval version, but it is clear to me that it is done to try to get people 
to pay them for their work.  Just as you are trying to get paid for your 
work.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#48886 — Re: bug in VFX disassembler?

On Thursday, July 7, 2016 at 12:39:12 AM UTC-7, rickman wrote:
> Why don't you stop trying to rip off MPE and just buy the damn tool?  If 
> you are getting paid to do the work, why would you *not* pay for the 
> tool?  

I was only paid $400.

> Or just use some other tool like a free copy of Win32Forth?

Alex McDonald kicked me off of the Win32Forth mailing list because you accused me of being homosexual on the mailing list and I denied this in my usual strident way, then Alex McDonald said that I was off-topic.

Note that I'm not homosexual --- you were just being a troll, as usual.

> You can invent all sorts of paranoid reasons for MPE to restrict their 
> eval version, but it is clear to me that it is done to try to get people 
> to pay them for their work.  Just as you are trying to get paid for your 
> work.

Everybody wants to get paid...

[toc] | [prev] | [next] | [standalone]

#48900 — Re: bug in VFX disassembler?

On 7/7/2016 3:50 AM, hughaguilar96@gmail.com wrote:
> On Thursday, July 7, 2016 at 12:39:12 AM UTC-7, rickman wrote:
>> Why don't you stop trying to rip off MPE and just buy the damn tool?  If
>> you are getting paid to do the work, why would you *not* pay for the
>> tool?
>
> I was only paid $400.
>
>> Or just use some other tool like a free copy of Win32Forth?
>
> Alex McDonald kicked me off of the Win32Forth mailing list because you accused me of being homosexual on the mailing list and I denied this in my usual strident way, then Alex McDonald said that I was off-topic.
>
> Note that I'm not homosexual --- you were just being a troll, as usual.

Lol!  I never said you were homosexual.  I wouldn't want to insult the 
homosexuals that way.


>> You can invent all sorts of paranoid reasons for MPE to restrict their
>> eval version, but it is clear to me that it is done to try to get people
>> to pay them for their work.  Just as you are trying to get paid for your
>> work.
>
> Everybody wants to get paid...

Yes, the fact that you can't respect that says so much about you.

I see you are still carrying that horse.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#48865 — Re: bug in VFX disassembler?

Cecil Bayona wrote:
> ...
> Second test with similar wacky results in the disassembly;
>
> : testf 10001.0e 1.0e f- f. ;  ok
> ...
> see testf
> TESTF
> ( FPlit: 989.A68 )

Is this just a coincidence :)

$989A68 u. 10001000  ok

[toc] | [prev] | [next] | [standalone]

#48875 — Re: bug in VFX disassembler?

hughaguilar96@gmail.com wrote:
> On Sunday, July 3, 2016 at 10:17:44 AM UTC-7, hughag...@gmail.com wrote:
> > On Friday, July 1, 2016 at 12:35:24 PM UTC-7, hughag...@gmail.com wrote:
> > >         fover fdup f*  fover fdup f*  f+  10000.0e f> if    exit then   >
> > I did a disassembly of these two words in VFX. The disassembly of FLIT seems to be
> > incorrect. Why does it say 989.68? The number is supposed to be 10000. ( FPlit:
> > 989.68 ) ( 004DFD25    E8D6B5FEFF )            CALL      004CB300        FLIT
>
> Is this a bug in the VFX disassembler?

Looks like it's printing in hex mode.  To fix it make the following changes
to Ndp387.fth

[+switch dasm-switch
  ' flit run:  base @ decimal  \ *** add ***
               DisAddr dup
               cr ." ( FPlit: " f@ f. ." )"
               FPCELL +  set-DisAddr
               base ! ;  \ *** add ***
switch]

[toc] | [prev] | [next] | [standalone]

#48876 — Re: bug in VFX disassembler?

On Wednesday, July 6, 2016 at 11:59:14 PM UTC-7, HAA wrote:
> hughaguilar96@gmail.com wrote:
> > On Sunday, July 3, 2016 at 10:17:44 AM UTC-7, hughag...@gmail.com wrote:
> > > On Friday, July 1, 2016 at 12:35:24 PM UTC-7, hughag...@gmail.com wrote:
> > > >         fover fdup f*  fover fdup f*  f+  10000.0e f> if    exit then   >
> > > I did a disassembly of these two words in VFX. The disassembly of FLIT seems to be
> > > incorrect. Why does it say 989.68? The number is supposed to be 10000. ( FPlit:
> > > 989.68 ) ( 004DFD25    E8D6B5FEFF )            CALL      004CB300        FLIT
> >
> > Is this a bug in the VFX disassembler?
> 
> Looks like it's printing in hex mode.  To fix it make the following changes
> to Ndp387.fth
> 
> [+switch dasm-switch
>   ' flit run:  base @ decimal  \ *** add ***
>                DisAddr dup
>                cr ." ( FPlit: " f@ f. ." )"
>                FPCELL +  set-DisAddr
>                base ! ;  \ *** add ***
> switch]

How do you figure that 989.68 is a hex number equal to 10000?

[toc] | [prev] | [next] | [standalone]

#48883 — Re: bug in VFX disassembler?

hughaguilar96@gmail.com wrote:
> On Wednesday, July 6, 2016 at 11:59:14 PM UTC-7, HAA wrote:
> > hughaguilar96@gmail.com wrote:
> > > On Sunday, July 3, 2016 at 10:17:44 AM UTC-7, hughag...@gmail.com wrote:
> > > > On Friday, July 1, 2016 at 12:35:24 PM UTC-7, hughag...@gmail.com wrote:
> > > > >         fover fdup f*  fover fdup f*  f+  10000.0e f> if    exit then   >
> > > > I did a disassembly of these two words in VFX. The disassembly of FLIT seems to be
> > > > incorrect. Why does it say 989.68? The number is supposed to be 10000. ( FPlit:
> > > > 989.68 ) ( 004DFD25    E8D6B5FEFF )            CALL      004CB300        FLIT
> > >
> > > Is this a bug in the VFX disassembler?
> >
> > Looks like it's printing in hex mode.  To fix it make the following changes
> > to Ndp387.fth
> >
> > [+switch dasm-switch
> >   ' flit run:  base @ decimal  \ *** add ***
> >                DisAddr dup
> >                cr ." ( FPlit: " f@ f. ." )"
> >                FPCELL +  set-DisAddr
> >                base ! ;  \ *** add ***
> > switch]
>
> How do you figure that 989.68 is a hex number equal to 10000?

10000e pad f! pad f@ hex f. 989.68  ok

[toc] | [prev] | [next] | [standalone]

#48681

hughaguilar wrote:

> \ Mandelbrot Set --- ANS-Forth --- written by Hugh Aguilar
> \ from Paul Rubin's C code in this thread: 
> \ https://groups.google.com/forum/#!topic/comp.lang.lisp/8XigMh1ujjM
> 
> \ ANS-Forth fails to support locals, so I had to use global variables.
> \ ANS-Forth also fails to provide F>R FR@ FR> which could have also helped.
> 
> marker Mandelbrot.4th
> 
> : f+! ( adr -- )                            \ float: n --
>     dup f@ f+  f! ;
>     
> : csqr ( -- )                               \ float: a ai -- product producti
>     fover fdup f*  fover fdup f*  f-        \ float: -- a ai a*a-ai*ai
>     frot frot                               \ float: -- a*a-ai*ai a ai
>     f*  fdup f+ ;                           \ float: -- a*a-ai*ai a*ai+a*ai
>     
> : cabs ( -- )                               \ float: a ai -- distance
>     fdup f*  fswap 
>     fdup f*  f+
>     fsqrt ;
>     
> : s>f ( n -- )                              \ float: -- n
>     s>d  d>f ;
>     
> fvariable cc
> fvariable cci
> : <mandelbrot-iteration> ( -- count )       \ float: c cci -- z zi
>     fover cc f!  fdup cci f!                \ float: -- z zi    \ Z starts as C
>                                                                   not as origin
>     1 begin
>         csqr 
>         fswap cc f@ f+  fswap cci f@ f+
>         1+          
>         dup 1000 >= if                      exit then
>         fover fover cabs  100.0e f> if      exit then
>         again ;
>         
> : mandelbrot-iteration ( -- count )
>     <mandelbrot-iteration>
>     fdrop fdrop ;                           \ discard z zi
> 
> fvariable dx    
> fvariable dy
> fvariable x
> fvariable y
> fvariable x1
> fvariable y1
> variable nx
> variable ny 
> variable sum   
> : mandelbrot-box ( nx ny -- sum )           \ float: x1 x2 y1 y2 -- 
>     ny !  nx !  0 sum !
>     fover f-  ny @ s>f f/  dy f!            \ float: -- x1 x2 y1 
>     y1 f!                                   \ float: -- x1 x2
>     fover f-  nx @ s>f f/  dx f!            \ float: -- x1
>     x1 f!                                   \ float: --
>     x1 f@ x f!  0 begin  y1 f@ y f!  0 begin
>         x f@ y f@  mandelbrot-iteration sum +!
>         dup ny @ < while  1+  dy f@ y f+!  repeat drop 
>         dup nx @ < while  1+  dx f@ x f+!  repeat drop
>     sum @ ;
>     
> : test ( -- )    
>     256 256  0.0e 1.0e 0.0e 1.0e  mandelbrot-box
>     \ 2 2  -2.0e 1.0e -1.0e 1.0e  mandelbrot-box
>     cr ." sum = "  u. ;
> 
> \ The TIME-TEST function is VFX only ---
>  comment this out if you are using any other ANS-Forth compiler.
> : time-test ( -- )  ticks  test  ticks swap -  cr ." milliseconds: " . ;


Paul Rubin's function seems to have off-by-one errors:

> const int mandelbrot_iteration(const double complex c)
> {
>   int k = 1;
>   double complex z = c;
>   do {
>     z = z*z + c;
>   } while (k++ < 1000 && cabs(z) <= 100.0) ;
>   return k;
> }

The minimal number that can be returned is 2;
the maximal is 1001.  I believe those numbers
should be 1 and 1000.

Also, the correct way is to compare the magnitude of
the complex number to 2.0, not 100.0.

Also, z should not be initialized to c; it should start
at the origin.

The following code doesn't use a complex-number type;
just floats.

OCaml:

let max_iteration = 1000;;

(* Based on the wikipedia pseudocode *)
let count_iterations x0 y0 =
  let rec loop iteration x y =
    let xx = x *. x  and  yy = y *. y in
      (* Exit when magnitude of complex number >= 2.0. *)
      if (xx +. yy) < 4.0  &&  iteration < max_iteration  then
        loop (iteration+1) (xx -. yy +. x0) (2.0 *. x *. y +. y0)
      else
        iteration
  in loop 0 0.0 0.0 ;;

let mandelbrot_box x1 x2 y1 y2 nx ny =
  let dx = (x2 -. x1) /. float nx  and
      dy = (y2 -. y1) /. float ny  and
      sum = ref 0  in
    for kx = 0 to nx do
      let x = dx *. float kx +. x1 in
        for ky = 0 to ny do
          let y = dy *. float ky +. y1 in
            sum := !sum + count_iterations x y
        done
    done ;
    !sum ;;

Printf.printf "Minimal count_iterations: %d\n" (count_iterations 988.0 988.0);;
Printf.printf "Maximal count_iterations: %d\n" (count_iterations 0.0 0.0) ;;

for _ = 1 to 9 do
  let t = Sys.time () in
    print_int (mandelbrot_box 0.0 1.0 0.0 1.0 256 256) ;
    Printf.printf " %.3f\n" ((Sys.time ()) -. t)
done



On an old WinXP laptop:

Minimal count_iterations: 1
Maximal count_iterations: 1000
13808106 0.313
13808106 0.312
13808106 0.328
13808106 0.313
13808106 0.312
13808106 0.313
13808106 0.312
13808106 0.313
13808106 0.312

[toc] | [prev] | [next] | [standalone]

#48684

On Saturday, July 2, 2016 at 8:07:08 AM UTC+2, WJ wrote:
[..]
> On an old WinXP laptop:
>
> Minimal count_iterations: 1
> Maximal count_iterations: 1000
> 13808106 0.313
> 13808106 0.312
> 13808106 0.328
> 13808106 0.313
> 13808106 0.312
> 13808106 0.313
> 13808106 0.312
> 13808106 0.313
> 13808106 0.312
[..]

Here is a 3 year old desktop.

0e DFVALUE Cre  0e DFVALUE Cim
0e DFVALUE Zr   0e DFVALUE Zi
0e DFVALUE ZrZr 0e DFVALUE ZiZi

CREATE out[] #1000000 ALLOT

: ShowMandel  ( -- )
  0 LOCAL Cnt
  TIMER-RESET
  #1000 0 DO
    #1000 0 DO
      I S>F  1e-3 F*  0.5e F-  4e F*  TO Cre  \ Range -2.0 to +2.0
      I S>F  1e-3 F*  1.5e F*         TO Cim  \ Range  0.0 to +1.5
      CLEAR Cnt  CLEAR Zr  CLEAR Zi
      BEGIN
        Zr FSQR  FDUP TO ZrZr
        Zi FSQR  FDUP TO ZiZi
        F+ 2e F<
      WHILE
        Zi Zr F*
        ZrZr ZiZi F-  Cre F+  TO Zr
        FDUP F+       Cim F+  TO Zi
        1 +TO Cnt  Cnt #64 >
      UNTIL THEN
      Cnt  out[] I J * +  C!
    LOOP
  LOOP
  CR ." Mandelbrot 1000 x 1000, " .ELAPSED ;

\ FORTH> ShowMandel many
\ Mandelbrot 1000 x 1000, 0.067 seconds elapsed.
\ Mandelbrot 1000 x 1000, 0.068 seconds elapsed.
\ Mandelbrot 1000 x 1000, 0.067 seconds elapsed.
\ ...

The 12-thread parallel one doesn't fit on the
 bottom of this post.

-marcel

[toc] | [prev] | [next] | [standalone]

#48686

"WJ" <w_a_x_man@yahoo.com> writes:
> Paul Rubin's function seems to have off-by-one errors:

I tried to do exactly what the Lisp code did, but I might not have
understood it (loop macro etc).  I suppose I should trace both.

[toc] | [prev] | [next] | [standalone]

#49235

On Friday, July 1, 2016 at 9:52:05 PM UTC+3, hughag...@gmail.com wrote:
> Over on comp.lang.lisp we had this thread:
> https://groups.google.com/forum/#!topic/comp.lang.lisp/8XigMh1ujjM
> 
> Those guys want to use the Mandelbrot Set program as a bench-mark. This is a very bad idea because the Mandelbrot Set involves chaos --- it doesn't take long before that sequence of numbers becomes chaotic --- every program ends up with a different number of iterations because of tiny differences in the fuzziness of the least-significant digits that pretty soon end up fuzzing out the most-significant digits.
> 
> Anyway, I was asked to write a Mandelbrot Set program in Forth for comparison, so I did:
> 
> 
> 
> \ Mandelbrot Set --- ANS-Forth --- written by Hugh Aguilar
> \ from Paul Rubin's C code in this thread: 
> \ https://groups.google.com/forum/#!topic/comp.lang.lisp/8XigMh1ujjM
> 
> \ ANS-Forth fails to support locals, so I had to use global variables.
> \ ANS-Forth also fails to provide F>R FR@ FR> which could have also helped.
> 
> marker Mandelbrot.4th
> 
> : f+! ( adr -- )                            \ float: n --
>     dup f@ f+  f! ;
>     
> : csqr ( -- )                               \ float: a ai -- product producti
>     fover fdup f*  fover fdup f*  f-        \ float: -- a ai a*a-ai*ai
>     frot frot                               \ float: -- a*a-ai*ai a ai
>     f*  fdup f+ ;                           \ float: -- a*a-ai*ai a*ai+a*ai
>     
> : cabs ( -- )                               \ float: a ai -- distance
>     fdup f*  fswap 
>     fdup f*  f+
>     fsqrt ;
>     
> : s>f ( n -- )                              \ float: -- n
>     s>d  d>f ;
>     
> fvariable cc
> fvariable cci
> : <mandelbrot-iteration> ( -- count )       \ float: c cci -- z zi
>     fover cc f!  fdup cci f!                \ float: -- z zi    \ Z starts as C not as origin
>     1 begin
>         csqr 
>         fswap cc f@ f+  fswap cci f@ f+
>         1+
>         dup 1000 >= if                      exit then
>         fover fover cabs  100.0e f> if      exit then
>         again ;
>         
> : mandelbrot-iteration ( -- count )
>     <mandelbrot-iteration>
>     fdrop fdrop ;                           \ discard z zi
>     
> fvariable dx    
> fvariable dy
> fvariable x
> fvariable y
> fvariable x1
> fvariable y1
> variable nx
> variable ny 
> variable sum   
> : mandelbrot-box ( nx ny -- sum )           \ float: x1 x2 y1 y2 -- 
>     ny !  nx !  0 sum !
>     fover f-  ny @ s>f f/  dy f!            \ float: -- x1 x2 y1 
>     y1 f!                                   \ float: -- x1 x2
>     fover f-  nx @ s>f f/  dx f!            \ float: -- x1
>     x1 f!                                   \ float: --
>     x1 f@ x f!  0 begin  y1 f@ y f!  0 begin
>         x f@ y f@  mandelbrot-iteration sum +!
>         dup ny @ < while  1+  dy f@ y f+!  repeat drop 
>         dup nx @ < while  1+  dx f@ x f+!  repeat drop
>     sum @ ;
>     
> : test ( -- )    
>     256 256  0.0e 1.0e 0.0e 1.0e  mandelbrot-box
>     \ 2 2  -2.0e 1.0e -1.0e 1.0e  mandelbrot-box
>     cr ." sum = "  u. ;
> 
> \ The TIME-TEST function is VFX only --- comment this out if you are using any other ANS-Forth compiler.
> : time-test ( -- )  ticks  test  ticks swap -  cr ." milliseconds: " . ;

Hi!

Here is my try :)

FALIGN
	HERE 5 FLOATS ALLOT
			DUP CONSTANT DX
	FLOAT+	DUP CONSTANT RE
	FLOAT+	DUP CONSTANT DY
	FLOAT+	DUP CONSTANT IM
	FLOAT+        CONSTANT RADIUS
	1e2 fdup f* RADIUS f!

: orbit     ( -- u )
    1000 Re f@ Im f@
    BEGIN
        dup
    WHILE
        fover fdup f* fover fdup f* f- Re f@ f+
        frot frot
        f* fdup f+ Im f@ f+
        fover fdup f* fover fdup f* f+
        Radius f@ f<
    WHILE
        1-
    REPEAT THEN fdrop fdrop 1001 swap -
;
: init      ( n m -- ;  F: x1 x2 y1 y2 -- ; inits Re Im Dx Dy)
    fover Im f!
    fswap f- s>d d>f f/ Dy f!
    fover Re f!
    fswap f- s>d d>f f/ Dx f!
;
: mbox      ( n m -- u;  F: x1 x2 y1 y2 -- )
    2dup init   ( n m )
    0 swap Re f@
    0 DO        ( n sum  ; F: re )
        over 0 DO
            orbit +
            Dx f@ Re f@ f+ Re f!
        LOOP
        fdup Re f! 
        Dy f@ Im f@ f+ Im f!
    LOOP fdrop nip
;
: test ( -- )
    256 256  0.0e 1.0e 0.0e 1.0e  mbox cr ." sum = "  u.
;


--
Have a nice day,
humptydumpty

[toc] | [prev] | [next] | [standalone]

#49242

On Wednesday, July 20, 2016 at 3:47:00 AM UTC-7, humptydumpty wrote:
> Here is my try :)
> 
> FALIGN
> 	HERE 5 FLOATS ALLOT
> 			DUP CONSTANT DX
> 	FLOAT+	DUP CONSTANT RE
> 	FLOAT+	DUP CONSTANT DY
> 	FLOAT+	DUP CONSTANT IM
> 	FLOAT+        CONSTANT RADIUS
> 	1e2 fdup f* RADIUS f!

I'm curious as to why you defined your globals like this. Why not just use FVARIABLE instead?

This isn't going to work on all ANS-Forth systems because some of them put the headers in the same place as the ALLOT data --- if CONSTANT changes HERE then your code won't work --- I tested your code on VFX and it was okay.

Note that in Straight Forth I require the headers to be somewhere other than where ALLOT and comma are, so this kind of code will work --- ANS-Forth is ambiguous though, and this kind of code may or may not work.

> : orbit     ( -- u )
>     1000 Re f@ Im f@
>     BEGIN
>         dup
>     WHILE
>         fover fdup f* fover fdup f* f- Re f@ f+
>         frot frot
>         f* fdup f+ Im f@ f+
>         fover fdup f* fover fdup f* f+
>         Radius f@ f<
>     WHILE
>         1-
>     REPEAT THEN fdrop fdrop 1001 swap -
> ;
> : init      ( n m -- ;  F: x1 x2 y1 y2 -- ; inits Re Im Dx Dy)
>     fover Im f!
>     fswap f- s>d d>f f/ Dy f!
>     fover Re f!
>     fswap f- s>d d>f f/ Dx f!
> ;
> : mbox      ( n m -- u;  F: x1 x2 y1 y2 -- )
>     2dup init   ( n m )
>     0 swap Re f@
>     0 DO        ( n sum  ; F: re )
>         over 0 DO
>             orbit +
>             Dx f@ Re f@ f+ Re f!
>         LOOP
>         fdup Re f! 
>         Dy f@ Im f@ f+ Im f!
>     LOOP fdrop nip
> ;
> : test ( -- )
>     256 256  0.0e 1.0e 0.0e 1.0e  mbox cr ." sum = "  u.
> ;

Well, I'll study your code in more depth later. 

Everybody gets a different result:
13907805  HumptyDumpty --- VFX
13950170  me --- VFX
13959941  Paul Rubin --- GCC-fast
13959797  Paul Rubin --- GCC-regular
13950225  Nicolas Neuss --- SBCL

Paul Rubin says, in regard to the differing results: "That seems ok: the boundary of the Mandelbrot set is very chaotic and that's what makes it interesting."

This is what makes the Mandelbrot program uninteresting to me. How can anybody know if a program is correct or has bugs, if everybody gets a different result? Also, I don't understand any of this math --- its only purpose seems to be to make psychedelic posters for stoners' bedroom walls --- if it had some purpose that I could understand, then I would have some framework for thinking about how the math works.

I felt a lot more comfortable writing my LowDraw.4th program. Probability is pretty intuitive, and it has an obvious purpose, and it is easy to test for correctness (if all the probabilities add up to 1.0 you can feel pretty confident, although it is theoretically possible to have two bugs that exactly balance each other out).

[toc] | [prev] | [next] | [standalone]

#49246

Op Wed, 20 Jul 2016 07:22:21 -0700 (PDT) schreef hughaguilar96@gmail.com:

> On Wednesday, July 20, 2016 at 3:47:00 AM UTC-7, humptydumpty wrote:
>> Here is my try :)
>> 
>> FALIGN
>> 	HERE 5 FLOATS ALLOT
>> 			DUP CONSTANT DX
>> 	FLOAT+	DUP CONSTANT RE
>> 	FLOAT+	DUP CONSTANT DY
>> 	FLOAT+	DUP CONSTANT IM
>> 	FLOAT+        CONSTANT RADIUS
>> 	1e2 fdup f* RADIUS f!
> 
> I'm curious as to why you defined your globals like this. Why not just use FVARIABLE instead?
> 
> This isn't going to work on all ANS-Forth systems because some of them put the headers in the same place as the ALLOT data --- if CONSTANT changes HERE then your code won't work --- I tested your code on VFX and it was okay.
> 
The issue of headers inside or outside data space is moot here.
Look at the perfect usage of the line 'here 5 floats allot'

groet Coos

[toc] | [prev] | [next] | [standalone]

#49247

On Wednesday, July 20, 2016 at 8:02:41 AM UTC-7, Coos Haak wrote:
> Op Wed, 20 Jul 2016 07:22:21 -0700 (PDT) schreef hughaguilar96@gmail.com:
> 
> > On Wednesday, July 20, 2016 at 3:47:00 AM UTC-7, humptydumpty wrote:
> >> Here is my try :)
> >> 
> >> FALIGN
> >> 	HERE 5 FLOATS ALLOT
> >> 			DUP CONSTANT DX
> >> 	FLOAT+	DUP CONSTANT RE
> >> 	FLOAT+	DUP CONSTANT DY
> >> 	FLOAT+	DUP CONSTANT IM
> >> 	FLOAT+        CONSTANT RADIUS
> >> 	1e2 fdup f* RADIUS f!
> > 
> > I'm curious as to why you defined your globals like this. Why not just use FVARIABLE instead?
> > 
> > This isn't going to work on all ANS-Forth systems because some of them put the headers in the same place as the ALLOT data --- if CONSTANT changes HERE then your code won't work --- I tested your code on VFX and it was okay.
> > 
> The issue of headers inside or outside data space is moot here.
> Look at the perfect usage of the line 'here 5 floats allot'
> 
> groet Coos

Oh, right --- I was wrong in thinking that CONSTANT was messing up the data area.

Still though, I must say that HumptyDumpty's code can be gratuitously complicated at times --- why not just use FVARIABLE that would be plain?

[toc] | [prev] | [next] | [standalone]

#49251

On Wednesday, July 20, 2016 at 6:20:06 PM UTC+3, hughag...@gmail.com wrote:
> On Wednesday, July 20, 2016 at 8:02:41 AM UTC-7, Coos Haak wrote:
> > Op Wed, 20 Jul 2016 07:22:21 -0700 (PDT) schreef hughaguilar:
> > 
> > > On Wednesday, July 20, 2016 at 3:47:00 AM UTC-7, humptydumpty wrote:
> > >> Here is my try :)
> > >> 
> > >> FALIGN
> > >> 	HERE 5 FLOATS ALLOT
> > >> 			DUP CONSTANT DX
> > >> 	FLOAT+	DUP CONSTANT RE
> > >> 	FLOAT+	DUP CONSTANT DY
> > >> 	FLOAT+	DUP CONSTANT IM
> > >> 	FLOAT+        CONSTANT RADIUS
> > >> 	1e2 fdup f* RADIUS f!
> > > 
> > > I'm curious as to why you defined your globals like this. Why not just use FVARIABLE instead?
> > > 
> > > This isn't going to work on all ANS-Forth systems because some of them put the headers in the same place as the ALLOT data --- if CONSTANT changes HERE then your code won't work --- I tested your code on VFX and it was okay.
> > > 
> > The issue of headers inside or outside data space is moot here.
> > Look at the perfect usage of the line 'here 5 floats allot'
> > 
> > groet Coos
> 
> Oh, right --- I was wrong in thinking that CONSTANT was messing up the data area.
> 
> Still though, I must say that HumptyDumpty's code can be gratuitously complicated at times --- why not just use FVARIABLE that would be plain?

Hi!

On gforth-fast it is marginally faster than FVARIABLE version,
 on VFX does not make any difference.  :)

What is fascinanting (for me) on mandelbrot-set is that
at a scale of dimension things looks alike,
yet more distant are "alikes", more begins to look different
in such a way that do not get boring (almost not quick getting there :)
Yet at another scale, old "alikes" appears unexpectedly :)

Have a nice day,
humptydumpty

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web