2015-07-23

Java编程基础详解
复习:
  • jdk
  • jre
  • 写第一个java程序
  • javac 编译
  • java 运行
  • 环境变量的配置
 

变量和数据类型

 
  1. 标识符
  • 什么是标识符:用来给变量、类、接口等等对象起名字;eg:动物 animal,电脑 computer;
  • 标识符的规则
    • 以字母、下划线、美元符号$开头
    • 其他部分可以包含字母、数字、下划线、美元符号$;
    • 标识符不能是java关键字或者保留字:public class static void…;
    • java中大小写敏感,长度没有限制;
  • java关键字和保留字
    • java语言内部预留的一些字词供java语言内部使用的java关键字,保留字;
    • 定义类 class if else while for switch break boolean true false…;
    • public class static void;
  • 字符集编码方式(计算机存储数据的方式是二进制 010101代码)
    • ISO8859-1:西欧字符 ASCII 1字节;
    • BIG5:针对台湾繁体字;
    • GB2312:针对中国大陆地区的简体中文;
    • GBK:GB2312的扩展 繁体字、简体字;
    • GB18030:GBK扩展 包含藏文、维吾尔族文…;
    • Unicode 国际通用编码 java 包含了世界上所有的文字字符 utf-8
  • 命名法则:userName
  • 驼峰式;
    • 类的命名 MyTest 首字母大写,遇到第二个单词的时候,单词的首字母大写;
    • 方法和变量的命名方式:首字母小写 main()  userPassword;
    • 常量在起名字的时候一般是大写;
  • 知名达意;
java八大数据类型
  • 数据类型
    • 计算 数字 (整型数字,浮点型小数)
  • 基本数据类型
    • 数值型:
      • 整型:
        • byte 字节型 数据范围 -128~127
        • int 整型 4个字节 232 最常用的 默认的类型
        • short 短整型 2个字节
        • long 长整型  8个字节 264  eg:34L(大写L,小写容易误认为1)
        • 十进制  0,1,2,3...9
        • 二进制 1...7
        • 八进制 以o开头 1...9
        • 十六进制 以ox开头 0~9 A~F
      • 浮点型(小数):
        • 单精度 float 4个字节 2^32 eg:32.3f
        • 双精度 double 8个字节 2^64 默认类型 
        • 科学计数法:314e2=314*10^2,3.1435e3,3.12e-2=3.12*10^-2;
    • 字符型:
      • char 字符 2个字节 Unicode 2个
      • Unicode 65535个字符 包含世界上几乎所有能够用语言和文字表述出来的字符
      • 转义字符:
        • \t:水平制表符
        • \n:回车换行
        • \r:回车
        • \":双引号
        • \':单引号
    • 布尔型(逻辑型):boolean,true、false;默认false;
  • 引用数据类型
局部变量和成员变量
  • 局部变量:定义在方法内的变量,必须在进行初始化后才能使用;
    • 生命周期:从方法定义的开始到结束,只在方法内部有效;
  • 成员变量:定义在类的内部,方法的外部,系统会对其进行默认的初始化,初始化值是它本身的默认值;
    • 全局变量 
    • 生命周期:类的开始到类的结束 成员变量的作用域;
  • java是一种强类型的语言,变量必须进行声明之后才能使用;
  • 变量:值是可以改变的量 对应内存中的小盒子;int age;
  • 常量:31 45 ‘A’
  • 不建议使用一行声明多个属性;
java运算符
  • 算术运算符:+ - / % * ++ --
  • 赋值运算符 =
  • 关系运算符 > < == != >= <= instanceof
    • 结果是布尔类型的boolean true false
    • 生活一些比较大小之类问题
  • 逻辑运算符 && || !
    • && 与 且关系
    • || 或
    • ! 非
  • 位移运算符 (了解) << >> <<<
  • 条件运算符,三目运算符:a>b?23:32
  • 扩展运算符 +=    /=     -=    *=
  • 一元运算符 ++ --
  • 二元运算符 + -...算术运算符,逻辑,关系
  • 字符串连接运算符 +
  • 运算符的优先级,数学中运算符的优先级是一致的
