Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Dimster

Pages: [1] 2 3 ... 34
1
QB64 Discussion / Re: SEEK # or not SEEK #
« on: April 15, 2022, 02:29:26 pm »
Thanks guys but I thought I could OPEN a file with data stored sequentially or even randomly with any file number I wanted. I will often store data multiple files with negative values or multiple files with positive values and the subsequent OPEN uses either an even number for the file for the positive data and an odd number for the negative data. I could for example OPEN file #33 and file #52 with no problems at all. The vast majority of the time the files are OPEN for INPUT and the subsequent INPUT #33 and INPUT #52 has worked without problems. I hadn't realized that the file number was an issue with a Seek statement.

I forgot about RANDOM. I don't work a lot with Random but when I did, I thought the data had to be stored as Random and then retrieved as Random. That being said however, I don't work a lot with Seek either but was pretty sure it should have worked with sequentially stored data and what I was trying to do was reset my Inputs back to the beginning of the file (Seek (1)) and then For Loop to the data I want to work with. But I gather Seek works only with Random??

The other thing that has me puzzled is the Seek statement itself. I believe I use to be able to write Seek #32, 1 but the wiki seems to have that 2nd Seek in the statement ..SEEK 32, SEEK(1) and it has dropped the use of the "#"

2
QB64 Discussion / SEEK # or not SEEK #
« on: April 15, 2022, 12:02:52 pm »
Running into a bad file name or number error message when using Seek on a sequential file and not sure why.

Open "d:/SequentialFile1" for INPUT as #52
Seek #52, Seek(1)

The above is generating the error message. I have checked the name of the file I'm trying to open, and that the file is indeed on my "d" drive, also that the same opening statement works with Input #52.

I checked the wiki and the example it provides drops the "#" . The wiki has the seek statement as SEEK 1, Seek(1) ( ie there is no "#").

I'm not sure which is the correct statement but no matter, both with or without the "#" I'm getting the error message. I have also tried to be sure the file I'm trying to access is Closed before the Opening statement.

Any idea's on what I could be doing wrong, and which to the two Seek statements is the correct one?

Thanks

3
QB64 Discussion / Re: Errors because some DOUBLE PRECISION numbers are wrong
« on: April 09, 2022, 06:17:12 pm »
Quote
Dr. Kerr designed a laser instrument for measuring the height of volcanoes and the depth of valleys and rifts on Mars.  The finished instrument, the Mars Global Surveyor, is still orbiting Mars.  It was the first successful use of a laser beyond the orbit of the Moon.  Thanks to the instrument our contour maps of Mars are better than the ones we have of the Earth.  Another instrument like the first mapped the Asteroid Eros and reposes on it.  A third instrument is aboard the MESSENGER mission to Mercury.  The Japan Aerospace Exploration Agency put a similar instrument on the Hayabusa space probe, which recently returned rock samples from the Asteroid Itokawa.

N. A. S. A. awarded Dr. Kerr a prize for his design of a telescope (shown at right) adapted to receive laser communications from space probes going to Jupiter, Uranus, and Neptune, into the Kuiper Belt as far as 35 times the distance to Pluto, or beyond.  The telescope will be one of the largest in the world.


That's pretty cool.

4
QB64 Discussion / Re: QB64 Bounty List
« on: April 09, 2022, 11:00:43 am »
Oh, so all the changes I would commission would only apply to me ... couldn't share my creations with others UNLESS the proposed change would go through an approval process???

5
QB64 Discussion / Re: QB64 Bounty List
« on: April 09, 2022, 10:24:39 am »
Do you feel Steve that there may be some unintended consequences if each person in our community commissions changes to satisfy a pet peeve?
I have tons of frustrations with my coding, or my lack of creative imagination to work with what is already there in the Basic language. So I tend to turn to the wiki or this community to help get me back to basics. I'm thinking a bounty to change/add/alter for my person massage of the language could make the wiki info outdated and unreliable, and if I pay enough money it would lead to a break in the backward compatibility. I know you have an easy fix to the consequence of wiki update and backward compatibility .... pay a bigger bounty to undo everything the Dimster has commissioned.

6
QB64 Discussion / Re: ElseIF v's Or
« on: April 07, 2022, 09:37:14 am »
The main difference is the logical comparison between two conditional statements v's the logical comparison between the value in two variables. It's also a more natural way in which logic is processed while theorizing. If you know, in the run of your program, that A "will" reach 101 then you can write code to deal with that condition. But if you have no idea if it will generate a value of 101 then you write code to "IF" it reaches 101. The code to deal with that condition could be the same but if 101 is a complete surprise then you may want to do something more.

I can see from your perspective that a logical operator between two concrete values can cover a lot of scenarios where the IF becomes redundant. After all, whether the 101 is expected or a surprise code can be developed to deal with the result ... So I guess we chalk this up to another one of those dumb questions.

