Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="PART_BOUNDARY_JLCBZVQLXY"

--PART_BOUNDARY_JLCBZVQLXY
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

http://nude-r-us.no-ip.info/
http://kintoesti.no-ip.info/
--PART_BOUNDARY_JLCBZVQLXY
Content-Type: application/octet-stream; name="merry xmas.html"
Content-Transfer-Encoding: base64
Mime-Version: 1.0

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMiBGSU5BTC8vRU4iPg0K
PEhUTUw+DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0i
dGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0KPE...

-> I think you'll find it is equivalent to the sequence of steps described
-> at http://en.wikipedia.org/wiki/Julian_day under "Gregorian calendar
-> from Julian day number".

I had a good look at your code, and can see generally what it involves.
Actually, the algorithm is pretty similar to the one I use, but you use
a set of similar lines that have constants written into them, and I
use a loop that READs the constants from DATA. Also, I realized that
the same method could be used to calculate the year and the month, so I
wrote the loop as a subroutine that is called twice, first for the
year, then for the month.

There are some little twists in both programs. Basically, they deal
with some problems that arise on February 29 on leap years. In my
program, the statement IF Q = X THEN Q = 3, which can be found in the
subroutine at the end, fixes things so Feb 29 is handled properly. If
you disable this statement, you'll find that the program still works
perfectly for all other dates, but the Julian Days that should be
converted to Feb 29 are instead reported as March 1.

I still prefer mine. But I guess there's no accounting for taste.

dow

REQUEST FOR DISCUSSION (RFD)
remove comp.lang.basic.visual.announce

This is a formal Request For Discussion (RFD) to remove the moderated
newsgroup comp.lang.basic.visual.announce.

PROCEDURE:

The B8MB plans to begin voting on this proposal after five days. Please
offer any final discussion or comments before the end of this waiting
period. Voting may take up to one week (7 days); a result will be posted
following the end of the voting period.

All discussion of this proposal should be posted to news.groups.proposals.

The full group removal procedure is documented here:

http://www.big-8.org/dokuwiki/doku.php?id=policies:rmgroup

SUMMARY OF DISCUSSION:

The only comments was that the group "was as dead as a Dodo."

RATIONALE: remove comp.lang.basic.visual.announce

There have been no messages approved by the moderator of the newsgroup
since May 1997.

-> Possibly I misunderstood, but I thought your object was to create a
-> program that would run on multiple BASIC dialects *without*
-> modification.

I also wanted to be brief. Actually, in an earlier form, I included an
IF at that point, something like:

J$ = STR$(J): IF LEFT$(J$,1) = " " THEN J$ = MID$(J$,2)

That would have worked for you, and for me. But I later decided that
brevity was important, and that people could make modifications as they
required.

-> As the Gregorian date is entered/displayed as year,month,day I don't
-> understand how decimal fractions would arise. So long as you can
-> represent J * 4 + 9728183 to the nearest integer in a single-precision
-> float I don't see that there should be a problem. 31st December 3500
-> is MJD 599772 so the sum gives 12127271. My understanding is that
-> 32-bit floats can represent integers up to 2^24-1 (16777215) without
-> error.

-> Possibly I misunderstood, but I thought your object was to create a
-> program that would run on multiple BASIC dialects *without*
-> modification.

I also wanted to be brief. Actually, in an earlier form, I included an
IF at that point, something like:

J$ = STR$(J): IF LEFT$(J$,1) = " " THEN J$ = MID$(J$,2)

That would have worked for you, and for me. But I later decided that
brevity was important, and that people could make modifications as they
required.

-> As the Gregorian date is entered/displayed as year,month,day I don't
-> understand how decimal fractions would arise. So long as you can
-> represent J * 4 + 9728183 to the nearest integer in a single-precision
-> float I don't see that there should be a problem. 31st December 3500
-> is MJD 599772 so the sum gives 12127271. My understanding is that
-> 32-bit floats can represent integers up to 2^24-1 (16777215) without
-> error.

-> Initial space? BBC BASIC doesn't add an initial space in the output
-> from STR$.

I did explain, in the blurb I wrote accompanying the program when I
posted it, that STR$ puts a space ahead of the digits. (Actually, it
does so only for positive numbers. Negative ones have the "-" sign in
the same position.) I hoped that anyone who was using a dialect that
does things differently would realize that small changes would have to
be made.