自动和强制类型的转换(留明天) 总结:
  • 标识符
  • java数据类型
  • 变量定义
  • 运算符
  • 字符串
 
 
 
 
 
 
 
 
 
 
 
 
 
 

转载于:https://www.cnblogs.com/xkk112/p/4671975.html

标题SpringBoot智能在线预约挂号系统研究AI更换标题第1章引言介绍智能在线预约挂号系统的研究背景、意义、国内外研究现状及论文创新点。1.1研究背景与意义阐述智能在线预约挂号系统对提升医疗服务效率的重要性。1.2国内外研究现状分析国内外智能在线预约挂号系统的研究与应用情况。1.3研究方法及创新点概述本文采用的技术路线、研究方法及主要创新点。第2章相关理论总结智能在线预约挂号系统相关理论,包括系统架构、开发技术等。2.1系统架构设计理论介绍系统架构设计的基本原则和常用方法。2.2SpringBoot开发框架理论阐述SpringBoot框架的特点、优势及其在系统开发中的应用。2.3数据库设计与管理理论介绍数据库设计原则、数据模型及数据库管理系统。2.4网络安全与数据保护理论讨论网络安全威胁、数据保护技术及其在系统中的应用。第3章SpringBoot智能在线预约挂号系统设计详细介绍系统的设计方案,包括功能模块划分、数据库设计等。3.1系统功能模块设计划分系统功能模块,如用户管理、挂号管理、医生排班等。3.2数据库设计与实现设计数据库表结构,确定字段类型、主键及外键关系。3.3用户界面设计设计用户友好的界面,提升用户体验。3.4系统安全设计阐述系统安全策略,包括用户认证、数据加密等。第4章系统实现与测试介绍系统的实现过程,包括编码、测试及优化等。4.1系统编码实现采用SpringBoot框架进行系统编码实现。4.2系统测试方法介绍系统测试的方法、步骤及测试用例设计。4.3系统性能测试与分析对系统进行性能测试,分析测试结果并提出优化建议。4.4系统优化与改进根据测试结果对系统进行优化和改进,提升系统性能。第5章研究结果呈现系统实现后的效果,包括功能实现、性能提升等。5.1系统功能实现效果展示系统各功能模块的实现效果,如挂号成功界面等。5.2系统性能提升效果对比优化前后的系统性能
在金融行业中,对信用风险的判断是核心环节之一,其结果对机构的信贷政策和风险控制策略有直接影响。本文将围绕如何借助机器学习方法,尤其是Sklearn工具包,建立用于判断信用状况的预测系统。文中将涵盖逻辑回归、支持向量机等常见方法,并通过实际操作流程进行说明。 一、机器学习基本概念 机器学习属于人工智能的子领域,其基本理念是通过数据自动学习规律,而非依赖人工设定规则。在信贷分析中,该技术可用于挖掘历史数据中的潜在规律,进而对未来的信用表现进行预测。 二、Sklearn工具包概述 Sklearn(Scikit-learn)是Python语言中广泛使用的机器学习模块,提供多种数据处理和建模功能。它简化了数据清洗、特征提取、模型构建、验证与优化等流程,是数据科学项目中的常用工具。 三、逻辑回归模型 逻辑回归是一种常用于分类任务的线性模型,特别适用于二类问题。在信用评估中,该模型可用于判断借款人是否可能违约。其通过逻辑函数将输出映射为0到1之间的概率值,从而表示违约的可能性。 四、支持向量机模型 支持向量机是一种用于监督学习的算法,适用于数据维度高、样本量小的情况。在信用分析中,该方法能够通过寻找最佳分割面,区分违约与非违约客户。通过选用不同核函数,可应对复杂的非线性关系,提升预测精度。 五、数据预处理步骤 在建模前,需对原始数据进行清理与转换,包括处理缺失值、识别异常点、标准化数值、筛选有效特征等。对于信用评分,常见的输入变量包括收入水平、负债比例、信用历史记录、职业稳定性等。预处理有助于减少噪声干扰,增强模型的适应性。 六、模型构建与验证 借助Sklearn,可以将数据集划分为训练集和测试集,并通过交叉验证调整参数以提升模型性能。常用评估指标包括准确率、召回率、F1值以及AUC-ROC曲线。在处理不平衡数据时,更应关注模型的召回率与特异性。 七、集成学习方法 为提升模型预测能力,可采用集成策略,如结合多个模型的预测结果。这有助于降低单一模型的偏差与方差,增强整体预测的稳定性与准确性。 综上,基于机器学习的信用评估系统可通过Sklearn中的多种算法,结合合理的数据处理与模型优化,实现对借款人信用状况的精准判断。在实际应用中,需持续调整模型以适应市场变化,保障预测结果的长期有效性。 资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
<think>我们被要求计算2015-07-18到2015-07-28期间,每天每个用户去重后的平均浏览量。 注意:这里要求的是每个用户每天只算一次浏览(即去重),然后计算整个时间段内,所有用户每天的平均浏览量(即平均每天每个用户浏览多少次?) 但是注意:问题要求的是“每天每个用户去重后的平均浏览量”,这里有两种理解: 1. 先计算每个用户每天的去重浏览量(即每天每个用户算一次浏览),然后在整个时间段内,对每个用户求其每天浏览量的平均值(按用户平均)。 2. 或者,先计算每天的总独立用户数(即每天有多少不同的用户浏览),然后计算这些天每天独立用户数的平均值(按天平均)。 然而,问题描述是:“每天每个用户去重后的平均浏览量”,并且要求的是“平均浏览量”,这里我们需要注意: 实际上,问题要求的是:在整个时间段内,平均每个用户每天浏览多少次?但是注意,这里每天每个用户只算一次浏览(去重)。 但是,问题要求的是“平均浏览量”,所以应该是先计算每个用户在整个时间段内浏览的天数(即这个用户在这段时间内有几天有浏览行为),然后求所有用户的平均浏览天数?或者? 重新阅读问题:“提取指定时间段内每天每个用户去重后的平均浏览量” 更合理的解释是:我们要求的是,在给定的时间段(2015-07-18至2015-07-28)内,平均每天每个用户浏览的次数(但注意,每天每个用户只算一次浏览,所以实际上是平均每天每个用户浏览了1次?这个理解不对)。 实际上,我们通常所说的“平均浏览量”是指平均每个用户浏览了多少次。但是这里要求每天每个用户去重,所以每天一个用户最多算一次。 因此,我们需要计算: 总浏览量(去重后) = 在时间段内,每个用户每天出现浏览行为就算一次,那么总次数就是所有用户在这段时间内浏览的天数之和。 然后,我们有两种平均方式: a. 按用户平均:总浏览量(去重后)除以总用户数(这段时间内至少浏览过一次的用户)?或者除以所有用户(包括没有浏览的?)但一般我们只考虑有行为的用户。 b. 按天平均:总浏览量(去重后)除以总天数(11天),得到平均每天的独立用户浏览总量,然后再除以用户数?还是直接就是平均每天独立用户数? 但是问题要求的是“平均浏览量”,并且是“每天每个用户去重后的”,所以应该是按用户平均,即每个用户平均每天浏览多少天?也就是每个用户在这段时间内平均有几天进行了浏览。 所以,具体步骤: 1. 先计算每个用户在这段时间内浏览的天数(每天去重,所以一个用户一天只算一次,然后统计这个用户在这段时间内一共有多少天有浏览)。 2. 然后,对所有用户的浏览天数求平均值,即平均每个用户浏览了多少天。 但是,问题描述为“平均浏览量”,而这里我们计算的是平均浏览天数,因为去重后每天只算一次,所以也可以理解为平均每个用户的总浏览次数(因为一天一次)除以总天数?不对,注意我们要求的是平均浏览量,而且已经去重了。 另一种理解:我们要求的是平均每天每个用户浏览的次数(去重后,每天最多一次),那么结果应该是:平均每天每个用户浏览的次数(在0和1之间)。但是这样计算的话,我们可以: 先计算每天独立用户数(即每天有多少不同的用户浏览),然后求这些天每天独立用户数的平均值,再除以总用户数?不对,应该是先计算每天独立用户数的总和,然后除以天数再除以用户数?这样得到的是平均每天每个用户浏览的概率。 然而,问题要求的是“平均浏览量”,所以应该是每个用户平均的浏览次数(按用户平均)。我们按照以下步骤: 步骤1:先获得每个用户的浏览天数(即该用户在2015-07-18到2015-07-28之间,有多少天有浏览行为) 步骤2:计算这些浏览天数的平均值(按用户平均) 但是注意:我们只考虑有浏览行为的用户?还是考虑所有用户?问题没有明确,但通常在这种分析中,我们考虑的是有浏览行为的用户。不过,问题要求的是“每天每个用户去重后的平均浏览量”,这里“用户”可能指的是所有用户(包括没有浏览的),但这样会导致很多0,所以需要明确。 根据问题描述,我们只考虑有浏览行为的用户?还是整个用户群?问题没有指定用户范围。因此,我们需要明确: 如果问题要求的是所有用户(包括没有浏览的)的平均,那么我们需要知道用户总数(来自用户表),但问题中只有user_behaviors表,所以如果没有用户表,我们只能计算有浏览行为的用户。 但是,问题要求的是“用户付款数量”等,但这里我们只要求浏览量,所以我们可以从行为表中获取用户。注意:行为表中可能只包含有行为的用户,没有行为的用户不会出现。 因此,我们只能计算有浏览行为的用户的平均浏览天数。 所以,SQL步骤: 1. 筛选浏览行为(action_type='View')且时间在2015-07-18到2015-07-28之间的记录。 2. 按用户和日期分组(因为每天每个用户去重,所以按用户和日期分组,每个组算一次浏览)。 3. 然后按用户分组,计算每个用户的浏览天数(即按用户分组,统计不同的日期数)。 4. 最后计算这些浏览天数的平均值。 但是,问题要求的是“平均浏览量”,而这里我们计算的是每个用户的平均浏览天数(即平均每个用户浏览了多少天)。由于每天只算一次,所以这个浏览天数就是浏览次数(去重后)。 因此,SQL如下: ```sql SELECT AVG(views_per_user) AS avg_views_per_user FROM ( SELECT user_id, COUNT(DISTINCT DATE(action_time)) AS views_per_user -- 每个用户浏览的天数(即去重后的浏览次数) FROM user_behaviors WHERE action_type = 'View' AND action_time BETWEEN '2015-07-18' AND '2015-07-28' -- 注意:包括两天的边界 GROUP BY user_id ) AS user_views; ``` 然而,这个查询计算的是每个用户在这段时间内平均浏览了多少天(即平均每个用户有几天进行了浏览)。这个结果是一个数值,表示平均每个用户的浏览天数。 但是,问题要求的是“平均浏览量”,而这里我们计算的是平均浏览天数,由于去重后每天只算一次浏览,所以这个浏览天数就是浏览次数(去重后)。因此,这个数值就是平均每个用户的总浏览次数(去重后)。 另一种理解:问题可能要求的是平均每天的独立用户数?但问题描述是“每天每个用户去重后的平均浏览量”,所以更倾向于按用户平均。 注意:问题要求的是“平均浏览量”,并没有明确是按天平均还是按用户平均。但是,从“每天每个用户去重”这个条件来看,我们计算的是每个用户的总浏览次数(按天去重),然后求所有用户的平均。 所以,上述查询是合理的。 但是,如果我们要求的是平均每天每个用户的浏览量(去重后),那么计算方式不同: 总浏览次数(去重后)= 这段时间内,每天独立用户数的总和(即把每天独立用户数相加) 然后,平均每天每个用户的浏览量 = 总浏览次数(去重后) / (天数 * 总用户数) ? 或者,平均每天每个用户的浏览量 = 总浏览次数(去重后) / 天数 得到平均每天的总独立用户数,然后再除以总用户数,得到平均每天每个用户浏览的概率(0~1之间)? 然而,问题要求的是“平均浏览量”,而浏览量通常是一个次数,所以可能是第一种理解(每个用户平均的总浏览次数)更合理。 考虑到问题描述为“每天每个用户去重后的平均浏览量”,我们更倾向于第一种理解:即先按用户和日期去重,然后计算每个用户的浏览天数(即该用户的总浏览次数),再求所有用户的平均值。 因此,我们使用上述查询。 但是,如果要求的是平均每天的独立用户数,那么查询应该是: ```sql SELECT AVG(daily_users) AS avg_daily_views FROM ( SELECT DATE(action_time) AS day, COUNT(DISTINCT user_id) AS daily_users FROM user_behaviors WHERE action_type = 'View' AND action_time BETWEEN '2015-07-18' AND '2015-07-28' GROUP BY day ) AS daily_views; ``` 这个查询计算的是平均每天的独立用户数(即平均每天有多少不同的用户浏览)。 现在,我们需要明确问题中的“平均浏览量”是指什么。由于问题中提到了“每天每个用户多次浏览只计算一次”,所以这里“浏览量”是指去重后的浏览次数。因此,第一种理解(按用户平均)更符合“每个用户”的表述。 所以,我们选择第一种方式:计算每个用户在这段时间内的浏览天数(即去重后的总浏览次数),然后求平均值。 但是,为了确保清晰,我们可以将问题拆解为两个指标,并分别给出解释。不过,根据问题描述,我们按照第一种方式。 最终SQL: ```sql -- 计算每个用户平均浏览天数(即平均每个用户在这段时间内浏览了多少天) SELECT AVG(views_per_user) AS avg_views_per_user FROM ( SELECT user_id, COUNT(DISTINCT DATE(action_time)) AS views_per_user FROM user_behaviors WHERE action_type = 'View' AND action_time >= '2015-07-18' AND action_time < '2015-07-29' -- 使用左闭右开,确保包含28号全天 GROUP BY user_id ) AS user_views; ``` 注意:时间范围的处理,我们使用`action_time >= '2015-07-18' AND action_time < '2015-07-29'`,这样包含7月18日到7月28日全天(假设action_time是datetime类型)。 如果action_time是DATE类型,那么可以直接用BETWEEN,但如果是DATETIME,用BETWEEN '2015-07-18 00:00:00' AND '2015-07-28 23:59:59'可能会有边界问题(比如23:59:59.5就漏掉了),所以用左闭右开更安全。 因此,我们使用`action_time >= '2015-07-18' AND action_time < '2015-07-29'`。 但是,问题中的表结构没有明确action_time的类型,所以按DATETIME处理。 另外,如果数据量很大,我们可以考虑在action_time和action_type上建立索引。 现在,我们输出这个SQL。</think>### SQL查询:计算2015-07-18至2015-07-28期间每天每个用户去重后的平均浏览量 ```sql SELECT AVG(daily_views) AS avg_daily_views_per_user FROM ( SELECT user_id, COUNT(DISTINCT DATE(action_time)) AS daily_views -- 计算每个用户每天去重后的浏览天数 FROM user_behaviors WHERE action_type = 'View' -- 筛选浏览行为 AND action_time >= '2015-07-18' AND action_time < '2015-07-29' -- 包含7月18日至28日 GROUP BY user_id -- 按用户分组 ) AS user_daily_views; ``` #### 关键逻辑说明: 1. **数据筛选** `WHERE action_type = 'View'`:仅处理浏览行为记录 `action_time >= '2015-07-18' AND action_time < '2015-07-29'`:精确包含7月18日00:00至28日23:59的数据 2. **用户每日去重** `COUNT(DISTINCT DATE(action_time))`:计算每个用户**浏览过的不同天数**(同一天多次浏览只计1次)[^1] 3. **平均值计算** 内层查询计算每个用户的浏览天数 → 外层`AVG()`求所有用户的平均值 最终结果表示:**平均每个用户在这11天中有几天进行了浏览** #### 示例结果: | avg_daily_views_per_user | |--------------------------| | 4.27 | > 解释:平均每个用户在2015-07-18至28期间有4.27天进行了浏览(最高值11表示天天浏览) --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值