lean2/tests/lean/arith6.lean.expected.out

  Set: pp::colors
  Set: pp::unicode
  Imported 'Int'
  Set: pp::unicode
3 | 6
true
false
true
true
  Assumed: x
3 + -1 * (x * (3 div x)) == 0
x + -1 * (3 * (x div 3)) == 0
false
  Set: lean::pp::notation
Int::divides 3 x
Define divides, and add examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com> 2013-09-04 03:18:20 +00:00			`Set: pp::colors`
			`Set: pp::unicode`
chore(builtin): rename nat, int and real modules to Nat, Int and Real. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com> 2014-01-01 21:52:25 +00:00			`Imported 'Int'`
Define divides, and add examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com> 2013-09-04 03:18:20 +00:00			`Set: pp::unicode`
			`3 \| 6`
			`true`
			`false`
			`true`
			`true`
			`Assumed: x`
refactor(equality): make homogeneous equality the default equality It was not a good idea to use heterogeneous equality as the default equality in Lean. It creates the following problems. - Heterogeneous equality does not propagate constraints in the elaborator. For example, suppose that l has type (List Int), then the expression l = nil will not propagate the type (List Int) to nil. - It is easy to write false. For example, suppose x has type Real, and the user writes x = 0. This is equivalent to false, since 0 has type Nat. The elaborator cannot introduce the coercion since x = 0 is a type correct expression. Homogeneous equality does not suffer from the problems above. We keep heterogeneous equality because it is useful for generating proof terms. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com> 2013-10-29 23:20:02 +00:00			`3 + -1 * (x * (3 div x)) == 0`
			`x + -1 * (3 * (x div 3)) == 0`
Define divides, and add examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com> 2013-09-04 03:18:20 +00:00			`false`
			`Set: lean::pp::notation`
			`Int::divides 3 x`