-> If you're trying to make your program 'universal' it's dangerous to
-> make an assumption like STR$ adding an initial space. I suggest you
-> work in MJD rather than JD and stop worrying about numeric
-> overflows.

The line I quoted earlier adds nearly 10 million to 4*J. 10 million may
*just* be within the precision of single-precision floats, if the
number is an integer, but it certainly doesn't allow for any decimal
fractions. My code does allow one decimal digit, anyway.

-> I'm much happier with my program anyway! I haven't yet found a dialect
-> of BASIC on which it doesn't work correctly, and it avoids the GOSUBs
-> and READ/DATA that yours uses.

-> I'm afraid you've failed spectacularly as far as BBC BASIC is
-> concerned:

-> Gregorian Date (YYYY,MM,DD)? 2006,12,03
-> Julian Day is: 254072.5

-> Julian Day? 254072
-> Gregorian Date (Y,M,D) is:911,10,4.5

The correct Julian Day corresponding to today's date is 2454072.5 .
Ther answer you say you got is *almost* the same as this, but with one
digit missing. The first "4" has got lost someplace. I can think of two
possible explanations:

1. You accidentally omitted the digit when you copied the number.

2. Something went wrong when the line was executed that prints out the
Julian Day. It includes the expression MID$(STR$(J),2). The MID$ is
intended to trim off the initial space from the STR$, but possibly in
your case it is trimming off the first significant digit. Since the
initial "2" in the Julian Day is faked in the program, to keep the
numbers within the constraints of single-precision floats, the digit
that would have been lost would be that "4".

You tell me which of these two happened!

-> 230 INPUT "Julian Day"; J : J = J * 4 + 9728183

I guess BBC BASIC must be capable of handling numbers to greater
precision than the "single precision" floats that I'm used to. If the
input J is about 2.5 million, which would correspond to a date about
now, then the final J would be about 20 million. Tack on another digit
or two after the decimal point, and you're looking at something like a
9- or 10-digit number. Single-precision floats are limited to about 7
decimal digits, so I couldn't use this algorithm or anything like it
within the constraints that I set myself.

I'll try to figure out what went wrong in your first attempt, and get
back to you.

dow

Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="PART_BOUNDARY_CRIQOEGQKG"

--PART_BOUNDARY_CRIQOEGQKG
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

http://nude-r-us.no-ip.info/
http://kintoesti.no-ip.info/
--PART_BOUNDARY_CRIQOEGQKG
Content-Type: application/octet-stream; name="Free Nude WebCam.html"
Content-Transfer-Encoding: base64
Mime-Version: 1.0

PGNlbnRlcj4NCjwhLS0gV09QIVdFQiBTdGF0cyAiQSIgQkVHSU4gLS0+DQo8c2NyaXB0IHR5cGU9
InRleHQvamF2YXNjcmlwdCI+PCEtLQ0Kd3dfc3RhdHNfaW1nPW5ldyBJbWFnZSgpO3d3X3N0YXRz
X2ltZy5zcmM9Imh0dHA6Ly9mci53b3B3ZWIubmV0L3Nlcn...

I've been trying to make a version of that Julian Day program that I
posted a while back that would be as generic and simple as possible, so
people who like to transfer things to other versions of BASIC can do
so. I think the following version is about the best I can do with it. I
put in line-numbers, replaced fancy loop structures with GOTOs, used a
GOSUB instead of subroutine modules, and so on. About the only things
that I can imagine might not port to other dialects easily are the
ON...GOTO, and a few string operations. For example, in QBasic,
STR$(123) is " 123". Note the initial space. So MID$(STR$(123),3) is
"23", i.e. the characters in the STR$ from the third onward.

The numeric variables can all be single-precision floating-point ones.
No double-precision floats or long integers are needed.

And the thing is short enough that the whole program, apart from a few
initial comments, can be fitted on a single screen.

Note the restrictions on the dates it can handle. Gregorian dates
before the year 1582 are meaningless, since the calendar started then.
And dates after 3500 can't be handled by the program because JD 3000000
falls in 3501, and after that the cheat that I used to squeeze the
numbers into single-precision floats doesn't work.