7
QB64 Discussion / Re: ElseIF v's Or
« on: April 07, 2022, 08:38:08 am »
I see it Steve , but my conundrum is a decisional statement following a logical operator. Mostly the decisional statement is an IF statement (I haven't tried it with a Select Case statement). But it seems logical to me to pose the formula

 if A=B or IF A=C then ...

if A=B and if A=C then ..

Brackets don't work either ..(if A=B) or (if A=C) then ..

I suppose Elseif could be considered a substitute for OR or AND but when it comes right down to it, Elseif is conditional and not logical. I do realize you can use logical operators within an IF statement ..If A=B or A=C then ... works fine but no go between two if statements.

8
QB64 Discussion / Re: ElseIF v's Or
« on: April 06, 2022, 05:41:40 pm »
In your example would you get a triplicate without the AND? The mix of logical operators with If statements I suppose is the problem.

9
QB64 Discussion / ElseIF v's Or
« on: April 06, 2022, 04:54:00 pm »
Ok, time for another dumb questions on "Why can't I...?"

Now I realize there is such a thing as ELSEIF. I do use it a lot. But I often find myself wondering why an IF statement can not follow an OR.

To give you an example.. Suppose you have an Array (1 to 10) and you want to search the array for duplicate, or triplicate, or quadruplicate, or Quintuplicate, or Sextuplicate etc values

For x = 1 to 10
  For y = 1 to 10
     If Array(x) = Array(y) then Duplicate = Array(x)
     or IF Array(x) = Array(y) and Array(x)=Array(y+1) then Tripiplicate = Array(x)

etc etc


10
QB64 Discussion / Re: Variable v's Fixed Value
« on: April 04, 2022, 11:29:07 am »
Hi Steve... ya. @MasterGy doesn't seem to use CONST, so I was thinking he may have a method whereby he comes up with a quasi CONST. So something like, if the value in the formula will never change then rather than use CONST, just use the fixed value (ie use a 2 instead of the variable zoom). Where there is a constant change in a value, like his POWER, then the obvious benefit of a named variable works for this case. But, where you want to see the full run of your program with the flexible POWER but in the 2nd run you want to alter only the zoom. Therefore he would need to somehow keep track of which variables he wants to change per run and which he wants to keep their fixed value every run.  A variable named A, or B or FN etc may be difficult to id as your quasi CONST, whereas a variable named zoom can clearly be found.

I haven't used variables as a quasi CONST. The thought just struck me when I was looking over @MasterGy 's code. And I think @bplus was alluding to simply changing CONST values in multiple run throughs. I assume he has a distinct name for his CONSTs

I don't use CONST and my naming of variables tend to be on the longish descriptive side. I'm not sure what kind of trouble I can get into if I include quasi CONST like zoom. Now in my case, where I have a head like a sieve so a simple zoom would not suffice, it would have to be Qzoom or Quasiz.

11
QB64 Discussion / Re: Variable v's Fixed Value
« on: April 04, 2022, 10:20:04 am »
Code: QB64: [Select]
  1. x=Cent_x + obj(a,0) * zoom
v's
Code: QB64: [Select]
  1. x=Cent_x + obj(a,0) * 2

I see it. By putting a name to the value of 2 you do get a better picture of the intent of the formula. Because it is however a "variable" do you have some trick that you use to be sure "zoom" doesn't change in value?

12
QB64 Discussion / Re: What's your philosophy about constants?
« on: March 25, 2022, 04:50:41 pm »
I think you are onto something there @bplus . A Buddhist would argue "impermanence" . There is nothing in this world, either in thought or tangible which is constant (or permanent). Everything built, given enough time, will be changed, replaced or left to crumble. All thoughts and emotions are impermanent and all the math theories are constantly being challenged and reconstructed in the search for that one pure underlaying formula. I suspect your application of a constant (ie a tool which you can change to a different value) is the way to go with constants in coding. Especially a program which is under construction. And then, once it's complete it's onto the next project.

I kind of like the idea of Impermanence. It kind of forces you to improve your coding so the utility of your project may last at least your life time.

Maybe this was Too Deep a dive into constants

13
QB64 Discussion / Variable v's Fixed Value
« on: March 22, 2022, 10:29:21 am »
@MasterGy ... Garland of Pearls is terrific. In going over the code I notice the use of a variable rather than a fixed value in the math formula. For example the variable ZOOM appears to be a constant 2 and the Name ZOOM is used in the math formula for x1,y1,x2,y2, rather than the fixed value of 2.

Whereas in the case of the variable POWER, it's value is not fixed and the math formula vec_x and vec_y also use the variable POWER.

The POWER application seems to me to be the way I mostly see named variables used. I was just wondering if you find some advantage in your coding to use named variables of fixed values for use in formulas ?

14
QB64 Discussion / Re: QB64 10-Liner programs or games
« on: March 21, 2022, 11:36:24 am »
Not sure how to fix this error bplus.

  [ You are not allowed to view this attachment ]  

15
QB64 Discussion / Re: How do you convert a nested Do Loop into a recursive subroutine call?
« on: March 14, 2022, 04:25:38 pm »
Food for thought Steve...Multiple nesting can be difficult to follow the action as well but I was thinking recursion maybe faster than a Do Loop with a high loop control value. Of course I have never been able to get it off the ground to see if there is any speed or accuracy advantage.

Pages: [1] 2 3 ... 34