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

Groups > alt.lang.basic > #761 > unrolled thread

Computer guesses your number

Back to article view | Back to alt.lang.basic

Contents

  Computer guesses your number "F. W." <me@home.com> - 2023-03-29 15:27 +0200
    Re: Computer guesses your number Physfitfreak <Physfitfreak@gmail.com> - 2023-12-26 19:28 -0600
      Re: Computer guesses your number "Auric__" <not.my.real@email.address> - 2023-12-27 23:17 +0000
        Re: Computer guesses your number Physfitfreak <Physfitfreak@gmail.com> - 2023-12-27 18:37 -0600
          Re: Computer guesses your number "Auric__" <not.my.real@email.address> - 2023-12-29 06:21 +0000
            Re: Computer guesses your number Physfitfreak <Physfitfreak@gmail.com> - 2023-12-29 18:26 -0600
              Re: Computer guesses your number "Auric__" <not.my.real@email.address> - 2023-12-31 19:18 +0000
                Re: Computer guesses your number Physfitfreak <Physfitfreak@gmail.com> - 2024-01-02 20:47 -0600
                  Re: Computer guesses your number Gordon Henderson <gordon+usenet@drogon.net> - 2024-01-03 15:17 +0000
                  Re: Computer guesses your number "Auric__" <not.my.real@email.address> - 2024-01-03 21:16 +0000
                    Re: Computer guesses your number Physfitfreak <Physfitfreak@gmail.com> - 2024-01-03 23:20 -0600
                      Re: Computer guesses your number "Auric__" <not.my.real@email.address> - 2024-01-04 22:09 +0000
                        Re: Computer guesses your number Physfitfreak <Physfitfreak@gmail.com> - 2024-01-05 20:41 -0600
                          Re: Computer guesses your number "Auric__" <not.my.real@email.address> - 2024-01-06 19:30 +0000
                            Re: Computer guesses your number Physfitfreak <Physfitfreak@gmail.com> - 2024-01-07 16:41 -0600
                              Re: Computer guesses your number "Auric__" <not.my.real@email.address> - 2024-01-08 03:21 +0000
                                Re: Computer guesses your number Physfitfreak <Physfitfreak@gmail.com> - 2024-01-26 19:03 -0600
                                  Re: Computer guesses your number Physfitfreak <Physfitfreak@gmail.com> - 2024-01-26 23:16 -0600
                                    Re: Computer guesses your number "Auric__" <not.my.real@email.address> - 2024-01-27 05:41 +0000
    Re: Computer guesses your number Gordon Henderson <gordon+usenet@drogon.net> - 2023-12-30 21:32 +0000
      Re: Computer guesses your number Physfitfreak <Physfitfreak@gmail.com> - 2023-12-30 20:20 -0600
        Re: Computer guesses your number Gordon Henderson <gordon+usenet@drogon.net> - 2023-12-31 08:02 +0000
          Re: Computer guesses your number Physfitfreak <Physfitfreak@gmail.com> - 2024-01-02 20:07 -0600
            Re: Computer guesses your number Physfitfreak <Physfitfreak@gmail.com> - 2024-01-02 20:35 -0600
              Re: Computer guesses your number Gordon Henderson <gordon+usenet@drogon.net> - 2024-01-03 15:10 +0000
                Re: Computer guesses your number Physfitfreak <Physfitfreak@gmail.com> - 2024-01-03 23:22 -0600

Page 1 of 2  [1] 2  Next page →

#761 — Computer guesses your number

10 Rem       *** Computer guesses your number ***
20 Print "Welcome to the guessing game!"
25 untergrenze = 1 : obergrenze = 0 : versuch = 0 : anzahl = 0
30 Input "To what maximal number will you guess";obergrenze
40 Do
42  versuch = untergrenze + Int((obergrenze - untergrenze) / 2)
43  anzahl = anzahl + 1
46  Print "Zwischen ";untergrenze;" und ";obergrenze
50  Print "I guess ";versuch
60  Input "g(reater, s(maller, i(t is it!";antwort$
63  Select Case antwort$
64    Case "g": untergrenze = versuch : Print "Okay, greater..."
65    Case "s": obergrenze = versuch : Print "Okay, smaller..."
66  End Select
70  If antwort$ = "i" Then 90
80 Loop Until antwort$ = "i"
90 Print "I needed ";anzahl;" tries. I remain a math-champion!"

FW

[toc] | [next] | [standalone]

#847

On 3/29/2023 8:27 AM, F. W. wrote:
> 10 Rem       *** Computer guesses your number ***
> 20 Print "Welcome to the guessing game!"
> 25 untergrenze = 1 : obergrenze = 0 : versuch = 0 : anzahl = 0
> 30 Input "To what maximal number will you guess";obergrenze
> 40 Do
> 42  versuch = untergrenze + Int((obergrenze - untergrenze) / 2)
> 43  anzahl = anzahl + 1
> 46  Print "Zwischen ";untergrenze;" und ";obergrenze
> 50  Print "I guess ";versuch
> 60  Input "g(reater, s(maller, i(t is it!";antwort$
> 63  Select Case antwort$
> 64    Case "g": untergrenze = versuch : Print "Okay, greater..."
> 65    Case "s": obergrenze = versuch : Print "Okay, smaller..."
> 66  End Select
> 70  If antwort$ = "i" Then 90
> 80 Loop Until antwort$ = "i"
> 90 Print "I needed ";anzahl;" tries. I remain a math-champion!"
> 
> FW

What language is this program in?

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

#848

Physfitfreak wrote:

> On 3/29/2023 8:27 AM, F. W. wrote:
>> 10 Rem       *** Computer guesses your number ***
>> 20 Print "Welcome to the guessing game!"
>> 25 untergrenze = 1 : obergrenze = 0 : versuch = 0 : anzahl = 0
>> 30 Input "To what maximal number will you guess";obergrenze
>> 40 Do
>> 42  versuch = untergrenze + Int((obergrenze - untergrenze) / 2)
>> 43  anzahl = anzahl + 1
>> 46  Print "Zwischen ";untergrenze;" und ";obergrenze
>> 50  Print "I guess ";versuch
>> 60  Input "g(reater, s(maller, i(t is it!";antwort$
>> 63  Select Case antwort$
>> 64    Case "g": untergrenze = versuch : Print "Okay, greater..."
>> 65    Case "s": obergrenze = versuch : Print "Okay, smaller..."
>> 66  End Select
>> 70  If antwort$ = "i" Then 90
>> 80 Loop Until antwort$ = "i"
>> 90 Print "I needed ";anzahl;" tries. I remain a math-champion!"
>>
>> FW
>
> What language is this program in?

