VisualG Estrutura de Repetição - Marcar os divisíveis por 4

T.A.L · 23 de agosto de 2020

Boa noite. Estou com um exercício pra resolver que eu estou dificuldade. Eis o exercício:

43) Desenvolva um algoritmo que mostre uma contagem regressiva de 30 até 1, marcando os números que forem divisíveis por 4, exatamente como mostrado abaixo:
30 29 [28] 27 26 25 [24] 23 22 21 [20] 19 18 17 [16]...

Infelizmente, os divisíveis por 4 estão se repetindo, mas também estão marcados. Não sei mais o que fazer. Até tentei usar outra variável, mas acabei me enrolando mais ainda.

algoritmo "divisíveis"
var
   cont : inteiro 
inicio
   cont <- 30
   enquanto (cont >= 1) faca
      escreva (cont)
      cont <- cont - 1
      se (cont mod 4 = 0) entao
         escreval ("[", cont, "]")
      fimse
   fimenquanto
fimalgoritmo

T.A.L · 23 de agosto de 2020

Consegui resolver

Coloquei o contagem regressiva no final do SE

c <- 30
enquanto (c >= 1) faca
   se (c mod 4 = 0) entao
      escreval ("[", c, "]")
   senao
      escreval (c)
   fimse
   c <- c - 1
fimenquanto

Simon Viegas · 24 de agosto de 2020

@T.A.L, não seria melhor utilizar o comando para, em vez do enquanto?

T.A.L · 16 de setembro de 2020

Olá, Simon. Resolvi 1 hora depois desta postagem no mesmo dia. Não deu pra fazer com o PARA, porque o exercício exigia utilizar a estrutura enquanto.

Simon Viegas · 16 de setembro de 2020

Em relação ao espaçamento dos números entre os colchetes:

      se (c mod 4 = 0) entao
         escreva (" [", c:1, "]")
      senao
         escreva (c)
      fimse

Observe que se faz também necessário um espaço antes do "[".

ou

      se (c mod 4 = 0) entao
         escreva (" [", c:1, "]")
      senao
         escreva (" ", c:1)
      fimse

O VisualG insere um espaço automaticamente nas variáveis do tipo inteiro. Para removê-lo, definiria que quer reservar apenas um dígito. Como os números tem 2, não vai ter espaço extra.

T.A.L · 21 de setembro de 2020

Simon, muito obrigado pelos esclarecimentos.

NerivanPrestes · 26 de dezembro de 2021

Em 16/09/2020 às 15:12, Simon Viegas disse:
Em relação ao espaçamento dos números entre os colchetes:
      se (c mod 4 = 0) entao
         escreva (" [", c:1, "]")
      senao
         escreva (c)
      fimse
Observe que se faz também necessário um espaço antes do "[".

ou
      se (c mod 4 = 0) entao
         escreva (" [", c:1, "]")
      senao
         escreva (" ", c:1)
      fimse
O VisualG insere um espaço automaticamente nas variáveis do tipo inteiro. Para removê-lo, definiria que quer reservar apenas um dígito. Como os números tem 2, não vai ter espaço extra.

Sensacional! obrigado pelas dicas

algoritmo "marcar_divisível_por_4"
var
   cont: inteiro
   divi4: real
inicio

   cont <- 30

   enquanto (cont >= 1) faca
      divi4 <- (cont/4)

      escolha divi4
      caso 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
         escreval ("[", cont:1, "]")
      outrocaso
         escreval (cont)
      fimescolha

      cont <- cont -1
   fimenquanto
fimalgoritmo

===================================

Fiz dessa forma usando caso, deu certo, bem gambiarrento kkkkkkkk, até porque se aumentar a contagem precisa aumentar as condições, usando Se/Fimse é melhor mesmo!

OBS: Postei somente para interagir!

Simon Viegas · 27 de dezembro de 2021

Em 26/12/2021 às 04:05, NerivanPrestes disse:

Fiz dessa forma usando caso, deu certo, bem gambiarrento kkkkkkkk, até porque se aumentar a contagem precisa aumentar as condições, usando Se/Fimse é melhor mesmo!

Não, não deu certo. Pelo menos aqui:

É necessário destacar apenas os múltiplos de 4. Você precisaria dar um revisada no código. Tenta aí.

NerivanPrestes · 29 de dezembro de 2021

Em 27/12/2021 às 08:10, Simon Viegas disse:

Não, não deu certo. Pelo menos aqui:

É necessário destacar apenas os múltiplos de 4. Você precisaria dar um revisada no código. Tenta aí.

Aqui deu, fiz assim usando "escolha/fimescolha:

algoritmo
var
   cont:inteiro
   divi4:real

