Hi,

Could it be possible to let the user choose how he wants to label his boolean return ?

I need it for example to simulate random throwing coins, random walks etc...

It would be really really usefull to teach mathematics or even computer science.

In this last example for instance, it would be better (according to me) to return a boolean in which it is written Right. The same for the others...

Thanks so much for this so wonderfull software !

This sounds to me like just layering a data abstraction over Booleans, the same as we can layer data abstraction over lists:

What am I missing?

Ok. Let's be clearer.

This is about simulations. And this is about the shape of the return of a boolean.
Here is an example :
This is throwing a coin :

I'd like to return a boolean labeled Pile or Face.
Like this :

(instead of True, I would like to be able to write Pile).

I see, it's important to you to have a hexagonal return value? Because, when you toss a coin, you don't get a Boolean, you get "heads" or "tails"!

I'm not trying to be difficult, I'm just really confused, because to me it seems that you want to have it both ways. You want an abstract data type, coin-side, whose possible values are Heads or Tails. People were tossing coins long before George Boole came along! It's just a coincidence that computers make heavy use of one particular two-valued data type, True and False.

Oh, wait, you want them to be Booleans because you want to use them in IF statements? But, I think that's really confusing. There's a reason why True is the value that makes IF happy, whereas False makes it unhappy. But there's no reason why one side of a coin is more worthy than the other side of satisfying an IF. If I'm reading code and I see

I have to remember, or look up, which is the "true" side of a coin. Whereas if the code has

then it's self-documenting.

The situation is quite different for actual Boolean values. It wouldn't make any sense to say

because you have to understand that IF looks for truth before you can even make sense of what = returns.

Am I making sense?

You can do this with @cameron8299's Custom Inputs block to get the full and options, instead of only the sliders.

Hey, please stop reprimanding Nathalie, who is neither a native English speaker nor is it your business to language-police these forums, okay? You're as much a guest in here as are the others.

I am sorry, I did not know they are a native English speaker, but I am just always tired of seeing "him" when talking about programming on programming forums, stack overflow, etc (even when they specifically say they aren't a boy!)

Hi @bh,
Yes, it is important to me (to teach Mathematics).
In my opinion, the set {Pile, Face} is an isomorphic set to the set {True, False}.

Indeed, in Wikipedia, we can find :
Boolean algebra also deals with functions which have their values in the set {0, 1}. So the values 0, 1 could also be the values of False, True, in a legitimate way.
We should be able in Snap! to choose either True either 1, the same with False and 0.

It should be the same with all isomorphic sets of {True, False}.

And we can proove that the set {Pile, Face} is isomorphic to the set {True, False}.

Let's have a look.

• Here is a bijection that sends True on Pile and False on Face.

• Here is a bijection that sends Pile on True and Face on False.

So there is an isomorphism between the two set {True, False} and {Pile, Face} :

Knowing that those two objects {True, False} and {Pile, Face} are isomorphic, it allows to transpose results and properties demonstrated from one to the other.

This is the reason why I ask to be able to do this :

I would like to be able to choose the label of True/False.
Like 0/1, Pile/face, Right/Left, On/Off etc...

And

makes sens if I decide that Pile is the True value of the coin.

I'm not convinced by the isomorphism argument. As a counterexample, NOT implements an isomorphism between Booleans and Booleans, and I don't think you would want Snap! to let you call True "False" and vice versa.

Pile and face don't naturally form a Boolean algebra, because the dyadic Boolean operators don't make sense for them. There's no inherent reason to choose one as True rather than the other. Why should Pile AND Face be Face but Pile OR Face be Pile? It's very different from 0 and 1, which make sense as a Boolean algebra only with 0 meaning False. Right and Left are also too symmetrical algebraically to form a natural Boolean algebra. On and Off are a more plausible example, because On has a commonsense connection with True, and it makes sense to interpret AND as a series circuit, and OR as a parallel circuit.

Would you argue that {3,7} is isomorphic to {True,False} and therefore we should label 3 as True and 7 as False?

I'm a little nervous arguing with you about isomorphisms because you're a real mathematician and I'm not. But I feel much more confident arguing computer science, namely about abstract vs. primitive data types. Suppose you're writing a Rock, Paper, Scissors simulator and you use {1,2,3} to represent {Rock,Paper,Scissors}. Would you argue that we should allow you to put the latter into numeric input slots? Numbers are a primitive data type, whereas Rock, Paper, Scissors moves are an abstract data type.

But on our list of things to do someday is to provide support for user-controlled display of abstract data types, so you could arrange that the list RATIONAL, 2, 3 would be displayed as ⅔. Then I guess you could do what you want, too.