Liberty BASIC 5 - More suggestions

[Marco Kurvers]

Here, I have more suggestions and ideas.

In VB, you can use more IF statements with one END IF by using an ELSE IF.

Example:

If A = 0 Then
    ...
Else If A = 1 Then
    ...
Else
    ...
End If

In LB, we must use more END IF statements, because the same shorthand is not possible.

Example:

If A = 0 Then
    ...
Else
    If A = 1 Then
        ...
    Else
        ...
    End If
End If

An another suggestion is the selection in the code. If you forgot to disable the selection and you run the program, LB will run it from the selection. This can cause problems.
I think it's better that the program run always from the first line.

Good luck, Carl, with the new version. I'm curious what it's going to be. 



    

[Carl Gundel]

May 18, 2022 8:52:23 GMT -5 Marco Kurvers said:

Here, I have more suggestions and ideas.

In VB, you can use more IF statements with one END IF by using an ELSE IF.

Example:

If A = 0 Then
    ...
Else If A = 1 Then
    ...
Else
    ...
End If

Hmm.  Not sure why that is an improvement.  Each IF THEN should have a matching END IF in my humble opinion.

Good luck, Carl, with the new version. I'm curious what it's going to be.

Thank you.

[tsh73]

In LB we have to use end if for each If, true
So no

if x = 1 then
   print "1"
else if x>1 and y <0 then
   print "2"
else if x>1 and y =0 then
   print "3"
else
   print "4"
end if


But we have another shortcut, not available in VB
select case
case x = 1
   print "1"
case x>1 and y <0
   print "2"
case x>1 and y =0
   print "3"
case else
   print "4"
end select


[Marco Kurvers]

We now have new commands in LB 5, but there is something wrong with command names and variable names.

See this:


dim trapclose(10)



open "test" for window as #w

#w trapclose("Quit")

wait



sub Quit handle$

    close #w

    end

end sub

Liberty BASIC 5 runs the program without an error, but I think that this is walking over a small cliff. There are more new commands that can used as variable names. I will say: don't do that. You can make your program so difficult for another people and for yourself.

Why I use an array in the example above, is because only with parenthesis gives trapclose the command color. Not if you say 'trapclose = 10'.

[Carl Gundel]

Jun 15, 2022 8:11:41 GMT -5 Marco Kurvers said:

We now have new commands in LB 5, but there is something wrong with command names and variable names.
See this:

dim trapclose(10)

open "test" for window as #w
#w trapclose("Quit")
wait

sub Quit handle$
    close #w
    end
end sub

Liberty BASIC 5 runs the program without an error, but I think that this is walking over a small cliff. There are more new commands that can used as variable names. I will say: don't do that. You can make your program so difficult for another people and for yourself.

Why I use an array in the example above, is because only with parenthesis gives trapclose the command color. Not if you say 'trapclose = 10'.

This is not a bug, and I'm not sure why it's a problem.  #w trapclose() is not a command.  It is a method, and LB5 allows users to create their own methods too, like a function name.

Let's have a conversation about it as a group?  I'm open to ideas.

[Carl Gundel]

Jun 15, 2022 8:11:41 GMT -5 Marco Kurvers said:

Why I use an array in the example above, is because only with parenthesis gives trapclose the command color. Not if you say 'trapclose = 10'.

As I said before it's not a bug, but your observation about the color is useful.  A different color for the form #handle methodName() in the editor, as well as other aids for the programmer can help to disambiguate.

[Marco Kurvers]

Yes, indeed. I understand what you mean. This gives LB 5 more functionality.

[alincon]

Is 'disambiguate' a reserved word in LB5?

[Carl Gundel]

Jun 16, 2022 18:50:21 GMT -5 alincon said:

Is 'disambiguate' a reserved word in LB5?

No, but apparently ‘ambiguate’ is. 😉

[cretuandrei]

Neuron.bas

 Dim Inputs(10)

 Dim Weights(11)

 Dim labels(10)

 Global sum,bias,outcome,lRate



 function Init(datas$,labels$)

N=1 : bias=1.0

  while (word$(datas$,N,",")<>"")

            Inputs(N) = val(word$(datas$,N,",")) : N=N+1

  wend

   

  N=1

  while word$(label$,N,",")<>""

       labels(N) =val(word$(label$,N,",")) : N=N+1

  wend

 end function



 function setRandomWeights()

      for N=1 to 11

          Weights(N)=rnd(1)

      next N

 end function



 function feedForward()

     sum=0.0 : outcome=0

     for i=1 to 10

          sum = sum+(Inputs(i)*Weights(i))

     next

     sum = bias*Weights(11)



     outcome = activate(sum)

     if outcome>=0.5 then

        feedForward=1

     else

       feedForward=-1

     end if

 end function





  function adjustWeights(err)

  for N=1 to 10

weights(I) = weights(I)*err

next N

  end function





  function activate(x)

      activate = (1/(1+exp(-1*x)))

  end function

     


Create Neurons using handles:

for N=1 to 10
library "Neuron.bas",#neuron
maphandle #neuron,"#neuron"+str$(N)next
next







[Marco Kurvers]

Carl, I have a question.

In LB 4, indentation does not work properly. LB does not remember that you are in a SUB block or in an IF block, for example. With a press of the backspace key, it doesn't work well every time the cursor goes to the right place, such as perfectly going back under an IF when you're done with the block code. Perhaps a good idea to refine the editor in LB 5 a little better and we need to correct less with the mouse or the arrow keys.

[Rod]

We need a crystal ball, when the crystal ball is on, Liberty will know when to automatically indent the forecasted END IF. When it is off we will wait for the user to enact the indent. Of course you could START with IF and END IF on the next line and then insert the code between. That way the indent is automatic and you never forget the END IF. So whenever you key IF the editor should automatically append an END IF, but wait! IF THEN, ELSE in a single line?

[Marco Kurvers]

Hello, I will tell you a question from another programmers, who use LB.

I get a lot of responses from other LB programmers, who also know other BASIC dialects. They wonder why determining a file, whether it exists, has to be done in such a roundabout way. Using info$(0, 0) is not exactly like BASIC to determine if a file exists or not.

Even in TRS80 BASIC and also in other BASIC versions and dialects it is much easier. Using error intercepts and using a FileExist() function, the array would not need to. If we want to find other data, then file management could just be done with BASIC functions. Having to get everything out of the info$ array and having to write their own functions every time is not useful for those who, for example, are still starting with LB.

They asked me if I wanted to ask this question here. Using info$() doesn't really say it has to do with file management.

That is why I have already written a module in which I have written functions myself to ensure that the array info$ is no longer needed. Of course, a module must be inserted so that you still encounter the array, but perhaps this is a good idea to make it a library for LB 5.