inicio
   cont<-30

   enquanto(cont>=1)faca
      divi4<-(cont/4)
      escolha divi4
      caso 1,2,3,4,5,6,7,8,9,10
         escreval("[",cont:1,"]")
      outrocaso
         escreval(cont)
      fimescolha

      cont <- cont-1
   fimenquanto
fimalgoritmo

==================================

Como disse, tem suas limitações se precisar for aumentar o número de divisões feitas, mas funciona no que é pedido.

Simon Viegas · 29 de dezembro de 2021

12 horas atrás, NerivanPrestes disse:

Como disse, tem suas limitações se precisar for aumentar o número de divisões feitas, mas funciona no que é pedido.

@NerivanPrestes, por definição, supostamente, o escolha não aceita valores do tipo real, ou seja: conceitualmente existiria um erro de sintaxe. Seu código nem deveria rodar por completo*!!!. Ali no escolha deveria ser passado um valor do tipo inteiro!!!

*o VisualG não compila os código, mas sim vai "interpretando linha a linha" (deveria dar erro de execução)... Diferente do seu pai, o Pascal, que primeiro compila, e depois executa o arquivo gerado (dá erro de compilação).

"Ah! mas o resultado está saindo como esperado". Eu entendo isso como uma "eventualidade". Como assim? Primeiro vamos aos fatos:

Teste do seu código no VisualG 2.0:

"Opa! Deu certo".

Agora exatamente o mesmo código na versão 3.6.0.5 (que seria versão mais estável):

"Vixe! Deu B.O."

O que pode está acontecendo? Eu acredito que o autor/criador do VisualG, provavelmente por algum motivo nobre, idealizou implementar algumas funcionalidades no programa para tentar facilidade a vida do estudante... daí, em vez de dar erro lá no escolha ao utilizar um real, ele fez alguma alteração para o recurso funcionar... meio que implicitamente convertendo de real para inteiro e/ou efetuando alguma outra coisa... só que, entre uma versão e outra (da 2x para 3x) ele meio que "reajustou" essa "ajuda"... que no final, como visto nas imagens acima, acabou causando essa inconsistência... já que um mesmo código está dando resultados diferentes... Não deveria, concorda? Na minha humilde opinião seria muito mais educativo dar erro mesmo... "Amigo, não pode usar real num escolha".

No VisualG 3x, ele meio que "pega a parte inteira do valor real e compara com os valores que estão nos caso". Ele "compara inteiro com inteiro".
Já no VisualG 2x, ele faz algo diferente... eu não entendi exatamente, mas ele meio que "pega a parte real do valor real e compara com a parte inteira dos valores que estão nos caso"... tá meio confuso, mas ele "compara um real com um inteiro". Ou seja: comportamentos diferentes entres versão... repito: era muito mais "lógico" simplesmente dar erro e não aceitar reais.

Em fim, na minha opinião seu algoritmo não seria válido.. pois o que está em jogo é o meio (de chegar a uma solução), e não o resultado.

Exemplo para contextualizar:

É para utilizar enquanto, né?

algoritmo "divisíveis"
var
   pronto: logico
inicio
   enquanto (não pronto) faca
      escreval("30 29 [28] 27 26 25 [24] 23 22 21 [20] 19 18 17 [16] 15 14 13 [12] 11 10 9 [8] 7 6 5 [4] 3 2 1")
      pronto <- VERDADEIRO
   fimEnquanto
fimalgoritmo

Essa resposta é válida? Não, não seria. Está implícito que precisaria gerar os número e verificar de alguma forma... O foco não é o resultado, mas sim o meio.

Outro exemplo:

algoritmo "divisíveis"
inicio
   enquanto (FALSO) faca
   fimEnquanto
   escreval("30 29 [28] 27 26 25 [24] 23 22 21 [20] 19 18 17 [16] 15 14 13 [12] 11 10 9 [8] 7 6 5 [4] 3 2 1")
fimalgoritmo

Usei enquanto e o resultado saiu como esperado... E aí?

CONCLUSÃO
O objetivo dos exercício seria justamente "exercitar algo".... No caso, provavelmente, o contexto do exercício está inserido no estudo do laços de repetição, daí está implícito que deve-se ser utilizado as características do tal laço de forma efetiva... nos dois exemplo acima, eu "utilizei" (tá lá no código), mas basicamente não teve propósito algum na lógica... entende?

Aí talvez entre a tal questão, que é positiva positiva, de "pensar fora da caixa", ok!, mas isso não seria o foco do exercício em si.

Resumindo:
Não acho que sua solução seja válida... seria necessário pensa em outra forma de resolver. O resultado está correto, mas o meio não.

NerivanPrestes · 30 de dezembro de 2021

