Author Topic: Implied  (Read 6884 times)

0 Members and 1 Guest are viewing this topic.

Offline TempodiBasic

  • Forum Resident
  • Posts: 1792
    • View Profile
Re: Implied
« Reply #15 on: August 26, 2020, 08:55:54 am »
an extensive talking is here
https://en.wikipedia.org/wiki/Material_conditional (EN)
https://it.wikipedia.org/wiki/Implicazione_logica (IT)

here we can read that A implies B has the meaning  A is condition to be B and B is neccessary condition for A
for example A = rain  B = clouds,
 so the rain is  the condition to (be) the clouds (it doesn't rain without clouds) 
and B is necessary to A (clouds are necessary to rain)
 but not A is necessary to B (it can be clouds without rain).

Logic is very impressive!
Programming isn't difficult, only it's  consuming time and coffee

Offline Dimster

  • Forum Resident
  • Posts: 500
    • View Profile
Re: Implied
« Reply #16 on: August 26, 2020, 09:47:55 am »
Thanks for those articles Tempodi - Feels the word "Implies" is the wrong descriptor for IMP. I've taken implication to be much less definitive, or a weaker connection than a "material" connection. So the statement "Blue implies Male" can be universally understood as a weak connection, the reverse "Male implies Blue" is not so well received unversally. Your example of "clouds" and "rain" do have the same material connection whether it's expressed "Rain implies Clouds" or "Clouds implies Rain"

IMP should be MIMP ie Material Implication.

I'm thinking - to use IMP then I would need at least 2 variables which are defined as material to each other

       DIM Rain
       DIM Clouds
       DIM Life

      Rain IMP Clouds
      Rain IMP Life
     Clouds IMP Rain
 
     RainStorm = Rain IMP Clouds
     NewGrowth = Rain IMP Life

Is more along the lines of assignment by associations if IMP could be used in an associative type of way. Seems I will need to GETS me to a library and learn a lot more on bits and bytes and the math of relational operators before I can force my computer to let me assign by my layout above.


Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
    • View Profile
Re: Implied
« Reply #17 on: August 26, 2020, 12:27:21 pm »
@Dimster

You might be interested in this:
https://link.springer.com/chapter/10.1007/978-3-319-64021-1_6#:~:text=Propositional%20logic%20is%20the%20study,is%20either%20true%20or%20false.&text=Predicate%20calculus%20includes%20predicates%2C%20variables,of%20a%20statement%20can%20have.
You can see Table 6.4 Implication TF Table matches exactly the pattern for QB64 IMP bit math operator. But your attempts to use bit math for Logical Implication requires some more background knowledge.

It would be interesting to see Logic problems or puzzles solved with QB64.
« Last Edit: August 26, 2020, 12:41:11 pm by bplus »

Offline Dimster

  • Forum Resident
  • Posts: 500
    • View Profile
Re: Implied
« Reply #18 on: August 26, 2020, 01:45:07 pm »
Thanks bplus - i'll definitely look into it. A lot of interesting subjects in that Concise Guide to Formal Methods.

Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
    • View Profile
Re: Implied
« Reply #19 on: August 26, 2020, 03:07:47 pm »
Thanks bplus - i'll definitely look into it. A lot of interesting subjects in that Concise Guide to Formal Methods.

Oh hey, I didn't even notice the title, yeah I think I will check out more of the book as well :)

Update: Shoot I was thinking there was more access, but it's gone now.
« Last Edit: August 26, 2020, 04:33:22 pm by bplus »

Offline Dimster

  • Forum Resident
  • Posts: 500
    • View Profile
Re: Implied
« Reply #20 on: August 28, 2020, 02:15:14 pm »
Ok, Here's my latest attempt - I'm moving in on it. This time I forced materialty (i think) by making blue = male and pink = female, but as you can see the results are not yet correct.

Code: QB64: [Select]
  1. Female = 100
  2. Male = 101
  3. Pink = 100
  4. Blue = 101
  5.  
  6. 'Kolor = Female IMP Male
  7. 'IF Kolor = 0 THEN Kolor$ = "Pink"
  8. 'IF Kolor = -1 THEN Kolor$ = "Blue"
  9. 'PRINT Kolor; " Kolor = 0 then false : Kolor <> 0 then true"
  10. 'PRINT Kolor$
  11. 'PRINT
  12.  
  13.  
  14. 'SLEEP
  15. PRINT "If Gender = 0 then Implication is False :  Gender <> 0 then Implication is True"
  16. Gender1 = Pink IMP Female
  17. IF Gender1 = 0 THEN Gender1$ = "Male"
  18. IF Gender1 <> 0 THEN Gender1$ = "Female"
  19. PRINT "Gender1 value is "; Gender1
  20. PRINT "Pink implies "; Gender1$
  21. Gender2 = Blue IMP Female
  22. IF Gender2 = 0 THEN Gender2$ = "Gender Unknown"
  23. IF Gender2 <> 0 THEN Gender2$ = "Female"
  24. PRINT "Gender2 value is "; Gender2
  25. PRINT "Blue implies "; Gender2$
  26. Gender3 = Pink IMP Male
  27. IF Gender3 = 0 THEN Gender3$ = "Gender Unknown"
  28. IF Gender3 <> 0 THEN Gender3$ = "Male"
  29. PRINT "Gender3 value is "; Gender3
  30. PRINT "Pink implies "; Gender3$
  31. Gender4 = Blue IMP Male
  32. IF Gender4 = 0 THEN Gender4$ = "Male"
  33. IF Gender4 <> 0 THEN Gender4$ = "Female"
  34. PRINT "Gender4 value is "; Gender4
  35. PRINT "Blue implies "; Gender4$

So Back to the F'n M'n drawing board.

Offline Gets

  • Newbie
  • Posts: 28
    • View Profile
Re: Implied
« Reply #21 on: August 28, 2020, 04:35:24 pm »
Because the topic was about the IMP operator there was a focus on bit manipulation in the replies, but you don't need to worry about that if you just want to associate colors with gender.

I had something similar in the example I posted earlier, but

Code: [Select]

Type Colordata

Col as string
gender as string

End type

Dim Colors(10) as Colordata

Colors(1).Col="Blue"
Colors(1).gender="Male"



That's the simplest form. The array will keep the associated colors and gender together, so you can just manually enter them.

If you really want to have a color *imply* a gender, then you don't need the IMP operator, you  can just create a function that checks each color for qualities that determine what gender to associate it with:


Code: [Select]

Function AssignGender(col as _unsigned long)

Male=1
Female=2

    IF _BLUE32(col) > 200 AND _RED32(col) < 200 THEN AssignGender = Male

    IF _RED32(col) > 200 AND _BLUE32(col) < 200 THEN AssignGender = Female

END FUNCTION



If you send a 32-bit color value to that function(using RGB32), then it will perform a simple check and return a result that's either Male(1), Female(2) or neither(0). In this example, a comparatively large amount of blue implies that the color is for males while red implies that it's for females. But you can create  whatever conditions you want, and based on what you tell it it will return the appropriate gender for every single 32 bit color.


It's definitely worth looking into how bits work and will help your understanding of what's actually happening in your programs;variable limits, how things work in memory, etc. But for the actual problem in front of you, you should focus on getting it to *work* in the simplest form possible. Once  you've done that, you can save the program and slowly improve it to be more efficient, dynamic, procedural etc. See if you can get the program to work using what you already understand, and then do the experimenting safely on top of that or separately.

Offline Dimster

  • Forum Resident
  • Posts: 500
    • View Profile
Re: Implied
« Reply #22 on: August 28, 2020, 05:19:33 pm »
You are absolute right - I don't need IMP - you have provided a couple of excellent workarounds.

But we have IMP and it seems to stand for "implied". The other relational operators - And, Or, Xor - all appear to be logical in their application - if I AND something I know the two go together - if I OR something, it's one or the other - Xor'ing something gets me it could be the one, or it could be the other.  IMP however has logic in that I understand that one value could IMPly another value but it somehow doesn't work LOGICALLY. It really doesn't seem to imply the other value at all. At least I haven't been able to make a formula where A IMP B to my logical understanding of the result.

As you pointed out in an earlier post, it simply turns a bit on or off and if that's the case , then we are more into machine language than Basic.

Just read where IMP performs the same way as NOT(A) OR B. I'm going to play with this idea.

Thanks Gets. I think I will eventually need to adapt your two excellent work arounds. And if I can't make Basic logical use of IMP then perhaps I'll start a petion to remove it from the Basic lexigon as a Relational Operator as one that doesn't really IMPLY anything.


Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: Implied
« Reply #23 on: August 28, 2020, 06:31:07 pm »
Logically, we can use IMP to decide if you're a recognized sentintent creature.

Are you living?
Are you dead?

Yes, Yes --> you are a zombie.
Yes, no --> you are a valid sentintent creature.
No, yes --> you are a corpse.
No, no --> you are a non-living object, like a rock.

In QB64, this would be:

INPUT "ARE YOU LIVING (-1 FOR YES, 0 FOR NO)"; living
INPUT "ARE YOU DEAD (-1 FOR YES, 0 FOR NO); dead
Result = living IMP dead
IF result = 0 THEN
   PRINT "YOU ARE A SENTIENT CREATURE"
ELSE
    PRINT  "YOU ARE SOMETHING NON-SENTIENT."
END IF

It's IMPlied that if you're living, and not dead, then you're a sentient creature.
« Last Edit: August 28, 2020, 06:39:21 pm by SMcNeill »
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: Implied
« Reply #24 on: August 28, 2020, 06:51:15 pm »
Another logic exercise on IMP:

Do you have a sandwich?
Are you hungry?

With IMP, we can determine ARE YOU LIKELY TO HAVE A SANDWICH LATER?

Yes, Yes = No.  You have a sandwich, but you're hungry.  You'll eat it and not have one later.
Yes, no = yes.  You have a sandwich, you're not hungry.  No reason you won't still have it later.
No, no = no.  You're not hungry, but have no sandwich.  One won't magically appear for you.
No, yes = no.  You're hungry, but have no sandwich.  One won't magically appear for you, and you're just going to get hungrier.

https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline Dimster

  • Forum Resident
  • Posts: 500
    • View Profile
Re: Implied
« Reply #25 on: August 29, 2020, 08:50:13 am »
Ah, thanks Steve - so that is how I would assign values and use IMP. Very much appreciated. Would love to see your example in the wiki. I hereby withdraw my petition for removal of IMP, it clearly does work.

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: Implied
« Reply #26 on: August 29, 2020, 10:23:42 am »
Honestly, I've never found any real use for IMP.  Basically it's a shortcut for:

IF NOT (condition1 AND NOT condition2) THEN...


Can't say I've ever needed something so convoluted in my programs before.  I suppose, if I ever do, I'll probably just write out the long form, as above, as IMP simply isn't part of my common-use toolset and I'd never remember it to make use of it.  ;)
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
    • View Profile
Re: Implied
« Reply #27 on: August 29, 2020, 10:36:43 am »
It just hit me, if A implies B then A is a subset of B or equivalent to B, no subset of A is outside B (thinking Venn Diagrams).


And NOT A could be in B or in NOT B.

Offline Dimster

  • Forum Resident
  • Posts: 500
    • View Profile
Re: Implied
« Reply #28 on: August 29, 2020, 10:39:09 am »
I heard ya Steve. I'm interested in trying to use it with a data base of Elastic/Inelastic relationships between 2 seperate events. At the moment AND, OR, XOR have very singular hard connecting results as in Yes or No. Whereas the IMPLIED, thanks to you, I can now use YES,YES = NO. Suttle but a little less binary. Stringing IMP's or Nesting IMP's may have my program thinking more like a human than a computer. Anyway, just a thought I had and most often gets abandoned as the failures to compute rise.

Offline Dimster

  • Forum Resident
  • Posts: 500
    • View Profile
Re: Implied
« Reply #29 on: August 29, 2020, 11:04:20 am »
I guess that's right bplus = if A = 1,2,3,4,5 and it Implies the next number will be 6, then B must be 1,2,3,4,5,6 which does make A a subset of B.
And the number 6 is NOT in A, it could be in B ... however "or in NOT B" ... NOT B would in fact be A and we know 6 is not in A, so would that last part actually read

And NOT A could be in B or NOT(in NOT B) ???