It looks like a mashup of GWBASIC and QBasic. Some form of Microsoft BASIC 
anyway.
- GWBASIC: No "DO" or "SELECT CASE". Change the DO-LOOP to WHILE-WEND, and
  SELECT CASE to IF-ELSE, and it should work, but I'm not going to bother.
- QBasic: No line numbers inside SELECT CASE, but if you run it through
  REMLINE.BAS it works. (Also in FreeBASIC.)

It works in QB64 and Bywater BASIC if you use capital letters in the inputs. 
(Why capitals, I don't know.)

If you delete line 10 it works in Chipmunk Basic.

It *doesn't* work in BBS BASIC, PowerBASIC, PureBasic, or True Basic.

Also, line 70 is probably unnecessary. Just sayin'.

-- 
Don't take advice from fools.

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

#849

On 12/27/2023 5:17 PM, Auric__ wrote:
> Physfitfreak wrote:
> 
>> On 3/29/2023 8:27 AM, F. W. wrote:
>>> 10 Rem       *** Computer guesses your number ***
>>> 20 Print "Welcome to the guessing game!"
>>> 25 untergrenze = 1 : obergrenze = 0 : versuch = 0 : anzahl = 0
>>> 30 Input "To what maximal number will you guess";obergrenze
>>> 40 Do
>>> 42  versuch = untergrenze + Int((obergrenze - untergrenze) / 2)
>>> 43  anzahl = anzahl + 1
>>> 46  Print "Zwischen ";untergrenze;" und ";obergrenze
>>> 50  Print "I guess ";versuch
>>> 60  Input "g(reater, s(maller, i(t is it!";antwort$
>>> 63  Select Case antwort$
>>> 64    Case "g": untergrenze = versuch : Print "Okay, greater..."
>>> 65    Case "s": obergrenze = versuch : Print "Okay, smaller..."
>>> 66  End Select
>>> 70  If antwort$ = "i" Then 90
>>> 80 Loop Until antwort$ = "i"
>>> 90 Print "I needed ";anzahl;" tries. I remain a math-champion!"
>>>
>>> FW
>>
>> What language is this program in?
> 
> It looks like a mashup of GWBASIC and QBasic. Some form of Microsoft BASIC
> anyway.
> - GWBASIC: No "DO" or "SELECT CASE". Change the DO-LOOP to WHILE-WEND, and
>    SELECT CASE to IF-ELSE, and it should work, but I'm not going to bother.
> - QBasic: No line numbers inside SELECT CASE, but if you run it through
>    REMLINE.BAS it works. (Also in FreeBASIC.)
> 
> It works in QB64 and Bywater BASIC if you use capital letters in the inputs.
> (Why capitals, I don't know.)
> 
> If you delete line 10 it works in Chipmunk Basic.
> 
> It *doesn't* work in BBS BASIC, PowerBASIC, PureBasic, or True Basic.
> 
> Also, line 70 is probably unnecessary. Just sayin'.
> 


It doesn't compile in latest version of FreeBASIC; it would need 
declaration of the variables, to begin with.

Who would just post a BASIC program presumably for others to try, 
without specifying what flavor of BASIC it got compiled on? I think the 
poster wasn't serious about what he wanted to do.

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

#850

Physfitfreak wrote:

> On 12/27/2023 5:17 PM, Auric__ wrote:
>> Physfitfreak wrote:
>>
>>> On 3/29/2023 8:27 AM, F. W. wrote:
>>>> 10 Rem       *** Computer guesses your number ***
>>>> 20 Print "Welcome to the guessing game!"
>>>> 25 untergrenze = 1 : obergrenze = 0 : versuch = 0 : anzahl = 0
>>>> 30 Input "To what maximal number will you guess";obergrenze
>>>> 40 Do
>>>> 42  versuch = untergrenze + Int((obergrenze - untergrenze) / 2)
>>>> 43  anzahl = anzahl + 1
>>>> 46  Print "Zwischen ";untergrenze;" und ";obergrenze
>>>> 50  Print "I guess ";versuch
>>>> 60  Input "g(reater, s(maller, i(t is it!";antwort$
>>>> 63  Select Case antwort$
>>>> 64    Case "g": untergrenze = versuch : Print "Okay, greater..."
>>>> 65    Case "s": obergrenze = versuch : Print "Okay, smaller..."
>>>> 66  End Select
>>>> 70  If antwort$ = "i" Then 90
>>>> 80 Loop Until antwort$ = "i"
>>>> 90 Print "I needed ";anzahl;" tries. I remain a math-champion!"
>>>>
>>>> FW
>>>
>>> What language is this program in?
>>
>> It looks like a mashup of GWBASIC and QBasic. Some form of Microsoft
>> BASIC anyway.
>> - GWBASIC: No "DO" or "SELECT CASE". Change the DO-LOOP to WHILE-WEND,
>>   and SELECT CASE to IF-ELSE, and it should work, but I'm not going to
>>   bother.
>> - QBasic: No line numbers inside SELECT CASE, but if you run it through
>>   REMLINE.BAS it works. (Also in FreeBASIC

using '-lang qb' or '-lang fblite'.)

>> It works in QB64 and Bywater BASIC if you use capital letters in the
>> inputs. (Why capitals, I don't know.)
>>
>> If you delete line 10 it works in Chipmunk Basic.
>>
>> It *doesn't* work in BBS BASIC,

Whoops. BBC BASIC.

>> PowerBASIC, PureBasic, or True Basic.
>>
>> Also, line 70 is probably unnecessary. Just sayin'.
>
> It doesn't compile in latest version of FreeBASIC; it would need
> declaration of the variables, to begin with.

Sorry, oversight on my part, corrected above. (I don't use FB's dialect; my 
script to call fbc includes the appropriate -lang needed for the source.)

> Who would just post a BASIC program presumably for others to try,
> without specifying what flavor of BASIC it got compiled on? I think the
> poster wasn't serious about what he wanted to do.

Serious or otherwise, at least he tried. This group is effectively dead, 
along with most of Usenet, so [shrug]. Anyway, it's not like anyone else is 
posting code here. So here, code for a random BASIC dialect. Have fun.

/*
    Actual BASIC code for an actual BASIC compiler (including this comment).
    Good luck figuring out which one.
*/

SUB INTRAND(min as INT,max as INT),INT
    RETURN RAND(min,max)
ENDSUB

OPENCONSOLE
DO
    LOCATE INTRAND(1,25),INTRAND(1,80)
    PRINT "#"
UNTIL INKEY$ <> ""
CLOSECONSOLE
END

-- 
I still don't understand how he could possibly have survived.
He was on fire when I left him.

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

#851

On 12/29/2023 12:21 AM, Auric__ wrote:
> Physfitfreak wrote:
> 
>> On 12/27/2023 5:17 PM, Auric__ wrote:
>>> Physfitfreak wrote:
>>>
>>>> On 3/29/2023 8:27 AM, F. W. wrote:
>>>>> 10 Rem       *** Computer guesses your number ***
>>>>> 20 Print "Welcome to the guessing game!"
>>>>> 25 untergrenze = 1 : obergrenze = 0 : versuch = 0 : anzahl = 0
>>>>> 30 Input "To what maximal number will you guess";obergrenze
>>>>> 40 Do
>>>>> 42  versuch = untergrenze + Int((obergrenze - untergrenze) / 2)
>>>>> 43  anzahl = anzahl + 1
>>>>> 46  Print "Zwischen ";untergrenze;" und ";obergrenze
>>>>> 50  Print "I guess ";versuch
>>>>> 60  Input "g(reater, s(maller, i(t is it!";antwort$
>>>>> 63  Select Case antwort$
>>>>> 64    Case "g": untergrenze = versuch : Print "Okay, greater..."
>>>>> 65    Case "s": obergrenze = versuch : Print "Okay, smaller..."
>>>>> 66  End Select
>>>>> 70  If antwort$ = "i" Then 90
>>>>> 80 Loop Until antwort$ = "i"
>>>>> 90 Print "I needed ";anzahl;" tries. I remain a math-champion!"
>>>>>
>>>>> FW
>>>>
>>>> What language is this program in?
>>>
>>> It looks like a mashup of GWBASIC and QBasic. Some form of Microsoft
>>> BASIC anyway.
>>> - GWBASIC: No "DO" or "SELECT CASE". Change the DO-LOOP to WHILE-WEND,
>>>    and SELECT CASE to IF-ELSE, and it should work, but I'm not going to
>>>    bother.
>>> - QBasic: No line numbers inside SELECT CASE, but if you run it through
>>>    REMLINE.BAS it works. (Also in FreeBASIC
> 
> using '-lang qb' or '-lang fblite'.)
> 
>>> It works in QB64 and Bywater BASIC if you use capital letters in the
>>> inputs. (Why capitals, I don't know.)
>>>
>>> If you delete line 10 it works in Chipmunk Basic.
>>>
>>> It *doesn't* work in BBS BASIC,
> 
> Whoops. BBC BASIC.
> 
>>> PowerBASIC, PureBasic, or True Basic.
>>>
>>> Also, line 70 is probably unnecessary. Just sayin'.
>>
>> It doesn't compile in latest version of FreeBASIC; it would need
>> declaration of the variables, to begin with.
> 
> Sorry, oversight on my part, corrected above. (I don't use FB's dialect; my
> script to call fbc includes the appropriate -lang needed for the source.)
> 
>> Who would just post a BASIC program presumably for others to try,
>> without specifying what flavor of BASIC it got compiled on? I think the
>> poster wasn't serious about what he wanted to do.
> 
> Serious or otherwise, at least he tried. This group is effectively dead,
> along with most of Usenet, so [shrug]. Anyway, it's not like anyone else is
> posting code here. So here, code for a random BASIC dialect. Have fun.
> 
> /*
>      Actual BASIC code for an actual BASIC compiler (including this comment).
>      Good luck figuring out which one.
> */
> 
> SUB INTRAND(min as INT,max as INT),INT
>      RETURN RAND(min,max)
> ENDSUB
> 
> OPENCONSOLE
> DO
>      LOCATE INTRAND(1,25),INTRAND(1,80)
>      PRINT "#"
> UNTIL INKEY$ <> ""
> CLOSECONSOLE
> END
> 


You are way more proficient in BASIC than I am.

I knew BASIC and C (and FORTRAN) decades back. I've forgotten all that 
and need serious refreshing so I could write some simple programs for 
fun. I first chose BASIC thinking it would compile faster, but after I 
installed FreeBASIC and ran a few very simple codes I noticed that 
compiling was way too slow for me. So as of now, I'm aiming at 
refreshing of C++, not BASIC.

I understand that today's BASIC compilers first convert the codes to 
C++, then compile the newly created code using Windows supplied C++ 
compiler. This takes too long, and I suspect this has something to do 
with the decline of BASIC language today.

I remember how fast (or slow) compiling of BASIC code was decades back 
on DOS. They were much faster than today's compilers which first convert 
the code to C++.

Is there a way to compile BASIC code today, on Windows or Linux, without 
changing the code first to C++? I'd appreciate if I could get your input.

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

#855

Physfitfreak wrote:

[snip]

> You are way more proficient in BASIC than I am.

40 years will do that. It's what I use for most of my professional work.

> I knew BASIC and C (and FORTRAN) decades back. I've forgotten all that
> and need serious refreshing so I could write some simple programs for
> fun. I first chose BASIC thinking it would compile faster, but after I
> installed FreeBASIC and ran a few very simple codes I noticed that
> compiling was way too slow for me. So as of now, I'm aiming at
> refreshing of C++, not BASIC.

Modern C++ is very, very different than C "decades back". Might as well start 
from the beginning.

> I understand that today's BASIC compilers first convert the codes to
> C++, then compile the newly created code using Windows supplied C++
> compiler. This takes too long, and I suspect this has something to do
> with the decline of BASIC language today.

No, most do *not* compile to C++. Some interpret, some compile to some form 
of bytecode, and some compile to machine code (a.k.a. "normal" compiler). 
Offhand I can only think of 2 that compile to anything in the C family that 
are in active development: BCX (to C/C++) and B4X (to Java). FutureBASIC used 
to have a project called FBtoC that allowed Mac apps to be compiled with GCC, 
but that appears to be dead. Other BASIC-to-C-ish translators exist, but most 
suck, and the ones that don't are generally dead.

(Also, Windows doesn't include any compilers by default.)

> I remember how fast (or slow) compiling of BASIC code was decades back
> on DOS. They were much faster than today's compilers which first convert
> the code to C++.
>
> Is there a way to compile BASIC code today, on Windows or Linux, without
> changing the code first to C++? I'd appreciate if I could get your input.

Compilation speed should not be something that determines your usage of a 
language, unless we're talking "hours" (or longer); runtime speed is far more 
important. Here's what I currently use for various projects:

- Visual Basic 2022: Free-ish. Compiles to .Net bytecode. Theoretically, apps
  can run on Linux and Mac (using the Mono runtime), but realistically, it's
  Windows-only. Not really the same as classic VB, but it gets the job done.
  Note that the IDE can be slow to open, especially on older machines. (I
  also still use VB6 for some things, and a lot of VBA under Excel, because
  of course I do.)
- PowerBASIC: Commercial. Windows-only, 32-bit only. (A DOS version is
  available but hasn't been updated in a couple decades.) Fast compile times,
  fastest runtimes I've seen for BASIC on Windows. GUI and CLI compilers are
  separate products, so [shrug]. My preferred BASIC for 32-bit development.
- FreeBASIC: Open Source. You know about this one, apparently.
- Chipmunk Basic: Free. Interpreter. Mainly for Mac but also has Windows,
  Linux, and Raspberry Pi versions.
- Xojo: Commercial. Windows, Mac, and Linux; also compiles for Raspberry Pi,
  iOS, Android, and web, if you get the Pro version. (Raspberry Pi-only
  appears to be free; unsure.)
- B4J: Free. Windows. Part of B4X, this is the one for desktop systems. There
  is also B4A for Android development, B4R for Arduino, and B4I, the
  company's only commercial product, for iOS. (This started as Basic4PPC,
  compiling for PocketPC, Microsoft's competitor to Palm Pilot, about a
  thousand years ago.) Very similar to VB.Net.
- App Game Kit: Commercial. Windows only, I believe. Compiles to its own
  bytecode, requires an interpreter (a "player"), which is available for
  Windows, Mac, Linux, Android, and iOS. Graphical/3D modes only, no windowed
  or CLI modes.

I've also tinkered with various other BASICs, including BBC BASIC (various), 
PureBasic (commercial, free for Amiga), True BASIC (commercial), QB64 (open 
source), XBASIC/XBLite (open source), Liberty Basic (commercial), and, well, 
a bunch of others you've probably never heard of. I either didn't like their 
dialects of BASIC, or else I didn't like something else about them, so I 
didn't stick with any of them.

The one I specifically recommend *against* is Objective-Basic for the Mac, 
from the same guy who created Kbasic, as the free version forces you to GPL3 
your own source code to stay within its own licensing rules. (Also, it hasn't 
been updated since 2012, so it's Intel-only, no Apple Silicon.)

-- 
...and in her self-loathing and despair she found wrath.

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

#858

On 12/31/2023 1:18 PM, Auric__ wrote:
> Compilation speed should not be something that determines your usage of a
> language, unless we're talking "hours" (or longer); runtime speed is far more
> important.


Actually in my particular case it is the compilation speed that bothers 
me, not the execution speed. In the course of writing the codes I have 
to compile many many times to remove bugs and correct my mistakes, etc, 
while after all issues are gone, I would have to wait just once for each 
run of the executable file. There would be no hurry there.

For a two line code in FreeBASIC, I have to wait 30 seconds for it to 
compile and run... This is way too slow. Imagine when I want to write a 
relatively involved program how many times and how long I have to wait 
to do the troubleshooting.

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

#860

In article <un2hrq$o1sd$4@solani.org>,
Physfitfreak  <Physfitfreak@gmail.com> wrote:
>On 12/31/2023 1:18 PM, Auric__ wrote:
>> Compilation speed should not be something that determines your usage of a
>> language, unless we're talking "hours" (or longer); runtime speed is far more
>> important.
>
>
>Actually in my particular case it is the compilation speed that bothers 
>me, not the execution speed. In the course of writing the codes I have 
>to compile many many times to remove bugs and correct my mistakes, etc, 
>while after all issues are gone, I would have to wait just once for each 
>run of the executable file. There would be no hurry there.
>
>For a two line code in FreeBASIC, I have to wait 30 seconds for it to 
>compile and run... This is way too slow. Imagine when I want to write a 
>relatively involved program how many times and how long I have to wait 
>to do the troubleshooting.

One of the joys of BASIC is the instant "always-on" nature of it. Or was.
It is interactive, fast (relatively speaking) and right there. Or should
be (IMO).  Then people started to get clever and compile it and add all
sorts of things to it like having to declare variables and so on.

I'm really surprised that FreeBASIC taks 30 seconds to compile a few lines
though.

Gordon

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

#861

Physfitfreak wrote:

> On 12/31/2023 1:18 PM, Auric__ wrote:
>> Compilation speed should not be something that determines your usage of
>> a language, unless we're talking "hours" (or longer); runtime speed is
>> far more important.
>
> Actually in my particular case it is the compilation speed that bothers
> me, not the execution speed. In the course of writing the codes I have
> to compile many many times to remove bugs and correct my mistakes, etc,
> while after all issues are gone, I would have to wait just once for each
> run of the executable file. There would be no hurry there.
>
> For a two line code in FreeBASIC, I have to wait 30 seconds for it to
> compile and run... This is way too slow. Imagine when I want to write a
> relatively involved program how many times and how long I have to wait
> to do the troubleshooting.

That's... odd. What OS? What hardware?

I'm running Windows 10 Pro 22H2 on a 10-year-old Intel i5 @ 3.2 GHz, using 
the current release of FreeBASIC (1.10.1, released Xmas Eve), and this test 
program:

  dim a as long
    for a = 1 to 255
    print bin$(a),""
  next

...takes about 2-3 seconds to compile for both the 32-bit and 64-bit 
versions. The same goes for the DOS version under DOSBox-X. (I don't have it 
installed on other systems to check, but I imagine it would be about the 
same.) So, something must be... uh... "different" about your setup.


As an aside, if I'm writing for a system like FreeBASIC that doesn't have a 
built-in interpreter or some fast way to do test runs, I usually write in a 
system that *does* -- often Qbasic or Chipmunk Basic -- and then when the 
program works, I make whatever edits are needed to make it work in my chosen 
system and *then* do the actual compile.

-- 
Almost everything here made it here because somebody managed to come
up with some new bad idea that we hadn't previously anticipated.

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

#862

On 1/3/2024 3:16 PM, Auric__ wrote:
> Physfitfreak wrote:
> 
>> On 12/31/2023 1:18 PM, Auric__ wrote:
>>> Compilation speed should not be something that determines your usage of
>>> a language, unless we're talking "hours" (or longer); runtime speed is
>>> far more important.
>>
>> Actually in my particular case it is the compilation speed that bothers
>> me, not the execution speed. In the course of writing the codes I have
>> to compile many many times to remove bugs and correct my mistakes, etc,
>> while after all issues are gone, I would have to wait just once for each
>> run of the executable file. There would be no hurry there.
>>
>> For a two line code in FreeBASIC, I have to wait 30 seconds for it to
>> compile and run... This is way too slow. Imagine when I want to write a
>> relatively involved program how many times and how long I have to wait
>> to do the troubleshooting.
> 
> That's... odd. What OS? What hardware?
> 
> I'm running Windows 10 Pro 22H2 on a 10-year-old Intel i5 @ 3.2 GHz, using
> the current release of FreeBASIC (1.10.1, released Xmas Eve), and this test
> program:
> 
>    dim a as long
>      for a = 1 to 255
>      print bin$(a),""
>    next
> 
> ...takes about 2-3 seconds to compile for both the 32-bit and 64-bit
> versions. The same goes for the DOS version under DOSBox-X. (I don't have it
> installed on other systems to check, but I imagine it would be about the
> same.) So, something must be... uh... "different" about your setup.
> 
> 
> As an aside, if I'm writing for a system like FreeBASIC that doesn't have a
> built-in interpreter or some fast way to do test runs, I usually write in a
> system that *does* -- often Qbasic or Chipmunk Basic -- and then when the
> program works, I make whatever edits are needed to make it work in my chosen
> system and *then* do the actual compile.
> 


Yes, I thought so too that something was wrong with my set up but I 
couldn't find what. My system is old also. I am using Win10 Enterprise 
64 bit on S20 ThinkStation (Xeon x5675, 20 gb RAM). I installed 
FreeBASIC 1.10.1-win64 and for GUI installed FBIde 0.4.6r4.

Wikipedia says FreeBASIC converts the code to C++ then compiles C++. I 
was thinking this conversion of code is what makes it take that long.

I'll try Qbasic to see how it goes.

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

#864

Physfitfreak wrote:

> On 1/3/2024 3:16 PM, Auric__ wrote:
[snip]
>> That's... odd. What OS? What hardware?
>>
>> I'm running Windows 10 Pro 22H2 on a 10-year-old Intel i5 @ 3.2 GHz,
>> using the current release of FreeBASIC (1.10.1, released Xmas Eve), and
>> this test program:
>>
>>    dim a as long
>>      for a = 1 to 255
>>      print bin$(a),""
>>    next
>>
>> ...takes about 2-3 seconds to compile for both the 32-bit and 64-bit
>> versions. The same goes for the DOS version under DOSBox-X. (I don't
>> have it installed on other systems to check, but I imagine it would be
>> about the same.) So, something must be... uh... "different" about your
>> setup.
>>
>>
>> As an aside, if I'm writing for a system like FreeBASIC that doesn't
>> have a built-in interpreter or some fast way to do test runs, I usually
>> write in a system that *does* -- often Qbasic or Chipmunk Basic -- and
>> then when the program works, I make whatever edits are needed to make
>> it work in my chosen system and *then* do the actual compile.
>
> Yes, I thought so too that something was wrong with my set up but I
> couldn't find what. My system is old also. I am using Win10 Enterprise
> 64 bit on S20 ThinkStation (Xeon x5675, 20 gb RAM). I installed
> FreeBASIC 1.10.1-win64 and for GUI installed FBIde 0.4.6r4.

Hm. I couldn't even begin to guess what the issue might be. I don't use any 
of the FB IDEs; I typically either use Qbasic or an old version of 
UltraEdit.

> Wikipedia says FreeBASIC converts the code to C++ then compiles C++. I
> was thinking this conversion of code is what makes it take that long.

Ah, I see. FreeBASIC has the *option* to compile to something C-ish, but the 
*default* is to compile to assembly, either x86 or x86-64, depending on the 
platform. (I was unaware of the ability to compile to C, so apologies for 
any confusion caused.) See this page for info:

  https://www.freebasic.net/wiki/CompilerOptgen

> I'll try Qbasic to see how it goes.

Just remember, Qbasic has limitations that don't exist in FB; notably, the 
DIR$ function doesn't exist, requiring some... interesting workarounds. In 
fact, here's what I use:

-----
  FUNCTION DIR$ (what AS STRING)
    ' usage:
    '   pass in the filespec you want: DIR$("*.*")
    '   for subsequent files, pass an empty string: DIR$("")
    ' returns:
    '   one filename per call
    '   if file not found, or end of list, returns empty string: ""
    '   ALWAYS includes hidden, system, and read-only files
    '   NEVER includes directories
    '   (could be modified to change either of the above)

    STATIC found() AS STRING
    STATIC fcount AS INTEGER
    STATIC fdnum AS INTEGER
    STATIC thisfile AS INTEGER
    DIM tmpfile AS STRING, tmpstr1 AS STRING, tmpint1 AS INTEGER

    IF LEN(what) THEN   ' new filespec; rebuild list
      fcount = -1
      thisfile = -1
      IF LEN(tmpfile) THEN KILL tmpfile
      tmpfile = ENVIRON$("TEMP")
      IF LEN(tmpfile) THEN IF RIGHT$(tmpfile, 1) <> "\" THEN _
            tmpfile = tmpfile + "\"
      tmpfile = tmpfile + LTRIM$(STR$(CLNG(TIMER * 100))) + ".tmp"
      IF LEN(ENVIRON$("COMSPEC")) THEN
        SHELL ENVIRON$("COMSPEC") + " /c dir /a-d /b " + what + " > " + _
            tmpfile
      ELSE
        SHELL "command.com /c dir /a-d /b " + what + " > " + tmpfile
      END IF
      fdnum = FREEFILE
      OPEN tmpfile FOR INPUT AS fdnum
        DO UNTIL EOF(fdnum)
          fcount = fcount + 1
          LINE INPUT #fdnum, tmpstr1
        LOOP
      CLOSE fdnum

      IF fcount > -1 THEN
        REDIM found(fcount) AS STRING

        OPEN tmpfile FOR INPUT AS fdnum
          FOR tmpint1 = 0 TO fcount
            LINE INPUT #fdnum, found(tmpint1)
          NEXT
        CLOSE fdnum
      END IF

      KILL tmpfile
    END IF

    IF fcount > -1 THEN
      thisfile = thisfile + 1
      IF thisfile > fcount THEN
        DIR$ = ""
      ELSE
        DIR$ = found(thisfile)
      END IF
    ELSE
      DIR$ = ""
      KILL tmpfile
    END IF
  END FUNCTION
-----

Public domain. Feel free to use or change as desired. Under non-Win/DOS 
systems it would need to be changed to invoke 'ls' instead of 'dir' (or 
whatever equivalent works) and change '\' to '/' (or whatever character the 
system uses to indicate directories) but otherwise should work.

(An alternate method I just thought of would involve calling 'attrib' 
instead of 'dir'. Something for future experimentation, I suppose.)

-- 
- What would that imply?
- I dunno.

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

#865

On 1/4/2024 4:09 PM, Auric__ wrote:
> Physfitfreak wrote:
> 
>> On 1/3/2024 3:16 PM, Auric__ wrote:
> [snip]
>>> That's... odd. What OS? What hardware?
>>>
>>> I'm running Windows 10 Pro 22H2 on a 10-year-old Intel i5 @ 3.2 GHz,
>>> using the current release of FreeBASIC (1.10.1, released Xmas Eve), and
>>> this test program:
>>>
>>>     dim a as long
>>>       for a = 1 to 255
>>>       print bin$(a),""
>>>     next
>>>
>>> ...takes about 2-3 seconds to compile for both the 32-bit and 64-bit
>>> versions. The same goes for the DOS version under DOSBox-X. (I don't
>>> have it installed on other systems to check, but I imagine it would be
>>> about the same.) So, something must be... uh... "different" about your
>>> setup.
>>>
>>>
>>> As an aside, if I'm writing for a system like FreeBASIC that doesn't
>>> have a built-in interpreter or some fast way to do test runs, I usually
>>> write in a system that *does* -- often Qbasic or Chipmunk Basic -- and
>>> then when the program works, I make whatever edits are needed to make
>>> it work in my chosen system and *then* do the actual compile.
>>
>> Yes, I thought so too that something was wrong with my set up but I
>> couldn't find what. My system is old also. I am using Win10 Enterprise
>> 64 bit on S20 ThinkStation (Xeon x5675, 20 gb RAM). I installed
>> FreeBASIC 1.10.1-win64 and for GUI installed FBIde 0.4.6r4.
> 
> Hm. I couldn't even begin to guess what the issue might be. I don't use any
> of the FB IDEs; I typically either use Qbasic or an old version of
> UltraEdit.
> 
>> Wikipedia says FreeBASIC converts the code to C++ then compiles C++. I
>> was thinking this conversion of code is what makes it take that long.
> 
> Ah, I see. FreeBASIC has the *option* to compile to something C-ish, but the
> *default* is to compile to assembly, either x86 or x86-64, depending on the
> platform. (I was unaware of the ability to compile to C, so apologies for
> any confusion caused.) See this page for info:
> 
>    https://www.freebasic.net/wiki/CompilerOptgen
> 
>> I'll try Qbasic to see how it goes.
> 
> Just remember, Qbasic has limitations that don't exist in FB; notably, the
> DIR$ function doesn't exist, requiring some... interesting workarounds. In
> fact, here's what I use:
> 
> -----
>    FUNCTION DIR$ (what AS STRING)
>      ' usage:
>      '   pass in the filespec you want: DIR$("*.*")
>      '   for subsequent files, pass an empty string: DIR$("")
>      ' returns:
>      '   one filename per call
>      '   if file not found, or end of list, returns empty string: ""
>      '   ALWAYS includes hidden, system, and read-only files
>      '   NEVER includes directories
>      '   (could be modified to change either of the above)
> 
>      STATIC found() AS STRING
>      STATIC fcount AS INTEGER
>      STATIC fdnum AS INTEGER
>      STATIC thisfile AS INTEGER
>      DIM tmpfile AS STRING, tmpstr1 AS STRING, tmpint1 AS INTEGER
> 
>      IF LEN(what) THEN   ' new filespec; rebuild list
>        fcount = -1
>        thisfile = -1
>        IF LEN(tmpfile) THEN KILL tmpfile
>        tmpfile = ENVIRON$("TEMP")
>        IF LEN(tmpfile) THEN IF RIGHT$(tmpfile, 1) <> "\" THEN _
>              tmpfile = tmpfile + "\"
>        tmpfile = tmpfile + LTRIM$(STR$(CLNG(TIMER * 100))) + ".tmp"
>        IF LEN(ENVIRON$("COMSPEC")) THEN
>          SHELL ENVIRON$("COMSPEC") + " /c dir /a-d /b " + what + " > " + _
>              tmpfile
>        ELSE
>          SHELL "command.com /c dir /a-d /b " + what + " > " + tmpfile
>        END IF
>        fdnum = FREEFILE
>        OPEN tmpfile FOR INPUT AS fdnum
>          DO UNTIL EOF(fdnum)
>            fcount = fcount + 1
>            LINE INPUT #fdnum, tmpstr1
>          LOOP
>        CLOSE fdnum
> 
>        IF fcount > -1 THEN
>          REDIM found(fcount) AS STRING
> 
>          OPEN tmpfile FOR INPUT AS fdnum
>            FOR tmpint1 = 0 TO fcount
>              LINE INPUT #fdnum, found(tmpint1)
>            NEXT
>          CLOSE fdnum
>        END IF
> 
>        KILL tmpfile
>      END IF
> 
>      IF fcount > -1 THEN
>        thisfile = thisfile + 1
>        IF thisfile > fcount THEN
>          DIR$ = ""
>        ELSE
>          DIR$ = found(thisfile)
>        END IF
>      ELSE
>        DIR$ = ""
>        KILL tmpfile
>      END IF
>    END FUNCTION
> -----
> 
> Public domain. Feel free to use or change as desired. Under non-Win/DOS
> systems it would need to be changed to invoke 'ls' instead of 'dir' (or
> whatever equivalent works) and change '\' to '/' (or whatever character the
> system uses to indicate directories) but otherwise should work.
> 
> (An alternate method I just thought of would involve calling 'attrib'
> instead of 'dir'. Something for future experimentation, I suppose.)
> 


I'll try that after I manage to run qbasic. Looks like on win10 I should 
download and install VMWare Workstation Player, and then use that to 
download and install Qbasic. But everytime I download VMware Workstation 
Player, right after download is done the file disappears and browser 
closes and instead of a downloaded ready to use file I see a file named:

Unconfirmed 937735.crdownload

What is slightly larger than the file I downloaded and useless to me. I 
don't know what the deal is with VMWare Workstation Player.

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

#866

Physfitfreak wrote:

> I'll try that after I manage to run qbasic.

Note that the code I posted is only for MSBASIC-alikes without an equivalent 
to DIR$. Under FreeBASIC it probably won't work due to name collision with 
the built-in function.

> Looks like on win10 I should
> download and install VMWare Workstation Player, and then use that to
> download and install Qbasic. But everytime I download VMware Workstation
> Player, right after download is done the file disappears and browser
> closes and instead of a downloaded ready to use file I see a file named:
>
> Unconfirmed 937735.crdownload
>
> What is slightly larger than the file I downloaded and useless to me. I
> don't know what the deal is with VMWare Workstation Player.

No, don't bother. I suggest using DOSBox or one of its derivatives instead. I 
use DOSBox-X:

  https://dosbox-x.com/

...but note that it doesn't come with QBasic. *That* you'll need to get from 
elsewhere; I recommend WinWorldPC:

  https://winworldpc.com/product/qbasic/1x

Extract the downloaded .7z to any folder on your system and run qbasic.exe in 
your emulator of choice.

(Note also that this only applies to 64-bit versions of Windows (and non-
Windows systems); 32-bit Windows 10 should be able to run DOS programs 
without issue.)

-- 
That boy ain't right.

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

#867

On 1/6/2024 1:30 PM, Auric__ wrote:
> Physfitfreak wrote:
> 
>> I'll try that after I manage to run qbasic.
> 
> Note that the code I posted is only for MSBASIC-alikes without an equivalent
> to DIR$. Under FreeBASIC it probably won't work due to name collision with
> the built-in function.
> 
>> Looks like on win10 I should
>> download and install VMWare Workstation Player, and then use that to
>> download and install Qbasic. But everytime I download VMware Workstation
>> Player, right after download is done the file disappears and browser
>> closes and instead of a downloaded ready to use file I see a file named:
>>
>> Unconfirmed 937735.crdownload
>>
>> What is slightly larger than the file I downloaded and useless to me. I
>> don't know what the deal is with VMWare Workstation Player.
> 
> No, don't bother. I suggest using DOSBox or one of its derivatives instead. I
> use DOSBox-X:
> 
>    https://dosbox-x.com/
> 
> ...but note that it doesn't come with QBasic. *That* you'll need to get from
> elsewhere; I recommend WinWorldPC:
> 
>    https://winworldpc.com/product/qbasic/1x
> 
> Extract the downloaded .7z to any folder on your system and run qbasic.exe in
> your emulator of choice.
> 
> (Note also that this only applies to 64-bit versions of Windows (and non-
> Windows systems); 32-bit Windows 10 should be able to run DOS programs
> without issue.)
> 


I downloaded and installed DOSBox-X, then got QBasic 1.0 from 
winworldpc.com in the form of one disk image file. Tried to undisk it 
but I keep getting there's no room in Z: drive. Qbasic.exe is only about 
250 KB, it's help file is about half the size, and the image file is 
about 1.5 megs. So I don't know why it runs out of space in that virtual 
DOS.

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

#868

Physfitfreak wrote:

> On 1/6/2024 1:30 PM, Auric__ wrote:
[snip]
>> No, don't bother. I suggest using DOSBox or one of its derivatives
>> instead. I use DOSBox-X:
>>
>>    https://dosbox-x.com/
>>
>> ...but note that it doesn't come with QBasic. *That* you'll need to get
>> from elsewhere; I recommend WinWorldPC:
>>
>>    https://winworldpc.com/product/qbasic/1x
>>
>> Extract the downloaded .7z to any folder on your system and run
>> qbasic.exe in your emulator of choice.
>>
>> (Note also that this only applies to 64-bit versions of Windows (and
>> non-Windows systems); 32-bit Windows 10 should be able to run DOS
>> programs without issue.)
>
> I downloaded and installed DOSBox-X, then got QBasic 1.0 from
> winworldpc.com in the form of one disk image file. Tried to undisk it
> but I keep getting there's no room in Z: drive. Qbasic.exe is only about
> 250 KB, it's help file is about half the size, and the image file is
> about 1.5 megs. So I don't know why it runs out of space in that virtual
> DOS.

Extract the disk image to a folder (I suggest a new one), mount that folder 
as the C: drive, and then try again from there.

-- 
- So you seek revenge?
- I seek righteousness. But I'll take revenge.

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

#869

On 1/7/2024 9:21 PM, Auric__ wrote:
> Physfitfreak wrote:
> 
>> On 1/6/2024 1:30 PM, Auric__ wrote:
> [snip]
>>> No, don't bother. I suggest using DOSBox or one of its derivatives
>>> instead. I use DOSBox-X:
>>>
>>>     https://dosbox-x.com/
>>>
>>> ...but note that it doesn't come with QBasic. *That* you'll need to get
>>> from elsewhere; I recommend WinWorldPC:
>>>
>>>     https://winworldpc.com/product/qbasic/1x
>>>
>>> Extract the downloaded .7z to any folder on your system and run
>>> qbasic.exe in your emulator of choice.
>>>
>>> (Note also that this only applies to 64-bit versions of Windows (and
>>> non-Windows systems); 32-bit Windows 10 should be able to run DOS
>>> programs without issue.)
>>
>> I downloaded and installed DOSBox-X, then got QBasic 1.0 from
>> winworldpc.com in the form of one disk image file. Tried to undisk it
>> but I keep getting there's no room in Z: drive. Qbasic.exe is only about
>> 250 KB, it's help file is about half the size, and the image file is
>> about 1.5 megs. So I don't know why it runs out of space in that virtual
>> DOS.
> 
> Extract the disk image to a folder (I suggest a new one), mount that folder
> as the C: drive, and then try again from there.
> 


Ok, now I have a working qbasic. But when I write a code with it, it 
can't be copied and kept on computer! Does one have to use another 
editor to develop a program and for testing insert it (if it can be 
done!) inside qbasic screen? This is cumbersome.

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

#870

On 1/26/2024 7:03 PM, Physfitfreak wrote:
> On 1/7/2024 9:21 PM, Auric__ wrote:
>> Physfitfreak wrote:
>>
>>> On 1/6/2024 1:30 PM, Auric__ wrote:
>> [snip]
>>>> No, don't bother. I suggest using DOSBox or one of its derivatives
>>>> instead. I use DOSBox-X:
>>>>
>>>>     https://dosbox-x.com/
>>>>
>>>> ...but note that it doesn't come with QBasic. *That* you'll need to get
>>>> from elsewhere; I recommend WinWorldPC:
>>>>
>>>>     https://winworldpc.com/product/qbasic/1x
>>>>
>>>> Extract the downloaded .7z to any folder on your system and run
>>>> qbasic.exe in your emulator of choice.
>>>>
>>>> (Note also that this only applies to 64-bit versions of Windows (and
>>>> non-Windows systems); 32-bit Windows 10 should be able to run DOS
>>>> programs without issue.)
>>>
>>> I downloaded and installed DOSBox-X, then got QBasic 1.0 from
>>> winworldpc.com in the form of one disk image file. Tried to undisk it
>>> but I keep getting there's no room in Z: drive. Qbasic.exe is only about
>>> 250 KB, it's help file is about half the size, and the image file is
>>> about 1.5 megs. So I don't know why it runs out of space in that virtual
>>> DOS.
>>
>> Extract the disk image to a folder (I suggest a new one), mount that 
>> folder
>> as the C: drive, and then try again from there.
>>
> 
> 
> Ok, now I have a working qbasic. But when I write a code with it, it 
> can't be copied and kept on computer! Does one have to use another 
> editor to develop a program and for testing insert it (if it can be 
> done!) inside qbasic screen? This is cumbersome.


When trying to save a file it gives, "Path / File access error". Also, 
it cannot be copied from screen (ctrl-C) and saved elsewhere in another 
editor,  so one can then save the work.

What am I doing wrong?

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

#871

Physfitfreak wrote:

> On 1/26/2024 7:03 PM, Physfitfreak wrote:
[snip]
>> Ok, now I have a working qbasic. But when I write a code with it, it
>> can't be copied and kept on computer! Does one have to use another
>> editor to develop a program and for testing insert it (if it can be
>> done!) inside qbasic screen? This is cumbersome.

No clue. The IDE just works for me as expected, including writing files to 
the computer's hard drive (not just the emulated drive).

> When trying to save a file it gives, "Path / File access error". Also,
> it cannot be copied from screen (ctrl-C) and saved elsewhere in another
> editor,  so one can then save the work.
>
> What am I doing wrong?

Keyboard combos are specific to whatever DOS app is running at the moment, 
and will only work inside the emulated DOS system. You can copy the entire 
screen to the Windows clipboard by pressing Ctrl+F5, and then paste it 
somewhere else (but note that EVERYTHING on screen gets copied).

Otherwise I have no idea what's wrong. Without sitting at your computer I 
couldn't even begin to guess what's wrong. The way I told you to do it is 
really, really different from my normal (unsafe) methods. Maybe my methods 
aren't right for you. Shrug. Sorry.

-- 
Oooh, spooky! You get to be a corporate drone.

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

#852

In article <u01ec6$55qd$18@dont-email.me>, F. W. <me@home.com> wrote:
>10 Rem       *** Computer guesses your number ***
>20 Print "Welcome to the guessing game!"
>25 untergrenze = 1 : obergrenze = 0 : versuch = 0 : anzahl = 0
>30 Input "To what maximal number will you guess";obergrenze
>40 Do
>42  versuch = untergrenze + Int((obergrenze - untergrenze) / 2)
>43  anzahl = anzahl + 1
>46  Print "Zwischen ";untergrenze;" und ";obergrenze
>50  Print "I guess ";versuch
>60  Input "g(reater, s(maller, i(t is it!";antwort$
>63  Select Case antwort$
>64    Case "g": untergrenze = versuch : Print "Okay, greater..."
>65    Case "s": obergrenze = versuch : Print "Okay, smaller..."
>66  End Select
>70  If antwort$ = "i" Then 90
>80 Loop Until antwort$ = "i"
>90 Print "I needed ";anzahl;" tries. I remain a math-champion!"

Lovely....

Still a BASIC fan after all these years, just recently wrote a new
TinyBasic for the 6502 CPU too... Because why not. It runs well with 4K
of ROM and 4K of RAM....

Translation to my TinyBasic:

>LIST
   10 REM I Guess a number...
   20 PR "Welcome to the guessing game."
   25 PR "What's the upper limit ";
   30 C = 0 : L = 1 : INPUT H
   35 PR "Great. Think of a number from 1 to ", H, " and lets go..."
   40 C = C + 1 : G = (H + L) / 2
   50 PR "I guess: ", G
   60 PR "Am I Higher, Lower or = ? ";
   70 Y = GET
   80 IF (Y = 72) OR (Y = 104) GOTO 100 : REM Higher
   90 IF (Y = 76) OR (Y = 108) GOTO 200 : REM Lower
   94 IF Y = 61 GOTO 300
   99 PR "Huh?" : GOTO 50
  100 PR "Higher, so ..."
  110 H = G
  120 GOTO 40
  200 PR "Lower, so ..."
  210 L = G
  220 GOTO 40
  300 PR "Equals!"
  310 PR "I got it right in ", C, " guesses."
  320 END


>RUN
Welcome to the guessing game.
What's the upper limit ?100
Great. Think of a number from 1 to 100 and lets go...
I guess: 50
Am I Higher, Lower or = ? Huh?
I guess: 50
Am I Higher, Lower or = ? Higher, so ...
I guess: 25
Am I Higher, Lower or = ? Lower, so ...
I guess: 37
Am I Higher, Lower or = ? Lower, so ...
I guess: 43
Am I Higher, Lower or = ? Higher, so ...
I guess: 40
Am I Higher, Lower or = ? Lower, so ...
I guess: 41
Am I Higher, Lower or = ? Lower, so ...
I guess: 42
Am I Higher, Lower or = ? Equals!
I got it right in 7 guesses.


How those old memories come flooding back... ;-)

Cheers,

-Gordon

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.lang.basic

csiph-web