22 horas atrás, Simon Viegas disse:
@NerivanPrestes, por definição, supostamente, o escolha não aceita valores do tipo real, ou seja: conceitualmente existiria um erro de sintaxe. Seu código nem deveria rodar por completo*!!!. Ali no escolha deveria ser passado um valor do tipo inteiro!!!

*o VisualG não compila os código, mas sim vai "interpretando linha a linha" (deveria dar erro de execução)... Diferente do seu pai, o Pascal, que primeiro compila, e depois executa o arquivo gerado (dá erro de compilação).

"Ah! mas o resultado está saindo como esperado". Eu entendo isso como uma "eventualidade". Como assim? Primeiro vamos aos fatos:

Teste do seu código no VisualG 2.0:

"Opa! Deu certo".

Agora exatamente o mesmo código na versão 3.6.0.5 (que seria versão mais estável):

"Vixe! Deu B.O."

O que pode está acontecendo? Eu acredito que o autor/criador do VisualG, provavelmente por algum motivo nobre, idealizou implementar algumas funcionalidades no programa para tentar facilidade a vida do estudante... daí, em vez de dar erro lá no escolha ao utilizar um real, ele fez alguma alteração para o recurso funcionar... meio que implicitamente convertendo de real para inteiro e/ou efetuando alguma outra coisa... só que, entre uma versão e outra (da 2x para 3x) ele meio que "reajustou" essa "ajuda"... que no final, como visto nas imagens acima, acabou causando essa inconsistência... já que um mesmo código está dando resultados diferentes... Não deveria, concorda? Na minha humilde opinião seria muito mais educativo dar erro mesmo... "Amigo, não pode usar real num escolha".

No VisualG 3x, ele meio que "pega a parte inteira do valor real e compara com os valores que estão nos caso". Ele "compara inteiro com inteiro".
Já no VisualG 2x, ele faz algo diferente... eu não entendi exatamente, mas ele meio que "pega a parte real do valor real e compara com a parte inteira dos valores que estão nos caso"... tá meio confuso, mas ele "compara um real com um inteiro". Ou seja: comportamentos diferentes entres versão... repito: era muito mais "lógico" simplesmente dar erro e não aceitar reais.

Em fim, na minha opinião seu algoritmo não seria válido.. pois o que está em jogo é o meio (de chegar a uma solução), e não o resultado.

Exemplo para contextualizar:

É para utilizar enquanto, né?
algoritmo "divisíveis"
var
   pronto: logico
inicio
   enquanto (não pronto) faca
      escreval("30 29 [28] 27 26 25 [24] 23 22 21 [20] 19 18 17 [16] 15 14 13 [12] 11 10 9 [8] 7 6 5 [4] 3 2 1")
      pronto <- VERDADEIRO
   fimEnquanto
fimalgoritmo
Essa resposta é válida? Não, não seria. Está implícito que precisaria gerar os número e verificar de alguma forma... O foco não é o resultado, mas sim o meio.

Outro exemplo:
algoritmo "divisíveis"
inicio
   enquanto (FALSO) faca
   fimEnquanto
   escreval("30 29 [28] 27 26 25 [24] 23 22 21 [20] 19 18 17 [16] 15 14 13 [12] 11 10 9 [8] 7 6 5 [4] 3 2 1")
fimalgoritmo
Usei enquanto e o resultado saiu como esperado... E aí?

CONCLUSÃO
O objetivo dos exercício seria justamente "exercitar algo".... No caso, provavelmente, o contexto do exercício está inserido no estudo do laços de repetição, daí está implícito que deve-se ser utilizado as características do tal laço de forma efetiva... nos dois exemplo acima, eu "utilizei" (tá lá no código), mas basicamente não teve propósito algum na lógica... entende?

Aí talvez entre a tal questão, que é positiva positiva, de "pensar fora da caixa", ok!, mas isso não seria o foco do exercício em si.

Resumindo:
Não acho que sua solução seja válida... seria necessário pensa em outra forma de resolver. O resultado está correto, mas o meio não.

Não entendi, sendo que todos os números que usei no escolha --> caso, foram inteiros, (1,2,3...) APESAR de ter escrito REAL na variável

Mas pode ser mesmo que para fins didádicos de alunos iniciantes, essa função esteja liberada nas versões iniciais do VISUALG.

Interessante seu ponto. Quanto ao uso do escolha_caso/fimescolha utilizando números inteiros, o próprio professor Guanabara faz isso, então só estou replicando o que o próprio professor fez, se está certo ou não, não sei, funciona para o caso específico, obviamente sim, testamos.

===> Caso queria ver o professor falando sobre isso e falando que a estrutura é válida: tempo: 17:48

Sobre ter outra solução, no mesmo dia eu fiz uma usando se/fimse e utilizando o módulo da divisão, dessa forma posso fazer com infinitos alterando até quanto quero contar, não só até o valor 30.

Mas agradeço, vou me esforçar para deixar meus programas menos gambiarrentos kkkkk

Simon Viegas · 30 de dezembro de 2021

9 horas atrás, NerivanPrestes disse:

Não entendi, sendo que todos os números que usei no escolha --> caso, foram inteiros, (1,2,3...) APESAR de ter escrito REAL na variável

Mas pode ser mesmo que para fins didádicos de alunos iniciantes, essa função esteja liberada nas versões iniciais do VISUALG.

Nisso que quero focar: eu entendo que o programa não dar erro na execução seria devido a um bug, e não por uma funcionalidade em si.

9 horas atrás, NerivanPrestes disse:

Interessante seu ponto. Quanto ao uso do escolha_caso/fimescolha utilizando números inteiros, o próprio professor Guanabara faz isso, então só estou replicando o que o próprio professor fez, se está certo ou não, não sei, funciona para o caso específico, obviamente sim, testamos.

===> Caso queria ver o professor falando sobre isso e falando que a estrutura é válida: tempo: 17:48

Sobre "estar replicando o professor", no vídeo ele uma variável do tipo inteiro, vide:

Já no seu código você utiliza real, vide:

Logo, o que foi feito no vídeo está de acordo com o que estou propondo ("não estar utilizando real"). O que estaria inconsistente no seu código não seria os valores nos caso, mas sim a variável de referência definida no escolha. Observação: sequer funciona valores do tipo real no caso, ou seja, no mínimo ficaria estranho aceitar real no escolha, mas não aceitar nos caso.

9 horas atrás, NerivanPrestes disse:

Sobre ter outra solução, no mesmo dia eu fiz uma usando se/fimse e utilizando o módulo da divisão, dessa forma posso fazer com infinitos alterando até quanto quero contar, não só até o valor 30.

Show! Mas só um adendo: "infinitos" não, existe um limite computacional... meio que baseado na faixa de valores do inteiro. Por sinal, os inteiros no VisualG são bem grandes... pelo que vi, pelo menos variando de menos -10^9 a mais de +10^9 (faixa de mais de 2 bilhões de valores). No Pascal, pai do VisualG, meio que seria um pouco mais de 32000 negativo e positivo (faixa de mais 64000 valores. Talvez dobrando em compiladores 64 bits...). Caso tenha interesse, deixo para você descobrir a faixa exata do inteiro no VisualG.

Adendo:
Um exemplo fazendo com escolha:

algoritmo "divisíveis"
var
   cont : inteiro
inicio
   cont <- 30
   
   enquanto (cont >= 1) faca
      escolha cont mod 4
      caso 0
         escreva (" [", cont:1, "]")
      outroCaso
         escreva (" ", cont:1)
      fimEscolha

      cont <- cont - 1
   fimEnquanto
fimAlgoritmo

No caso acima, está tudo ok. "Ah!, mas você utilizou um real lá no escolha". Não, não usei. O que "vai" para escolha é a resultante da expressão... No caso, operador aritmético mod retorna um inteiro.. Faz até sentido, né? Já que "todo resto de uma divisão é um inteiro"... logo é tecnicamente válido para usar no escolha.

NerivanPrestes · 3 de janeiro de 2022

Em 30/12/2021 às 09:21, Simon Viegas disse:

Show! Mas só um adendo: "infinitos" não, existe um limite computacional... meio que baseado na faixa de valores do inteiro. Por sinal, os inteiros no VisualG são bem grandes... pelo que vi, pelo menos variando de menos -10^9 a mais de +10^9 (faixa de mais de 2 bilhões de valores). No Pascal, pai do VisualG, meio que seria um pouco mais de 32000 negativo e positivo (faixa de mais 64000 valores. Talvez dobrando em compiladores 64 bits...). Caso tenha interesse, deixo para você descobrir a faixa exata do inteiro no VisualG

Oooxi é modo de falar, quando digo infinito é quantas vezes o cara quiser fazer, utilizando loops kkkk. A forma que tu trata as respostas e como tu escreve tantos termos técnicos numa conversa simples me faz pensar que estou falando com um robô ahahah

Agradeço pelas pontuações, serão ser de grande ajuda. Só uma dica, relaxa um pouco, nem tudo deve ser levado tão tecnicamente técnico ao ponto de perdermos a parte humana rs. De novo, obrigado!

Suas Críticas são muito bem pontuadas e diretas, e isso é ótimo, mas sempre que possível elogie mais o progresso de alguém antes de criticar, imaginando que tu deve ser uma moderador e até um instrutor, creio que possa ajudar os aspirantes da programação mais do que críticas diretas, sua parte técnica é admirável, isso é nítido, porém do jeito que tu trata as coisas parece até que realmente falamos com uma máquina.